RE: Canvas limitations (was Re: Coding question, canvas)

[Havoc Pennington <hp Mcs Net>]

On Tue, 9 Feb 1999, Richard Hult wrote:
> 
> So a "grid" (dots that objects snap to) would be a candidate for an own
> canvas item? I tried putting lots of rectangles on my canvas and it's not
> exactly slow but it takes a bit of memory.
>

Look at the 'ezpaint' module in CVS, the 'EZPaste' object has a grid
(however it doesn't work right now. :-) I know how to fix it, but haven't
yet.
 
> Something that comes to mind is that it's a kind of weird object. It covers
> the whole canvas but there is a lot of space really, just some dots here and
> there. Will this cause lots of redraw requests, when objects move over the
> grid, even over the space between the dots? This seems a bit inefficient.
> 

It will but AFAIK the redraw requests will not be for the entire grid
object, just for the area the object was on previously and the area the
object is now on. Your redraw routine can be optimized to do nothing if 
there are no dots in the redraw area.

> I'm not completely clear about exactly what's involved in making a canvas
> item, so these questions may be a bit irrelevant ;)
> 
> Is there a commented example of this somewhere in the sources? Is a
> copy-and-paste-operation from the already defined canvasitems the way to go?
> 

Definitely start from an existing canvas item.

For the grid, you need to either re-use a single SVP over and over to
create each dot/line, or draw to the RGB buffer. That's whats wrong with
EZPaste, it has a giant SVP which is super-slow. 

For an example of drawing to the RGB buffer, look at
guppi2/src/libguppi/canvas-scatter.cc in CVS. (and rgbdraw.h in the same
dir).

Havoc