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

[Lincoln Stein]

Hi,

I like the approach you're taking (creating a fake GD object that stores the
graphics primitives). Perhaps the best thing to do is to subclass Panel
itself so that it doesn't draw the gridlines (or turn gridlines off
completely). Then you can draw gridlines after the fact in each tile as
needed.

Lincoln

On 2/7/07, Mitch Skinner <mitch_skinner at berkeley.edu> wrote:
>
> 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
>



-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
(516) 367-8380 (voice)
(516) 367-8389 (fax)
FOR URGENT MESSAGES & SCHEDULING,
PLEASE CONTACT MY ASSISTANT,
SANDRA MICHELSEN, AT michelse at cshl.edu