Re: Gtk performance issues from a user's point of view

[Adalbert Dawid <dawid rinux net>]

Hi Eero,

Am Fri, 29 Sep 2006 09:48:31 +0300 schrieb Eero Tamminen:

> Hi,
> 
> ext Adalbert Dawid wrote:
>> Both things are getting much worse, when the visible part of the
>> GtkTreeView is pretty large, which is often the case on today's hi-res
>> screens...
>> 
>> 2. Resizing of GTK windows is slow. This effect, too, is getting worse
>> the bigger the resized window is. It is very interesting to see, that a
>> really small (say, 200*200 pixels) window can be resized pretty smoothly,
>> even if it is full of widgets that need to be layouted. Another
>> observation is, that even an empty GTK window (i.e. one with a plain grey
>> backgroud and no widgets) repaints really slowly when you resize it on a
>> screen with high resolution and drag it large.
>> 
>> This indicates that not the layouting of the widgets, but the actual
>> painting costs most of the CPU cycles and that these costs directly
>> correlate with the size of the drawing area. I could not observe such a
>> correlation between the drawing area size and the "redraw-slowness" on
>> other platforms, like Win or KDE, so I conclude that "there must be
>> something wrong" in GTK's drawing code. You can clearly see how slow GTK's
>> repaints are, when you use it together with compiz and try to resize a
>> window in synchronized mode...
> 
> If you're using compiz, i.e. composited windows with shadows etc,
> Windows (XP) is not really comparable, you should be comparing the
> speed to (similarly HW accelerated) Windows Vista or to KDE which also
> uses a composite manager (or window manager with builtin composite
> manager).  AFAIK composited windows have a double buffer (i.e. large
> OpenGL texture) at the X server side which needs to be re-created each
> time the window size changes (in addition to buffering that is done to
> get flicker-free drawing at the X client side).

I wasn't comparing Gnome/Compiz to WinXP, but just wanted to provide a
good example where GTK's slow repaints get clearly noticeable. If the slow
window resizing with Compiz is not the fault of GTK, then this example was
probably a bad one...

Nevertheless, if you compare plain Gnome/Metacity to Win{2000,XP} then it
gets pretty obvious that the latter clearly outperforms the former when it
comes to redrawing speed. I know that this is not really dramatic, as
Gnome is already usable as it is (and it has probably never been the
primary goal of the GTK hackers to outperform anyone speed-wise). I just
wanted to point out that
a) resizing of GTK windows is still an area with improvement potential
b) it seems to get *much* worse when large areas are repainted.
The second point is the one that makes me hope that there is something
fundamentally wrong with GTK's drawing code.

For example, if you create a GTK window and populate it with a single
GtkButton (which will resize along when one resizes the window). Now
select the "classic" GTK theme, so that the button is just a flat, grey
area. No gradients, no further calculations should be necessary when the
button gets bigger. Now resize the window and you will notice that the
repaints get *much* slower when the window (and the embedded button) gets
large. But why is that? The button is only a flat grey area, so one would
expect that it can be drawn equally fast, independently of it's size.

I hope, that makes my thoughts clearer now.

Adalbert

> 
> 
> 	- Eero