RE: GTK+ 2 speed

["Robert Thorpe" <Robert Thorpe antenova com>]

> -----Original Message-----
> From: gtk-list-bounces gnome org 
> [mailto:gtk-list-bounces gnome org] On Behalf Of Clemens Eisserer
> Sent: 31 July 2005 21:28
> To: gtk-list gnome org
> Subject: Re: GTK+ 2 speed
> 
> > You're right, I went back and fiddled with my system a lot.  The 
> > redraw is slow on that particular operation because of some 
> aspect X 
> > not because of GTK+ (or GNOME).
> 
> Well this really depends.

I was referring to a very specific problem, moving from the console to X
with Alt-Ctrl-F7.
What I meant was it doesn't seem to depend, most of the delay seems to
lie with X.  It takes equally long when displaying anything, even TWM
just showing a clock.  So, this particular delay (that I'm seeing at
least on my machine) isn't a GTK+ issue.

> Windows does some (cheap) sort of 
> composition, so when moving windows arround the application 
> itself is not forced to redraw its components - so this is 
> simply not fair when comparing windows with X-based toolkits.

It doesn't do an awful lot.  If you drag a window by the bar at its top
across the screen then it doesn't ask the app to redraw it.  If you
resize the edge of a window, or in any way write over what's on it, then
by default the app redraws it.

> If you use X with a composition manager (xcompmgr -a) it 
> shows equal moving performance to windows.

I'll have to try that.  I assume this is something like using "startx
+bs -wm"

> However there ARE X-Toolkits which handle redraws much 
> better/faster than GTK on X, so X is no excuse for GTKs 
> slowness, especially if you keep in mind that font-operations 
> on client-side fonts are almost free and the 
> primitive-rendering throughput of X is quite good.

I can certainly see the reasons for some of the slownesses (and the one
I blamed GTK for above wasn't it's fault), but not all of them.