Using most recent compiz (3.4) as well as earlier versions, under Ubuntu with AIGLX and an nvidia card, with 9629 driver. Steps to reproduce: 1. Start a compiz session. 2. Open a terminal window and type "yes | gzip > /dev/null" to keep the CPU busy. 3. If you have more than one CPU or core, open up multiple terminal windows and repeat step 2 the appropriate number of times, to keep all cores busy. Treat hyperthreading CPU's as multiple cores for this purpose. 4. Now move the mouse, drag some windows etcetera Actual results: the system is rather unresponsive, mouse movement is jerky, dragging windows are updated maybe twice (?) per second. Expected results: moving the mouse and dragging windows remains smooth, as happens with other composite managers. Hardware details: a Pentium-4 machine at 3 GHz, with a GeForce 6200 card and 256MB of video ram on the card.
I can confirm this with the newer nvidia drivers 9746 and direct rendering too. I use ubuntu edgy too.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
start compiz with __GL_YIELD=NOTHING /usr/bin/compiz --direct-rendering and this should not happen. if you have installed compiz in /usr/bin/ try adding this script to /usr/local/bin #!/bin/bash __GL_YIELD=NOTHING /usr/bin/compiz --direct-rendering $@ call it compiz and make it execulteablel for me this solved this issue.
the __GL_YIELD=NOTHING fix does not work for r300 video cards (radeon)
(In reply to comment #4) > the __GL_YIELD=NOTHING fix does not work for r300 video cards (radeon) > try running a 2.6.23 based kernel. the new cfs scheduler solved it for me without the need for the __GL_YIELD hack.
Is this still relevant? I haven't had this issue on my r100, r300 or nVidia card in recent times... Feel free to re-open at bugs.opencompositing.org if relevant.
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.