A bug in vsync handling?

[moenchmeyer]

I ran Beryl before I recently switched to compiz-fusion a a Opensuse 10.2 system. I installed the SuSE rpms, e.g. compiz-0.6.2-3.1.x86_64.rpm, from the Opensuse X11 repository. I use the nvidia extensions - no XGL, no AIGLX. The latest nvidia driver NVIDIA-Linux-x86_64-100.14.19 is active.

In comparison to Beryl I see a rather pronounced and ugly "tearing" of vertical window edges when moving windows in horizontal direction. This effect is especially strong with "wobbling" windows. The somehow "delayed" rendering of vertical window edges leads to a flickering effect at the edges in case of fast window movements.

After some discussion with a guy from Nvidia he thinks that the handling of the vblank synchronization may not be correct. There are some findings that support this point of view:

1) The tearing effect was significantly less pronounced with Beryl.
2) The tearing effect disappears completely (a dream!) as soon as you start the transparent performance test window of the compiz-fusion package.
3) The tearing effect is zero during the small time period when the transparent compiz-fusion splash window is displayed after startup of compiz-fusion.
4) The (transparent) cube does not show any ugly efects during rotation - at least not in comparison to the previous Bery installation.

So there are states of the composite window manager in which it can handle a smooth rendering of window edges during (fast) window movements.

Could someone of the developers have a look into this? Something with the rendering got worse in comparison to Beryl.

-------- Additional remark: ---------
I retested an hour ago with Nvidia driver ...100.14.23 instead of ...100.14.19. With the new driver the smoothing (or better quality enhancement) effect of the compiz benchmark plugin on the rendering of moving windows cannot be reproduced. It is only there with driver ...100.14.19!
So, the Nvidia drivers do have an impact on the rendering quality (at least under certain conditions). It should be investigated more thoroughly because there is a chance to improve the rendering quality of compiz significantly!

[enigma_0Z]

I too have experienced more slowness when using Compiz fusion, compared to beryl. Granted, it's been getting better, but the performance is still not up to what it was with beryl...

[moenchmeyer]

So, lets hope for the best ....

I did some more intensive testing and I saw another defect that did (does) not show up in Beryl:

After working some time with complex windows like that of Konqueror, smb4K or vmware I sometimes get an artificial diagonal white stripe from the left top corner down to the lower right corner of a window whilst moving it.

Sometimes it helps to resize the window to make the artefact disappear, sometimes not. In the latter case, one has to restart the application to get rid of the diagonal.
In my opinion this additional effect also indicates that something is wrong with the calculation and handling of y-dimensions in relation to x-dimensions during window movement.

Both the tearing problem and the problem of the artificial diagonal occur for KDE and Gnome.
I tried to reproduce that on a different system - a Dell Laptop, also equipped with a Nvidia card. The problems exist there, too.

[moenchmeyer]

I experimented with a patch for Compiz which I got from a guy at the NVidia forum.
I quote: "The patch emulates the behaviour of Beryl and the benchmark plugin - it damages the whole screen instead of regions and forces buffer swapping".

I recompiled Compiz with the patch applied - and it helped significantly regarding the tearing effect of moving windows.

The patch and its implications should be analyzed by Compiz developers. Have a look at the NVidia forum
http://www.nvnews.net/vbulletin/showthread.php?t=101336

[some-guy]

There is another way to fix this, disable 'Detect Refresh Rate' (in General Options), start compiz with the '--loose-binding' option and Manually set the Refresh rate to something suitable, I set mine to 120 :D

[enigma_0Z]

That doesn't fix the issue entirely... the nvidia driver is a bit slow boosting the chip's clock speed, so initial choppyness is very visible with this...

AFAIK the reason that "Detect Refresh Rate" is broken with nvidia cards is that TwinView abuses this with it's Xrandr implementation.