Animations aren't smooth when sync to vblank is enabled

Bug Description

WORKAROUND (PREFERRED):
1. Run ccsm
2. Go to Workarounds
3. Enable "Force full screen redraws (buffer swap) on repaint"

WORKAROUND (RELIABLE):
1. Run ccsm
2. Go to OpenGL
3. Disable "Sync To VBlank"

ORIGINAL DESCRIPTION:
When "Sync to Vblank" is enabled in the OpenGL section of the CompizConfig Settings Manager (the default setting for precise) animations, specially minimize and maximize animations, aren't smooth and stutter a lot. Moving windows, or entering the Expo mode are smooth though.

Disabling "Sync to Vblank" CompizConfig Settings Manager solves the problem. However, glxgears still informs that it is "running synchronized to the vertical refresh" so I am not sure what the "Sync to Vblank" options actually does.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.12-0ubuntu1.1
ProcVersionSignature: Ubuntu 3.2.0-24.39-generic 3.2.16
Uname: Linux 3.2.0-24-generic x86_64
NonfreeKernelModules: wl
.tmp.unity.support.test.0:

ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
CrashDB: unity
Date: Thu May 24 21:32:03 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus:
bcmwl, 5.100.82.38+bdcom, 3.2.0-23-generic, x86_64: installed
bcmwl, 5.100.82.38+bdcom, 3.2.0-24-generic, x86_64: installed
virtualbox, 4.1.12, 3.2.0-22-generic, x86_64: installed
virtualbox, 4.1.12, 3.2.0-23-generic, x86_64: installed
virtualbox, 4.1.12, 3.2.0-24-generic, x86_64: installed
EcryptfsInUse: Yes
GraphicsCard:
Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device [103c:1436]
Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series] [1002:68c1] (rev ff) (prog-if ff)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
MachineType: Hewlett-Packard HP ENVY 14 Notebook PC
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-24-generic root=UUID=c5085274-714d-4ec5-9bbb-67d38b3cac46 ro quiet splash pcie_aspm=force radeon.audio=1 acpi_osi=Linux acpi_backlight=vendor vt.handoff=7
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/01/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.26
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1436
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 59.24
dmi.chassis.asset.tag: CNU03538DZ
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.26:bd12/01/2011:svnHewlett-Packard:pnHPENVY14NotebookPC:pvr0492100000241910000620000:rvnHewlett-Packard:rn1436:rvr59.24:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: HP ENVY 14 Notebook PC
dmi.product.version: 0492100000241910000620000
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.7.8-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu36
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3.1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3.1
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.19.0-0ubuntu1~xup1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

This sounds like a regression of bug 930192. That bug is still fixed, but overall rendering performance in Ubuntu 12.04 has regressed still when using Unity. I believe this is a problem with the unityshell plugin because performance becomes fast again if I (briefly) disable Unity.

In the mean time, please try this potential workaround:
1. Run ccsm
2. Go to Workarounds
3. Enable "Force full screen redraws (buffer swap) on repaint"

I think I forgot to mention, this bug would be totally fixed by a fix for bug 901097, which I hope we will complete before 12.10.

Daniel, I tried your workaround. It appears to work, approximately the same as disabling sync to vblank, but I am not completely sure. It is not easy to measure smoothness. Is there a way to quantify the smoothness of the animations (something like a fps counter for example)?

However, even if it works as well as disabling sync to vblack, what is the advantage of your workaround? In CCSM, it has a warning saying that it will cause "a massive increase in GPU and CPU usage" which is a problem for me as I am frequently working on battery. Also, disabling sync to vblank does not appear to have any adverse effects (no tearing or other visual artifacts). As I said in the bug description, even after disabling sync to vblank glxgears says it is "running synchronized to the vertical refresh", so I assume that unity is also synchronized to the vertical refresh, is this true? If so, what does "disable sync to vblank" do?

Nicolás,

Yes, there is an FPS counter in the Benchmark plugin, which is part of package: compiz-plugins-extra
Just install that package. Though you might need to change the key combination for it (ccsm) before you can get it to appear.

The advantage of the workaround is that it uses a different rendering method, which is able to "offload" the waiting for vsync from the CPU to the GPU. That allows the CPU to prepare new frames faster and hand them over to the GPU early, held until it's time to show them on the monitor.

If disabling sync to vblank makes no visible difference for you then that usually means your driver has a setting forcing it on or off regardless of the application/compiz settings. This is common and all drivers are different unfortunately, with different defaults.

Sync-to-vblank is different between apps (glxgears), the compositor (compiz) and the graphics driver. At every stage, the lower level is allowed to virtualize the vblank event so the next level up still thinks it's happening even if it's not. Thus applications like glxgears might think that they are syncing to vblank, but they actually won't unless it's enabled in the next level down (compiz), and the level below that (the driver).

Daniel, thanks for your answer.

I'll try the FPS counter when I have access to my Ubuntu laptop.

There is something I still don't fully understand though. Apparently, my graphics drivers (Intel Ironhide) forces sync to vblank because, even with it disabled in CCSM, glxgears maxes out at 60fps saying it is synchronized to the vertical refresh rate. So, disabling vblank in CCSM shouldn't do anything, should it? If it doesn't do anything why is it improving the smoothness of the animations?

Nicolás, there is a direct relationship between the application (glxgears) and the driver too. So the application gets throttled by the driver at 60Hz. And it *might* closely match the monitor vblank timing. However in the end, compiz is responsible for rendering everything on the screen. So you shouldn't expect apps to be tear-free unless sync to vblank is enabled in compiz too.

Daniel, I tried the FPS counter, but I think there is something wrong with it. It oscillates between 5 and 30 fps, most of the time staying close to the low 10's even if the desktop is smooth.

For know I will re-enable sync to vblank with your workaround and test it in the day to day usage. I never found any tearing in any app with sync to vblank disabled, though. It may be that it is to small to be noticeable, but I have noted it in other PCs with different graphics drivers (most notably, Nvidia cards).

Nicolás, it is correct for the compiz frame rate to be low when the desktop is not too busy. And even zero when idle. It's designed to only render frames when something is changing.

Maybe this is of interest for you.
I have noticed that suddenly compiz/unity is much smoother. My observation is not about FPS but more about how frequent the frames make it on screen. Video playback in xbmc is much smoother with 25FPS (monitor at 50Hz).
In the past I had every few seconds stuttering but now it seems to be gone.

I am not 100% sure but the proposed mesa update in combination with proposed unity made the difference for me.
I changed no settings in unity or compiz.

xserver-xorg-video-intel: 2:2.19.0-0ubuntu1~xup1
libgl1-mesa-dri: 8.0.2-0ubuntu3.1
unity: 5.12-0ubuntu1.1
compiz: 1:0.9.7.8-0ubuntu1
linux: 3.4.0-030400-generic

Achim: you appear to be using the "Ubuntu-X team" ppa (https://launchpad.net/~ubuntu-x-swat/+archive/x-updates), so you have the 2.19 version of the intel driver instead of the 2.17 that comes with precise. Also, you are using a newer kernel, with improved DRM code.

I, too, have this ppa enabled and I also found it improves the performance a bit. I guess that this bug is somehow related to the power of the graphics card used and the new driver improves things for Intel graphics. In fact, I recently installed precise in a SandyBridge laptop and the animations are smoother in that laptop than in mine (Ironhide-based).

Fix committed into lp:compiz at revision 3320

This bug was fixed in the package compiz - 1:0.9.8.0-0ubuntu1

---------------
compiz (1:0.9.8.0-0ubuntu1) quantal-proposed; urgency=low

* debian/control, debian/rules:
- enable gles on armel and armhf
- use dh-translations rather than custom code

[ Sam Spilsbury ]
* Enable OpenGL ES building
- Refresh debian/patches/workaround_broken_drivers.patch
- Remove non-ported plugins from compiz-plugins
- Add FindOpenGLES2.cmake to compiz-dev

[ Timo Jyrinki ]
* New upstream release.
- Code to make compiz work on GLES. This includes several changes
to the compiz API. (LP: #201342) (LP: #901097) (LP: #1004251)
(LP: #1037710)
- Draft first 0.9.8.0 NEWS and bump VERSION
* debian/patches/compiz-package-gles2.patch:
- Remove, obsoleted by the upstream GLES work
* Disable plugins that don't work on pure GLES on armhf/armel:
- bench, firepaint, mblur, showmouse, splash, showrepaint, td, widget
-- Sebastien Bacher <email address hidden> 2012年8月31日 22:59:50 +0200