Incorrect (low/stuttering) refresh rate with NVIDIA driver

Thanks for your report Andrey,

What do you mean by "xorg lets me choose only between 50 Hz and 54 Hz"?
Is it during the X configuration process (sudo dpkg-reconfigure xserver-xorg)?

What are the modifications you have tried to xorg.conf?
Did you just change your HorizSync and VertRefresh params in the monitor section, or did you add a new modeline?

Could you also please attach a copy of your (actual) xorg.conf file as well as your (actual) xorg log file (/var/log/Xorg.0.log) to your report?

Many thanks in advance.

1. No, I set HorizSync up to 81 during the xserver-xorg configuration process (according to gtf, hsync must be 80.17 in mode 1280x1024_75.00), and VertRefresh to 75. But it still has no effect.
2. 50 Hz and 54 Hz appear in the screen resolution and refresh rate configuration dialog in Gnome - there are no other options.
3. I've tried to reconfigure the server, then to edit VertRefresh manually, and then to add my own modeline, overwriting all others.
4. xorg.conf, as well as Xorg.0.log, is in the attachment. The xorg.conf included has HorizSync and VertRefresh parameters. Howewer, these two were commented in the original xorg.conf version (the one after upgrade to feisty), but it didn't work, too.

Thank you for posting answer on this report.

Andrey,

by looking at the info you provided, I suspect that the problem lies in your video card/driver. But before giving you my opinion, I would like you to help me narrow it down:

Could you provide me the output of xresprobe?
Could you provide me with a more detailed X log file (you should start the X server with a verbose level of at least 5)?

Many thanks in advance.

Cesare,

Here you go.

I started Xorg with verbosity 6. Notice that mode 1280x1024 @ 75 Hz is identified as "valid" at lines 572, 728, 1256 and 2199.

xresprobe didn't produce anything when it was started with parameters "nvidia" and "nvidia lcd", so I started ddcprobe. I hope it will be helpful.

You mention the video card and its driver. In a reply, I can say that hardware worked OK on edgy and works OK even now on Windows, so the problem might be in the drivers. Here are the versions of driver software I'm using: nvidia-glx version 1.0.9631+2.6.20.3-11.10 and linux-restricted-modules-2.6.20-11-generic version 2.6.20.3-11.10.

Thank you.

please don't put files in a tarball in the future, since it makes it more difficult to read them. Launchpad does have enough storage, I think ;)

I understand that, but I didn't find a way to post multiple files within one message :)

I think we got the guilty :)
Thirst of all, sorry to have confused you. By hardware I didn't mean an hardware failure but an hardware limitation (I was thinking about the single link TMDS, but that was a false lead).

Now, in line 2404 you will see that your driver (note, this is the nvidia proprietary driver, which is, afaik, not supported by ubuntu) selects the 1280 x 1024 @ 60.0 Hz as the best fit to your specification.

Why is that, I can only guess, but you will see in line 366 that your driver EDID probing only detects a maximum pixel clock of 140 MHz: in principle this would mean that you could not use a resolution of 1280x1024@75 Hz which requires a pcf > 150 MHz.

You can try (AT YOUR OWN RISK) to override the EDID and check that you have the resolution/frequency you like, by using either of these options in your xorg.conf file (either in the Screen or Device sections):

Option "IgnoreEDID" "true"

This will disable probing of EDID from your monitor.

Option "ConnectedMonitor" "DFP"

This will override what the NVIDIA kernel module detects is connected to your video card.

Hope it helps.

Now it tells me that 50 Hz and 51 Hz modes are avaiable. :)

In addition, I've noticed that my monitor's OSD shows 75 Hz (or, rarely, 60 Hz) screen refresh rate even when Gnome's configuration dialog sets the rate to 50 Hz.

What is the mode the nvidia driver selects when EDID probing is disabled?
BTW, you can find quite a lot of helpful information about X configuration in appendix D of the driver's README (I don't have an NVIDIA myself).

It selects the same, 1280x1024 @ 60 Hz, which is reported as 51 Hz mode by Gnome.

I found some options relevant to EDID in the README, but they require either custom EDID file or modes file. btw, the "IgnoreEDID" option is now obsolete, "UseEDID" is used instead.

I'm somewhat confused. You instructed the driver with UseEDID false to not use EDID and the the driver still selects the 1280x1024 @ 60 Hz? Have you tried to use a modeline? Perhaps a range of (correct) vertical freq. instead of a set number?
Please check also the ModeValidation option. I see some interesting options there (for instance AllowNon60HzDFPModes).

I didn't hear again from you. I suppose you have solved the problem?
If not, could you let me have the output of xrandr too?

I have already tried modelines and VertRefresh ranges (43-75 and 60-75). I'll try ModeValidation and AllowNon60HzDFPModes today, also.

Here's the xrandr output:

 SZ: Pixels Physical Refresh
*0 1280 x 1024 ( 382mm x 302mm ) *50 51
 1 1280 x 960 ( 382mm x 283mm ) 52
 2 1280 x 800 ( 382mm x 236mm ) 53
 3 1280 x 768 ( 382mm x 226mm ) 54
 4 1152 x 864 ( 344mm x 255mm ) 55
 5 1024 x 768 ( 305mm x 226mm ) 56 57 58
 6 960 x 600 ( 286mm x 177mm ) 59
 7 840 x 525 ( 251mm x 155mm ) 60
 8 832 x 624 ( 248mm x 184mm ) 61
 9 800 x 600 ( 239mm x 177mm ) 62 63 64 65 66 67
 10 800 x 512 ( 239mm x 151mm ) 68
 11 720 x 450 ( 215mm x 132mm ) 69
 12 640 x 512 ( 191mm x 151mm ) 70 71
 13 640 x 480 ( 191mm x 141mm ) 72 73 74 75
 14 640 x 400 ( 191mm x 118mm ) 76
 15 640 x 384 ( 191mm x 113mm ) 77
 16 576 x 432 ( 172mm x 127mm ) 78
 17 512 x 384 ( 152mm x 113mm ) 79 80 81
 18 416 x 312 ( 124mm x 92mm ) 82
 19 400 x 300 ( 119mm x 88mm ) 83 84 85 86
 20 320 x 240 ( 95mm x 70mm ) 87 88 89
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none

The current mode is marked with an *. As you can see, current refresh rate is 50, although the monitor's OSD indicates 75Hz vertical and 80.0 KHz horizontal refresh at the same time.

Why do you care about the refresh rate when the monitor is a DFP? Doesn't the native resolution work right? I'm going to reject this soon, unless there is something wrong in the scripts that you can point out.

I'm sorry Timo,

the problem for me is not if the refresh rate is or not 75 Hz (on a side note Andrey, I wouldn't trust the OSD, I know I don't trust mine).
The problem is not also that either the nvidia driver doesn't seem to be doing its work or his monitor EDID reports wrong information.
What I really don't understand is why the RandR extension is reporting 50 Hz when the driver sets it to 60 Hz .....
Admittedly, it is a small issue; if you don't think it is worth investigating this, by all means, reject the bug report.

Timo, I have 2ms response time here, so I can see the difference between 60 Hz and 75 Hz (it's not big, but it exists, especially noticeable in 3D-games like q3). And because of this I do care of the refresh rate. However, I can set the 75 Hz mode, selecting 50 Hz in Gnome settings, so if it isn't counted as a bug, reject this.

xorg.conf indicates the nvidia binary driver is in use. Punting from xorg -> linux-restricted-modules-2.6.20

This sounds awfully similar to Bug #104105 ...

Andrey:
Can you indicate whether following the steps outlined in https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/104105/comments/9 makes a difference?

It looks very similar, indeed. Although I don't use TwinView, the refresh rate seems to be reported correctly by monitor's OSD and nvidia-settings, but not by Gnome's screen resolution setup dialog and xrandr command.

Here's the output of "nvidia-settings -q RefreshRate"

   Attribute 'RefreshRate' (Xel-Naga:0.0; display device: DFP-0): 75,02 Hz.

Andrey:
Because you don't use Twinview you should be able to disable it without any side effects (unless you one day do wish to use it). Could you try disabling DynamicTwinView in xorg.conf and reporting back?

Wow, it works now! The refresh rates 60 and 75 are present in Screen Resolution dialog. Thank you for the hint.

Confirming based on duplicates.

For anyone stumbling across this problem, the reason for the behaviour of the DynamicTwinView is described on http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9755/README/appendix-d.html :

"Option "DynamicTwinView" "boolean"

Enable or disable support for dynamically configuring TwinView on this X screen. When DynamicTwinView is enabled (the default), the refresh rate of a mode (reported through XF86VidMode or XRandR) does not correctly report the refresh rate, but instead is a unique number such that each MetaMode has a different value. This is to guarantee that MetaModes can be uniquely identified by XRandR.

When DynamicTwinView is disabled, the refresh rate reported through XRandR will be accurate, but NV-CONTROL clients such as nvidia-settings will not be able to dynamically manipulate the X screen's MetaModes. TwinView can still be configured from the X config file when DynamicTwinView is disabled.

Default: DynamicTwinView is enabled."

VIDIA has its own implementation of dualhead support called twinview enabled by default when using nvidia driver. Xorg (and GNOME) reports (availible) refresh rates wrong, and you cant select the good ones. This is absolutely annoying when using CRT monitors.

Using the following option in display section solves the problem (by switching off twinview):
Option "DynamicTwinView" "False"
Then the resolutions reports correctly, and can be selected correctly.

Since Gutsy have a displayconfig-gtk app, with dual monitor support, (and nvidia-settings is hidden in the menu by default) the above line should be add to the Xorg.conf by default when using nvidia binary drivers.

further to the //Option "DynamicTwinView" "False"// recommendation above, would someone please give more detailed info on exactly where in the xorg.conf file this should go?
thank you

You should insert it into the "Device" section.

For future reference: this also occurs on at least one 7x series cards. I encountered this exact same issue with an NVIDIA GeForce 7200GS video card (reported as 7300 SE in xorg.conf under a new Ubuntu 7.10 Gutsy install).

Adding this line to my Device section in the xorg.conf file corrected the issue:

Option "DynamicTwinView" "false"

Otherwise, as NVIDIA has mentioned (as Holger quoted here: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/104105/comments/9), the video card and display are running at the correct refresh rates, but are reporting different values to Gnome and/or X. Essentially, I had a 50Hz and 51Hz option for 1280x1024 resolution on my Samsung SyncMaster 731B. The 50 selection would really set my refresh rate to 60Hz, while the 51 selection would set it to 75Hz.

Running the following command made this apparent, along with verification from my monitor's OSD:

nvidia-settings -q RefreshRate

So it is fixed for me since I don't need or want "DynamicTwinView". Perhaps others might need this functionality?

The DynamicTwinView fix worked for me, too. For what it's worth, I was interested in 60hz on my flat panel because it's necessary (in North America) for MythTV's "bob" deinterlacing to work right, which IMO is absolutely the smoothest way to watch on your PC. ;)

This is my second comment on this bug since I experienced this identical problem on a different PC.

This PC uses a 6600GT AGP video card attached to a BenQ FP93GX monitor. Reported refresh rates in Ubuntu when using the restricted (NVIDIA) drivers were 50Hz, 57Hz, and 58Hz in the GUI Screen Resolution dialog, while nvidia-settings reported an actual 75Hz refresh rate when set to 50Hz in the GUI.

Adding the same DynamicTwinView option to false in my xorg.conf fixed this one as well.

I have also confirmed this issue, and disabling DynamicTwinView fixes it.

I'm running a Geforce3 Ti200 on with nvidia-glx 1:96.43.01+2.6.24.4-11 (hardy). And am running a DFP natively at 1280x1024x24 @ 75Hz on DVI.

I recommend this bug be closed, as it is not a problem originating with either xorg or Ubuntu, but with the proprietary nvidia driver. I also own a laptop with integrated nvidia graphics (8400M GS). The README.txt supplied with the driver explains both the issue and the workaround, which is fully discussed above.

If we, as nvidia graphics owners, desire a change in the way the driver works, then we have to request this of NVIDIA through proper channels.

Hope this helps,

Harvey

I agree that this bug report should be closed. It is still a bug, but with the NVIDIA software as mentioned earlier. Therefore, it's no longer work for the Ubuntu developers to handle. However, I do hope that when closing a bug here, it will still be accessible to users who search for it in the future. I am unfamiliar with Ubuntu's bug-base and what happens when a bug is closed. Thanks.

This bug shouldn't be closed, but fixed instead, and preferably before Hardy release. NVIDIA people are not going to change this, but Ubuntu developers can fix it easily by adding Option "DynamicTwinView" "False" to xorg.conf. Of course, some people need TwinView, but they are much less than those who want correct refresh rates more. Such little bugs are the ones that scare people away from Ubuntu.

Nicholas,

I respectfully disagree. This is a documented feature of the closed source nvidia driver. You can confirm (or deny) this by reading the README.txt file supplied by Nvidia with the driver.

The guidance on reporting problems (http://www.ubuntu.com/community/ReportProblem) states that bugs should be reported when they are not a feature of the program.

To be more clear, I should have recommended that this [bug report be closed because this is not a bug]. I still recommend that.

If Nvidia will not either make their drivers open source so others may hack on them, or fix them as we request, then we as consumers can make the choice not to purchase any of their products in the future.

Best regards,

Harvey

Harvey Muller (and everyone else)

I think you are right, changing something in the driver without asking the user is not the best way to improve Ubuntu. However, leaving it as it is is not a solution either. As I have stated before, such refresh rates are more than confusing for new users. I know Ubuntu developers can thing of something - at least a dialog box asking if the user wants this DynamicTwinView. In any case, whether or not this is Ubuntu's fault, the outcome of it is in a very remarkable spot. This is not something that should be left behind.

The behavior of showing incorrect refresh rates in the Ubuntu configuration tools is not a feature, it's a bug. Whether that bug is in the Ubuntu tool or in the Nvidia driver is debatable.

Since Nvidia has not chosen to fix this behavior in the driver in the year since this bug was initially reported, the cleanest answer would be for the maintainers of the Ubuntu config tools to treat it as intended behavior and implement a work around - even if that work around is a big old warning saying "Dynamic Twin View is enabled, either disable it or use nvidia-settings".

As Nat mentioned, this *is* a bug. It's a bug with the NVIDIA drivers,
though, not Ubuntu. Therefore, it should stick around until NVIDIA fixes it
with the restricted, closed source drivers. Otherwise, we should add a *
feature* that automatically disables TwinView in the x config file by
default (ie: a GUI setting in Ubuntu). Then for those few using TwinView,
then can enable it and everyone is happy.

On Sun, Apr 20, 2008 at 6:29 PM, Nat Tuck <email address hidden> wrote:

> The behavior of showing incorrect refresh rates in the Ubuntu
> configuration tools is not a feature, it's a bug. Whether that bug is in
> the Ubuntu tool or in the Nvidia driver is debatable.
>
> Since Nvidia has not chosen to fix this behavior in the driver in the
> year since this bug was initially reported, the cleanest answer would be
> for the maintainers of the Ubuntu config tools to treat it as intended
> behavior and implement a work around - even if that work around is a big
> old warning saying "Dynamic Twin View is enabled, either disable it or
> use nvidia-settings".
>
> --
> [nvidia-glx] unable to "set" proper screen refresh rate due to
> DynamicTwinView
> https://bugs.launchpad.net/bugs/92599
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
John Suit

I agree with commenters that this seems unfixable in lrm, but should be done through Jockey. Setting to wishlist.

There is a chance that the fix proposed in bug 763005 might also fix this one. Please test it.

Got subscribed here by a bug that was marked as a duplicate, however disabling DynamicTwinView did not work for me. Compiz is still extremely choppy and slow.

Please check that the NVIDIA Settings app shows Dynamic Twin View as disabled. Sorry; I forget where it is exactly, and can't show you because I stopped using NVIDIA graphics a while ago.

Also, try installing compizconfig-settings-manager. Then go to:
System Settings >
Control Center >
CompizConfig Settings Manager >
Composite

And check the Refresh Rate is the same as what your monitor is using.

I checked nvidia-settings and DynamicTwinView was definitely disabled. I also set the refresh rate in CCSM to 60Hz which is what my monitor runs at. Didn't make any difference.

On 09/16/2011 12:19 AM, Daniel van Vugt wrote:
> Please check that the NVIDIA Settings app shows Dynamic Twin View as
> disabled. Sorry; I forget where it is exactly, and can't show you
> because I stopped using NVIDIA graphics a while ago.
>
> Also, try installing compizconfig-settings-manager. Then go to:
> System Settings >
> Control Center >
> CompizConfig Settings Manager >
> Composite
>
> And check the Refresh Rate is the same as what your monitor is using.
>

OK, it seems to be a different issue. You bug 773861 is no longer marked as a duplicate of this one.

Since #760814 is deemed a duplicate, I've bounced overhere.

Just installed 11.04 w/ Classic (i.e., GNOME 2.32). GeForce 210 and binary driver 270.41.06-0ubuntu1. Window movement was stunningly jerky.

Went into CCSM and disabled "Bailer". Now, window movement is acceptable, but glxgers is still horrible.

Ron, please try the workaround in the bug description above.

If that fails, I suspect an alternative workaround might work:
In CCSM > Composite set ...
  Detect Refresh Rate = OFF
  Refresh Rate = the real refresh rate of your monitor, maybe even higher.

Daniel, no luck with smooth windows after disabling Detect Refresh Rate. In fact, they became jerky again.

Also, it turns out that disabling Bailer didn't work well either.

What does seem to work is disabling all Window Management options except Move Window and Resize Window.

Lastly, as another bit of info: the OpenGL game Extreme Tux Racer performs well, but the screen is corrupted upon exit. Attached is a screenprint demonstrating the problem. Actually *doing* the screen print refreshed the screen.

Ron, if the xorg.conf workaround doesn't work for you either then you're experiencing a different bug. Please log a new one.

Please also log a separate bug for the Tux Racer corruption issue.

This may be related: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061

same problem here, deactivating bailer and forcing the framerate to 120Hz (my monitor goes 60Hz) did the trick.
now i've got a smooth experience, even if gnome-shell (mutter) appears still faster (mut it may be just an impression).

That's excellent news. Please create a new bug titled something like:
  "Compiz refresh rate is slow and stuttering when Bailer plugin is active"

It's good news because it sounds like we're just dealing with a logic problem, or frame deadline problem, in compiz.

Instead of disabling Bailer however, can you change its settings in CCSM and solve the problem with Bailer still active?

Ideally, please put your responses in the new bug. Thanks...

Deactivating Bailer and increasing the refresh rate do improve, but don't completely fix the problems. glxgears is smoother, but still jerks noticeably from time to time and gets much smoother as the window size increases. And moving and resizing windows is still much, much slower than with compiz 0.8.6.

Tried the TwinView workaround and lightdm won't even load. Tried manually setting the refresh rate in ccsm and there is no appreciable change. Turning off bailer also does nothing. Seems to be some sort of leak because at startup or compiz restart everything works smoothly. 2 minutes later and the stutter to moving windows returns.

This bug really degrades the Ubuntu experience.

Sorry, I performed some other tests and they proved I was wrong with bailer.

Now it seems that the situation can be simply improved by deactivating the FPS detection, and forcing the framerate to 120Hz. In this way the performance is acceptable.

However, now I'm writing from gnome-shell, and it's sad to repeat, but here there simply isn't any problem. Windows move smooth as silk, like any other animation.

Yes, this bug is something we can work around in compiz, as you found by changing the frame rate. I suggest it is also possible to improve the compiz code so that it avoids the issue and also avoids the need for a very high frame rate. But wait and see, if and when I (or someone else) has the time to look at doing that...

I have smooth animations on everything compiz-related EXCEPT window movement, file dragging, and the like. It slowly degrades after a while of usage. This has been an issue for me since Natty and the introduction to compiz 0.9.*. This is both on my nvidia gtx 560 and Intel i915.

I've tried all the workarounds mentioned in this bug, bug 763005, and bug 86106. There have been absolutely no improvements. Am I even in the right bug report? Should I report a new one? What should I name it so it does not get merged in with the current cluster of performance bugs? Should I upload a video demonstrating the behavior? Is my behavior unique amongst the problems documented across the three bugs?

@Chauncellor...

If disabling DynamicTwinView didn't work for your nvidia system, try setting this in CCSM:
  Detect Refresh Rate = OFF
  Refresh Rate = the real refresh rate of your monitor, maybe even higher.
If that still doesn't work then you are not experiencing bug 92599. But read on...

In CCSM again, go to the Workarounds section and enable:
    Force full screen redraws (buffer swap) on repaint.
If that solves your problems then you're probably experiencing tearing, not stuttering or a low frame rate, so you actually have bug 880707.

Finally, please confirm you are experiencing stuttering, and _not_ tearing. If you're unsure about the difference please log a new bug with a video. Link to the new bug from one of the existing bugs like this one so myself and other people see it. Don't worry too much about the title of the bug. A nice clear video should allow us to accurately classify the bug and not accidentally merge it with unrelated bugs.

@Daniel and Chauncellor:

I seem to have exactly the same problems mentionned by Chauncellor :

- problem is only on Compiz 0.9 (NVidia GeForce GTS240, driver ver. 280.13 on x86_64)
- Problem only affects moving windows around and dragging icons.
- The very first window movement (right after logging in) works perfectly
- I have disabled DynamicTwinView : no improvement
- I have disabled Detect refresh rate in xorf.conf : no improvement
- I have forced refresh rate to 60Hz (this is what my monitor says) : no improvement
- I have set "Force full screen redraws on repaint : no improvement

So I'm not sure whether this is tearing or stuttering or something else but if Chauncellor
creates a new bug report, I'd like to know the bug number so please mention it in this thread.

I suspect I *might* have just fixed (worked around) this bug in compiz:
https://code.launchpad.net/~vanvugt/compiz-core/fix-880707/+merge/81737

Not sure yet. Stay tuned.

Will any fixes for this bug be pushed in the regular 11.10 updates, or will this remain an issue until 12.04?

The compiz fix for bug 880707 is the change that I think might solve (hide) this bug. I am getting a new Nvidia card today so I can retest this.

However the current proposed fix for bug 880707 is much too complex and risky to put in updates right now. It needs much more testing. Also, the compiz administrator wants to completely rewrite it according to my emails this morning. So much more work and debate yet.

In the best case, when we agree on the final compiz fix for bug 880707 (not the unity fix), then I'll put it in my PPA for all 11.10 users to try.

Testing with a new NVIDIA card, I found the workaround of disabling dynamic twin view didn't seem to work in Ubuntu 11.10.

Further investigation seems to suggest the workaround failing is in fact regression bug 888039 which appears to be solved by the new compiz-composite timing code I proposed in bug 880707.

Please note: The fix for bug 880707 only works as a fix/workaround for this bug when you have "Sync To VBlank" enabled in your compiz opengl plugin settings.

Experimental fixes for this and related performance bugs are now available
for testing in ppa:vanvugt/compiz and ppa:vanvugt/unity. For the best
results I recommend trying both together. But testing them individually is
useful too.

IMPORTANT NOTES:

  * The fixes in ppa:vanvugt/compiz REQUIRE that "Sync To VBlank" is ENABLED
    in CompizConfig Settings Manager (OpenGL section).
    This is the default setting when Ubuntu 11.10 is installed.

  * When using ppa:vanvugt/compiz you should DISABLE the workaround
    "Force full screen redraws (buffer swap) on repaint" in
    CompizConfig Settings Manager (Workarounds section).
    This is the default setting when Ubuntu 11.10 is installed.

  * I don't claim to have fixed all tearing. I only claim that the amount of
    tearing in oneiric with the fix is no longer worse than in natty.

  * nouveau: If you are using the "nouveau" driver for NVIDIA chips you will
    need to enable sync-to-vblank support in the driver options because
    nouveau has it disabled by default. You can do this by editing
    /etc/X11/xorg.conf and adding:
       Section "Device"
           Identifier "My Graphics"
           Option "GLXVBlank" "on"
       EndSection
    Then log out and in again for it to take effect.

  * fglrx (Catalyst): The fglrx driver also disables sync-to-vBlank support
    by default. To fix this:
      1. Open Catalyst Control Center.
      2. Go to 3D > More Settings.
      3. Set "Wait for vertical refresh" to
         "On, unless application specifies".

  * Please don't try using the Benchmark plugin in compiz-plugins-extra
    because it is broken and misleading (bug 898548).

Please leave feedback in the relevant bug reports.

- Daniel

---

ppa:vanvugt/compiz | https://launchpad.net/~vanvugt/+archive/compiz
compiz (1:0.9.6+bzr20110929-0ubuntu6vv2) oneiric

  * Added proposed fix for inaccurate frame timing causing tearing and
    stuttering.
    (LP: #880707) (LP: #888039) (LP: #92599) (LP: #798868) (LP: #876575)

ppa:vanvugt/unity | https://launchpad.net/~vanvugt/+archive/unity
unity (4.24.0-0ubuntu2b1vv4) oneiric; urgency=low

  * Fix major performance regressions due to unnecessary UnityFBO binding
    (LP: #861061) (LP: #880707)
    UnityFBO was being bound even when not required. This caused major lag in
    glPaintOutput, which slowed down all rendering. This was seen in reduced
    framerates in apps (LP: #861061) and significantly worse screen tearing
    with Unity 4.x compared to 3.x (LP: #880707).

Daniel:
I tried everything in your post. I guess my problem is not amongst the ones you've solved. :(

Should I switch to nouveau? The nvidia drivers worked quite well up until Oneiric. Gnome-shell does work, but it has its own issues (crashing randomly when switching workspaces).

(Windows dragged do not redraw during drag action unless you drag very slowly.)

If the workaround at the top of this bug and my PPA do not solve the problem, then it's likely you have a very different bug. And therefore I would have no idea if nouveau would improve things for you. But it's worth a try.

Please also confirm the version you're testing from ppa:vanvugt/compiz. It should be "vv5" now, if you do a system update. Please try that version before moving on to create/find a new bug.

Daniel, I resetted unity (--reset) and tried both your compiz and unity packages (vv7 and vv5 respectively).
The combination of both solved my performance problems almost completely, putting unity on par with gnome-shell.
However, it seems to me that performance is still a little better when *not* using twinview.

I've used the PC for some days and I've not seen any issue. Just one time, when looking at a youtube video, compiz froze and I had to switch to another VT to restart lightdm. That was quite annoying given the lack of a ctrl-alt-canc substitute in ubuntu.

Finally, bug #888039 is still here. Moving windows after hours of usage, and some suspend/resume cycles, goes at a low framerate. restarting X solves the problem.

Thank you for the moment, keep up with you good work!

"However, it seems to me that performance is still a little better when *not* using twinview."

This is not surprising. Regretfully compiz does have to use the detected frame rate for some (very few) things even with the fix. And if the frame rate reported by the driver is still wrong (TwinView enabled) then some things might still be slightly worse performing than with TwinView disabled. The solution should simply be setting the correct refresh rate in CCSM (Composite Section):
    Detect Refresh Rate = OFF
    Refresh Rate = the correct refresh rate of your monitor

Hi Daniel,

your PPAs resolved the problems for me.
Unity feels fast like hell.

p.s. I had to "unity --reset" and reboot afterwards.

Daniel, I don't know what are the changes between version vv9 and vv10 of compiz, but now things have improved considerably. Most notably, I can't tell the difference with or without Twinview. I tested also with several suspend/resume cycles and I saw no performance slowdowns.

Finally, also bug #888039 seems now fixed to me. Is it possible?

I'm not sure about bug 888039 because it's hard to reproduce (for me) and hard to distinguish between other similar performance bugs. I think it's likely half the people subscribed to that bug were actually seeing different bugs, some of which are now fixed.

Versions vv9 and vv10 only changed the Move plugin to make moving windows faster and more responsive (bug 764330). But it's excellent that ppa:vanvugt/compiz now contains enough fixes that things have improved considerably for you. I hope all the fixes in there get approved in time to go into Ubuntu 12.04.

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

It should be possible to determine the actual display refresh rate on TwinView setups through NVidia's configuration X extension. Has anyone looked into this?

With the introduction of swapbuffers rendering in compiz 0.9.8.*, the fix/workaround for this bug that we did in compiz-core 0.9.7.0 no longer works. We are now working on a new workaround for compiz 0.9.8.4.

Fix (workaround) committed into lp:compiz at revision 3391

Same problem here with Ubuntu 13.04 daily build (updated everyday). Compiz detects my refresh rate as 50hz instead of 75 which is set in Nvidia Settings, I have to turn off autodetect and set refresh rate manually in CCSM. However CCSM doesn't remember this setting after relog or restart and I have to do that every single time I log to my machine.

I got the same Problem, CCSM doesnt remember the 60hz and i also have to turn off "Sync to VBlank" in Nvidia-Settings to get no stutter when running glxgears and compiz at the same time.
I also run ccsm and set it every reboot cause the setting also reverts to 50hz.

Also tried with 310 and 313 Nvidia-Drivers... Problem still remains. No Problems in Xsession-Errors.

Workaround:

Create a Script with the desired Refresh Rate and mark it as excutable and add it to startup Programs:

 #!/bin/bash
 sleep 5 &&
dconf write /org/compiz/profiles/UnityNeu/plugins/composite/refresh-rate "60"

Now i dont have to open CCSM after every restart and got my 60hz refresh-rate.

I also have this issue with ubuntu 13.04 daily build (updated), refresh rate value won't stick after reboot or logout.

This still happens with a fresh install of Ubuntu 13.04 (final release), using nvidia driver 313. Correcting the refresh rate (uncheck autodetect, set to 60) in CCSM fixes it.

Yep, bug still occurs in 13.04 (fully updated, 310.44 drivers).

I can confirm comment #82. Fresh install and 313 drivers.

Same problem here. Changing refresh rate by Michael's script doesn't work. I have to change this value by CCSM every login on to Unity.

@Piotr Stefanczyk

Try this:

#!/bin/bash
sleep 5 &&
dconf write /org/compiz/profiles/unity/plugins/composite/refresh-rate "60"

Wait: why is this marked "fix released"? Problem exists on a fresh install of 13.04.

I don't so much care about compiz not having the right refresh rate OOTB, but changing it and having that setting forgotten after a reboot is *maddening*. It shouldn't take to much to make sure two settings (detect refresh rate, manual refresh rate entry) don't erase themselves every boot, and I'd consider the problem fixed if this were the case.

But having to resort to a kluudge (bash script with sleep 5 in it? Really?) isn't really... optimal.

Yes this bug should not be marked as fixed. The issue still occurs in the final version of 13.04 with the latest Nvidia 319.23 drivers.

As always, if a bug reoccurs, please open a new one. It's easier to track problems and get them fixed that way.