Re: control-center 2.13.90 released

[Federico Mena Quintero <federico ximian com>]

On Tue, 2006-01-31 at 15:08 -0500, Rodney Dawes wrote:

> Profiling the capplet won't help at all. It's not actually doing any of
> the drawing on the desktop. Someone needs to profile nautilus and/or the
> gnome-settings-daemon processes. These are the places where the drawing
> happens. Albeit much faster without nautilus running, it could probably
> still stand to see a little bit of improvement. A quick test by quickly
> changing some background images on my old Powerbook G3 (400 w/192 MB
> RAM, on OS 10.2), showed that it still seemd a bit faster than we are,
> even without nautilus managing the desktop.

Okay, so let's profile all the parts involved to see where the problem
is.

Can you build the whole gnome-control-center module with no inlining and
debug info (-O2 -fno-inline works well), and then run sysprof while
changing backgrounds quickly?

Do that with and without nautilus running.

As far as I know, we have two main slow paths:

1. Nautilus redrawing its background.  It doesn't do anything special;
it just sets the desktop window's background to the pixmap that g-s-d
maintains; then it does gtk_widget_queue_draw() on the desktop window.
This goes through the normal double-buffering code in GTK+.  The test
code here does exactly what Nautilus does:
	https://bugs.freedesktop.org/show_bug.cgi?id=4320#c3

2. G-s-d generating a new background pixmap.  This is the
create-a-pixmap, paint-a-gradient, scale-an-image thing.  No idea if
this is slow, but it certainly doesn't need to be.  

Running sysprof on the whole stack will tell you who is at fault.

It would be good to know how much time (2) takes.  Stick printf()s at
the beginning and end of the "change-the-background" process in g-s-d,
and make them print timestamps.

  Federico