> -----Original Message----- > From: gtk-list-bounces@xxxxxxxxx > [mailto:gtk-list-bounces@xxxxxxxxx] On Behalf Of Clemens Eisserer > Sent: 31 July 2005 21:28 > To: gtk-list@xxxxxxxxx > 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. _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
