Re: [Gmod-ajax] Simile::Timeline

[Andrew U. <and...@gm...>]

Just to stress something... Timeline loaded ALL the "feature DIVs" for
the entire timeline, even if they were far off-screen - right?
Something like this would be difficult to do for large (or even
decently-sized chromosomes), which is the same reason for why we don't
load all the tiles at once, but rather cache only the ones close to
the current view.

We counted up something like <1000 Timeline points (each a DIV or some
sort of DOM node) yesterday, but there could easily be an order of
magnitude more features on a chromosome, especially for multiple-track
views.  I think it reasonable to assume around 10-30 tracks being open
in a genome browser, so add another order of magnitude to it.  This is
why I strongly believe that the client should NOT be aware of ALL the
features - just the local ones - and the server should filter them
down to keep feature density reasonable in situations where, for
example, you are looking at the entire chromosome in a single window.

The Timeline demo is also a good reminder that we need to have an
"Overview" track like GBrowse does, displaying the entire chromosome
and showing the user what part of it they are looking at.

Andrew

On 1/27/07, Mitchell Skinner <mi...@ar...> wrote:
> On Sat, 2007-01-27 at 18:33 -0500, Hilmar Lapp wrote:
> > Obviously, I thought if you replace the time scales with genomic
> > scales, and the temporal events with genomic features, you would
> > pretty much have an AJAX-based genome browser.
>
> I haven't seen Timeline before, thanks for the link.
>
> The boatload-of-divs approach that Timeline takes is nice because the
> client knows more about what it's displaying, so some functionality is
> easier to implement:
> * clickable features
> * hightlighting features
> * keeping labels on the screen
> * ? there's more, I'm sure
>
> The approach does have some downsides.  A large number of DOM nodes
> slows down the browser.  For me (firefox on linux) dragging in Timeline
> is quite slow, though it's unclear how much of this is due to the
> multi-res scrolling thing they're doing.  I'd be interested to see how
> (and whether) it runs in IE.  When I get a chance I'm going to spend
> some time profiling it.
>
> On the other hand, for clickable features we've got a DOM node for each
> imagemap area anyway (and the number of those is larger than the number
> of features, due to tile-spanning features), so maybe we have to pay
> that cost in any case.  Currently, we're loading those lazily, which
> must be part of the reason why our panning is faster than Timeline's.
>
> DIVs are also more limited in what they can render.  As far as I can
> tell it would be impossible to show GBrowse-style transcripts (with the
> hats) using just DIVs (actually, thinking about it some more, this could
> be done at the cost of several (4?) more DOM nodes per intron).
> However, it would be fairly straightforward to do Santa-Cruz-style
> transcripts using CSS background-repeat.  Apparently some people have
> strong opinions about how those look; would anyone here like to comment?
>
> One difference between us and Timeline is that I think we're generally
> going to be dealing with a larger number of much denser tracks.
> Especially with something like a %conserved track, you've potentially
> got a data point for each base, and there's no way you're going to send
> 300 million data points to the browser.  Again, with lazy loading this
> gets a lot easier, though dealing with different zoom levels does take
> some extra server-side work.
>
> I did a zooming experiment a while ago using DIVs to represent features;
> you can see my toy here:
> http://arctur.us/dasclient/test.html
> The approach works well in firefox but not really in IE.  That kind of
> thing is much easier to do with DIVs than with images, but I haven't
> really tried to do it with large numbers of DIVs.  And it won't zoom
> 3-million-fold without a lot of extra work (it's currently in the
> few-hundred-thousand-fold range as I recall).  But it's an example of
> the kind of thing you can do.
>
> Andrew and I are planning to do some experimenting along these lines.
> We'd like to see how much the browsers can handle before they really
> start to bog down, and how cross-browser the DIV approach is.  We'll
> also be trying out SVG and VML (and some libraries that try to abstract
> away the differences between the two).
>
> My sense is that Ian thinks that gmod-ajax feature display works "well
> enough" for now, and that search and community annotation are more
> immediate priorities.  If we can use a substantial body of Timeline's
> work, though, then it might make sense to spend some time on that.  It
> looks like they've implemented layout (bumping), and they apparently
> also have a way to render at different scales.
>
> It would be cool if the browser could just pull some DAS/2 from the
> server and do the rest itself, wouldn't it?
>
> Mitch
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>