compiz team mailing list archive

[Phil Doroff <764330@xxxxxxxxxxxxxxxxxx>]

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 compiz
packagers, which is subscribed to compiz in 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