[Bioperl-l] Bio::Graphics::Panel gridlines and pixels

[Mitch Skinner]

Lincoln Stein wrote:
> However, I'm also very interested in why grid-drawing takes so long. 
> When I've profiled drawing, neither grid drawing nor map_pt() consume 
> any significant amount of time.
Well, the approach that we've been taking is to hand 
Bio::Graphics::Panel a fake GD object that stores all of the graphical 
primitives (line, rectangle, filledRectangle, etc. + their parameters) 
and then draws them later in chunks (for each tile, we draw all the 
primitives that overlap its pixel boundaries).  We're doing this because 
trying to create a real GD object that's hundreds of millions of pixels 
wide takes too much RAM.  But storing all the gridlines (for a whole 
chromosome, at a high zoom level) also takes a lot of RAM, and getting 
the gridlines for the current tile and translating their coordinates 
into the coordinate space of the tile also takes a fair amount of CPU.  
The gridline hack I've been experimenting with (that prompted these 
emails) was motivated by the hope that the gridlines were regular enough 
that we wouldn't have to store them explicitly, but just draw the same 
gridlines over and over again.  It runs almost twice as fast as the 
version that explicitly stores the gridlines.

So the main slowdown is not in draw_grid or map_pt, but in our code 
that's storing/retrieving and translating the gridlines.  Which we are 
also looking into speeding up.  But the memory usage is harder to 
reduce; I've experimented with trying to compress the gridline data but 
it seems easier to just have the panel draw the grid directly.

The more I read the Panel code, the more I think it would be nice to 
make more use of it.  One of the reasons that we're trying to fool it 
right now is that there seem to be a number of behaviors in it (and/or 
in the glyphs?) that take the current image boundaries into account 
(drawing an arrow where a feature runs off the edge of the image, 
etc.).  But in our browser each tile is supposed to mesh seamlessly with 
its neighbor, so if there's an easy way to turn off those edge-aware 
behaviors that would be pretty interesting.

Ian has also suggested that it might be better to store less information 
than the full set of graphics primitives.  For example, we could just 
store the Panel's glyph boxes and use their (pixel bound)->feature 
information to decide which features need to be drawn for each tile.

I'm going to be spending some time reading the Bio::Graphics code in 
more depth.  I'd also welcome suggestions from you or anyone on the list.

Thanks,
Mitch