[regression] Moving windows lags behind the mouse by 1-2 seconds; appear to freeze when dragging.

[glazs]

SRU test case:

1. start Ubuntu
2. start any application
3. try to move its window around on the desktop
4. note the movement is lags alot
5. now install compiz from oneiric-proposed
6. the lag should not happen anymore.

====Original Report====

[Impact]
Windows don't move when dragged with the mouse, except intermittently. Very poor user experience.

[Development Fix]
Deleted a temporary workaround for an old bug in the move plugin, which itself was buggy. It was causing the move plugin to unexpectedly revert from the default "lazy" asynchronous mode (fast) to a blocking synchronous mode, which is simply too slow to keep up with the mouse on some machines.

[Stable Fix]
As above.

[Test Case]
Drag windows around rapidly using the mouse.
Broken Behaviour: Windows don't move, except maybe once every 1-2 seconds.
Fixed Behaviour: Windows move smoothly and keep up with the mouse.
If you can't reproduce the bug then try using a very slow or old machine. I used an N270 based Atom netbook.

[Regression Potential]
Low. The fix has been in every-day use by many users of ppa:vanvugt/compiz for a while.

[Original Report]
I have fast machine( 4gb of ram, amd64 x4, nvidia 460 ), using proprietary nvidia driver.
Natty b2 x64, updated yesterday.

Windows move very slow, but only by mouse. Windows moving fast by Put plugin.
lasy_positioning is enabled.

Disabling wobbly windows and switching window decorator not helping.
video:
http://images.rock.su/bugs/move.ogv
When video is recording, windows moves much faster. Maybe problem with screen redraw.
If you need, i can record video by camera, windows moving unreal slow when video not recording.

[glazs (l-admin-rock-su)]

Recorded by camera.
http://images.rock.su/bugs/move2.ogv

[Mr.Beard (mr-beard-mail)]

I have same bug.
amd64 X4, 4gb ram, radeon 4850
natty b2 x64

[Socket (skuzn)]

There is a quiet simple solution. Disable the vert refresh sync in compiz options.

[Sergey Ukolov (zezic)]

Same bug at E2140, 2gb ram, radeon HD 4670
Disabling the vert refresh sync in compiz not help.

[softzilla (softzilla)]

Confirm. Bug still exists in 11.04 Release (Update from 10.10)

NVIDIA 330M, proprietary driver 270. All animation is smooth and fast, except windows movement.
In 10.10 all works perfect.

[David Burrows (snadge)]

If you load amsn or quanta on Ubuntu 11.04, it is trivial to reproduce this bug, on ANY driver/hardware combination. Using either compiz or unity. Problem does not exist with acceleration disabled (ubuntu classic, no effects).

[Eduardo Cárdenas-Trejo (edcartre)]

Same here, I noticed a slow movement of windows (not too annoying, though)

AMD Athlon(tm) II X4 640 Processor, 4GB RAM
Ubuntu 11.04 AMD64
ATI Radeon HD 4250

Disabling vert refresh sync in compiz DOES work for me.

[Geoffrey Pursell (geoffp)]

This happens for me on a Radeon 3870 using the r600g driver. Unchecking OpenGL -> Sync To VBlank does not help me.

[Lonnie Princehouse (lonnie-princehouse)]

Update: After extensively screwing around with compiz config options and then restarting X, the problem is magically gone. The weird thing is, I had restored all of the settings to their original settings. Afraid to reboot now.

Update: Disabling window decoration and moving the window with ALT-click removes the extreme lag, but it is still choppy.

-------------
This happens to me too, exactly the same as glazs' video. Disabling vblank sync does not fix it, although it does fix other compiz effects (e.g., expo).

Oddly, toggling "enhanced zoom desktop" off and then on again caused a visible reset of the unity border features, and this fixed the extreme window choppiness for about a minute, bringing the window redraw rate during dragging up to about 10fps. An improvement, but still nowhere near the ~60fps I had with Ubuntu 10.10.

AMD Phenom(tm) II X6 1045T Processor, 8GB RAM
ATI Radeon HD 5450 using fglrx 8.78.3
Ubuntu 11.04 amd64, upgraded from 10.10 (not freshly installed).

[Andrei Gladkyi (arg)]

Confirmed on E7500/4GB/GeForce GT 240 after updating to 11.04 from 10.10.
Any changes in ccsm didn't help.

[Jan (jan-tux)]

Also on AMD-X4/4GB/GeForce 9600 GT after switching to 11.04

[Jan (jan-tux)]

Also within Virtualbox 4.0.8 (71778)
Host: AMD-X4/4GB/GF9600GT

[Richard Terrett (rterrett)]

I get this under Ubuntu 11.04 running Unity. Windows are smooth for a variable period of time, and then become jerky. Other Unity functions such as sidebar auto-hide and workspace switching remain smooth. I have not found a combination of nvidia-settings and ccsm settings that ameliorate this problem. Resetting Compiz fixes the problem temporarily.

Running 11.04 AMD64 final with 260GT

[mariux (marius24s)]

EXACTLY same problem here. When using Unity or Ubuntu Classic (with Compiz effects) window management becomes very jerky and unusable. I tried to play with VSYNC options, even tested all available Nvidia drivers and no luck. AMD Phenom II 965, GTX560Ti.

[Timo Reimerdes (timorei)]

Fresh install of natty. (ubuntu 11.04)
All packages upgraded.
recommended proprietary nvidia-drivers installed.
fresh configuration.

Choppy window movement when using compiz.

$ compiz --version
Compiz 0.9.4.0

$ uname -r
2.6.38-8-generic-pae

$ lspci |grep nV
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GS] (rev a1)

[Timo Reimerdes (timorei)]

About 5 minutes after posting this I found a kind of workaround that seems to improve things a lot:

in ccsm (compizconfig-settings-manager)
in the composite plugin, deactivate auto detection and set the refresh to something like 60.

restart compiz by doing compiz --replace

---
also in nvidia-settings, check if the powermode is set to performance (in the powermizer entry of the menu to the left)

[Socket (skuzn)]

Catched the problem again, but now in Linux Mint. HW: ATI Radeon HD 4500 series mobility, Core i3-330M, 4GB RAM.
Proprietary drivers installed (fglrx).

My configuration In CCSM:
Composite - Update freq=60; all checkboxes are clear.
OpenGL - all checkboxes unchecked. All works properly. But when check "Sync with VBlank", windows are moving slowly again. If uncheck - it starts work right again.

However, there is another problem, not connected with this thread. E.g., I have opened chromium-browser in full-size mode. After switching between windows I cant see if I control some elements in the chromium window, e.g. textboxes. Minimize, then maximize - and everything is OK then. I'll search another thread connected with it.

[Socket (skuzn)]

PS. Sorry, hadn't read Timo's messages.

[Geoffrey Pursell (geoffp)]

I found the same fix, but I had to set the refresh rate to more like 120. Large windows still exhibit jerkiness, which makes me wonder if they're catching on the edges of the screen because of some edge-snapping plugin that I haven't found yet.

[Colin D Bennett (colinb)]

Another confirmation that Unity gets slow after running for a while. Unity runs fine when I first boot up, but after a while things get unusable: Dragging windows to move them is nearly impossible, I sometimes have to wait 5+ seconds for the window to react to a drag. Switching desktops is also extremely slow. When I hit Ctrl+Alt+Right to switch to the right desktop, nothing happens for a few seconds, and then it switches.

Another problem is that the “overlay scrollbars” are reacting extremely slow as well. Of course they are completely unusable! In evince (Document Viewer) and nautilus (File/Folder Browser), for instance here is what happens: Move mouse near the slim little scroll thumb indicator; the overlay scrollbar widget quickly appears. I press the mouse button on the scrollbar widget and drag up or down a hundred pixels or so and wait... it takes 5+ seconds for anything to happen, but eventually the content jumps and the overlay scrollbar widget jumps under the mouse. If, instead of dragging the overlay scrollbar popup thumb, I click the Up/Down arrows on it, the reaction is immediate.

I am definitely going to switch back to the “Ubuntu Classic” session and hope it works better. I want to like Unity, but this performance problem is a killer.

Details
-------

OS: Ubuntu 11.04 amd64
Graphics driver: nvidia (package nvidia-173 173.14.30-0ubuntu1)
Graphics hardware: NVIDIA GPU GeForce 9600M GT (G96) Memory: 524288 kBytes
Machine: MacBook Pro 5,1 - 4 GiB RAM

After running for a while, top (sort by memory usage) shows:
    VIRT RES %CPU %MEM COMMAND
  1,164m 585m 0 14.9 unity-panel-ser
  1,420m 458m 2 11.6 firefox-bin
    701m 328m 0 8.3 Xorg
    990m 266m 0 6.8 nautilus
    858m 210m 0 5.3 gnome-power-man
  1,042m 172m 2 4.4 compiz
    534m 127m 0 3.2 evince

unity-panel-service is using over 512 MB of RAM? What is it doing with all my memory?! As you can see, the system processes (unity-panel-service, Xorg, gnome-power-manager, and compiz) are taking up over 1.2 GB of RAM alone. This is crazy.

[Colin D Bennett (colinb)]

@Timo:
Regarding your workaround of using Compizconfig Settings Manager to set the Composite plugin refresh to 60 Hz (or another fixed value) rather than automatically detect it, I am skeptical that it works.

I found that simply restarting Compiz with 'compiz --replace' is what causes the temporary performance improvement. Have you run for days with your manual refresh setting to see if there is a long-term improvement?

In fact, I though my computer had locked up when I first did compiz --replace. It did some flashing stuff with the windows, and then froze up for at least 60 seconds. I almost rebooted it, but them compiz came back up and things were working smoothly! Do I really need to make a cron job to restart compiz every few hours or once a day?

I am going to suggest that this is a compiz bug...? I haven't tested on 'Ubuntu Classic' session with Gnome+compiz to see if there is a difference compared with Unity+compiz. I'll do that soon.

[Colin D Bennett (colinb)]

... (Returning to comment after switching from the Unity “Ubuntu” session to “Ubuntu Classic” session for one week.)

Moving windows became very slow again. I tried “compiz --replace” but it did not help. I had to log out and back in again to fix it. The Xorg process had a resident memory size of more than 400 MB before I logged out.

After logging out and back in again, moving windows is nice and snappy again.

[Screatch (screatch)]

I experience exactly same problem and it happens with unity and normal classic ubuntu session. Lag happens after working a while, compiz --replace does give a temporary performance boost but not for long.

[Covi (j.a.cobo)]

Me too.

- AMD Penom II X2 550 & nVidia GTX250 (nvidia-current from ppa)
- Upgrade from 10.10.

:(

[CadamR (caserichter)]

Natty
Compiz 0.9.4.0
2.6.38-8-generic-pae
Radeon HD 5750 w/ proprietary driver 11-6-x86
MOUSE: Logitech G500

Compiz is very slow/choppy during window movement and desktop cube rotation. It is choppy ONLY WHILE THE MOUSE IS MOVING. Compiz is not slow/choppy while the mouse isn't moving. I assume this means that mouse input events are somehow interfering with Compiz? SWITCHING TO A DIFFERENT MOUSE FIXES THE PROBLEM COMPLETELY (a cheap dell mouse).

Disabling Sync to VBlank does not help. Disabling Detect Refresh Rate does not help.

I get an error message in /var/log/Xorg.0.log:
(EE) Logitech G500: failed to initialize for relative axes.
(II) Logitech G500: initialized for absolute axes.

I wonder how many others' problems are due to the mouse without realising it? It was difficult to realise that Compiz was only lagging while the mouse was moving.

Thanks in advance for any feedback.

[Soren ONeill (soren-s)]

Same story, but with even better hardware: Intel i7 at 3.4 Ghz with 16 Gb RAM and a nVidia Corporation GF104 [GeForce GTX 460]

I'm also finding when running glxgears, that nothing at all comes up (no window with gears and no output in terminal), UNTIL i ctrl-c and it quits. It reports ~16.000 FPS but actually does nothing on screen.

The suggested work-arounds above (changing re-fresh rate) does nothing for me.

This is a show stopper! Unity is going OUT! and perhaps ubuntu is too ... back to Mint for me

[Kad Reynolds (packinator76)]

Happening to me in latest Mint, Soren.

i5 2500k
8gb RAM
SSD
GTX 580

GLXGears reporting about 15,000 but everything is choppy.

This seems kind of serious, how long is this going to take?

[Phil Doroff (phil21)]

At the risk of simply posting another "me too" comment..

Me too! :)

Hardware: Intel Core i5, Nvidia GTX570

Symptoms: Anything related to moving windows around is absolutely insanely sluggish/jittery/slow. Reverting to either Ubuntu Classic (no effects) or Unity2d brings the window management back to being smooth as silk. However, both of those workarounds have serious drawbacks.

I have tried all the reported fixes in this thread, relating to vsync and various compiz settings/configuration changes. I've also tried running kernel 3.0.3 w/ the Nvidia 275 drivers - which seem to have the same identical problem, so it appears the issue is definitely in compiz itself. Around 50 reboots and a couple fresh installs later, and I'm exactly where I started.

Happy to provide any and all troubleshooting required!

[Phil Doroff (phil21)]

I posted 2 hours too soon!

So on a hunch, based on some other xorg.0.log output from other users in this ticket, I noticed that all folks with both and Nvidia Video card, and a Logitech mouse seem to have reported this problem. I run this configuration as well (G700- same problem wired or wireless).

Based on this, I went out and grabbed a Microsoft Intellimouse classic - $30 mouse at your local shop. Unity restart, and problem completely and entirely gone. Window dragging is now smooth as butter, effects don't lag, etc.

It has something to do with this in the Xorg logs:

[ 1077.302] (II) XINPUT: Adding extended input device "Logitech G700 Laser Mouse" (type: KEYBOARD)
[ 1077.302] (EE) Logitech G700 Laser Mouse: failed to initialize for relative axes.

I have pasted all "logitech" based output from my Xorg.0.log where the problem is happening, and where it appears to be fine:

26.460] (II) XINPUT: Adding extended input device "Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)" (type: MOUSE)
[ 26.460] (II) Microsoft Microsoft 5-Button Mouse with IntelliEye(TM): initialized for relative axes.

Note the KEYBOARD and MOUSE types. Something perhaps not registering correctly? I don't have time to look into this more at the moment, but I believe this should actually give this bug some traction.

If any developers want to contact me for direct testing, please let me know. I'm happy to setup a machine here for remote access if that is beneficial.

[Colin D Bennett (colinb)]

On Tue, 05 Jul 2011 21:49:10 -0000
Phil Doroff <email address hidden> wrote:

> I posted 2 hours too soon!
>
> So on a hunch, based on some other xorg.0.log output from other users
> in this ticket, I noticed that all folks with both and Nvidia Video
> card, and a Logitech mouse seem to have reported this problem. I run
> this configuration as well (G700- same problem wired or wireless).
>
> Based on this, I went out and grabbed a Microsoft Intellimouse
> classic - $30 mouse at your local shop. Unity restart, and problem
> completely and entirely gone. Window dragging is now smooth as
> butter, effects don't lag, etc.

Interesting observation, but did swapping your mouse actually speed up
Unity window dragging, or would restarting Unity alone without changing
the mouse have had the same effect?

[Phil Doroff (phil21)]

Yep, absolutely confirmed that the mouse is the underlying cause. I was not one of the ones with the "slower over time" problem, it's either 100% in your face, or not there at all it seems.

I can actually do you one better. If I leave both mice plugged in, moving windows with the Microsoft mouse is very smooth, and moving windows with the logitech is choppy/unusable. I can unplug/replug these mice in, in any order, and have it exhibit the exact same behavior. I've also tried another G700 I have in the house, and it does the same thing (e.g. not simply a bad mouse).

Still looking through things, will be able to debug hopefully more in-depth tonight

[Colin D Bennett (colinb)]

@Phil,

Very interesting! If I experience the problem again, I will definitely
do some testing of different mice. However, I recall that my MacBook
Pro's trackpad also exhibited the problem as well as my Logitech
mouse. It really sounds like two very different bugs, doesn't it?

[Phil Doroff (phil21)]

I've successfully narrowed down the cause of this, and found a workaround - for my systems. I'm unsure if this will fix things for anyone else, however. I did find some items surprising here, and they may warrant a deeper look.

This all came down to USB HID mouse sampling rates. The logitech reports a bInterval of 1, which is 1000Mhz. For whatever reason (this is likely a bug, I would imagine?) compiz appears to be doing work on every mouse poll. 1000 times/sec = you get stuttering going on. At least in my case.

I also noticed throughout this that my Nvidia card was on APIC interrupts - while this did not end up being the root cause, it's certainly not good. Check that out as well perhaps, fix is:

options nvidia-current NVreg_EnableMSI=1 in /etc/modprobe.d/nvidia.conf

For now, my workaround on the performance issue is to simply limit mouse polling to something sane. This is done by creating a file (anything will do really) in /etc/modprobe.d/usbhid.conf

Add:
options usbhid mousepoll=10

- this is 125mhz, next up is 8, 6, 4, 2, and so on. Go with the lowest you enjoy - honestly I'm fine personally with 10 or 8.

I do wonder how many laptops (as reported here) utilize USB-based trackpads? I would imagine this would contribute to quite a bit of battery drain in some use cases. Good howto is here for further reading: http://wiki.quakeworld.nu/Howto_customise_mouse_polling_rate

I can't imagine there is much benefit to compiz attempting to render frames (or otherwise "do stuff") faster than a certain fail-safe. At least there should be a configured maximum somewhere - as I don't think 1000 frames/second is truly needed for my desktop window redraws :) I would imagine this bug exhibits itself more on nvidia hardware, due to needing vsync turned off as well, but that's rampant speculation.

Hopefully this helps someone out there!

[Soren ONeill (soren-s)]

Interesting indeed. I also have a Logitech mouse (MX500) - but then who doesn't?

I tried plugging it into my ps2 mouse connector (using an interface, obviously). I don't know whether it fixes my problem yet, as I am one of the ones where the problem only comes up after a while and not immediately after log-in. However, it certainly hasn't fixed glxgears at all ...

Does anyone else have the glxgears problem or is it just me?

Phil Doriff - you're fix above looks interesting .. I don't have a /etc/modprobe.d/nvidia.conf file at all ... I have a nvidia-graphics-drivers.conf but i only contains:
blacklist nouveau
blacklist lbm-nouveau
blacklist nvidia-173
blacklist nvidia-96

Running sudo modprobe usbhid mousepoll=10 doesn't fix glxgears

- Soren

[Soren ONeill (soren-s)]

..won't it just be a laugh, if the solution to our Linux woes is to buy a Microsoft mouse LOL!

[yannack (yannack)]

Hello,
I can confirm that this is indeed a mouse-related problem. On my laptop, I have no lagging issues when dragging a window with the touchpad. However, when using my mouse (Razer DeathAdder), moving windows is very slow and choppy.
Also the mousepoll options trick doesn't seem to work for me. (BTW, I have an Intel graphics card)

[yannack (yannack)]

Sorry spoke too fast, I needed to fully reboot my computer for the options trick to work ,but it did indeed solve the issue. Simply unplugging the mouse and replugging wasn't enough (even doing modprobe usbhid mousepoll=10 as suggested on the quake-related page linked above did not work either).

[Soren ONeill (soren-s)]

I'm getting optimistic :-)

I've plugged my Logitech USB mouse in via a PS2 interface and rebooted. That's more than an hour ago now, and I've not experienced the problem yet! It normally appears after 15-30 minutes. Problem solved?!

However, glxgears is still not working: no glxgears and no output into bash and not possible to switch focus to another window ... but I can ctrl-c and kill glxgears after which glxgear output is listed in bash (framerate supposedly 15.000+) and I get desktop control back :-)

[Phil Doroff (phil21)]

Soren -
I haven't had a chance to even take a look at glxgears yet, I will tomorrow and see if I can get the same behavior you're seeing.

I can confirm that while the "mouse fix" works every time for me now, there are definite lingering "slow performance creepage" problems going on as well. I was just hit with the same stuttery windows (confirmed that at least mouse input was still at 125hz), and then compwiz crashed after a few minutes of this. When it came back, it's smooth again.

In short, there is a definite USB (at least!) input device sampling issue that needs addressing, but there is very much likely more to the story. I'll reply to your specific questions OOB, so as to not spam the list.

yannack -
I actually came back before bed to post due to something almost like that. After a reboot, I noticed the laggyness again - quick look showed the mouse back up to 1000Mhz sampling rates. So apparently the USB hid driver is being loaded prior to it being re-loaded for final system boot. Makes sense, so you can interact with the kernel during it's bootup process if needed.

This puzzled me a little, and still does - but I've been able to get the mouse to reset to 125Mhz by simply plugging it into a different USB root hub. You can then switch it back to the original port, and it will again negotiate at the desired mousepoll rate. So seems like there is some "caching" going on, I just am too tired to investigate exactly where/why.

So, work around above likely will help some users - but there is a lot more debugging to be done!

[Soren ONeill (soren-s)]

Not so optimistic now :-(

the lag is back despite using the (USB) mouse connected by PS2

[isecore (isecore)]

This whole mouse-polling thing might be onto something.

I have a Phenom II X4, with an ATI Radeon HD 5870. Moving windows and icons was jerkier than Kathryn Hepburn on bad acid. My mouse is a Razer DeathAdder Respawn (the 3500 dpi version) which I normally have set to 900 dpi, and running a pollrate at 1000hz.

This mouse remembers the settings between boots, so I dualbooted into Windows, lowered the polling rate to the default 125hz and rebooted into Ubuntu. Lo and behold, dragging windows and icons was SUBSTANTIALLY smoother. Still not as smooth as before I upgraded from 10.10 to 11.04 but now it's actually tolerable.

[Phil Doroff (phil21)]

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 e...

[Soren ONeill (soren-s)]

120$ spent and none the wiser :-(

Went out and bought a microsoft natural ergonomics 4000 keyboard and a microsoft mouse Arc touch.

Both will take some getting used to, but they certainly don't fix my compiz problems...

[yannack (yannack)]

I don't think this bug is a duplicate of #770160. Reading the reports, it seems that bug happens after a while, whereas this one is immediate for me, and directly linked to the mouse refresh rate.

[Sean G (sean-gilbertson)]

Adding more confirmation to the pile, in the hopes that someone actually FIXES THIS!

I have an i7 laptop with an NVIDIA GTX 460M (1.5GB vram). When I move windows with my external mouse (a Razer Orochi, plugged in; not in bluetooth mode), I get major choppiness. When I move windows with the trackpad, I get no slowdown at all.

It sounds to me like the users have done an excellent job tracking down the precise problem. How about some dev support on this?? Sounds like a pretty easy fix to me!

[Colin D Bennett (colinb)]

This bug does not appear for me. I do not have any slowdown when dragging windows with the mouse. There is no lagging or choppiness. I am using a Logitech MX310 wired USB optical mouse on Ubuntu 11.04 (Ubuntu Classic session: Gnome w/ compiz enabled). I have not changed any options such as poll rate. (“cat /sys/module/usbhid/parameters/mousepoll” reports “0”.)

I do, however, experience the gradual slowdown bug, where switching windows with alt-tab, switching workspaces, and scrolling through a document by dragging the scrollbar thumb all become ridiculously and unbearably slow. That bug appears after multiple days to several weeks of uptime. I can recover from the slowdown by logging out and back in again, but that is annoying since I keep many different special workspaces and programs up all the time.

[Sean G (sean-gilbertson)]

FYI, this works for me: options usbhid mousepoll=10

[Soren ONeill (soren-s)]

"It sounds to me like the users have done an excellent job tracking down the precise problem."

..actually I suspect there are two different issues here, as:
- some report it as an immediate problem present from boot-up and others as problem that gradually appears after a while
- some report only lagging when moving windows about, others also find lagging with the keyboard
- some have reported actual crashes of compiz/X others have not
- some have found replacing the mouse with a non-logitech fixes it, other have not
- ditto for the mouse polling variable
- and then theres the glxgears question ... does it work for the rest of you

[Soren ONeill (soren-s)]

Actualy - I've just realised, that despite nVidias driver being installed from repository, it didn't function correctly

I've downloaded the lastest from nVidias site and managed to install it (with some difficulty) - glx gears is now running smoothly ... can't wait to see how it affects the unity issues... i'll let you all know

[Soren ONeill (soren-s)]

Nah! Despite new nVidia drivers, I still get the slow-down after a (longer) while.

In my case, it's not just the moving windows around which is slow, but also typing, unfolding menus, scrolling etc - the whole user-interface.

If I run glxgears now (after the slowness has set in), I'm getting 10 fps again and everything else slows to a standstill until I kill glxgears, after which it's back to the regular slowmotion.

This is a serious and very annoying bug, which seems quite common as well :-(

[Soren ONeill (soren-s)]

Now thats interesting.

Last night I installed a new nVidia driver and got it working fine.
Booted up this morning - that was fine as well

After a long(!) time - several hours as opposed to 20-30 minutes, I got the slow-down again. Logged out and in again and it seemed to work. Shut down. Booted up and hey presto - my new nVidia driver not working again!? Had to uninstall the nouveau driver and re-install nVidia - now working again.

So it seems to me, that after a while the driver-unity-glx combo (or whatever) becomes so corrupt, it actually harms the xorg setup ... or perhaps I'm just being a cleverdick-ignoramus :-)

[gbmidd (gbmidd)]

I have experienced this problem as well, with an Intel 965 graphics kit. I tried the mouse-polling fixes suggested here (I often use Logitech USB mouse), but they didn't seem to make much of a difference for me.

Today this issue had deteriorated my desktop to near-unusability. My uptime was 6 days under heavy use, lots of suspend/resume, so I checked the system monitor to see what was going on. I noticed what I thought was an anomaly: unity-panel-service used nearly 105 Mb RAM, well above the ~6ish it uses when it launches. This memory leak is documented elsewhere (#779185), but this is what's interesting:

when I killed unity-panel-service from the console, it immediately restarted as expected...but the window dragging issue went away immediately. I wonder if anyone else can confirm this? There may be a connection between the memory leak and the behavior we're seeing here.

[Achim (ach1m)]

gbmidd, I can confirm your observation. But I have to note that the slow windows come back very quickly.
Also the unity-panel-service doesn't use that much memory in my case. I think you should also take a look at this Bug #770160.
The difference is that people here are seeing slow windows not only after some time but rather all the time.

[vdry76 (vdry76)]

The interesting thing thing about this bug is, on my Razer mouse I have a hardware toggle switch on the bottom to switch between 125hz and 1000hz polling options. If I switch to 1000hz (which is my usual) I get the large window skipping problems when dragging them. When I switch to 125hz it's perfectly smooth. Neither setting seems to correct glxgears running at a seemingly VERY low FPS and still reporting very high frame rates.

[Jeffrey brydges (jeffreybrydges)]

Hey everyone,

I had no success using the sync to vblank, but have had success with the mouse polling. In windows I set my Razer mouse to 125hz, and the window slowness went away. There is an option in the compiz settings manager for mouse polling. I went in there, changed it to 2 (500hz), went into windows, changed my mouse back to 500 and voila, it still works.

I suggest that if you have had no luck with vblank, change the polling settings in compiz and see if that helps.

[Phylock (phylock)]

My problem was a laser mouse, to be exact "Steelseries Ikari Laser Mouse". The problem showed as lag when I dragged a window around the screen. No problems with scroll, glxgear or slowness over time.

This fixed my problem:
Remember to do a backup of xorg.conf.

first my auto generated mouse section in "xorg.conf" from when I installed Ubuntu

Section "InputDevice"
 Identifier "Mouse0"
 Driver "mouse"
 Option "Protocol" "auto"
 Option "Device" "/dev/psaux"
 Option "Emulate3Buttons" "no"
 Option "ZAxisMapping" "4 5"
EndSection

I replaced it with this section instead, notice the driver is now "evdev"

Section "InputDevice"
 Identifier "Steelseries Ikari Laser Mouse"
 Driver "evdev"
 Option "Device" "/dev/input/by-id/usb-SteelSeries_ApS_Ikari_Laser-event-mouse"
 Option "ZAxisMapping" "4 5"
EndSection

Change device to your mouse id or maybe "/dev/input/mice" will work as well(haven't tried).

[Soren ONeill (soren-s)]

I've tried installing Fedora 15 including the proprietary nVidia drivers and I get the same problem o that installation ...

[Soren ONeill (soren-s)]

Fedora was Gnome 3 btw ... I like!!!

[Cody Nybo (cmnybo)]

I had this problem too. I was able to fix it by changing the mouse settings in xorg.conf I am using a Logitech G500 mouse.
Use man mousedrv to find the list of valid protocals.

I changed my mouse section too

Section "InputDevice"
    Identifier "Mouse0"
    Driver "mouse"
    Option "Protocol" "Logitech" # was auto
    Option "Device" "/dev/psaux"
    Option "Emulate3Buttons" "no"
    Option "ZAxisMapping" "4 5"
    Option "SampleRate" "1000" # i added this to take advantage of the G500's 1000Hz sample rate
EndSection

The settings applied when I reconnected the mouse.
Also the problem went away when I swapped with a crappy 10 year old microsoft mouse.

[Alexei Colin (alexei.colin)]

Call me crazy, but in my case the severe lag on moving windows shows up *only* when Firefox >= v4.0 is running.

In fact, the lag is proportional to the number of Firefox windows open (but not to the number of tabs). The Firefox window state and which workspace it is in relative to the window being dragged does not matter. Reproducible with about:blank and in Firefox safe-mode (no add-ins). No other application (tried a few: from Chrome open to GIMP) causes any lag regardless of number of windows, also Firefox v3.6 does *not* cause the lag either (so I downgraded for now). Yes, it sounds crazy -- but that's it: the fewer Firefox windows open, the less lag, and no lag when Firefox is not running!

Why? My only wild guess is: Firefox 4.0 is the first one that came with Unity integration (however, I have the "menu bar integration with Unity" disabled... and Unity turned off). In any case, its tab control is noticeably different from v3.6 (and feels like it comes from outside of Firefox -- pure speculation). It might not be Firefox's fault, but it does something to bring up the problem wherever this problem is.

Different mice (Thinkpad's trackpad, trackpoint, external Logitech wireless) exhibit noticeably different degrees of lag -- so it does seem mouse related in some way. Setting mousepoll=10 (and confirming it had that value after reboot) makes no difference (for the usb mouse). Killing unity-window-decorator and moving window using context menu's Move also lags in same way. Playing with above-mentioned params in compiz config makes no difference. Restarting compiz makes no difference -- lag disappears after Firefox is closed *without* any restart.

System:
Ubuntu Natty, Radeon X1400 with open source drivers
gnome-panel+compiz (Unity turned off)
All other actions in compiz e.g. cube are smooth regardless of whether Firefox is running, although when Firefox is running, there is a lag when rotation is initiated.

[Tytus Mak (tytus-mak)]

I have the same issue, with a Logitech G500 mouse.

I find that if any application opens up secondary windows, like say a search/replace dialog boxes, or even too many menus, then there seems to be some sort of buffer that fills up and makes window dragging more and more choppy.

This is usually resolved by simply closing and restarting that application.

it's a very annoying bug, and like everyone else here has said, if I plug in an old Microsoft mouse the problem goes away completely.

[Jean-Christophe Baptiste (jc-baptiste)]

I found an interesting behavior with my Nova X600 laser mouse.
It has some buttons on it to switch between modes with different frequencies.

Whenever I press it, window moving becomes smooth for a few second (approx 30s). Then, it becomes extremely laggy again.
I can reproduce it all the time. Note that it doesn't matter if I change the frequency up or down. The only fact of changing seems sufficient to "reset" this lag problem.

Otherwise, like almost everyone here, every thing else is smooth, and the compiz settings have no effect.

[kslen (pewpew)]

I just got my smooth window movement back by applying Phil Doroffs usbhid polling solution. Thanks a bunch!

[Michael Mistretta (michaelserious)]

I was also able to correct this with Phil Doroff's solution by changing the usbhid polling by setting it to '10'. My mouse was a Saitek Cyborg R.A.T. 7, seems to be working great now, thanks!

[Thad E Ginathom (thad-7)]

Ubuntu 11.04; ATI Radeon HD 4290 (integrated on Gigabyte GA-890GPA-UD3H); 3.2Mhz AMD 955; 4Gb DDR3.
Driver Packaging Version 8.84.6-110324a-116088C-ATI
OpenGL Version 3.3.10665 Compatibility Profile Context

I just gave myself this problem tonight, and got rid of it again. No change of mouse, keyboard or HID settings (although I will look into those mouse polling settings)

Made various changes to the Compiz settings. Of course, I did not document them, but they included adding an animated skydome and changing transparency settings for the cube to give some transparency when not rotating. Apart from that, I think that changes were minor, such as changing the mouse button to change viewpoints, and changing the brightness for menus. "including but not limited to".

Having made everything very pretty, I then found I could not move a window, using the mouse, without this lagging-behind effect. Moving the mouse back and forth even made the window spring forward and back again. CPU activity remained at minimum.

After making a satisfactory set of tweaks, I always use Ubuntu Tweak to back up my settings. I reverted to my last-backed up good setting. No more lagging windows --- but a bit of tearing at the window edges.

Exploring Catalyst Control Centre (AMD/ATI proprietary drivers/software) I selected "Enable Tear Free Desktop" under Display Options. This improved things a lot. There are reports here of similar problems with different hardware: this fix is obviously hardware/driver specific.

[Thad E Ginathom (thad-7)]

I should have mentioned... Classic login. No Unity implications.

[Reet (rtowsley)]

Phil Doroff,
Thank you very much for your investigation to this problem. I have had this issue since 11.04, and now with 11.10 Ubuntu. On both these versions I installed gnome-shell and had no problems with window movement and general animation jitters.

I've changed my mousepolling to "10" which has solved this problem.

Instructions for anyone who would like to replicate my solution:

sudo gedit /etc/modules

Append the following:
-r usbhid
usbhid mousepoll=10

Save the file and reboot. To verify that the setting is in effect, run the following command:
cat /sys/module/usbhid/parameters/mousepoll

If the result is "10", you have succeeded. You should also now have smooth window movement.

[Yao (chunlinyao)]

I found on my computer ,if the glxgears runing, window move is more faster.
If I close glxgears, Other window move choppy

Ubuntu 11.10
kernel 3.0.0-12-generic-pae

name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB,
    GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap,
    GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control,
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
    GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS880
OpenGL version string: 2.1 Mesa 7.11
OpenGL shading language version string: 1.20
OpenGL extensions:
    GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture,
    GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array,
    GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip,
    GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels,
    GL_EXT_point_parameters, GL_EXT_rescale_normal,
    GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp,
    GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_framebuffer_sRGB,
    GL_ARB_multitexture, GL_EXT_framebuffer_sRGB,
    GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix,
    GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
    GL_EXT_secondary_color, GL_EXT_texture_env_add,
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
    GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent,
    GL_NV_texgen_reflection, GL_NV_texture_env_combine4,
    GL_SUN...

[Solnyshok (solnyshok)]

Ubuntu 11/10, Intel graphic (Core i-540m) amd64 with 8GB RAM
and LOGITECH wireless G700
I noticed that window movement with mouse is very laggy, while using touchpad it is smooth. So I googled "compiz window move mouse touchpad" and found this bug. This solution worked

sudo gedit /etc/modules
Append the following:
-r usbhid
usbhid mousepoll=10

Thanks Phil, Reet and Co.

[Jan (jan-tux)]

Ubuntu 11.10 nvidia with Cyborg RAT 5
Changing the mousepoll works fine. I use 5 as pollrate, otherwise the my mouse moves very slow.

I add a separate file into /etc/modprobe.d, instead of unloading and loading usbhid module via /etc/modules

sudo gedit /etc/modprobe.d/bug-764330-usbhid.conf

add following line:
options usbhid mousepoll=5

save file and update ramdisk
sudo update-initramfs -u

Thanks to all

[Daniil Bubnov (demoth-cadaver)]

hi! had this bug, used this fix
http://www.urbanterror.info/forums/topic/21844-howto-changing-mouse-polling-rate-on-ubuntu/
helped me

[Kristijan Puljek (sampleofsoul)]

Of all the things I thought were related to this bug, this one really eluded me.
I can confirm that the bug is gone if I replace my Razer Copperhead with a random generic 10$ Genius mouse. After messing with mouse polling, razer is a lot usable, but still it's choppier than what I get with the Genius mouse (over 9000 fps)

[Andrew McNamara (andrewm-object-craft)]

I can confirm the usbhid setting addresses the problem for me (Logitech G500). It was also possible to change while the compiz desktop was running by "echo 4 > /sys/module/usbhid/parameters/mousepoll" as root, then unplugging and replugging the mouse.

[Jean-Christophe Baptiste (jc-baptiste)]

I didn't fix anything for me.
By the way, I started to use Gnome-shell and the windows are not lagging at all there (tough there are other graphical glitches, thanks ATI for the great driver). :(
It probably confirms the laggy windows is caused by a specific issue between Compiz/Unity and ATI.

[Moko (haohmaru2040)]

Changing the mouse poll rate doesn't fix the problem for me either (oneiric, geforce gt240m, logitech performance mx mouse).
choppyness happens with all my (logitech) mice and also the internal touchpad.
But the choppyness is gone, the moment I release the mousebutton and stop moving the mouse. You can see it, by enabling wobbly windows....the moment I release the button it becomes smooth as butter.
So there must be something different interfering while using the mouse, besides an uncorrect mouse poll rate, which seems to fix the problem for some people

[Mark Mandel (mark-mandel)]

Big thanks to ~jan-tux - that made a huge difference. It's like night and day.

(Razer Imperator mouse)

Awesome.

[jefdebruges (jefdebruges)]

I tried the various solutions in this thread, without success. With Unity 3D I experience a laggy smooth scrolling in Firefox as well (with the smoothwheel plugin), apart from the strange behaviour when moving windows. Unity 2D works fast, scrolls great in Firefox, but gives me the already old bug of video tearing when playing video. Only Gnome3 works reasonably fast without general lagginess. Pity, because I like unity3D the most in terms of appearance and productivity.

AMD X4 620, 4GB, integrated ATI HD4200 graphics, open-source drivers

[DJ (ke7mbz)]

I have this bug with a Nvidia GT430, 4GB mem, AM2 X2, Ubuntu 11.10 64 bit. However, I haven't had it on my laptop which uses Intel graphics. But I always use the touchpad there. It happens after unity has been running for awhile. ctl+f2 then unity --replace always fixes it temporarily. If I had a dollar for every unity --replace I've done since 11.04...

But, honestly, I like Unity. Just getting tired of the bugs. It runs great on my laptop. 32 bit, not 64. 64 bit has java applet problems. If stability is paramount, I advise waiting at least until 12.04 to try Unity.

I also found that restarting Firefox fixes it for awhile. This makes me think that there's a memory leak somewhere. Fortunately unity --replace fixes most mem leak issues for awhile. Pretty common with the Nvidia and ATI drivers. I haven't had any problem with Intel. I know that there's a slow Xorg and Compiz mem leak. It was much worse before I replaced the onboard ATI with the Nvidia GT. Oh, I'm so tired of memory leaks :-(

You can check this out by running top in the terminal. The actually percentage isn't as important as just comparing it to what's normal for that process. Xorg usually starts out below 1% and slowly creeps up. Compiz starts around 2%, and rises more quickly. I usually get a noticeable slow down at around 5%.

I restarted firefox about 10 min ago, and the choppiness is back already.

I'm also wondering whether this problem exists on a 32 bit install, or if it's just a 64 bit issue. I've generally found the the 64 bit system is more abundant in bugs.

I haven't tried the mouse polling trick yet. It doesn't sound like it always works. It could be that the mouse is somehow exacerbating the memory leak.

I also tried running in Gnome-Shell, and had no problems there, but I only used it for a day or two.

[DJ (ke7mbz)]

One other point: I have doubts about the mouse controller being the cause. My computer can be working fine, then I'll leave and come back several hours later and the problem is back. I can't see how the mouse can cause problems when it's not being used. More likely, it's just compensating. Like walking slower when your tired. But eventually your going to have to eat something or take a nap. I think the real culprit here is Compiz. There's a big memory leak with certain graphics drivers. Obviously, though, not everyone's having the same issue. Just similar symptoms.

[Rurouni (rurouni)]

Also affects me:

Ubuntu 11.10 becomes absolutely laggy when I move a window or scrolling firefox.

I have a Logitech Laser Mouse (LS1), so I tried the "usbhid" workaround with no results.

Also I tried this workaround, and also without results:

http://ubuntuforums.org/showthread.php?p=11469148

10 minutes after login in my system, compiz uses continously the 6% of the CPU and 350Mb of RAM. As the time pases, the system become slow... very slow.

My system specs:

* Ubuntu 11.10 (3.0.0-14-generic-pae) with Unity
* Dell Vostro 1500 (Laptop)
* CPU: Intel Core2Duo 2.2Ghz, 4Gb RAM
* GPU: nVidia Corporation G84 (GeForce 8600M GT, 1Gb). Propietary driver: 290.10

The only Compiz plugin I've activated is "Show all windows", that works perfectly but some times hangs half a second and takes almost 90% of the CPU.

[Wessel Dankers (wsl)]

Issue got fixed for me after applying recent updates.

[Matt Pharoah (mpharoah)]

The mouse polling fix worked for me.

[Thomas Schüßler (vindolin)]

I'm also affected.
Slow scrolling, sluggish window movement.

What I noticed is that when I close all Gecko applications (Firefox/Thunderbird/KomodoIDE) everything is snappy again!
After reopening those apps everything starts slowing down again (over hours).

My system:
   Linux Mint 11 (Ubuntu 11.04) 64bit
   Nvidia 8600M GT
   NVIDIA Driver Version: 290.10

[Achim (ach1m)]

Can someone raise the importance to high please.

[Thomas Schüßler (vindolin)]

I think I've found the problem.. at least for my setup.
I disabled Hardware Acceleration in Firefox (8).
No slowdowns for 8 hours now.

[Matteo De Wint (mdwint)]

This bug affects me as well, and changing the mouse polling rate does not seem to fix anything. However, I did notice the problem only occurs when moving a window more than once. The first time a window is moved, it always goes smoothly. Can anyone confirm this behaviour?

[Matt Pharoah (mpharoah)]

#86 yes I can confirm this behavior
Interesting, I just discovered that #33 's mouse polling fix only works on ONE of my usb ports o.0. I really don't understand that, but for some reason only 1 port is affected by the fix.

I'll have to do more testing, but I THINK that it works on ANY usb port so long as the mouse is plugged into it when the laptop starts, but once you unplug the USB port, it only works on 1 port (not the one it was originally in when you started the computer, but a specific one).

I have a System76 Gazelle laptop with 3 USB ports on the left side and 1 on the right side. The fix only works when I plus the mouse into the port on the right.

[Dennis-martin-herbers (dennis-martin-herbers)]

I can confirm this, #86. It also slows down if you move (for the first time) the window to the top or left/right border, so how you would use the "Aero Snap" or whatever it is called.

[Rurouni (rurouni)]

Hi!

I also confirm what #85 said: disabling the "Hardware Acceleration" in Firefox makes the system usable. I was one step from installing Lubuntu...

But, there is still some problems related: Compiz uses lots of memory and the 6% of the CPU (and any little move increases it to 20% or more).

Thanks!

[Daniel van Vugt (vanvugt)]

Hey all... Although this bug has been around for the longest, a fix has been proposed in bug 773861 so I'm marking this as a duplicate of that one. Sorry I didn't find this bug sooner.

[Goddard (kinggoddard)]

How can this bug be a duplicate when it came before 773861? Just curious.

But hey unplugging the mouse worked for me as well, but I use the ASUS Republic of Gamers mouse. Is this considered a Logitech mouse?

[Daniel van Vugt (vanvugt)]

Tagging as a regression. The netbook I can reproduce the bug on used to work quite nicely with Ubuntu 10.04. The bug only happened after I upgraded it (clean install).

[Daniel van Vugt (vanvugt)]

I've added a possible fix to ppa:vanvugt/compiz. Wait a few hours at least, and it will appear as version 1:0.9.6+bzr20110929-0ubuntu6vv9

The fix works wonders on a little old netbook that has this bug, but let me know if it works for you. But before commenting, please do ensure you have the same bug as is described in the title and is shown in the videos attached by glazs.

[Alexander Dobetsberger (masternoob)]

fix worked for me...

thx for the good work!

[Dennis-martin-herbers (dennis-martin-herbers)]

Wow, you legend! vv9 has fixed this issue for me and so now I have no performance issues left, it's all working great! Please tell me all the good stuff gets upstreamed before 12.04!

[Bruno Santos (bsantos)]

vv9 is much better (almost perfect)!
I only get drawing corruption while resizing some apps (nautilus and firefox were the ones I tried), but the resizing is smooth and immediate (less when the corruption occurs) on the ones that work well.

Don't you get this drawing corruption while doing a fast resizing with the normal resizing mode (which is the only one I find useful to resize windows to fit the content)?

[quequotion (quequotion)]

Good News first:

vv9 is very smooth!

With vv8, I had smooth window movement only on freshly mapped windows.
After being remapped (like after being moved) the window movement became choppy.
This behavior was similar to my experience with the main and proposed packages.

With vv9 the windows stay smooth even after being remapped!
Excellent work! I really appreciate it!

Bad News next:

Dragging windows around the cube fails in a very odd way.
The cube starts to rotate, with the window, then snaps to the next workspace but leaves the window behind.
The mouse is still able to move the window although they are on different sides of the cube (O_o).
The breakage occurs when windows from the previous workspace momentarily flash on the current one ( bug 876198 )

I suspect that bug has some relationship with the screen redraw issues you've been working on.
I don't want to open a new (duplicate?) bug report, since both the packages and the settings I use are unsupported.

[Peter (kzq-lutar-x8o)]

Hmm, It's much better, finally no lags (some slight delay still there).

But I remember previous version and it was much smoother (I'll try live
distro to compare of stable debian :o) ). I have monitor with 120Hz and
difference is visible.

BIG Thanks for working on it, put on ubuntu paypal donation link ;-) I
think Im gonna stay with ubuntu.

W dniu 20/12/11 19:11, quequotion pisze:
> Good News first:
>
> vv9 is very smooth!
>
> With vv8, I had smooth window movement only on freshly mapped windows.
> After being remapped (like after being moved) the window movement became choppy.
> This behavior was similar to my experience with the main and proposed packages.
>
> With vv9 the windows stay smooth even after being remapped!
> Excellent work! I really appreciate it!
>
> Bad News next:
>
> Dragging windows around the cube fails in a very odd way.
> The cube starts to rotate, with the window, then snaps to the next workspace but leaves the window behind.
> The mouse is still able to move the window although they are on different sides of the cube (O_o).
> The breakage occurs when windows from the previous workspace momentarily flash on the current one ( bug 876198 )
>
> I suspect that bug has some relationship with the screen redraw issues you've been working on.
> I don't want to open a new (duplicate?) bug report, since both the packages and the settings I use are unsupported.
>

--
Peter Fronc

<email address hidden>

[Daniel van Vugt (vanvugt)]

The fix is only designed to sample the mouse at 200Hz, so I think according to the Nyquist–Shannon sampling theorem[1] it will only look smooth on monitors up to 100Hz. I could raise the rate to 250Hz to try and cover the case of 120Hz monitors, but I think other timing issues in compiz might still make it look imperfect on displays above 100Hz. Maybe I should make it a config option, perhaps as a separate enhancement later...
[1] http://en.wikipedia.org/wiki/Nyquist-Shannon_sampling_theorem

The "slight delay" issue is a different bug to do with the hardware cursor (Xorg option "HWcursor") and compiz lagging a frame or two behind. Not sure if we have a bug ID for that problem yet.

If you have resizing issues, please log a new bug. Preferably with video.

[Daniel van Vugt (vanvugt)]

OK, I've made the sample rate configurable in the new version (vv10 -- may take a few hours to be published). Just look in ccsm for the new setting.

You can also set the sample rate to zero for maximum smoothness (and the highest CPU usage) on fast machines.

[Soumyadeep Chanda (deep-fatality)]

Is this fix included in compiz for 12.04 also?

[Daniel van Vugt (vanvugt)]

I am certainly trying my best to get it reviewed and into compiz 0.9.6-final for Ubuntu 12.04.

[Daniel van Vugt (vanvugt)]

Handing this bug over to smspillaz. He says he has a better fix than mine in the pipeline for Ubuntu 12.04. And we can't accept both fixes because they overlap and conflict.

[Daniel van Vugt (vanvugt)]

Sam, please try to give the subscribers to this bug have something to test, either in a precise-alpha release, or a PPA for oneiric.

[Bucic (bucic)]

I'm too of a noob to call it relevant with certainty but yesterday all was running rather smooth for me and today it doesn't. While not noticeable that much in the desktop browsers suffered particularly. I couldn't watch low q youtube neither with flash nor with html5. Choppy scrolling too.

The only thing I recall I've done to my system is an update from the test ppa. I restored my disk image from yesterday and it all runs similarly 'rather smooth' again. After the update I ran the updater to see how my backup differed (update-wise) from my todays install that was struggling so much. I see:
Installed version: 1:0.9.6+bzr20110929-0ubuntu6vv9
Available version: 1:0.9.6+bzr20110929-0ubuntu6vv10 and other vv9->vv10 packages from the ppa

Other packages are insignificant IMO:
clementine beta, I don't use anyway and libt1-5

Thinks I did before backing up my nicely performing install:
- changed: from GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm="force" i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 radeon.modeset=0" to GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm="force" i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1"

I hope I'm not wasting anybody's time.

[Daniel van Vugt (vanvugt)]

Bucic, this bug is about moving windows only. Your comments suggest you experienced a different bug/regression.

[Daniel van Vugt (vanvugt)]

Note: This bug is made much worse by bug 861061 in some cases. So make sure you have a fix for that one such as is in ppa:vanvugt/unity before testing fixes for this bug.

[val.kotlarov.hoffman (val-hoffman)]

I hope someone already mentioned, if not I've noticed that-

The 'hanging' during the dragging of a window happens when you move it fast (like from the one side of the screen to another), but!! if you move it also fast -- by only by 1-5 pixels or so then it doesn't hang and responds ok.

[Helmut (debesh)]

Just to confirm: using compiz vv10 from ppa:vanvugt/compiz makes moving windows smooth as silk again -- reliably since a couple of days now. Thank you so much Daniel!

[Jeroen Hoek (mail-jeroenhoek)]

Indeed, window dragging has been smooth for me as well for a while. Hopefully Precise will not become a regression for us.

Thanks for the great work Daniel.

[Dennis-martin-herbers (dennis-martin-herbers)]

Can you rebase for compiz-plugins-main 0.9.6-0ubuntu4.2?

[Daniel van Vugt (vanvugt)]

This bug is not related to compiz-plugins-main. The move plugin is in the compiz-plugins-default package, which comes from the "compiz" source package. See: dpkg -S /usr/lib/compiz/libmove.so

However I will rebase compiz-plugins-main for the other bugs it relates to...

[val.kotlarov.hoffman (val-hoffman)]

Thanks Daniel, for me too, the ppa:vanvugt/unity fixed the problem.

[Goddard (kinggoddard)]

thanks for your work Daniel.

On Sat, Jan 7, 2012 at 2:21 AM, vhof <email address hidden> wrote:

> Thanks Daniel, for me too, the ppa:vanvugt/unity fixed the problem.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (903395).
> https://bugs.launchpad.net/bugs/764330
>
> Title:
> [regression] Moving windows lags behind the mouse by 1-2 seconds;
> appear to freeze when dragging.
>
> Status in Compiz:
> Confirmed
> Status in Compiz Core:
> In Progress
> Status in “compiz” package in Ubuntu:
> In Progress
>
> Bug description:
> Binary package hint: compiz
>
> I have fast machine( 4gb of ram, amd64 x4, nvidia 460 ), using
> proprietary nvidia driver.
> Natty b2 x64, updated yesterday.
>
> Windows move very slow, but only by mouse. Windows moving fast by Put
> plugin.
> lasy_positioning is enabled.
>
> Disabling wobbly windows and switching window decorator not helping.
> video:
> http://images.rock.su/bugs/move.ogv
> When video is recording, windows moves much faster. Maybe problem with
> screen redraw.
> If you need, i can record video by camera, windows moving unreal slow
> when video not recording.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz/+bug/764330/+subscriptions
>

[Simon Hirscher (codethief)]

The fix works perfectly. Thanks, Daniel!

[Tamale (uictamale)]

Please let me be noted that this newer version of compiz (from ppa:vanvugt/compiz) runs absolutely beautifully for me:
AMD Mobility FirePro M8900 / Dell M6600 / two external 1080p monitors + the laptop 1080p screen / open source radeon drivers / ubuntu 11.10 / standard unity.

Dragging windows used to start out slightly sluggish, then after a few minutes they became so slow it was almost impossible to use. Now it's smooth as silk and most importantly it STAYS that way - even with many windows slightly transparent. Kudos, and please make sure this gets into 12.04!

[Miklos Juhasz (mjuhasz)]

Great work, Daniel!

One thing I noticed: if I move a window with Alt+F7, the mouse pointer turn into a hand and is positioned to the center of the active window (so far so good) but when I press an arrow to move the window it suddenly jumps to an unspecified location, even out of the current workspace. I can still drag it though but the hand-shape mouse pointer and the window itself can be far away from each other. This renders the move feature pretty much unusable.
I tested on 2 machines with compiz from the repository and also from your ppa. It is a regression of one of your patches. I will take a look if I have some time on my hands but if you have an idea I would appreciate it. I'd like to keep your patches but move windows with Alt-F7 as well.

[Simon Hirscher (codethief)]

I can confirm the issue Miklos is having. However, for me it only
jumps the first time I press an arrow key. All subsequent key presses
work as usual until I disable Alt+F7-moving again (by clicking /
pressing ESC / …).

On Thu, Jan 12, 2012 at 21:47, Miklos Juhasz <email address hidden> wrote:
> Great work, Daniel!
>
> One thing I noticed: if I move a window with Alt+F7, the mouse pointer turn into a hand and is positioned to the center of the active window (so far so good) but when I press an arrow to move the window it suddenly jumps to an unspecified location, even out of the current workspace. I can still drag it though but the hand-shape mouse pointer and the window itself can be far away from each other. This renders the move feature pretty much unusable.
> I tested on 2 machines with compiz from the repository and also from your ppa. It is a regression of one of your patches. I will take a look if I have some time on my hands but if you have an idea I would appreciate it. I'd like to keep your patches but move windows with Alt-F7 as well.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/764330
>
> Title:
>  [regression] Moving windows lags behind the mouse by 1-2 seconds;
>  appear to freeze when dragging.
>
> Status in Compiz:
>  Confirmed
> Status in Compiz Core:
>  In Progress
> Status in “compiz” package in Ubuntu:
>  In Progress
>
> Bug description:
>  Binary package hint: compiz
>
>  I have fast machine( 4gb of ram, amd64 x4, nvidia 460 ), using proprietary nvidia driver.
>  Natty b2 x64, updated yesterday.
>
>  Windows move very slow, but only by mouse. Windows moving fast by Put plugin.
>  lasy_positioning is enabled.
>
>  Disabling wobbly windows and switching window decorator not helping.
>  video:
>  http://images.rock.su/bugs/move.ogv
>  When video is recording, windows moves much faster. Maybe problem with screen redraw.
>  If you need, i can record video by camera, windows moving unreal slow when video not recording.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz/+bug/764330/+subscriptions

[Daniel van Vugt (vanvugt)]

Well, the good (bad) news is that my fix for this bug has been rejected because smspillaz apparently has a better fix. So any regression I introduced in the PPA probably won't be in 12.04. The bad news is that I haven't been able to test or verify the new planned fix yet.

[Alexander Dobetsberger (masternoob)]

will the fix of smspillaz make it into 12.04 and is there a way to test his fix?

[Miklos Juhasz (mjuhasz)]

@Simon: Same for me: subsequent keypresses work as usual.

@Masternoob: smspillaz's fix is still under review. At the moment I am not aware of any way to test it. It's too big (3436 lines) for me to merge and upload it into my ppa since I am afraid of regressions with a patch of this size, especially without tests. That's my opinion, not Daniel's (just to make it clear).

[Miklos Juhasz (mjuhasz)]

@Daniel:

I would still prefer to use your fix as the best available solution for now but I'd like to fix the Alt+F7 move behaviour.

By debugging move.cpp a bit I checked the difference between mouse and keyboard movement. It turned out that

- when Alt+F7 is pressed moveInitiate is called and ms->lastRootX gets updated to the current position of the pointer, say 1012
- then the pointer turns into a hand and jumps to the middle of the window to be moved
- when I press the arrow buttons for the first time updateMotion gets called and in there pointerX has the value where the pointer is _after_ it jumped to the middle of the window to be moved (say 362) therefore moveHandleMotionEvent thinks that the window has to be moved by 1012-362=650px and the window jumps to the left, partly out of the current workspace.

So, in short, when Alt+F7 is pressed the ms->lastRootX should be updated to the pointer position when it's _already_ in the middle of the window to be moved, not where it was before we initiated the movement. (Same goes for y values of course).

Do you have any idea how to do this?

[Daniel van Vugt (vanvugt)]

Miklos, I think it is safe to say the Alt+F7 bug is a different bug, in the move plugin (compiz-core project). Please log a new bug for that.

The fix might be simple as you suggest. Sorry I don't have time to investigate right now.

[Miklos Juhasz (mjuhasz)]

Daniel, this bug is a regression of your patch which, as you stated earlier, will not be merged into compiz so there's no reason to open a bug for it.

[Miklos Juhasz (mjuhasz)]

It's not going to be used, but for the record, one more regression for your move.cpp patch: it triggers lp: #860257 which is caused by lp: #860304

[Daniel van Vugt (vanvugt)]

A new simplified fix for this bug has been proposed and uploaded to ppa:vanvugt/compiz. Please wait for it to build (version vv11).

[Alexander Dobetsberger (masternoob)]

is this the fix of smspillaz?

[fldc (fldc)]

Daniel: any chance of a forward port of this to precise on your ppa while we wait for the other repo to be merged in the future? :D

[Miklos Juhasz (mjuhasz)]

Thanks, Daniel! I built compiz with the new fix right away locally and has been running it for about 2 hours. No lagging yet, and it does not suffer from any of those regressions I found with the previous patch.
I'll report back if I find something.

[Daniel van Vugt (vanvugt)]

Alexander: No, this is my fix.

fldc: Sorry, I'm only maintaining the PPA for oneiric right now. I have it on good authority that precise will start getting the new compiz code in the next few weeks or so. Hence the rush to get high priority fixes completed.

Miklos: You were right that the Alt+F7 issue was a bug I introduced in my old fix. Sorry about that. That bug is not present in the new fix.

[DJ (ke7mbz)]

I tried setting the mouse poll and using Chrome instead of Firefox. Both seemed to have improved the issue, but have not fixed it. The time it takes for the problem to resurface has gone from hours to days. Apparently, these have been successful workarounds for some people. Changing mouse poll rate via the Compiz plugin appears to do nothing.

Is there any chance of the proposed fix being applied in 11.10, or will be delayed until 12.04? One of my greatest frustrations with Ubuntu lately is that Canonical seems to quickly abandon recent releases, and focus all attention on the next one.

I've tried to be patient with Unity - and even upgraded to, supposedly, friendlier hardware - but it's interfering with my workflow far too much. Frequent running unity --replace, logouts, and reboots have only gotten worse from 11.04 to 11.10. I really like Unity overall, but I've switched over to Gnome 3 for now so I can get some work done. So far, it's been much more stable.

[Daniel van Vugt (vanvugt)]

Yes it is certainly possible (and easy) to squeeze this fix into an 11.10 update. I developed and tested the fix in 11.10 so it's only a matter of pushing the same fix into the 11.10 branches. The slowest part is the code review and approval, but that's not bad. I will try to do this soon. Please remind me if I forget.

I agree with your frustrations. From my observations of Ubuntu development in action, the tendency to abandon old releases while they're still supported on paper is just a matter of man-power. There aren't enough people to backport and test all fixes to all the releases that each bug affects. More help is welcome and even one person can make a big difference.

[Omer Akram (om26er)]

I would work to backport if you could guide me to the right patch that fixes this issue

[Daniel van Vugt (vanvugt)]

Omer, the approved fix is here:
https://code.launchpad.net/~vanvugt/compiz-core/fix-764330-simplified-trunk/+merge/88834
Though it should be obvious if you look at "Related branches" :)

If you download the diff it works with the oneiric compiz code (patch -p0 < filename).

[Omer Akram (om26er)]

"Though it should be obvious if you look at "Related branches" :)"

Ah, I have been think it won't apply to the stable series, I am also going to propose your fix to compiz-core/oneiric (or you can do that yourself, ofcourse)..

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Henning Pohl (hpohl)]

When this fix will be released?

[Daniel van Vugt (vanvugt)]

The SRU fix for oneiric is still pending review. Omer will have a better idea of how long that usually takes.

The fix is in compiz 0.9.7.0 already though. And that should go into precise, probably by Beta 1 (just guessing).

[Daniel van Vugt (vanvugt)]

Omer, I suspect this fix caused regression bug 923683. Admittedly, that bug is not as bad as this one. But that bug does seem to affect systems that this one did not.

I don't think this bug fix should be in an SRU (yet).

[Omer Akram (om26er)]

Thanks Daniel, deleted the branch :-) Once my compiz upload from -proposed goes to updates I can surely make a new branch if we get a fix without regressions

[Daniel van Vugt (vanvugt)]

Omer, here is the combined fix for both bugs if you would like to SRU it.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "fix-764330-923683-oneiric.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Sebastien Bacher (seb128)]

I've sponsored the stable update with the fix for that bug on https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/perf-sru/+merge/92444

The update should be reviewed and accepted earlier next week, the bug will be updated when that happens

[Nipas (nik8pol)]

Will this fix also go to precise? Is there anything that we should do? I did a quick search and didn't find such bug reported at 12.04
Sorry if this is a silly question

[Nipas (nik8pol)]

Also, when can er have the fix available in oneiric-proposed?

[Daniel van Vugt (vanvugt)]

I just checked. This is not Fix Committed to oneiric-proposed yet.

The fix is however already committed in compiz 0.9.7. And the first beta of compiz 0.9.7.0 for precise is being tested right now. So yes, the fix will be in 12.04 very soon.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.7.0~bzr2995-0ubuntu1

---------------
compiz (1:0.9.7.0~bzr2995-0ubuntu1) precise; urgency=low

  [ Didier Roche ]
  * New upstream snapshot:
    - Fix slow/stuttering display with fglrx (LP: #763005)
    - Don't dynamically link to compiz_core
    - Fix build failures with glib 2.30 (oneiric) (LP: #921406)
    - Fix uninitialized variable warnings in valgrind (LP: #921451)
    - Fixes up a bunch of boost::variant edge cases
    - Fixes a race condition where the xig restart test would fail spuriously
    - Incorrect (low/stuttering) refresh rate with NVIDIA driver (LP: #92599)
    - Benchmark window slows the system and degrades graphics resources
      (LP: #254561)
    - Windows that hide themselves when closed don't appear in any
      "this workspace" switcher (LP: #684731)
    - hang in g_spawn_sync and select() (LP: #690239)
    - word misspelled - bunding (LP: #694169)
    - sometimes, restored window placed too high. (LP: #716521)
    - Compiz clears the root window in the installer session (LP: #720679)
    - unity-window-decorator: When switching between windows, Orca does
      not speak the title of the focused window. (LP: #724093)
    - Cannot open a window that starts iconified (LP: #732997)
    - Minimize animation flickr when for maximized apps (LP: #737125)
    - Pixmap memory leak in gtk-window-decorator (LP: #740258)
    - Windows should not automatically be focused when opened if the
      focus is on another application (LP: #748840)
    - [sandybridge] Graphics tearing when playing video (LP: #755841)
    - Compiz's "Sync to Vblank" makes display stutter/slow with fglrx
      (LP: #763005)
    - [regression] Moving windows lags behind the mouse by 1-2 seconds;
      appear to freeze when dragging. (LP: #764330)
    - Launcher - Spread should not affect the state of window (LP: #764673)
    - Clicking on a tweet/message link sometimes does not work (LP: #790565)
    - scrolling on top of a close animation switches viewports (LP: #795065)
    - unity video tearing when moving windows in oneiric with
      nvidia-current (LP: #798868)
    - dialogs really slow to be displayed since the compiz update (LP: #812711)
    - It is possible to stack windows relative to windows that are
      destroyed (LP: #837252
    - Should keep list of windows last sent to server and last recv
      from server (LP: #841727)
    - compiz and X can disagree on the stacking order (LP: #845719)
    - A minimized window 'remains' behind on the desktop if
      /apps/compiz-1/plugins/unityshell/screen0/options/
      show_minimized_windows is set to true (LP: #847967)
    - maximized windows fail to update their input extents when
      undecorated (LP: #853734)
    - resizing bugs with xterm (LP: #854725)
    - crash on closing a window (LP: #856015)
    - Java application windows cut-off/truncated/not displayed properly
      (LP: #857201)
    - compiz crashed with SIGSEGV in CompScreen::insertServerWindow()
      (LP: #857487)
    - compiz crashed with SIGABRT in raise() (LP: #857738)
    - Applications which create multiple windows that are transients of
      each other...

[Daniel van Vugt (vanvugt)]

This is NOT Fix Released or even Fix Committed in oneiric yet. Please change the status back to In Progress.

This confusion may have come from the fact that:
    https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/perf-sru/+merge/92444
is marked as Merged when it has not been merged yet at all (!)

[Martin Pitt (pitti)]

Reopening oneiric task, and reopened merge proposal.

[Sebastien Bacher (seb128)]

well, as written on the merge request it has been uploaded so it's "merged":
https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=compiz

it's just waiting for approval for a week

sorry if packaging can be confusing, launchpad does vcs commits from the uploads for us so I didn't bother to actual fetch the oneiric-proposed vcs to commit, I'm just waiting on the package to go in and launchpad to do that for us

[Martin Pitt (pitti)]

Hello glazs, or anyone else affected,

Accepted compiz into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Chow Loong Jin (hyperair)]

It doesn't look like the fix for this bug has entered oneiric-proposed yet. I've backported a patch and built a package locally for compiz, but it doesn't seem to fix the issue.

[Anders Aagaard (aagaande)]

I'm still seeing 1:0.9.6+bzr20110929-0ubuntu6.1 as the latest package in my tree, no trace of 0.9.7, has this not been approved yet?

[Daniel van Vugt (vanvugt)]

Compiz 0.9.7 is only going to be available in Ubuntu 12.04 and later. If you're already using 12.04 then you probably need to do a "distribution upgrade" to get the new packages.

[Anders Aagaard (aagaande)]

I thought 0.9.7 was hitting oneiric through backports, my bad. But I though the fix was going into oneiric backports, I have backports enabled and the issue is VERY apparent, with your compiz ppa everything works fine.

[Dmitry Shachnev (mitya57)]

For some reason the fix (https://launchpad.net/ubuntu/oneiric/+source/compiz/1:0.9.6+bzr20110929-0ubuntu6.2) wasn't published in oneiric-proposed, reverting the status.

[Kay (ksthiele)]

it's not fixed...

[Daniel van Vugt (vanvugt)]

Kay,

Commenting on bugs that are Fixed Released will usually be ignored. If you have any continuing issues, please log a new bug using this command:
    ubuntu-bug compiz

[Michael Kogan (michael-kogan)]

Same here, after the update from Precise to Quantal the bug appeared again. If anybody opens a new report, please link it here!

[Alistair Buxton (a-j-buxton)]

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1084277

[Mik Wind (evilpollo)]

I can confirm the following, and add some interesting things:

The bug starts when moving any window, by moving it in circles you can even get the window to freeze.
compiz --replace or unity --replace fix it for one or 2 mins.

as mentioned above, It must related to the mouse, and how it is captured because using the TOUCHPAD works perfectly...
note: I also have a logitec laser mouse G9

More interesting, Moving the windows, even woobly windows while in the expo mode (wall enabled) does not lag, can anyone confirm the behaviour with the touchpad and the expo plugin?

[Michael Kogan (michael-kogan)]

By the way, I was able to solve this problem by change the mouse polling time as described here http://www.urbanterror.info/forums/topic/21844-howto-changing-mouse-polling-rate-on-ubuntu/ on Oneiric/Precise, but on Quantal this lead to the USB driver not being loaded at startup at all, so the mouse refused to work and I had to remove the fix again...

[G.C. Hassink (gchassink)]

I did it a little different:

in CCSM:
    composite --> detect refreshing OFF and set it manually to 60
    openGL --> texture filter set fast

compiz --replace worked but not after a restart so,

change in start up applications:
and turn NVIDIA xserver settings OFF

works for now