Re: Slow canvas performance

[Soeren Sandmann <sandmann daimi au dk>]

Rob Clack <rnc sanger ac uk> writes:

> I thought that if what I was drawing was outside the viewable area (ie
> the canvas is bigger than the scrolled window) then it wouldn't even
> try to draw the squares, but that doesn't seem to be the case.  eg if
> the window can show, say, 1000 squares and I run 3 tests, drawing
> 1000, 2000 and 3000 squares respectively, I'd expect them to take the
> same time to run, since the extra squares should simply be cropped
> before the display was rendered on the screen.  This is not the case.
> The time taken increases linearly.  I thought that was the whole point
> of double-buffering.
>
> Have I misunderstood how this is supposed to work or is there some
> setting I've got wrong that disables that aspect?  Or is there a
> better way for me to set about this?

In addition to what Jody said (which is good advice), you might look
into organising the squares in a tree use FooCanvasGroup.

When Gnome/FooCanvas is asked to redraw itself and it contains tens of
thousands squares, it has to do

        for each item
                if (item is visble)
                        draw item

so drawing performance will only improve marginally when many items
are invisible because they still have to be checked for visibility.

If you organize the data into a tree of CanvasGroups you allow the
canvas to skip entire groups of invisible squares. The exact structure
of the rectangles would depend on your applicatoin -- it could be
arbitrary if there isn't a natural tree structure.

You could argue that the canvas should sort the items by coordinate
automatically, and I'd agree with you. Unfortunately it doesn't do
that.

Søren