Created attachment 8964 [details]
x11perf comparison log (7.1.1 vs. 7.2)

Hello,

Let me expand on this bug, upon request from Sebastien Bacher; I thought it may be an Ubuntu-specific problem, but there's no harm to post it upstream here.

Here's an overview of the problem:

System 1: Dell Dimension 1100 (desktop) w/Celeron 2.80GHz, Intel 82865G (disabled), NVIDIA GeForce FX 5200 PCI. Running Feisty with latest updates (xorg 7.2 with newest drivers).
System 2: Dell Inspiron 510m (laptop) w/Pentium M 1.5Ghz, Intel 82855GM. Running Feisty with latest updates (xorg 7.2 with newest drivers).

Since Feisty upgraded xorg-server to 2:1.2.0-3ubuntu1, 2D rendering has become very sluggish and choppy for certain operations, particularly minimizing & unminimizing applications in GNOME (using metacity).

Steps to reproduce:
1. Open firefox and leave its window open & maximized
2. Open a GNOME terminal window (normal size), then minimize and unminimize the window while observing its choppy animation.

As you can see, metacity's black frame appears for considerably longer than it should while minimizing, approximately 0.5-1secs on both of my testing systems (sometimes it's even slower, hence having firefox open in the background).

I am having this problem on two of my systems, using the nv driver and i810 driver respectively. I have since performed x11perf benchmarks on my system, and compared it against Feisty's Herd 4 CD - I chose this version as it is the latest testing release that uses xorg 7.1.1, which did not exhibit this slowdown.

The x11perf logs I previously attached apply to my Dimension 1100 (desktop) system using the nv drivers, I have yet to perform the same benchmarks on my laptop.

I'm also attaching more complete logs (dmesg, xorg.conf, Xorg.0.log and /proc/mtrr from Herd 4 and my installed system, equivalent to Herd 5). Some 2D operations seem perfectly snappy, and a kind of workaround was to use kwin which made things snappy again. I downgraded metacity to edgy's version, but the slowness was still present - so the sluggishness is most likely due to xorg 7.2.

Created attachment 8965 [details]
Logs & config files from comparison environments, Ubuntu Feisty Herd 4 & Herd 5

I have confirmed the source of this problem stemming from Ubuntu's update of libx11-6 from 1.0.3 to 1.1.1, which notably added the new dependency of libxcb1 and libxcb-xlib0 - the problem stems somewhere within these three packages, most likely related to xcb.

Steps to reproduce:
1. Boot Ubuntu Herd 4 LiveCD (uses Xorg 7.1 w/libx11 1.0.3-4ubuntu1), noticing normal performance with minimizing and maximizing.
2. Invoke "sudo apt-get update", "sudo apt-get install libx11-6"
3. Note that libx11-6 gets upgraded to 1.1.1-1ubuntu1, and new dependencies are installed: libxcb1 and libxcb-xlib0 1.0-1.1.
4. Restart gdm (pkill gdm; sudo gdm), and notice choppy minimizing animations.

Using Herd 4 I tried selectively upgrading packages, including all xorg 7.2 components, metacity, nautilus, etc., but libx11-6 (w/xcb dependencies) is the only package that introduces the slowness.

Thanks, reassigning to Xlib. Does it also happen if you don't restart the X server after upgrading libx11-6?

Michel,

Nothing changes until I restart X. For example, upgrading libx11-6 to 1.1.1-1ubuntu1 while running the Herd 4 LiveCD, performance remains fast until I restart X, and with my installed system, when I downgrade libx11-6 and libx11-data (to Herd 4's version 1.0.3-4ubuntu1), performance remains sluggish until I restart X.

Thanks for your attention, and if there's any logs or debug output you need, I'll be happy to provide it. I grabbed Ubuntu's source for libx11 and I'm going to try recompiling 1.1.1 without xcb support, I'll let you know if it helps.

Just a little note,

I haven't had luck rebuilding libx11-6 without xcb on Ubuntu due to my lack of experience dealing with debian scripts; hopefully an Ubuntu developer can take a look and do a better job.

Other users have confirmed the problem (see launchpad's bug, linked above) and experienced the same results as I had with downgrading libx11-6 and libx11-data.

So apparently it's related to something the X server uses in Xlib... It would indeed be interesting to know whether this also happens with current libX11 without XCB, I put up packages for that at http://people.debian.org/~daenzer/ but I'm not sure they'll work on your system.

It would also be nice if you could try profiling this with sysprof or oprofile.

Michel,

Thanks for the follow-up. I was able to eliminate the performance regression by downgrading libx11-6 and libx11-data to Ubuntu's version 1.0.3-4ubuntu1. The issue is being followed at my bug here: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/88815 and comment 39 contains the links to the older packages: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/88815/comments/39

The sluggishness indeed seems to be caused by xcb in some way, as libx11 1.0.3 doesn't use xcb. I tried building the newest libx11-6/libx11-data from Ubuntu's source debs without xcb support, but I had some trouble rebuilding the debs due to scripting errors, as they expect the xcb files to be built.

I'll see if I can install the packages you linked to and get back to you with the result soon.

Thanks,
Conn

From quick tests, it indeed seems related to XCB, but on the client side. Maybe the difference you saw on server restart was due to the window manager or so. Could you repeat the server restart experiments with a 'naked' X server (I used the 'Failsafe Terminal' session from gdm)?

Michel,

Luckily your debs installed without any dependency conflicts, and I can confirm
that after restarting X the sluggishness is no longer present. Apparently this
is an xcb issue after all.

I'll certainly help out with profiling, but due to my lack of experience with
sysprof and oprofile, I just need a little time to figure out how to use these
tools.

Can you clarify what you mean by server restart experiments? Do you mean using x11perf, or checking the minimizing/maximizing animations? If it's the latter, Will I just run "metacity&" in the failsafe terminal and then run firefox, then start minimizing and maximizing - and check that with the xcb-enabled libs and without?

Sorry for asking for clarification, it's just that x11perf takes a long time on my system. And I think you're right that it's a client-side problem, as when I use kwin in the GNOME environment instead of metacity, there's no slowness. Downgrading metacity didn't help, though.

(In reply to comment #11)
> Luckily your debs installed without any dependency conflicts, and I can confirm
> that after restarting X the sluggishness is no longer present. Apparently this
> is an xcb issue after all.

Okay, reassigning to XCB for now get the attention of XCB savvy folks.

> Can you clarify what you mean by server restart experiments? 

I mean the tests to determine whether restarting the server or client(s) makes the difference.

> Do you mean using x11perf, or checking the minimizing/maximizing animations? 

The latter is fine, but you'll have to make sure to restart metacity after installing a different libx11-6.

I didn't need to boot into the failsafe terminal, from the normal GNOME session:

1. Starting with your packages without xcb (X was restarted), everything is fast.
2. Re-install Ubuntu's libx11 packages with xcb. Everything remains fast. After "pkill metacity", metacity respawns and everything is slow again. No X server restart necessary.
3. Install your packages again. Everything remains slow. After "pkill metacity", metacity respawns and everything is fast.

So I guess it's a client-side issue, as you expected. Thanks for the help with troubleshooting the issue.

I know that XCB is slower than Xlib because Xlib uses a greater cache size (I've experienced that slowlessness). It makes xcb a bit slower, so I don't know if the problem comes from here or not.

Nevertheless, you can try that: before you use Xlib (that is before running the wm), set the environment variable XLIBBUFFERSIZE to 4 and see if you have the same problem than with XCB.

I don't think that it is the problem, but you can try ;)

I tested it with that variable, but there was no slowdown.

The x11perf results are a known issue, but not obviously significant. (How many apps do you have that use the X NoOperation request?) Despite our belief that the "slow" requests have almost no impact on real applications, we are working on improvements in this area.

However, I believe the bug you actually experienced with metacity is identical to #10644, which Josh and I believe is fixed in libX11 git.

Can you confirm that current libX11 fixes metacity's performance for you?

*** This bug has been marked as a duplicate of bug 10644 ***