Sluggish rendering since xorg 7.2 update

Bug #88815 reported by Conn O Griofa on 2007-03-01
74
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Invalid
Medium
libx11 (Ubuntu)
Undecided
Timo Aaltonen
xcb (Ubuntu)
Undecided
Unassigned
xorg (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: xserver-xorg-core

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

Since the upgrade of xorg-server to 2:1.2.0-3ubuntu1, 2D rendering has become very sluggish and choppy for certain operations, particularly minimizing & unminimizing applications.

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 .5secs 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'm attaching logs of my first system exhibiting this sluggishness, and if it will help, I also have logs from a fresh unmodified install of Herd 4 (using xorg 7.1 and exhibiting no slowness issues) if they're needed.

Conn O Griofa (psyke83) wrote :
Conn O Griofa (psyke83) wrote :
Conn O Griofa (psyke83) wrote :
Conn O Griofa (psyke83) wrote :

conn@dimension:~/bugreport$ cat mtrr-old.log
reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0x3f800000 (1016MB), size= 8MB: uncachable, count=1
reg02: base=0xe0000000 (3584MB), size= 256MB: write-combining, count=1

The mtrr hasn't changed since the upgrade, in case someone suggested it. Also, I have since installed nvidia-glx on my first system (which is a Dell Dimension 1100, sorry) which exhibits the same slowness issue.

Another note: on my second system, I tried the newest xf860-video-intel from git, and it doesn't help with 2D performance at all.

Thomas Wolfe (tomwolfe) wrote :

same here with an ati radeon 9000 mobility

Thomas Wolfe (tomwolfe) wrote :
Thomas Wolfe (tomwolfe) wrote :

Just wondering, if for my case, could it be because the ati drivers are still compiled for xorg 7.1.1 when I am running xorg 7.2? I tried running the debian ati drivers (did not fix the problem) since it showed a newer version, but it is also compiled for 7.1.1 and not 7.2.

Conn O Griofa (psyke83) wrote :

Thomas,

No, I don't think it's the problem. On my second system, I compiled xf86-video-intel from git using xorg 7.2 sources; here's my log:

(II) Module i810: vendor="X.Org Foundation"
 compiled for 7.2.0, module version = 1.7.4
 Module class: X.Org Video Driver
 ABI class: X.Org Video Driver, version 1.1

Performance is exactly the same.

jsage (jsage) wrote :

This problem has been plaguing me ever since 7.2 hit the repos. I'm running feisty on a ThinkPad T43p with ATI FireGL V3200 using the open-source ati driver and aiglx. Beryl and Compiz are unusable.

Conn's description of the problem using Firefox and gnome-terminal apply to my machine also. I'll add that gnome-system-monitor will peg the CPU at 100% when displaying the resource graphs.

Following suggestions in this thread:

 http://www.ubuntuforums.org/showthread.php?t=372693

I first ran sudo dpkg-reconfigure xserver-xorg to create a more "generic" xorg.conf (still using ati, but no aiglx). This gave me a small but noticeable improvement.

I next restored my original xorg.conf, but disabled EXA acceleration. This has provided the most notable improvement, but still not quite as good as pre-7.2. Compiz will run without choppiness, but is somewhat flakey when rotating the cube or alt-tabbing.

My current xorg.conf is attached.

Thomas Wolfe (tomwolfe) wrote :

confirmed that exa slowed it down for me too, sad since XAA has stopped being developed and only EXA from now on (it is superior, not sure what is clutzing it up)

Cyclops (rms) wrote :

In my case, EXA or XAA had more or less exactly the same dragging performance on 3D. My card:
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M] (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 99
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: d4300000-d43fffff
        Prefetchable memory behind bridge: dc000000-dfffffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

It should be noted that this card was very well supported up untill the Xorg upgrade.

Happens here too. I'm using nvidia drivers.

Can confirm it happens with the ati (radeon) driver too, independant of using XAA or EXA.
VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)

benobi (macbenobi) wrote :

Same problem fro intel i915 chip using i810 driver.
Beryl with aiglx was perfect before xorg 7.2 update. Now it's damn slow, even sluggish when you scroll a window.

Timo Aaltonen (tjaalton) wrote :

I still can't reproduce all the symptoms myself but confiming since others can. For instance on my work desktop (Core2duo, Nvidia 7950, binary driver) everything just works (installed it 30min ago), but on my home desktop (XP3000+, Radeon8500, free driver) I can see the window minimize -action being slower.

Changed in xorg-server:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Timo Aaltonen (tjaalton) wrote :

..and it seems that the intel folks have been hit the most. You'll get a new driver soon (1.6.5->1.7.4), so maybe that helps.

Simon Strandman (nejsimon) wrote :

I have this problem with both the nvidia and nv driver so I don't think this is driver related, but rather a problem with the xserver. The nv driver uses XAA while nvidia has its own NAA so I don't think the acceleration architecture is at fault either.

Not only is minimizing a window, or fading the screen for gksu slow but the mouse also lags when doing it and gnome-system-monitor shows a peak in CPU usage. I wonder why other distributions with xorg 7.2 don't have this problem? Perhaps you could try readding all fedora patches to see if it helps?

Conn O Griofa (psyke83) wrote :

Timo,

Since the new updates (xserver-xorg-video-nv 1.2.2.1-0ubuntu1, xserver-xorg-video-i810 1.7.4-0ubuntu1), both of my systems still exhibit slow 2D rendering (using the nvidia, nv and i810 drivers). I tried re-building xserver-xorg using the only most innocuous patches (see attached "series" from debian/patches/) - performance was just as bad, so perhaps they aren't the source of this problem.

Are there any LiveCDs (from other distros) using xorg 7.2 that I can test on my systems?

Conn O Griofa (psyke83) wrote :

Timo,

Upon further investigation I think I may have found the real culprit - metacity.

As I had kdebase installed on my system, I decided to try "kwin --replace" within GNOME, and performance is back to normal! Maybe the problem is specific to metacity and not xorg at all (a reasonable hypothesis, as when I checked the feisty-changes list, metacity and xorg-server were updated within very soon of each other).

Anyone with KDE installed, try it out! Just make sure you go into kcontrol and in Desktop, Window Behavior, Moving, disable "Animate minimize and restore", then try kwin. Minimize and maximize some apps and hopefully you'll notice that it's instantaneous like before. Tested & verified on both my systems with nvidia, nv and i810 drivers.

In light of this, I'm reassigning/adding to metacity.

Cyclops (rms) wrote :

With the latest updates, things are snappy again. Quite snappy indeed. But the only problem is that I'm suddenly loosing input focus on gnome-terminal and xterm windows.

Just as suddenly it comes back, at a random time...

I don't think this has anything to do with metacity.

Cyclops (rms) wrote :

Well, it just looks like I can execute commands, but the characters don't appear, and the window "looks", but isn't, frozen.

Maximized apps also get random weird factors.

Cyclops (rms) wrote :

It's actually worse than that. Windows randomly stop being updated, focus is lost (also on run command dialog), etc...

Hi,

As part of an ongoing effort to isolate poor performance in Ubuntu Feisty, I performed a set of benchmarks on version 7.1.1 and 7.2 of Xorg (Using Herd 4 LiveCD using 7.1.1 and latest installation using 7.2). Here's the bug: https://launchpad.net/ubuntu/+source/xorg-server/+bug/88815

I'm attaching the resulting comparison here in case it's of any use to the Xorg devs for performance tuning or troubleshooting.

Thanks,
Conn

P.S. I have a feeling that the i810 driver (and others) will show a similar disparity for window operations, as the sluggishness I'm experiencing is common to both my systems, using the nv (or nvidia) and i810 drivers respectively. My system specs are in Ubuntu's bugreport, look there if you're interested.

Created an attachment (id=8964)
x11perf comparison log (7.1.1 vs. 7.2)

Conn O Griofa (psyke83) wrote :

Cyclops,

It's still feasible that xorg is to blame, but it sounds like metacity could be stealing focus from your apps, or it could be an EXA rendering bug. Try changing back to XAA to see if it helps, and try kwin (or another WM besides metacity) to see if this behaviour continues with a different window manager.

Conn O Griofa (psyke83) wrote :

Hmm,

I downgraded metacity, metacity and metacity-common to 2.16.3-0ubuntu2 from Edgy, but it's still slow. Perhaps there's certain rendering paths that are slow in xorg that metacity happens to use; all I know is that performance is excellent with kwin. Maybe I'll try some x11perf tests on my system and compare them against a Herd 4 LiveCD to see any differences.

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 an attachment (id=8965)
Logs & config files from comparison environments, Ubuntu Feisty Herd 4 & Herd 5

Conn O Griofa (psyke83) wrote :

Hi,

I ran a complete set of x11perf on first system (Celeron 2.8Ghz w/NVIDIA GeForce FX 5200 using nv driver), using the herd 4 livecd, and the version installed on my drive (herd 5 with updates, including the new xorg 7.2 drivers). I used the same xorg.conf, disabled screensavers and monitor poweroff, and had no other processes running for these tests. I'm attaching the results, and system logs tarred together.

As you can see from the output, some operations with xorg 7.2 are up to 5x slower than xorg 7.1.1; in particular see 1x1 fills, "X protocol NoOperation", and nearly all window operations.

I can perform these benchmarks on my laptop (Intel 82855GM) if you wish, but I'm pretty sure we'll see a similar pattern (especially regarding window operations), as I'm seeing the same sluggishness on both systems using xorg 7.2.

Conn O Griofa (psyke83) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for your work on that. Could you open a bug upstream?

Conn O Griofa (psyke83) wrote :

Hi Sebastien,

I've opened a bug there, but I focused more on performance profiling. I'll expand on it and explain the problem in detail (I had just linked to launchpad).

Here it is: https://bugs.freedesktop.org/show_bug.cgi?id=10173

Changed in xorg-server:
status: Unknown → Confirmed

A couple of things/differences I noted whilst reading through your logs:
- The Xorg.0.log from Herd5 mentions it can't initialize the GLX extensions, since it is using the Nvidia libglx.so
Might this be the cause?
- In the Xorg.0.log from Herd5 AIGLX is disabled (since it can't load the GLX module)
- The Xorg.0.log from Herd5 mentions it loads a vm86 module (libvm86.so), which isn't loaded in the Herd4 log.

It might be good to try to keep the config the same, so the comparison is fair (though the stock config might be different).

Conn O Griofa (psyke83) wrote :

disturbedsaint,

Thanks, let me address your points:
1. That's right, nvidia-glx is installed on my system and so the nv driver can't initialize GLX.
2. Ditto, see above.
3. This may be a symptom of the above too, so I don't know.

In light of this, I'm running the benchmarks again, this time using the herd 5 livecd instead, and have copied xorg.conf from herd 4. I checked the resulting logs and libvm86.so is still being loaded; it's because of the new xorg build, I believe. I ran a quick test, "x11perf -umove" - here's the results (herd 4 livecd vs herd 5 livecd):

514000.0 186000.0 ( 0.36) Moved unmapped window (4 kids)
503000.0 185000.0 ( 0.37) Moved unmapped window (16 kids)
496000.0 184000.0 ( 0.37) Moved unmapped window (25 kids)
485000.0 184000.0 ( 0.38) Moved unmapped window (50 kids)
472000.0 182000.0 ( 0.39) Moved unmapped window (75 kids)
465000.0 181000.0 ( 0.39) Moved unmapped window (100 kids)
452000.0 175000.0 ( 0.39) Moved unmapped window (200 kids)

As you can see, these results reflect my initial benchmarks on my installed herd 5 system. I'm running the full set right now to be sure, and if anything significantly changes I'll post them here.

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.

Conn O Griofa (psyke83) wrote :

Hi,

After some troubleshooting I have identified the precise source of this sluggishness. When I downgraded xserver-xorg-core sluggishness persisted, so I experimented with downgrading other packages selectively, and found the problem to be with libx11-6 (1.1.1-1ubuntu1). After downgrading to version 1.0.3-4ubuntu1 from the Herd4 alternative cd, performance is back to normal.

Simon Strandman (nejsimon) wrote :

FYI I installed fedora 7 test2 in parallel with feisty. It has the same versions of metacity and xserver but it doesn't show this problem. But libX11 is still at version 1.0.3 in fedora while feisty has 1.1.1. Perhaps xcb is the problem?

Conn O Griofa (psyke83) wrote :

nxsty,

I would say xcb definitely is to blame. I booted up Herd 4, ran "sudo apt-get update", "sudo apt-get install libx11-6", and libxcb-xlib0 and libxcb1 were installed as new packages. Upon restarting gdm, I could see the sluggishness present.

Thomas Wolfe (tomwolfe) wrote :

Until the bug is fixed, any tips on how to properly go back to the old version? Good work pinpointing where the problem was.

Conn O Griofa (psyke83) wrote :

Hi Thomas,

What you can try is to downgrade libx11-6 and libx11-data to version 1.0.3 from the Herd 4 alternative cd (I'm not sure where to get obsolete packages from Feisty). I've grabbed them from my cd and uploaded here in case you want to try:

http://www.zshare.net/download/oldx11-6-tar-bz2.html

sudo dpkg -i oldx11-6/libx11*

The packages should downgrade fine, but when you next try to use apt-get it will complain about breakage, and offer to upgrade these packages again. I suggest you try it nevertheless; downgrade the packages, restart X and test your system's minimizing speed, then upgrade afterwards with apt-get. At least you'll be confirming the bug, and then something better can be done by the developers.

benobi (macbenobi) wrote :

I am having the same problem.
I'll try the downgrade tonight and post the result.

Thanks for the good work on that guys.

BjornarBerg (ssamik) wrote :

I had this problem, but downgrading as suggested really got things going.

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

benobi (macbenobi) wrote :

Just did the downgrading and things work much better. So, apparently those packages really are the problem.
Next step is to figure out what's happening !

Thanks again for looking into that.

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.

Thomas Wolfe (tomwolfe) wrote :

Downgrade helped metacity quite a bit, back to normal speeds, although compiz and beryl both seem a bit sluggish still, anyone else notice this (mainly when scrolling web pages, uses 100% cpu and is very slow)? Still using the same xorg.conf as i posted before. Thanks again guys.

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.

Thomas Wolfe (tomwolfe) wrote :

nevermind, http://bugs.beryl-project.org/ticket/1 is the bug, seems be related to exa acceleration

Timo Aaltonen (tjaalton) wrote :

Slow performance when EXA is enabled is not what this bug is about, see bug #88696 instead.

Though I'd like to know if downgrading libx11 helps to improve performance with EXA..

Thomas Wolfe (tomwolfe) wrote :

yes, I realize that, i was just commenting on my comment, sorry for the confusion. And to answer your question timo, yes, it does.

Guido Conaldi (guido-conaldi) wrote :

Using Fiesty with an ati RV350 NP, 'ati' driver, and XAA.

Switching to EXA did not make any difference
sudo dpkg-reconfigure xserver-xorg did not make any difference

Downgrading libx11* worked

Simon Strandman (nejsimon) wrote :

A workaround might be to compile libX11 with "--without-xcb". At least then we'll be sure if it's really xcb that's the problem and not any other change in libX11 1.1.

Conn O Griofa (psyke83) wrote :

nxsty,

I've tried to modify the deb source and rebuild without xcb, but it failed building and I couldn't test. Feel free to try yourself, but one thing to note: you need to use "--with-xcb=no", the line you typed above has no effect (I already tried).

Martey,

It was an understatement to say that "finding old packages in Launchpad is really annoying". How do you do it?

I want to downgrade also libx11-dev to stop aptitude complaining.

Simon Strandman (nejsimon) wrote :

Conn:

Actually both work, you can see a status message when configure completes that tells if xcb is disabled. It builds but debconf wants to package the xcb files intead of xlib and fails as they're missing. It might work to use some files from libx11-1.0.3/debian/ and just change the version but I'll leave that to someone who better understand how debbuild works. :)

Martey Dodoo (martey) wrote :

Bruce: I use Søren Hansen's tricks: http://www.warma.dk/blog/article/68/

Conn O Griofa (psyke83) wrote :

Timo,

This bug is still present on my systems, have you gotten any closer to isolating the problem? Have you tried building libx11-6 without xcb support? I tried, but couldn't build the debs due to the script expecting the xcb files to be present.

Conn O Griofa (psyke83) wrote :

Another note regarding the sluggishness: the slowdown is not just visual (i.e. metacity's animations).

Steps to reproduce:
1. Open a firefox window, maximized.
2. Click on the minimize button of firefox's window, and immediately move the mouse in a circular or zig-zag motion.

It appears that minimizing and maximizing applications affect even the mouse, causing interruption/jerkiness in movement.

Also, I noticed when using tsclient to make a vnc or rdp connection to another connection, if I switch from fullscreen to windowed, there is often a very large delay when switching modes (~2 secs to render the window), whereas using the downgraded packages, there's no delay at all.

PurpleSkunk (purple-skunk) wrote :

Confirming that downgrading to libX11-6 and libX11-data to version 1.0.3-4ubuntu1 solve this issue.

Tim Perry (pimterry) wrote :

Had issue - Fixed with downgrade.

buckeliger (buckeliger) wrote :

Same here; feels much! better after downgrade (VIA onboard grafics, VIA driver, very 2D).

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.

Mirco Müller (macslow) wrote :

I mainly notice the sluggishness in OpenGL-apps (compiz etc). Downgrading libx11 from 1.1.1 to 1.0.3 - like suggested above - did not improve the situation for me. The machine is question is a laptop with i915-based graphics.

Conn O Griofa (psyke83) wrote :

Mirco,

Your issue is not related to this bug, please see here: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88918

I suggest you experiment with the INTEL_BATCH variable, e.g. "INTEL_BATCH=1 glxgears", and compare it with normal glxgears performance. Please don't reply in this bug, though, as it's a separate issue.

Changed in xorg-server:
importance: Medium → High
Timo Aaltonen (tjaalton) wrote :

Ok, I managed to build libx11 without xcb:

http://users.tkk.fi/~tjaalton/dpkg/

at least on my laptop (savage) the performance is much improved.

Conn O Griofa (psyke83) wrote :

Timo,

By coincidence Michel Danzer and I were experimenting with packages he built sans xcb, see the upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=10173

What we discovered is that it's definitely caused by xcb, and it's a client-side issue - respawning metacity after changing the packages will trigger the slowness/speedup, without an X server restart.

Tollef Fog Heen (tfheen) on 2007-03-30
Changed in xorg-server:
assignee: nobody → tepsipakki
Jan Claeys (janc) wrote :

Timo,

I tried your libx11-packages-without-xcb (thanks to Mithrandir for pointing me to them) and I too can see a clear improvement.

(this is on a P3@666MHz and a Riva TNT2 Pro using nvidia-glx-legacy driver)

Matti Lindell (mlind) wrote :

I tried Timo's libx11 packages without xcb and I can confirm improvement as well.

dbuchmann (dbuchmann) wrote :

Hello, I´m new to linux and when I try to use the libx11-6 package I get this error:

Error: Dependency is not satisfiable: libc6

And when I tried: sudo dpkg -i oldxll-6/libxll*

in the terminal I got this error:

dpkg: error processing oldxll-6/libxll* (--install):
cannot access archive: No such file or directory
Errors were encountered while processing:
oldxll-6/libxll*

I was able to use GDebi Package installer to install the libxll-data_1.0.3-4ubuntu1_all.deb but not the libxll-6_1.0.3-4ubuntu1_i386.deb it gives me the dependency error.

Hopefully this is a simple problem that can be attributed to inexperience. If anyone has any insight I would appreciate it!

Thanks,

-David-

Are you running Edgy? This bug only appears on Feisty, and the package
only installs on Feisty.

Mirco Müller (macslow) wrote :

I just witnessed an odd behaviour. When I unplug the power-cable from my i915-based laptop and the CPU-throttling kicks in (going from 2 GHz to about 800 MHz). Once that happened all the sluggish drawing performace of OpenGL- and cairo-based programs gets smooth as silk again. I'm running a up-to-date Feisty without downgraded libx11. I've currently no idea what's going on and causing this behaviour, but this might be a hint for more xorg/kernel savvy people here to solve the issue.

Bordiga Giacomo (gbordiga) wrote :

I noticed that high CPU usage improves the drawing performance of OpenGL programs.

dbuchmann (dbuchmann) wrote :

I am running Edgy Eft as far as I know but I'm having the same scrolling issues.

-David-

Conn O Griofa (psyke83) wrote :

David,

This bug is only on Feisty, and has nothing to do with scrolling. It's slowness when minimizing/maximizing windows, and switching between windows.

Tomi Urankar (tomi0) wrote :

Tnx TIM for your link. Works much better now. I was begining to wonder what I had done to make GNOME so sluggish

Benjamin_L (benjamin-lebsanft) wrote :

seems to be fixed with the latest upgrades! Thank you

Timo Aaltonen (tjaalton) wrote :

indeed, fixed it by this upload

 libx11 (2:1.1.1-1ubuntu2) feisty; urgency=low
 .
   * Don't build with libxcb, since it causes performance regressions on
     some X clients. (LP: #88815)

I'll keep the xcb component open, though.

Changed in xorg-server:
importance: High → Undecided
status: Confirmed → Rejected
status: Rejected → Confirmed
Changed in libx11:
status: Confirmed → Fix Released
Changed in xorg:
status: Unconfirmed → Rejected
Changed in xcb:
assignee: nobody → ubuntu-x-swat
status: Unconfirmed → Confirmed
Conn O Griofa (psyke83) wrote :

Good work Timo, the sluggishness is now gone on all my systems. What are the implications of building without xcb, are we losing functionality somewhere? Nevertheless, this issue is reported upstream so there's a good chance it will be fixed in the xcb component too.

Timo Aaltonen (tjaalton) wrote :

Currently there are no other component which depends on xcb, and no-one has reported of any regressions so we should be safe for Feisty.

Denis Washington (dwashington) wrote :

I just updated to the new libx11-6 package and rebooted, but my performance is still horrible when I am using EXA (i use the "radeon" driver with an ATI Radeon 9600 XT). Could this be a driver bug?

Tomi Urankar (tomi0) wrote :

EXA
Lots of ppl get sluginesh with EXA.
Heres a bug report sbout it. Suggest U ask there:
https://bugs.launchpad.net/xorg-server/+bug/88696

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

Jamey Sharp (sharpone) wrote :

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 https://bugs.freedesktop.org/show_bug.cgi?id=10644, which Josh Triplett and I believe is fixed in libX11 git.

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

Assuming it does, could the libX11 maintainer for Ubuntu please stop building libX11 without XCB?

Changed in xorg-server:
status: Confirmed → Rejected
sumsar (rasmus-baath) wrote :

For people with intel graphics cards xgl could be the problem. I ad problems with realy bad graphis performance using a 915 intel card but then i followed the advise in this post:

http://ubuntuforums.org/showpost.php?p=3416144&postcount=15

I just uninstalled the xserver-xgl package and then everything worked just fine. According to the post above this is not a bug, just a performance issue...

Jojoma (zyozyoma) wrote :

I just recently installed Ubuntu 8.4 (8.04?) with Gnome and noticed the problem. After seeing someone’s suggestion with KDE, I tried this:
I went to the System menu, selected Preferences - Appearance, clicked the Visual Effects tab and selected “None”. It got rid of the sluggishness for me.

Changed in xorg-server:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
status: Unknown → Invalid
Timo Aaltonen (tjaalton) on 2011-02-25
Changed in xcb (Ubuntu):
assignee: Ubuntu-X (ubuntu-x-swat) → nobody
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.