I'm forwarding this Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/101943 To reproduce on Ubuntu, install the following packages: xscreensaver, xscreensaver-data-extra. Then run one of the problem screensavers (such as braid) via /usr/lib/xscreensaver/braid. With compiz disabled, it will run quickly with modest processor usage, but with compiz enabled it runs the cpu to 95% and bogs the system down significantly (sometimes you can ctrl-C out, other times you must powercycle). For testing purposes, running 'braid -cycles 10' is enough to demonstrate the issue but avoid the lockups. Commenting out the XDrawLine() calls in the screensaver prevents the lockups from happening. strace also confirms the screensaver is doing a lot of xserver calls (running the screensaver under strace also prevents the lockups, presumably because it throttles the calls down?) The effect has also been seen with -nvidia, but not with -ati or -fglrx.
Fwiw, other screensavers reported to show this issue include interaggregate, vermiculate, whirlwind, imsmap, zoom, xrayswarm, substgrate, and mismuch. Others, such as crystal, are making XDrawLine() calls but don't seem to be triggering the lockups or exhibiting slowdowns.
> The effect has also been seen with -nvidia, but not with -ati or -fglrx. Are you sure? I was able to reproduce the problems described in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478836 with the radeon driver. Your analysis sounds like the server could simply be getting swamped with draw line requests and not dealing with it gracefully.
I also wondered if it was just swamping the xserver, however in testing it with compiz turned off, the behavior is notably different. If it was simply swamping the xserver, I'd expect that to occur with about the same performance in both situations. I've not tried it myself on -ati so couldn't confirm that, but other commenters on the original report claimed they couldn't reproduce the issue on ATI hardware, but didn't provide much detail.
(In reply to comment #3) > If it was simply swamping the xserver, I'd expect that to occur with about the > same performance in both situations. Well, compiz does incur some overhead and generally has an impact on how things are drawn, but yeah. Also, the Debian bug report mentions that usually the bad behaviour persists after killing the application, in which case only killing compiz recovers. This made me wonder if there could be some kind of damage event related feedback loop between the X server and compiz.
sounds like not a driver bug? component field updated.
Created attachment 17815 [details] [review] Contain number of screen damage rects in compiz It does look like compiz gets overwhelmed by lots of damage events generated by small lines / points. This compiz patch avoids the problem for me with interagreggate. Can you update http://bugs.opencompositing.org/show_bug.cgi?id=961 with this information?
(In reply to comment #6) > Created an attachment (id=17815) [details] > Contain number of screen damage rects in compiz > > It does look like compiz gets overwhelmed by lots of damage events generated by > small lines / points. This compiz patch avoids the problem for me with > interagreggate. > > Can you update http://bugs.opencompositing.org/show_bug.cgi?id=961 with this > information? Thanks much Michel for that patch, I have applied it (slightly adapted) in http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=aed97c441881d9c382c7865d0305fc8f884c10ac
Thanks Danny.
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.