After starting X with Composite extension enabled everything looks fine (very fine, due to transparency). However, when running "glxinfo" CPU-usage jumps up to 100% for some seconds, then I can see the glxinfo-info and after that CPU-usage remains high (70-100%) for one hour or more (depends on something I wasn't able to find out yet). When disabling the Composite extension, everything is fine, running glxinfo or not. My system: AMD Athlon64 (Gentoo Linux, 64bit-Version) Sapphire ATI Radeon 9200 radeon-driver from kernel 2.6.9 Programs running: xfce4 (the whole desktop) gkrellm2 psi root-tail terminal (xfce4-terminal) Somebody mentioned a similar problem when running gkrellm2, but stopping it didn't have the desired effect on my machine. Attached You will find my xorg.conf and Xorg.0.log (with and without Composite enabled). Greetings, Dirk
Created attachment 2976 [details] xorg.conf
Created attachment 2977 [details] Xorg.0.log (working, without Composite)
What I forgot to mention: glxinfo is just a bulletproof way to trigger the bug - You might think "just don't use it". Unfortunately there are other programs that do it, too. I wasn't able to compile a list, though, because there's no user interaction required. Sometimes I come back to my desk and CPU=80%. So I can't just stop using glxinfo and expect everything to be alright.
Created attachment 2978 [details] Xorg.0.log (with Composite, before glxinfo)
Created attachment 2979 [details] Xorg.0.log (with Composite, after glxinfo, CPU=100%)
Created attachment 2980 [details] Output of glxinfo with Composite enabled
Created attachment 2981 [details] Output of glxinfo with Composite disabled
I tested this with external radeon modules (not in-kernel). Same effect. Very strange, though: When CPU is near 100% after glxinfo it drops to 3%-10% when running glxgears (can be invisible, hidden, on other workspace). So I'm now able to work when I run glxgears...
Just to chime in. This bug is still present in X11R6.9-RC4. As soon as the dri driver gets loaded (triggered by running glxinfo), the whole system becomes extremly sluggish and virtually unuseable. I'm using the latest cvs radeon_dri.so driver (Radeon 7500 in my case).
Does this also happen if you don't enable backing store?
(In reply to comment #10) > Does this also happen if you don't enable backing store? Short answer, probably misleading: No! Long answer: I got so frustrated with all this eyecandystuff that I started to use icewm again - icewm does not have this sort of problem (the problems occured in xfce4 with transparency, window-shadows and all possible wizardry enabled). Now, when I read Your post I tried it all again - and it seems that I cannot trigger the bug anymore (both with and without backingstore). There's one thing to note, however: I run "conky" and "root-tail", both of which draw directly to the root window. Conky is put into "single buffer" mode, because otherwise it makes root-tail invisible. When I ENABLE backingstore and issue "glxinfo" conky starts to update itself r ea ll y s l o oo o w. So I guess it has to do something with backingstore and improved a bit since my last post. Greetings, Dirk
Dirk, are you willing to go back to XFCE to do some more debugging or should we close this bug?
Hey Erik, I'd prefer to stay with icewm for now. I have to get some serious work done, and I simply don't have the time for debugging eyecandy at the moment. (Sometimes I think by myself: "Hey, isn't all of this going into the wrong direction, and shouldn't everybody be using wmii by now?") If I ever get into the lucky situation to have the time to tinker with these configfiles again, I will reopen the bug (if it persists). Greetings, Dirk
Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.