compiz refresh problems with QT apps

[kinzeron]

Hi,

I m having real trouble with QT applications when compiz turned on, on gnome like skype or kile. They don't refresh properly when something in the window change. Is there some workaround for fixing that?

I have an nvidia 8400 G, with 128M. Centrino Duo 2GHz 2G RAM.
ubuntu 9.04 and default nvidia driver 180.44

Regards,

[kinzeron]

The problem exists even when compiz is not enabled. Anyone have a similar problem?

Kile for example doesn't refresh right when scrolling, and it looses the cursor...

regards

[NotALInuxExpert]

Hey all,

I can confirm this problem.

Also nvidia driver version 180, but a 140M in a thinkpad T61.

Ubuntu 9.04 up-to-date.

Kile shows weired refreshing problems, also okular. So assumption of QT seems to be correct.

Cheers,

NotALinuxExpert

[skirst]

Hello,

I fixed this problem by installing a newer version of the 'workarounds' compiz plugin from git. It has a new option called 'Force synchronization between X and GLX'. Enable it, and the problem goes away, at the cost of a little performance, but it was hardly noticeable for me on my 8600M GT. I use the QtCreator IDE daily, and this bug annoyed me to no end when scrolling through source code and not having the editor refresh correctly. With this, everything is perfect. I attached a source code snapshot from GIT which is compatible with compiz 0.8.2.

[kinzeron]

Thx skirst, it now works, but I got a big hit on performance! I think I will keep it disabled, the 8000 series seem to be as bad as the 5000 series. We can thank nvidia for that!

[skirst]

I have since started working in a KDE 4.3 environment, and with it's compositing effects, I don't have this problem. Either KDE already does what this compiz plugin does (and it is an issue with nvidia's drivers), or it's a compiz only issue.

[Dragoran]

Originally Posted by kinzeron

Thx skirst, it now works, but I got a big hit on performance! I think I will keep it disabled, the 8000 series seem to be as bad as the 5000 series. We can thank nvidia for that!

This is not a driver bug, but a bug in the xservers damage extension (race condition), newer open source (DRI2) drivers hit the same problem now.

Calling glxWaitX() is recommended by the xorg devs and will be the default in feature compiz releases.

[AaronP]

We discussed this at the X Developers Conference. glXWaitX isn't even guaranteed to be sufficient because it only causes the GL to wait for X rendering from the current client (i.e. Compiz), and not necessarily other clients (i.e. the one that caused the Damage event). It should be okay for now, but what's really needed is interaction between X's Damage extension and the GL_ARB_sync extension.