Re: [Gmod-ajax] Simile::Timeline

[Mitchell S. <mi...@ar...>]

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