[SOLVED] 'bezel' effect with vsync disabled

I've noticed a strange effect on my system recently. Along the 4 edges of the screen a strip around 20 pixels across displays the previous frame. It looks a bit like a bezel in a mirror kind of.

This only happens on my main system (Arch x86-64, 9600GT, NVIDIA driver) and only when vsync is disabled. Enable vysnc and it goes. Nothing else changes the behaviour.

To reproduce load a map and crank the settings up a bit as it's easier to spot at low framerates. Then look from side to side. Notice anything or just on my system? Might not be a Xonotic issue but could just be an NVIDIA driver issue.

A screenshot doesn't show it as it uses what's in a buffer, bypassing the problem!

how long does the artifact last ... if only while moving ... then you are likely seeing the reason vsyn was put in the game

If you are stationery you wouldn't notice so much as the difference between one frame and another would be minor. When moving it becomes apparent however it is always real.

This is not the reason for vsync. Vsync is to prevent 'tearing' between frames. Tearing occurs at very high framerates and vertically as the frames are rendered. This is something very different from normal tearing. You can get this affect even when running at less than 20fps in Ultimate with everything switched on, hence it isn't an inherent thing as vsync will affect things at high framerate, not low. Vsync will preventing this bezel artefact however by waiting for each frame to render before putting it in the framebuffer.

You'll also find many people play with vsync off on purpose so I would not expect this to be a problem everywhere or someone else would already have said something. As I also said, it doesn't come up on other systems I've tried on, even with some of the bizarre obsolete hardware I've been benching. On specific configurations perhaps?

Have you tried disabling motion blur? Maybe it's related.

Doesn't appear motion blur related as it also occurs with lower detail levels too.

Worked out what this is. I'd actually missed it for a while!

This is caused by KWin compositing. Disabling/blocking compositing fixes this. It is however only an issue with vsync off, I think Xonotic starts getting out of sync with the WM which is still syncing and includes the border of the window in it's sync. I wouldn't be suprised if something similar can be seen with other compositing WMs with a keen eye.

So, my advice once again, reinforcing what we've spoken about very recently is that compositing really should be disabled (in your WM!) when you run Xonotic. Not just for performance reasons but also for visual quality.

To help with this I've already presented some bash code for a dbus fix which was a bit of a kludge but worked. Similarly I have a way of doing it for Compiz too. I have however FINALLY got a KWin rule that properly works with Xonotic. Some talking with KWin developers helped on this as it appears the Xonotic window class doesn't actually get picked up properly. Instead the window title 'Xonotic' has to be used instead. This is so simple I've exported it and attached it for anyone else who wants to use it.

If you run KDE with KWin desktop effects, I would recommend trying this and hope it helps. Some drivers might not like disabling and enabling compositing to watch for any issues and if you find them, remove the rule.

To install, rename it to take off the '.txt' - a kludge to get it uploaded. Then go to KDE system settings > Window Behaviour > Window Rules and hit 'Import'.