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

[Federico Mena Quintero <federico nuclecu unam mx>]

>  I can definitely see this sort of requirement coming up again and again.
>  Is there a good general solution that can be suggested?

The main question here is, what is a "general solution?" :-)

There are two separate issues when having Many(tm) objects in the
canvas:

	1. Memory usage.  The base GnomeCanvasItem uses 60 bytes on a
           386.  GnomeCanvasRect uses 144 bytes.  I can do a few
	   things to make canvas items leaner, but that won't be a
	   lot.

	2. Performance.  The canvas lets you use groups to do
           efficient hierarchical bounding.  If you place all your
           objects directly under the toplevel group, though, you may
           have some redraw/repick performance issues.  This would
           require *lots* of objects, and is generally not a problem.

I do want something about (1).  The addition of libart support into
the canvas did make it a bit more memory-hungry, but not much.  I need
to do some things to canvas items (sharing GCs, etc.) that will make
them leaner.  Adding support for "cloned" canvas items is an
interesting possibility, but that's a bigger project.

I don't think (2) is an issue for now.  Applications with very
shallow/wide hierarchies of objects should use their own custom items,
anyway.  Applications with deep hierarchies of items will generally
not have problems (think of a circuit editor).

  Federico