Re: [Gmod-ajax] rendered larger chromsome

[Mitch S. <mit...@be...>]

Ian Holmes wrote:
> i suspect that other people (probably some on this list, or the other 
> GMOD lists) have thought quite hard about this kind of issue 
> (collapsing features, density thresholds, etc) and we'd benefit from 
> consulting with them.

Well, the GBrowse code that we're using certainly has facilities for 
dealing with high feature densities; right now the generate-tiles.pl 
code for turning off labels looks like this:

            # if the average number of features per tile is
            # less than $feature_thresh, we print labels
            if (($#features  / $num_tiles) < $feature_thresh) {
                $track->configure(-bump => 1, -label => 1, -description 
=> 1);
            } else {
                $track->configure(-bump => 1, -label => 0, -description 
=> 0);
            }

where $feature_thresh is set using the new -f command line option 
(default: 50, which is what I used to render 3R).

We could certainly add a second threshold above which we turn off 
bumping; I'm not a big fan of the non-bumped view since I don't think 
it's as useful as a density plot but I'd certainly be interested in 
hearing arguments for it.  Glyph also has a bump_limit option that I 
should try out at some point.

Right now this is how flybase deals with dense views:
====
/Detailed view is limited to 1 Mbp. Click in the overview to select a 
region 20 kbp wide.
/====
so we're not covering terribly heavily trodden ground by exploring 
different alternatives.

This ties in with what Andrew said:
> Yeah, we definately need some sort of heuristic where we compact
> features above some threshold.  Suzi's suggestion to turn them into a
> feature density plot or some such was a good idea, but would require a
> bit of work... maybe for now we can just drop the smaller features
> out, or turn them off completely (e.g. how GBrowse stops displaying
> features above the 1MB zoom level) or do something smarter than that,
> where we have a "max track height" above which feature display would
> shut off. 

I'm not too concerned with the amount of graphical space that the 
features take up (especially since it's easy to turn tracks on and off), 
although I guess that as we try to do larger chromosomes the 
entire_landmark zoom level will start to get quite tall.  The main 
problem in my view is the number of imagemap regions that get created 
for dense tracks.  Even if we load feature info lazily there's a minimum 
bound on the size of the html required to define those imagemap 
regions.  And the browser starts to have problems when we create large 
numbers of them.

If we turn off the HTML above some threshold then those problems goes 
away.  IMO the question is whether or not the graphical view is useful 
even when you can't click on things, and I think the answer is "yes", 
but it would be confusing for the user to be able to click on features 
at some zoom levels but not others.

Mitch