mpv-0.16.0 triggers disabling compositing in kwin for windowed mode [plasma 5.6]

[rphl321]

Info:
OS: Gentoo
Kernel: 4.4.0
DE: KDE Plasma 5.6
MPV 0.16.0
GCC 5.3.0

This behavior is undesired for windowed mode because it disables all desktop effects and ruins plasma5 expirience when not in fullscreen. Please, make it disable compositing in fullscreen only or disable this feature by default:

--x11-bypass-compositor Flag (default: yes)

upd: this doesn't happen in plasma 5.5.5 so maybe it is plasma's new feature
upd2: learned on #plasma that it is like this because kwin got support for _NET_WM_BYPASS_COMPOSITOR hint

[ahjolinna]

I also have this same problem with the git version and 0.16
OS: ChakraOS (testing)
Kernel: 4.4.6-1-ck
DE: plasma 5.6
gcc 5.2
GPU/driver: GTX 970 + 364.12

[Paviluf]

That's why I try to make this happen for month ;)

https://github.com/mpv-player/mpv/issues/2582

[mc4man]

By default the player shouldn't be involved in this at all. If options are helpful for defective compositors then they should be just that, options.

[Paviluf]

Maybe the _NET_WM_BYPASS_COMPOSITOR hint should be disable by default. However it's really useful to have it as an option and it will even more useful if https://github.com/mpv-player/mpv/issues/2582 is implemented.

[rphl321]

I honestly think kwin and others should honor_NET_WM_BYPASS_COMPOSITOR hint only for fullscreen windows, because the way it is now it affects a lot of GL apps and ruins feeling of DE. Or at least provide such option... or options.

[Paviluf]

If you read the specification it's the apps that control the compositor through the hint. So it's the app that should enable the hint only when it's needed. If we have https://github.com/mpv-player/mpv/issues/2582 implemented we can disable the compositor only in fullscreen. The others options covers the other cases that can be needed for some users (No bypass, Compositing always enabled, Compositing always disabled, Compositing disabled only in Fullscreen)

https://cgit.freedesktop.org/cgit/?url=xdg/xdg-specs/tree/wm-spec/wm-spec.xml#n1579

[mc4man]

As far as I know in compiz for example, video players are default excluded as a window match for Unredirect Fullscreen Window which itself seems to be similar to disabling compositing.
So in other words compositing should not be disabled by default for windows or fullscreen

[Paviluf]

One way to deal with this feature is to not disabled the compositor by default and provide the options of https://github.com/mpv-player/mpv/issues/2582 to let the user control the behavior of the compositing.

[rphl321]

I agree that this feature should not be enabled by default in apps, yes it IS. I've tryed xonotic, warsow and left4dead2 from steam thay all do this!

[mc4man]

From a compiz perspective unredirect fullscreen was enabled by default
specifically for games as it was likely to increase performance (higher
fps). At the same time many common video players were excluded as no
real benefit & unredirect _could_ cause tearing on some vids.

On 03/28/2016 06:41 PM, rphl321 wrote:

I agree that this feature should not be enabled by default in apps,
yes it IS. I've tryed xonotic, warsow and left4dead2 from steam thay
all do this!

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/mpv-player/mpv/issues/2997#issuecomment-202610301

[Paviluf]

At the same time many common video players were excluded as no
real benefit & unredirect _could_ cause tearing on some vids.

Some "simple" video players can have tearing without compositing but not MPV that have built-in opengl vsync. Not unredirecting a video player can also cause stutter / judder. It depend of the drivers and the compositor and there is so much combination possible that a single setting can't be perfect for everyone.

[ghost]

The default shortcut for toggling the kwin compositor is ALT+SHIFT+F12. I would suggest using that whenever you have any tearing for any program. There's no need to fiddle around with WM flags per say.

By the way, desktop tearing in gl+kwin only seems to happen with nvidia drivers. AMD's fglrx does not seem to have this problem for me. GTX550Ti, R7 250E, and AMD A4 APU owner here.

[qmega]

Anyone who's getting tearing with kwin/nvidia with compositing enabled, this is a really old issue: https://bugs.kde.org/show_bug.cgi?id=322060

Basically, kwin disables vsync if it thinks it will cause high CPU usage.

Putting export __GL_YIELD=USLEEP before kwin runs (e.g. in ~/.kde4/env/something) should fix it. (Enabling triple buffering should also, but I've never tried that.)

[ahjolinna]

qmega: yes, usleep is also an option instead of triple buffering, but for some reason it didn't work for me.

note: you can't use both at the same time on kwin, you still can have triple buffering enabled in the driver if you use usleep it won't cause any problems

[NiLuJe]

FWIW, I went the triple buffering way.

Meaning I have:

Option  "TripleBuffer" "true"

In my Xorg config, and

export KWIN_TRIPLE_BUFFER=1

in my zshrc (I start Plasma via startx & a custom xinitrc).

And, since this came up recently in #2999, I also keep "Allow flipping" enabled in nvidia-settings.

To alleviate the vsync timing issues that and/or triple buffering introduces, I'm using vo_opengl's waitvsync option. It's been working wonders (jitter almost constantly around 0.001) without the CPU usage downsides of the other solutions (it's been my experience that vsync-fences or glfinish both tend to peg a core to ~100% of systime).

And KWin is happy w/ vsync working properly, without having to resort to a potentially problematic __GL_YIELD for my workloads.

I've been doing that since KWin 4 w/ a GTX 275, and now on KWin 5 w/ a GTX 960, with similar results.

TL;DR: It might look a bit messy, but no matter what you do, you have to make a choice to get vsync working properly w/ KWin on nVidia anyway...

[Paviluf]

@wm4 still no interest in this https://github.com/mpv-player/mpv/issues/2582 ?

[ghost]

No, because such a heuristic would most likely make someone else unhappy too.

You could write a script and use some tool that can set properties on arbitrary X windows (and use it on mpv).

[Paviluf]

I don't thought of it as a heuristic feature, because as you said it will make someone else unhappy too, but I see it as an improvement of the "--x11-bypass-compositor" option like that :

--x11-bypass-compositor : no, always-on, always-off, fs-off

You set it to "no" by default, like it is now, and that's the user that decide what behavior he want.
What do you think ?

[Paviluf]

@wm4 What do you think of giving more control to the user with these settings ?

--x11-bypass-compositor :

• no : No bypass like the current "no" setting (DONE) (Default) [_NET_WM_BYPASS_COMPOSITOR=0]
• always-on : Compositing always enabled [_NET_WM_BYPASS_COMPOSITOR=2]
• always-off : Compositing always disabled like the current "yes" setting (DONE) [_NET_WM_BYPASS_COMPOSITOR=1]
• fs-off : Compositing disabled only in Fullscreen [_NET_WM_BYPASS_COMPOSITOR=1 only in fullscreen]

That way every case are covered and it's the user that choose what is the best for him.

[qmega]

To alleviate the vsync timing issues that and/or triple buffering introduces, I'm using vo_opengl's waitvsync option. It's been working wonders (jitter almost constantly around 0.001) without the CPU usage downsides of the other solutions (it's been my experience that vsync-fences or glfinish both tend to peg a core to ~100% of systime).

I'd never tried it before, but the waitvsync option greatly improves my vsync jitter as well, with or without compositing. Another interesting note is that with power saving enabled (and without waitvsync), vsync timings are much better _with_ compositing enabled. I guess the compositor keeps the GPU on its toes. But with waitvsync I get around 0.001-0.002 either way. I'm not sure where the best place to put this information is, but I think it's something that other people using nvidia proprietary drivers should probably try.