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

Bug #764330 reported by glazs on 2011-04-18
This bug affects 149 people
Affects Status Importance Assigned to Milestone
Compiz Core
Daniel van Vugt
compiz (Ubuntu)

Bug Description

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====

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

Related branches

glazs (l-admin-rock-su) wrote :
Mr.Beard (mr-beard-mail) wrote :

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

Socket (skuzn) wrote :

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

Serge Ukolov (zezic) wrote :

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

softzilla (softzilla) wrote :

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) wrote :

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

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) wrote :

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

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) wrote :

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) wrote :

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

Jan (jan-tux) wrote :

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

Richard Terrett (rterrett) wrote :

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) wrote :

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) wrote :

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

$ uname -r

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

Timo Reimerdes (timorei) wrote :

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) wrote :

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) wrote :

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

Changed in compiz (Ubuntu):
status: New → Confirmed
Geoffrey Pursell (geoffp) wrote :

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) wrote :

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.


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:
  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) wrote :

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) wrote :

... (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) wrote :

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) wrote :

Me too.

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


CadamR (caserichter) wrote :

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) wrote :

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) wrote :

Happening to me in latest Mint, Soren.

i5 2500k
8gb RAM
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) wrote :

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

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.

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?

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


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?

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

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) wrote :

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) wrote :

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

yannack (yannack) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Not so optimistic now :-(

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

summary: - Move window annoying slow with compiz
+ Moving windows lags behind the mouse by 1-2 seconds; appear to freeze
+ when dragging.
Changed in compiz (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in compiz-core:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
importance: Undecided → High
summary: - Moving windows lags behind the mouse by 1-2 seconds; appear to freeze
- when dragging.
+ [regression] Moving windows lags behind the mouse by 1-2 seconds; appear
+ to freeze when dragging.
tags: added: regression-release
Changed in compiz-core:
milestone: none → 0.9.6
Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → Confirmed
Changed in compiz-core:
assignee: Daniel van Vugt (vanvugt) → Sam Spilsbury (smspillaz)
Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz (Ubuntu):
assignee: Daniel van Vugt (vanvugt) → nobody
83 comments hidden view all 163 comments
Miklos Juhasz (mjuhasz) wrote :

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) wrote :

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

Changed in compiz-core:
assignee: Sam Spilsbury (smspillaz) → Daniel van Vugt (vanvugt)
Daniel van Vugt (vanvugt) wrote :

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

is this the fix of smspillaz?

fldc (fldc) wrote :

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) wrote :

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) wrote :

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.

Changed in compiz-core:
status: In Progress → Fix Committed
DJ (ke7mbz) wrote :

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) wrote :

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) wrote :

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

Daniel van Vugt (vanvugt) wrote :

Omer, the approved fix is here:
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) wrote :

"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)..

Omer Akram (om26er) on 2012-01-22
Changed in compiz (Ubuntu):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

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

Changed in compiz (Ubuntu Oneiric):
status: New → Confirmed
Henning Pohl (hpohl) wrote :

When this fix will be released?

Daniel van Vugt (vanvugt) wrote :

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 already though. And that should go into precise, probably by Beta 1 (just guessing).

Bryce Harrington (bryce) on 2012-01-27
description: updated
description: updated
Daniel van Vugt (vanvugt) wrote :

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) wrote :

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) wrote :

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

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

tags: added: patch
Omer Akram (om26er) on 2012-02-09
description: updated
Sebastien Bacher (seb128) wrote :

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

Changed in compiz (Ubuntu Oneiric):
status: Confirmed → Fix Committed
importance: Undecided → High
Nipas (nik8pol) wrote :

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) wrote :

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

Daniel van Vugt (vanvugt) wrote :

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 for precise is being tested right now. So yes, the fix will be in 12.04 very soon.

no longer affects: compiz
Changed in compiz (Ubuntu Oneiric):
status: Fix Committed → In Progress
Launchpad Janitor (janitor) wrote :
Download full text (6.6 KiB)

This bug was fixed in the package compiz - 1:

compiz (1: 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
      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...


Changed in compiz (Ubuntu):
status: In Progress → Fix Released
Andy Pollitt (badgerint) on 2012-02-16
Changed in compiz (Ubuntu Oneiric):
status: In Progress → Fix Released
Daniel van Vugt (vanvugt) wrote :

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:
is marked as Merged when it has not been merged yet at all (!)

Martin Pitt (pitti) wrote :

Reopening oneiric task, and reopened merge proposal.

Changed in compiz (Ubuntu Oneiric):
status: Fix Released → Triaged
Sebastien Bacher (seb128) wrote :

well, as written on the merge request it has been uploaded so it's "merged":

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

Changed in compiz (Ubuntu Oneiric):
status: Triaged → Fix Committed

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!

tags: added: verification-needed
Chow Loong Jin (hyperair) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Changed in compiz-core:
status: Fix Committed → Fix Released
Dmitry Shachnev (mitya57) wrote :

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.

Changed in compiz (Ubuntu Oneiric):
status: Fix Committed → Confirmed
tags: removed: verification-needed
Changed in compiz (Ubuntu Oneiric):
status: Confirmed → Fix Released
Kay (ksthiele) wrote :

it's not fixed...

Daniel van Vugt (vanvugt) wrote :


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

Photon (michael-kogan) wrote :

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

Mik Wind (evilpollo) wrote :

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?

Photon (michael-kogan) wrote :

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) wrote :

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

Displaying first 40 and last 40 comments. View all 163 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers