Gtk performance issues from a user's point of view

[Adalbert Dawid <dawid rinux net>]

Hello Hackers,

I don't know if this list is the right place to write to, but as the topic
of this posting is performance, I'll just have a try.

In the first place, I'd like to thank all of you for investing your
(spare) time and making Gnome/GTK improve from release to release.
Especially, there were many efforts to improve Gnome performance-wise in
the near past, but still I can see some areas where GTK clearly
could/should improve with respect to its speed. IMHO the speed of a
desktop is even more important than its memory consumption, because many
users (especially those switching from windows) expect high responsiveness
of their applications, as this is what they know from their experience
(and, IMO, windows has *really* fast graphics redraws on the desktop --
faster than Mac, KDE or GTK). Then, when they switch from Win32 to Gnome,
they (in some areas) *feel* that the Gnome desktop is somehow slower and
so they might think that it's badly programmed because of that.

I am aware of the latest developments and improvements (e.g. the
GTK-engine torturer) but I think I found at least two problematic areas in
GTK, which, IMO, still demand investigation.

1. GtkTreeView's repaints are slow. This gets especially obvious, when you
perform one of the actions below:
 * Resize a column (i.e. change its width). You will notice that the
   header is badly lagging behind the mouse pointer, which gets worse as
   one enlarges the viewport.
 * Drag an icon from the Desktop over a big nautilus window with many
   files and directories in the list view mode. When you keep moving the
   icon over nautilus, the CPU goes up to 100% and the icon leaves an ugly
   white trail.

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...

To make it clear: I don't want to criticise GTK (or its speed) as
a whole, but just point out two things that are annoying me about GTK
performance-wise. The fact that there seems to be a correlation between
size and (lack of) drawing speed (which occurs in both issues I described
above) makes me hope that there is some general mistake in GTK's drawing
core (or maybe in GDK, or maybe even in X?) that just needs to be spotted
and fixed... 

Thank you,
Adalbert