Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

There was a problem

You must be a member of this account.

Arrowheads are outside feature boundaries

#54

When using className: transcript and arrowheadClass: transcript-arrowhead, the arrowheads are drawn as being outside the bounds of the feature. This leads to incorrect rendering of features - the attached image shows two features that have identical coordinates on opposite strands, but the position of the arrowheads makes that look like that is not the case.

If there's a different way to render these please let me know; I didn't see one in my first readthrough of the available facilities.

Thank you,
--bob

Reported by Robert Olson · March 17th, 2010 @ 02:11 PM

State: new
Milestone: none
Assigned to: Mitch Mitch

Activity

  1. Mitch
    Mitch

    Thanks for the bug report. I confess I've always thought of arrowheads as being outside of the feature bounds, on the grounds that the arrowhead width is a fixed number of pixels, and when you're zoomed out, the feature size in pixels may be smaller than the arrowhead size.

    I talked to Ian about it, and we started a discussion on the gmod-ajax list (where JBrowse is usually discussed) and so far it seems inconclusive:
    http://sourceforge.net/mailarchive/forum.php?thread_name=4BA27CC9.7...

    In particular, I looked at GBrowse and it looks like it depends on the glyph: the transcript glyph looks like it draws the arrowheads outside of the features, while the transcript2 glyph draws the arrowhead as part of the feature unless the feature is narrower than the arrowhead, in which case it draws the arrowhead outside the feature.

    Maybe there's some way to make new graphics for the transcript class and the arrowhead to visually emphasize that the arrowhead is outside of the feature bounds? When I originally drew those I tried to come up with something and I didn't, but I'm not super skilled with visual design.

    March 19th, 2010 @ 06:20 PM

  2. Robert Olson
    Robert Olson

    Hi --

    Thank you for the quick reply.

    I actually figured out a fix for this that met my desires:

    +++ FeatureTrack.js 2010-03-18 14:43:10.927831215 -0500 @@ -390,13 +390,16 @@

            switch (feature[strand]) {
            case 1:
                ah.className = "plus-" + curTrack.arrowheadClass;
    
    •          ah.style.cssText = "left: 100%; top: 0px;";
      
    •          // ah.style.cssText = "left: 100%; top: 0px;";
      
    •         var pct = Math.round(100.5 - 100 * (curTrack.plusArrowWidth)  / (scale * (feature[end] - feature[start])));
      
    •          ah.style.cssText = "left: " + pct + "%; top: 0px;";
              featDiv.appendChild(ah);
              break;
          case -1:
              ah.className = "minus-" + curTrack.arrowheadClass;
      
    •          ah.style.cssText = "left: " + (-curTrack.minusArrowWidth)
      
    •                                 + "px; top: 0px;";
      
    •          //ah.style.cssText = "left: " + (-curTrack.minusArrowWidth)
      
    •         // + "px; top: 0px;";
      
    •          ah.style.cssText = "left: 0px; top: 0px;";
              featDiv.appendChild(ah);
              break;
          }
      

    Regarding the zoomed-out issue; you seem to solve that anyway by flipping the rendering to something different when you zoom out far enough. If the arrowheads were an issue you could drop them when the scale is out far enough (at those scales you can't see the internal glyph details to really tell the direction anyway.

    --bob

    March 22nd, 2010 @ 09:10 AM

  3. Robert Olson
    Robert Olson

    Wow, that got mangled. attaching the patch instead.

    March 22nd, 2010 @ 09:12 AM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.