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 _______________________________________________ Performance-list mailing list Performance-list@gnome.org http://mail.gnome.org/mailman/listinfo/performance-list
