[nvidia] Moving windows freezes and stutters on nvidia (especially if some other window is redrawing).

[Paulo Narciso]

Using the NVIDIA driver, moving windows freezes and stutters (especially if some other window is redrawing).

TEST CASE:
1. Open a regular window (Nautilus or Terminal)
2. Verify you can move it with ease
3. Open another window that will render graphics constantly, like glxgears.
Expected: Still able to move the first window with ease.
Observed: Display freezes and rarely updates. Have to stop glxgears to move windows.

ORIGINAL DESCRIPTION:
I'm running ubuntu 12.10 with a Geforce Gtx680 + 2600k + 8gb, and compiz performance is awful in the desktop and playing games.

Dragging a window across the desktop is a pain, because it stutters so much it's not even funny. Compiz 0.9.7.8 doesn't have this behavior, so something got broken in this release.

Now, about opengl games. It's also a terrible experience, and no matter what settings I try there's always a lag feel. Games simply don't run smooth, despite the frame rate that shows on screen. This behavior is present in both 0.9.8 and 0.9.7.8.

By running ubuntu without any effects (gnome classic panel) games run super smooth without any lag or stutter.

By the way, I'm running 304.22 driver with default settings, but all previous drivers show the same behavior.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: compiz 1:0.9.8+bzr3249-0ubuntu2
ProcVersionSignature: Ubuntu 3.5.0-5.5-generic 3.5.0-rc7
Uname: Linux 3.5.0-5-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.4-0ubuntu3
Architecture: amd64
Date: Fri Jul 20 19:52:47 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=pt:pt_BR:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=pt_PT.UTF-8
 SHELL=/bin/bash
SourcePackage: compiz
UpgradeStatus: Upgraded to quantal on 2012-07-20 (0 days ago)

[Daniel van Vugt (vanvugt)]

The Compiz rendering pipeline is undergoing major changes that you won't see until version 0.9.8.0 arrives. These will improve smoothness for most people.

Until then, please try a workaround:
CCSM > Workarounds > Force full screen redraws (buffer swap) on repaint = ON

[Daniel van Vugt (vanvugt)]

Please let us know if the above workaround improves smoothness for you. And then set the bug Status back to New. Thanks...

[MC Return (mc-return)]

Daniel, a BIG part of the slowness problem is due to Unity-3d, we need to investigate there.

Running Compiz without Unity-3d, for example as standalone session with Unity-2d, speeds up the desktop dramatically, while almost all the functionality of Unity remains.
It already got a lot faster with your recent fixes, but there is still a lot of potential in optimizing Unity-3d.

I had to switch to a selfmade Compiz/Unity-2d session desktop, because otherwise things became to laggy to use, especially when I turned on the 3rd screen (ATI HD5750 with Gallium 0.4 driver here, because afaik no compatible fglrx driver is available for Kernel 3.5 yet).
And while there is almost no visual and usability difference, when using the unity-2d-panel (all indicators work like expected) and the unity-2d-launcher (here the vertical scrolling of the Dash is even much better and smoother) performance-wise the difference is huge.

[Daniel van Vugt (vanvugt)]

mc-return, you are describing bug 988079 and bug 874619 which are fixed in Unity 6.0, now available for early adopters of Ubuntu 12.10.

[MC Return (mc-return)]

Daniel, yes I am describing those, but I am using Quantal and also the Unity staging PPA, so while your fixes did improve the situation a lot, those bugs are unfortunately both still valid.
Somewhere Unity-3d is burning performance - a lot of it.

[MC Return (mc-return)]

To be able to easily compare Compiz & Unity-2d vs. Compiz & Unity-3d one can setup a standalone Compiz session like for example described here:
http://www.webupd8.org/2012/02/how-to-create-standalone-compiz-session.html

[Daniel van Vugt (vanvugt)]

The case of dragging windows stuttering a lot is bug 1025586.

[MC Return (mc-return)]

This is how my ~/.compiz-session file looks like:

#!/bin/bash
/usr/lib/notify-osd/notify-osd &
/usr/lib/gnome-settings-daemon/gnome-settings-daemon &
unity-2d-panel &
unity-2d-shell &
nautilus -n &
docky &
synapse -s &
glippy -s &
guake &
indicator-keylock &
indicator-forceclose &
/usr/share/my-weather-indicator/my-weather-indicator.py &
nm-applet &
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
start-pulseaudio-x11 &
radiotray &
shutter --min_at_startup &
indicator-multiload &
wallch --constant &
window-list &

[Daniel van Vugt (vanvugt)]

mc-return, performance issues are usually very subjective. Please log your problems in separate bugs.

[Paulo Narciso (p-narciso)]

I had already tried the workaround in #2, it fixes window tearing while using vsync, but doesn't fix stuttering while moving windows.
Like I said, compiz 0.9.7.8 doesn't have this behavior and I can drag windows smoothly.

[Daniel van Vugt (vanvugt)]

I am aware of a significant regression in window movement performance in 0.9.8. That's bug 1025586.

However most nvidia users will find stuttering caused by bug 92599 instead. Please look at the workaround for bug 92599.

[Launchpad Janitor (janitor)]

[Expired for compiz (Ubuntu) because there has been no activity for 60 days.]

[Kay (ksthiele)]

For the guys who have problems with the FPS in games, I strongly recommend you to turn on "Unredirected Fullscreen Windows" it will help you a lot.

[Dave bonago (davidstanquinijr)]

Paulo, I have the same issues with my 12.10.

I would like to ask you try dragging a glxgears window through the desktop. It's almost impossible.

I had been using 12.04 until change to 12.10. On 12.04 the Unity performance was awesome. Incredibly fast.

The cube was very smooth, too.

I'm using a core I7 with a Geforce GTX520 low profile, SSD and 8gb RAM.

I've tried using gnome without effects, and there I have no issues.

Another guy told me to remove nvidia drivers because nouveau drivers were better than nvidia, but it's not true and I had serious troubles doing that. Fortunately, I had a backup disc.

Other important issue is about Conky. After upgrading, Conky uses to loose it's background transparency, showing a dark one instead.

The things are quite better after installing the 310.19 driver downloaded from nvidia.com. I simply had marked it as executable, opened a terminal session by ctrl-alt-f1, sudo service lightdm stop and ran the install file.

Now, dragging a normal window is quite quickly, even though, dragging a glxgears still locking a lot.

I think this new compiz are using opengl resources even to draw the desktop image, and not just to do the effects as it used to do.

If you were interested, we could talk by skype or msn, in Portuguese, of course, because I'm Brazilian.

If you have found a way to fix it, please, tell me.

Thank's

David.

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1049214, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

[Daniel van Vugt (vanvugt)]

Note that this may yet turn out to be solved with a fix for bug 1025586. If so, it would become a duplicate of that bug. But if we can fix just this one in the mean time then it can stay separate.

[Sam Spilsbury (smspillaz)]

Since bug 1049214 was marked as a dupe of this one, I'll continue the discussion here.

The problem I was describing was not merely the usage of XSync, but the way in which we use the synchronous parts of the X11 protocol.

Especially with moving windows you have a call to sendConfigureNotify (required for ICCCM compliance). To avoid any race conditions with the server regarding override redirect windows, we basically take a server grab and query the server for all state relevant to us.

We might be able to be a little more lax than that - I'm pretty sure that applications don't need the window stacking information. If that's the case then we don't have to take a server grab at all.

[Sam Spilsbury (smspillaz)]

Can I reopen bug 1049214 ?

Overuse of the synchronous functions in any case is bad, we shouldn't keep it closed for that reason.

[Sam Spilsbury (smspillaz)]

I've linked lp:~compiz-team/compiz/compiz.performance_1027211 .

Its not a "fix" for this bug per-se, because its very difficult to tell when you've "fixed" a performance problem which has multiple causes, but it does help somewhat (if I'm right about the requirements of the ICCCM)

[Sam Spilsbury (smspillaz)]

OK, so I've found the underlying cause of the extremely bad performance when moving OpenGL windows around (or moving anything around while OpenGL is running).

It seems the the NVIDIA driver completely chokes when you send any geometry change request (eg X_ConfigureWindow) to the server while its rendering something. This is even if you be careful to be completely asynchronous about it. Simply not sending those requests at all fixes the problem completely. This is, incidentally the way it used to be done in compiz.

However, its really not a world I want to go back to. Not updating the server immediately whenever compiz' impression of the window geometry changes causes all sorts of weird and wonderful race conditions that get icky fast. There might be some ways around that, but we'll have to see.

To be honest, it should be possible for the nvidia driver to handle this, so we should really take it up there. Every other driver handles it.

I really don't want to regress bug 923683 :(

[Sam Spilsbury (smspillaz)]

I'll investigate whether or not we can avoid sending geometry updates to the server immediately in the next few days.

[Silviu C. (silviucc)]

Is there any way you could talk to the guys in charge of the nvidia driver for linux? Some time ago they were asking on the lkml if there was anything they could help, I mean work on other projects if possible and whatnot. Maybe that was a sincere offer :)

[Daniel van Vugt (vanvugt)]

No, don't be fooled. This bug needs more proposals to land till it's fixed properly.

[Sam Spilsbury (smspillaz)]

@silviucc

I've got some ideas about how we can reduce the load that the driver is choking on so that there's not such a big slowdown. The main problem is that were sending requests that cause the driver to choke, and then because the driver is choking, we have time to make even more of those requests which causes it to choke even more.

I'll have something up in the next few days. Getting it under test is tricky.

[Daniel van Vugt (vanvugt)]

The first, primary problem, with an expensive XSync is now fixed. But that's not enough to solve the bug adequately. Here are my comments from the tail end of that fix yesterday...

OK, I've tracked down the main offenders that remain _after_ this fix.

1. XSync() inside PrivateWindow::updateRegion()
2. XShapeGetRectangles() inside PrivateWindow::updateRegion()
3. XShapeGetRectangles() called from decor.

If you remove those from the equation then there is no longer a complete freeze. But it still stutters. Further analysis then shows compiz spending its time in one of:

(a) XSync in PixmapBinding::bind
(b) bindTexImageGLX
(c) PrivateVertexBuffer::render

I should add that reverting to the old asynchronous damage handling does not help at all with stutters/freezing. The main issues are those listed above.

It looks to me like our XShape support could be made more efficient instead if synchronously querying XShapeGetRectangles all the time.

[Sam Spilsbury (smspillaz)]

I've reintroduced "lazy positioning" in the move plugin for the attached branch, which causes us not to send any ConfigureWindow requests to the driver unless we absolutely have to, or the the window is later ungrabbed. That pretty much causes the "massive slowdown when dragging stuff while redirected windows are rendering" problem to go away.

Of course this bug is quite vague and is large in scope, so it only fixes one aspect of it really.

Lazy positioning is currently an option that's off by default, it could have some unknown side effects and needs more testing. At the moment, we have a version that limits the number of ConfigureWindow requests to frames, and that keeps the framerate at a steady 12fps instead of grinding to a halt here.

[Paulo Narciso (p-narciso)]

I must say that window movement is super smooth in Xubuntu 12.10 using compiz_0.9.9~daily12.12.05bzr3517 from Unity Staging PPA, no more stuttering while moving windows across the screen, even when multiple windows are opened.

Now, the problem you added later, related to moving windows while having glxgears running still stands.

[Daniel van Vugt (vanvugt)]

On principle I would prefer that we did not need or use lazy positioning. Conversely I'm surprised and curious as to how and when we dropped lazy positioning (I don't remember). Last time we accidentally lost lazy positioning it caused bug 764330, which sounds much like this one.

[Daniel van Vugt (vanvugt)]

In progress still. The two fixes landed so far only address window movement. We have not started fixing the resizing problem.

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

I know this is tagged as a NVIDIA bug but I have drastically improved window movement performance with fglrx here on Ubuntu 12.10 and the newest builds of the unity-team/staging PPA. I also had stutter/freezing when moving windows after I already opened some other windows. It was the worst when I had Steam open, but it's all smooth now! Great news for Ubuntu 13.04!

[Daniel van Vugt (vanvugt)]

Yeah the fixes are not driver-specific. Everyone will benefit. We're just using nvidia as the test platform because it has the biggest problem with move/resize performance.

[Sam Spilsbury (smspillaz)]

Last fix merged was reverted due to an unforeseen regression. I expected that might happen, the geometry code is quite sensitive to other factors. Here it was a interaction with the unity minimization code.

I'll be posting up a ppa with my movement fixes applied there for broader testing. That'll include some other performance tweaks too, but we should log separate bugs for those.

Daniel - can we split this bug into movement performance issues and resize performance issues? They're not the same problem.

[Sam Spilsbury (smspillaz)]

The fix for this (and other performance problems) is available from ppa:smspillaz/compiz-experimental . Please test it and file bugs tagged compiz-experimental-ppa if there are problems.

[Daniel van Vugt (vanvugt)]

Yes, feel free to move mentions of "resize" into a new bug.

[Esokrates (esokrarkose)]

A good message: With compiz 1:0.9.9~daily12.12.05-0ubuntu2 updated today (on 13.04) and the latest Nvidia 313.09 drivers window resizing is ways better (not perfect but definitely much better). Before today I was not able to resize a window in normal mode, now it is possible (even if there are too much grey areas left).

[Almas (almasd)]

I don't know is it same bug or not? It freezing when minimize some applications such as Firefox, Nautilus etc.

[Daniel van Vugt (vanvugt)]

Almas: Please log a new bug for your problem using this command:
    ubuntu-bug compiz

[Daniel van Vugt (vanvugt)]

Mentioning resizing again. At least until someone logs a separate bug for resizing.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.9~daily13.01.14-0ubuntu1

---------------
compiz (1:0.9.9~daily13.01.14-0ubuntu1) raring; urgency=low

  [ sampo555 ]
  * compiz crashed with SIGSEGV in DodgeAnim::applyDodgeTransform() (LP:
    #1048840)
  * compiz crashing if window un-/minimize animation is "Random" (LP:
    #1098185)

  [ Daniel van Vugt ]
  * Several leaks in new GLProgram from compileProgram() from
    GLScreen::getProgram() from GLWindowAutoProgram::getProgram() (LP:
    #1097644)

  [ Sam Spilsbury ]
  * Several leaks in ccsIntegratedSettingListAppend() ... from
    ccsGNOMEIntegrationBackendGetIntegratedSetting() from readSetting
    (gsettings.c:375) (LP: #1097661)

  [ MC Return ]
  * Thumbnail Window Previews: Flickering of background/glow and window
    title text (LP: #1098758)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 3561
 -- Automatic PS uploader <email address hidden> Mon, 14 Jan 2013 04:03:09 +0000

[Nicholas Urfe (nicholasurfe)]

Hi,

I just tried the latest sources (lib-path-patches and compiled on Fedora), but the issue still persists for me. That is, if this manifests itself as high Xorg CPU usage - if not, then I apologize.

[Nicholas Urfe (nicholasurfe)]

An update: suddenly it doesn't go to 88% anymore when I move a window - it stays to 20%, which I think it will be improved for the stable release.

[Daniel van Vugt (vanvugt)]

In progress still. I think Sam had more move improvements, and the resize improvements are not begun (though should be in a different bug).

[Daniel van Vugt (vanvugt)]

PLEASE NOTE

The issue with resizing is being handled in bug 1100073 now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.9~daily13.02.28-0ubuntu1

---------------
compiz (1:0.9.9~daily13.02.28-0ubuntu1) raring; urgency=low

  [ Sam Spilsbury ]
  * [nvidia] Moving windows freezes and stutters on nvidia (especially
    if some other window is redrawing). (LP: #1027211)

  [ Brandon Schaefer ]
  * [Regression] Lowering window by middle click doesn't switch focus to
    raised window (LP: #1034616)

  [ Sam Spilsbury ]
  * compiz crashed with SIGSEGV in DecorWindow::moveNotify()
    [decor.cpp:2791] (LP: #1056409)
  * [regression] r3523: Restored windows' contents are offset from (not
    aligned with) their frames (LP: #1089279)
  * Creating windows above just-destroyed windows causes newly created
    windows to receive invalid stack positions (LP: #1088399)

  [ Paul Donohue ]
  * Dim Inactive plugin disabled by default although stated as enabled
    (LP: #808909)

  [ MC Return ]
  * Dim Inactive plugin disabled by default although stated as enabled
    (LP: #808909)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 3627
 -- Automatic PS uploader <email address hidden> Thu, 28 Feb 2013 04:02:37 +0000