Re: [Gmod-ajax] Simile::Timeline

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

On 1/30/07, Hilmar Lapp <hl...@gm...> wrote:

[snip]

> As Mitch's experiments seem to suggest (or my admittedly limited
> understanding of it) though, the rendering approach may still be
> overwhelmed by the number of DIVs to handle in the DOM for a genome
> browser with multiple tracks and dense single-base features?
>
>         -hilmar

Yeah... an experiment definately should be done where you draw a plot
using single-pixel divs (or whatever JS libraries like Canvas use), or
use SVG or VML or whatever to generate tracks like "% conserved" or "%
GC", and then try to drag it.  Seth has claimed good results with JS
rendering many features using Canvas, but I wonder how dragging will
be affected.

There have been a few arguments against this kind of rich
client-intensive rendering (mainly, it adds a lot of complexities, but
do the benefits/features gained justify it?).  There is a good reason
for it in ONE case, though: I think Mitch mentioned this earlier, but
Suzie Lewis said that toggling between a frequency plot and a box plot
is a desired feature.  That is, let's say you have a track plotting GC
content - and you can toggle that track to display all regions above,
say, 50% GC content in box form instead (the threshold would be
arbitrary, of course).  The client would therefore have to know the
values at each X-coord of the plot, so that it could filter out
everything about the threshold and display it as boxes, without
involving the server in this decision-making... or maybe this is
getting too complicated?

To relate this to our lab's work, I can see this being useful in
genome screens for example.  Let's say you have a method which assigns
to each nucleotide (or window) a probability that it is in a gene or
any feature (e.g. in a ncRNA).  Now I want to select all predictions
with P > 0.9 and eyeball the distribution.  I would certainly use
this.

Going in the reverse fashion - from a box feature display to a density
plot - is also good.  If I'm looking at the whole chromosome on a
single screen, GBrowse will currently filter and display only the
largest features... but info about small features would be lost.  If I
saw a feature density plot, I could get insight about how they are
distributed on the chromosome, which is more useful than having small
features drop out when zooming out.  THIS component is something that
the server would have to do, as it is impossible to send a
chromosome's worth of features to the client and have it figure out
these things, as JS has too much overhead.


Andrew