Re: Canvas redraw priority / speed

[Federico Mena Quintero <federico ximian com>]

On Fri, 2002-08-23 at 07:31, ERDI Gergo wrote:

> To try this, I'll need one more bit of info: what priority should the
> signal-queuing (see original mail) be running at, for use with a
> GDK_PRIORITY_REDRAW canvas?

I am fixing the following things in the canvas right now:

1. Make it process expose events by decomposing event->region, rather
than using the overly wasteful event->area.

2. Making it use an update priority higher than the GDK redraw priority.

3. Making it generate all the temporary redraw pixmaps first and then
paint them one after another, to reduce tearing.

This stuff should be in CVS in a few hours.

As for your queueing scheme, you should make your idle handler run at a
higher priority than the canvas's, but probably lower than
GDK_PRIORITY_EVENTS.

The stock items in the non-AA canvas seem to be slower on my machine
(no-frills Neomagic X server) than the AA items because a)
GnomeCanvasShape is fantastically stupid, and b) GnomeCanvasShape is
fantastically stupid.  And then there are things like
gnome-canvas-util.c:gnome_canvas_item_request_redraw_svp() which for no
good reason requests a redraw of the item's whole bounding box for the
non-AA case, but the smaller UTA region on the AA case...  this needs to
be fixed at some point.

  Federico
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers