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

[Adalbert Dawid <dawid rinux net>]

Am Fri, 29 Sep 2006 12:54:11 -0500 schrieb Federico Mena Quintero:

> On Thu, 2006-09-28 at 20:13 +0200, Adalbert Dawid wrote:
> 
>> 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.
> 
> What theme engine are you running?

I have been a Gnome user for some years now (IIRC I switched to Gnome when
2.4 was released), so I had the chance to run many engines. Some of them
are slower and some are faster, but none of them feels *really* fast.

Currently I'm running (mainly) the non-cairo version of Clearlooks, which
I regard as one of the fastest engines available.

> 
> Are you running a compositing manager?  If so, which one, and which
> graphics driver do you have?

I have a Debian Etch partition (productive system) without a compositing
manager and an Ubuntu Edgy partition (for playing around) with Xgl. My
graphics card is a GeForce 5700 LE (128 MB video mem) driven by the
proprietary nvidia drivers.
In addition, I have a HP Compaq nx9005 notebook with a low-end ATI
graphics card, which has the advantage that it is very well supported by
the free radeon driver. Even AIGLX runs on it and is (nearly) usable.

Again: on some hardware GTK is a bit faster, on the other it is a bit
slower (I have the feeling that the free nv driver is even faster than the
proprietary driver from nvidia), but the slowness of GtkTreeView and of
window-resizing is omnipresent, AFAICT.

> 
> On my non-composited, Xorg Radeon setup (IBM Thinkpad T41p), I don't get
> lagging when I resize the columns in Nautilus's list view.  I get only
> minimal trailing (1 or 2 "positions") when I do drag and drop over it.
> I'm using Novell's "Gilouche" theme, which is essentially pre-Cairo
> Clearlooks.

What resolution does your Thinkpad's screen have? My observation is that
the lagging gets worse when the list contains many entries (30 should be
enough) and the visible area is high (i.e. large in vertical direction).
This tends to be the case more often on high-res screens (say, 1280x1024),
e.g. when you maximize a nautilus window.

> 
> Can you run a global profiler like sysprof to identify the culprit?
>

Unfortunately I am not really a C programmer (I do have basic knowledge,
but I mainly code in Java) and I did not run sysprof or other C-related
profiling tools before. But I think I could install sysprof and give it a
try in the next days.

> Apart from that, GtkTreeView *does* have problems.  GtkCellRendererText
> is written in a way that each repaint cycle causes it to re-layout the
> same string two or three times.  On a treeview with a lot of text, this
> is the hotspot in the profile:
> http://primates.ximian.com/~federico/news-2005-10.html#gtkfilechooser-profile-4
> 
> That doesn't look terribly hard to fix; it's just that no one has done
> it yet :)

I will have a look on that, but can't promise anything...

> 
> We need a set of benchmarks for GtkTreeView.  I'd start with comparing
> various operations (layout, column resizing, repaint, etc.) between a
> treeview with no-op cell renderers, and busy text renderers.
> 
>> 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.
> 
> Again, which theme engine, and which compositing manager?  Does your
> engine paint gradients or other exotic stuff on the otherwise plain
> window background?
> 
> With my setup, an empty window resizes quite quicly.  It is a bit slower
> when the window gets close to full-screen (1400x1050), but I can't get
> it to lag or anything.

Yes, you are right, an empty window is not so problematic. My description
was faulty, sorry for the confusion. What I really meant was exactly what
you are describing below: a single big button in a window. Then the
resizing gets really slow, even if you choose a very simple engine that
does not paint any gradients.

> It's interesting to note that if I add a single button to the window,
> then it gets noticeably slower (but it doesn't lag, either).  Then,
> Sysprof says that 69% of the time is spent in libfb/libxaa in the X
> server, not GTK+ itself.

Then, maybe X is the real bottleneck. Or GTK utilizes X drawing functions
in some inefficient way...
If the GTK engine has to paint a plain, single coloured button, then
this operation should not take any longer than drawing a plain rectangle
on the root X window (of course apart from the text on the button etc.),
should it? Otherwise there must be something that GTK is doing wrong... 

> 
>   Federico

Adalbert