I've done a little bit more testing, but haven't had time to really go into depth yet.
I've been able to reproduce this issue on every machine I've tried now - no matter the video card. Plugging in a mouse w/ a 1000Mhz sample rate = the UI slows down. On some machines (nvidia desktops here in particular, may be a coincidence) it is drastically slower to the point of being unusable. On other machines, based on intel GMA and ATI graphics, the slowdown/jerkyness is absolutely evident, but it looks more like a low refresh rate than being completely unworkable. I have also expereinced the "slowdown over time" problem reported here. However in both cases, while testing (likely strace caused this, but not enough info yet) compiz crashed, restarted, and came back fine. A compiz --replace fixes it as well, of course. As otherwise reported here, I played with glxgears a little bit before bed last night. The frame rates you are seeing are very likely normal and "good" - since you are running with vsync off. If you have vsync on, obviously something is incorrect. However, glxgears should NOT "jam" the computer like it does, I've been able to reproduce that effect both with vsync on and off - while the problem is much worse with vsync off, it's still very evident with it on as well. Definitely interesting, not sure if it's related to this or not. The only correlation I've been able to make with my two "slowdowns" have been I've was using a Windows 7 Virtualbox, to RDP to a remote computer on the network. After some time, window moving again became excusably slow, and eventually compiz crashed. Again, most likely simple coincidence but wanted to see what others were doing during the slowdown periods. I do find it very strange that the behaviour between the high sample mouse rate, and the "the UI randomly slowed down!" is pretty much identical. While this could be yet another coincidence, I really do feel that they are related in some underlying manner. The "good news" is that so far I've been able to get vsync running properly now, which gets rid of the screen tearing - while I'm also not seeing any noticeable performance penalty. Hopefully a developer or someone with far more knowledge of the Xorg/Compiz side of the fence will be able to chime in here soon and direct testing in a more specific manner. I'm from a server background, so all these fancy graphics things are new to me :) I still have a few paths to follow up on, but nothing too concrete at this time. To any compiz devs here, this may or may not be interesting to you regarding the mouse poll issue. Both straces are "roughly" 10 seconds of me moving a window around on the desktop. (broken mouse) root@mancave:~# strace -p 1724 -c Process 1724 attached - interrupt to quit ^CProcess 1724 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 92.28 0.010677 0 71364 poll 6.20 0.000717 0 35542 writev 1.26 0.000146 0 115638 75323 read 0.18 0.000021 0 760 ioctl (working mouse) root@mancave:~# strace -p 1724 -c Process 1724 attached - interrupt to quit ^CProcess 1724 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 66.76 0.006456 0 31039 poll 31.68 0.003063 0 14870 writev 1.14 0.000110 0 54801 37716 read 0.34 0.000033 0 3067 ioctl The interesting part, is that when the machine "randomly slowed down" with the "working" mouse attached, it also showed roughly similar strace system calls. Obviously both are spending considerable time in poll() with a HIGH (the *vast majority* are errors, not sure if that's normal or not!) number of polling errors strace output looks something like: poll([{fd=7, events=POLLIN}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=3, events=POLLIN}, {fd=23, events=POLLIN}, {fd=36, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=32, events=POLLIN}, {fd=16, events=POLLIN|POLLPRI}, {fd=33, events=POLLIN}, {fd=42, events=POLLIN}, {fd=41, events=POLLIN}, {fd=40, events=POLLIN}], 16, 3754) = 1 ([{fd=3, revents=POLLIN}]) read(3, "}\0\33J\207\31`\4\211\31`\4\231\302\6\4\3\0;\0\217\5\334\3\0\0\0\0\225\5\32\4"..., 4096) = 64 read(3, 0x247a434, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x247a434, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x247a434, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(23, 0x2820774, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(24, 0x288d5b4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=7, events=POLLIN}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=3, events=POLLIN}, {fd=23, events=POLLIN}, {fd=36, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=32, events=POLLIN}, {fd=16, events=POLLIN|POLLPRI}, {fd=33, events=POLLIN}, {fd=42, events=POLLIN}, {fd=41, events=POLLIN}, {fd=40, events=POLLIN}], 16, 9) = 0 (Timeout) poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\210\t\2\0\1\0\0\0+8\1\0", 12}, {NULL, 0}, {"", 0}], 3) = 12 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "\1\2\35J\0\0\0\0(\366`\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32 read(3, 0x247a434, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x247a434, 4096) = -1 EAGAIN (Resource temporarily unavailable) Over and over in a loop, essentially. Not much changes from the output broken vs. working vs. idle, other than the poll() and read()'s come MUCH faster during window operations. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/764330 Title: Move window annoying slow with compiz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/764330/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs