Compton is incompatible with Savage 2 when using Nvidia

[Anixx]

I start Compton with the following line:

compton --vsync opengl

Everything works well except the Savage 2 game. In this game the tearing line appears in the middle of the screen, so any moving object appears to be teared apart. The top half shows the next frame while the bottom half still shows the previous frame.

Note that this also happens when using pure xcompmgr without vertical sync at all, when the vertical sync is enabled in the game or in the driver settings.

This does not happen in ATI video cards.

[richardgv]

Do you need a link to our VSync guide? https://github.com/chjj/compton/wiki/vsync-guide

The thing that probably is going to help the most is compton --backend glx --vsync opengl-swc. And make sure your version of compton is not too old. Some extra advices are available in #7.

[Anixx]

Oh no, the glx backend does not fit my purposes because of multiple reasons:

• Moving and resizing windows with glx backend is too slow. especially, resizing. This is much worse than tearing
• I use the FXAA, which makes all desktop fonts a mess when the sesktop is in 3D.

As such, only the xrender backend is suitable.

[Anixx]

And I want to say that this game works with standard driver's vsync without bugs, but with compton the picture is MUCH more smooth. It seems that with standard vsync it looses some half of the frames. The only problem with compton is that the tearing line is in the middle of the screen, otherwise the picture is MUCH better than with standard vsync.

[Anixx]

Upon starting the game, compton gives the following message:

[ 25.98 ] error 3 (BadWindow) request 2 minor 0 serial 35965 ("BadWindow (invalid Window parameter)")

[Anixx]

Note that similar symptoms appear in standard vsync as well when the vsync polarity is set wrongly. Changing the polarity in the modeline moves the tear line in a different position, but does not move it where it should be - on the edge of the screen.

[Anixx]

By the way, the same problem in other games as well, for example, in Enemy Territory.

[richardgv]

Except the single word "nVidia", seemingly I haven't acquired much info about your system, hardware, version of driver, version of compton, compton configuration, WM, etc. I'm afraid it isn't going to be beneficial if you want us to assist you.

Freenode/#compton is our semi-official support channel. I believe assistance through IRC is probably going to be helpful in this case. I will get onto the IRC channel later.

As such, only the xrender backend is suitable.

Basically, perfect X Render is not very possible to achieve with X Render backend. It's a limitation of X, as far as I know. See #7 for more info.

And, I mentioned --unredir-if-possible in the start of VSync Guide. Does it work?

Moving and resizing windows with glx backend is too slow. especially, resizing. This is much worse than tearing

1. This might be related to a driver issue.
2. Mixing VSync in the driver, in compton, and in the application may lead to such results. I would recommend you to play with different combinations of settings. For example, turn off VSync in nvidia-settings and use compton --backend glx --vsync opengl-swc.
3. If your CPU / graphic card is under very high stress, missing VSync is pretty possible.

I use the FXAA, which makes all desktop fonts a mess when the sesktop is in 3D.

Newer nvidia-settings provides an "Application profiles" feature that could be useful for the problem.

[ 25.98 ] error 3 (BadWindow) request 2 minor 0 serial 35965 ("BadWindow (invalid Window parameter)")

Ignore it. See #52.

By the way, you don't have a multi-head setup, do you?

[Anixx]

hardware, version of driver, version of compton, compton configuration, WM, etc.

Driver version is 304.88. Compton is 0.1. Compton configuration is default. The bug happens under any WM.

And, I mentioned --unredir-if-possible in the start of VSync Guide. Does it work?

This does not affect anything.

Basically, perfect X Render is not very possible to achieve with X Render backend.

I experience omly this bug mentioned in the issue.

Mixing VSync in the driver, in compton, and in the application may lead to such results.

I do not mix vsync. All opengl compositors slow down windows resizing and movement. Opengl backend is thus not an option.

By the way, you don't have a multi-head setup, do you?

No, I use a desktop computer with only one video card and only one monitor.

[richardgv]

Heh, I always find it depressing when I have to try so hard to get necessary information, and repeat my words again and again just for people to notice them.

Driver version is 304.88. Compton is 0.1. Compton configuration is default. The bug happens under any WM.

The hardware, specifically, the CPU and GPU, is important for us. We wish to know if your system is under heavy load of some sort when VSync-related issues occur: Do you think your CPU/GPU is too weak for the game? Is your CPU completely occupied? Is your CPU/GPU fan running terribly fast (and noisy)? Are you running out of memory? Does it occur as terribly on OpenGL programs that uses less resources?

"Compton is 0.1" is not the accurate description we are expecting. 0.1_beta and 0.1_beta2 both are in the class of 0.1, and probably maintainers from certain distros will set an incorrect version number. compton -h | head -n1 typically prints the version number we want. You are recommended to upgrade if your version is older than 0.1_beta2.

Default configuration is not entirely clear to us, either. Defaults built into the program, compton.sample.conf, and default configuration provided by your distro could all be counted as "default". Does --config /dev/null change anything?

And, I mentioned --unredir-if-possible in the start of VSync Guide. Does it work?

This does not affect anything.

If you are playing your game in full-screen mode, compton should unredirect the screen with --unredir-if-possible, just like no compositor is running. Are you running them in window mode? Or it happens without a compositor as well?

I experience omly this bug mentioned in the issue.

Just to clarify this: This is most likely not a bug in compton, because X Render backend typically doesn't play with VSync very well, and this is not something we could change.

And, have you tried --paint-on-overlay?

I do not mix vsync. All opengl compositors slow down windows resizing and movement. Opengl backend is thus not an option.

By mixing VSync I mean enabling both at the same time, like, enabling "Sync to VBlank" in nvidia-settings and use --vsync opengl simultaneously. I've heard similar issues more than once, and as far as I could remember, they are usually tied with it. I would recommend you to disable "Sync to VBlank" in nvidia-settings firstly and play with --vsync in compton and your application VSync settings. GLX backend perform much better in VSync than X Render, and we don't have much things to do when you are under X Render backend.

And, does your CPU get to 100% when it occurs?

[Anixx]

The hardware, specifically, the CPU and GPU, is important for us.

GeForce 9500GT

We wish to know if your system is under heavy load of some sort when VSync-related issues occur

No. One can see the bug even when in start menu of Savage2. It has a monster in in 3D shown. His sword seems to be broken in the place of the tear line, like if it was refraction in the boundary of water.

compton -h | head -n1

compton (0.1.0%)

Does --config /dev/null change anything?

No.

Are you running them in window mode?

The tear line appears both in fullscreen and windowed mode of Savage 2.

If you are playing your game in full-screen mode, compton should unredirect the screen with --unredir-if-possible, just like no compositor is running.

I have just tried this option and first time there was no tear line, but the picture was slowed, as is usually with driver anti-tearing. I run the game for the second time, and the bug seems not to appear! I see no tear line and the screen update is very fast, like it was previously when the line was present. I will try the thing further.

And, have you tried --paint-on-overlay?

Yes.

By mixing VSync I mean enabling both at the same time,

Yes, I understood. I meant I do not use conflicting settings.

[richardgv]

compton (0.1.0%)

That version is not correct. We have never released anything like 0.1.0, yet. The latest version is 0.1_beta2.

Yes, I understood. I meant I do not use conflicting settings.

Does it happen when you have all VSync stuffs disabled, with GLX backend?

[Anixx]

Well it seems the option --unredir-if-possible completely solves the problem for fullscreen mode!

In windowed mode there is still the tear line.

Does it happen when you have all VSync stuffs disabled, with GLX backend?

With GLX backend there is no tear line, but the performance is so bad, that it is impractical. I think it gives like 15 frames per second, all things move unsmoothly.

[Anixx]

Even worse - when I start

compton --backend glx --vsync opengl

with sync disabled in nvidia settings, there is just huge tearing, no tear line, but just plain tearing everywhere AND terrible performance. When sync is enabled in nvidia, there is no tearing but terrible frame rate.

[Anixx]

Vsync with xrendr backend in Compton is so much faster than the standard nvidia vsync (which I considered accptable) that it is like I just upgraded my computer hugely!

Everything on the screen looks like real and solid!

[richardgv]

Well it seems the option --unredir-if-possible completely solves the problem for fullscreen mode!
...
Vsync with xrendr backend in Compton is so much faster than the standard nvidia vsync (which I considered accptable) that it is like I just upgraded my computer hugely!
...
Everything on the screen looks like real and solid!

Good to hear. :)

with sync disabled in nvidia settings, there is just huge tearing, no tear line, but just plain tearing everywhere AND terrible performance. When sync is enabled in nvidia, there is no tearing but terrible frame rate.

That's... Interesting. If you still have any interest in playing with the GLX backend -- I would truly doubt so :-D : --glx-no-stencil --glx-no-rebind-pixmap --glx-swap-method 3 may be helpful for the performance issue under GLX backend. --vsync opengl-swc may work better under GLX backend than --vsync opengl. If the performance issue occurs only when your game is running, the driver may be failing at load balancing the whole thing, in which case you may wish to turn VSync in the application on. It's more or less a game. The driver is a blackbox. You just play with different combinations of settings and check if you are lucky enough to amuse the closed-source driver.

[Anixx]

I tried

compton --backend glx --vsync opengl-swc --glx-no-stencil --glx-no-rebind-pixmap --glx-swap-method 3

and it is similarly terrible.

if the performance issue occurs only when your game is running

No. You even cannot smoothly move windows (not to say, resize).

[richardgv]

That's weird. GeForce 9500GT should be enough for compton's operations. I suppose that it's likely a driver bug instead of a performance issue. Could you please disable all VSync options in your driver and run compton with compton --backend glx --config /dev/null --glx-no-stencil --glx-no-rebind-pixmap --glx-swap-method 3 (don't use --vsync), and check if there's still a performance problem? Also, is upgrading nvidia-drivers and compton (to a sensible version) viable?

[Anixx]

After running this command there is no difference from what was without compton - I see a huge tearing. No difference at all.

[richardgv]

After running this command there is no difference from what was without compton - I see a huge tearing. No difference at all.

Huh, I'm primarily talking about the performance issue. Is it slow when you have VSync off everywhere? If it becomes as fast as when no compositor is running in the case, the slowness is caused by a bug in your driver, presumably.