Re: gtk+ performance, especially as seen by the magnifier

[Soeren Sandmann <sandmann daimi au dk>]

Brian Cameron <Brian Cameron Sun COM> writes:

> 1) The magnifier is spending over half of its time in XSync.  The
>     magnifier makes calls to either gdk_window_invalidate_rect or
>     gdk_window_scroll each time it updates the screen.  In either
>     case, gdk_window_invalidate_region is called, which sets up an
>     idle handler (gdk_window_update_idle) of priority
>     GDK_PRIORITY_REDRAW.  The idle handler calls
>     gdk_window_process_all_updates, which calls gdk_flush.  The
>     XSync calls are all coming from this gdk_flush.
> 
>     Is it really necessary to call gdk_flush in all situations?

GTK+ HEAD doesn't actually synchronize with the X server anymore.

"Half the time" must of be of wall clock time, right? The time spent
in gdk_flush() is really just GTK+ waiting for the server to finish
drawing, so on a local X server on a single-CPU machine, I doubt it
would make much difference, since it wouldn't reduce the amount of
work that actually has to be done (not by much anyway).

>     So, mostly from _gdk_x11_copy_to_image and _gdk_x11_gc_new.  Is
>     there any reason why GDK needs to keep creating these?  Couldn't
>     GDK simply cache and reuse them?  If so, this would drastically
>     reduce the overall load that GDK places on the Xserver.

Yes, some form of GC caching would probably be a good idea, especially
considering that the creating of the client side GdkGC object is
fairly expensive too. The question is how much to cache exactly.


Søren