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