Re: [Gmod-ajax] Openlazlo

[Steve T. <st...@mo...>]

Hi Mitch,
> On Fri, 2007-06-01 at 10:32 -0400, Michele Clamp wrote: 
> 
>>What's a div?
> 
> 
> This may be overkill for answering a simple question, but it's a good
> jumping off point for me to try and justify this approach.
> 
> A div is a plain-vanilla HTML element; it's just a rectangle that you
> can position, style (change the background color/image, border
> properties, etc.), and put stuff in.
> 
> Since features are often represented in genome browsers by rectangles, I
> think divs are a pretty good fit for displaying them.  Like with
> Simile::Timeline, there's a single axis (time for them, reference
> sequence for us) along which we want to represent start/stop information
> (events for them, features for us).  So most of the time a rectangle is
> enough.

There are an increasing number of biological techniques that are producing genome wide quantitative data that require graph like visualisation, such as array intensities and ChIP-on-chip. While 
graphs/plots *can* be broken down into rectangles how do think the div method will cope with the increased amounts of elements required?

Regards,

Steve



> 
> So in this context a div is a way of getting a web browser to draw
> features on its own, rather than having the server draw features into an
> image and send the image to the web browser.  Having the web browser
> draw things gives us the flexibility to do lots of interesting things on
> the client side.  Zooming with divs is sort of my pet example, but you
> could also do things like directly edit features (i.e., click and drag
> to adjust feature boundaries or create new features).
> 
> I think a lot of people consider SVG the Right Way of having a web
> browser draw things, and it's true that divs are extremely limited in
> comparison, but if you're dealing with things that live on a 1-d axis
> then divs aren't so bad.  And I think people generally underestimate
> what divs can do:
> http://genome.biowiki.org/test/divbrowser/genome.html
> 
> My concern with SVG is that it's less consistently implemented in web
> browsers.  IE doesn't have it at all, though it does have its own vector
> drawing language (VML).  Some people are trying to make javascript
> libraries that hide the differences between SVG and VML, but when I
> looked they were relatively immature and limited in functionality, and
> the ones I looked at presented an immediate-mode API ("draw a line from
> here to here") on top of a retained-mode system ("there's a line from
> here to here; remember it and draw it") which I think is backwards.
> 
> Maybe at some point SVG and/or VML will be the way to go; if we decide
> to go in that direction we don't have to start from scratch.  The server
> side can be exactly the same as with divs, and a lot of the client side
> should also be the same.
> 
> I also think a lot of people see divs as being relatively large
> heavyweight containers of things, rather than graphical elements in
> their own right, so relatively few people have done things like
> Simile::Timeline where the position/size of a div is used to convey
> information.  And it's true, divs are fairly heavy, but they're
> implemented in C++ and the browser writers put a fair amount of effort
> into making them fast.  I think we've recently gotten to the point where
> cheap, widespread hardware can use divs to do animation in real time.
> And going forward I think the browser implementors are going to be
> giving more consideration to this use case.
>