Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support NET_WM_BYPASS_COMPOSITOR #267

Closed
steinex opened this issue Nov 18, 2019 · 8 comments
Closed

Support NET_WM_BYPASS_COMPOSITOR #267

steinex opened this issue Nov 18, 2019 · 8 comments

Comments

@steinex
Copy link

steinex commented Nov 18, 2019

Wine, Proton, Lutris etc. can set a hint on a window (NET_WM_BYPASS_COMPOSITOR) for which compositing should be disabled. This helps especially for performance in games.

It would be really nice if picom could support this. I'm aware of --unredir-if-possible, however that only works for fullscreen windows and I think implementing this defacto-standard would be a good idea either way.

All other compositors from the bigger DEs support this.

@steinex steinex changed the title Support NET_WM_BYPASS_COMPOSITING Support NET_WM_BYPASS_COMPOSITOR Nov 18, 2019
@aufkrawall
Copy link

Gnome can't turn off compositing for non-fullscreen windows. KWin can do that, but that's probably rather for the silly reason that it lacks unredirect. Turning off compositing for non-fullscreen breaks vsync in every window if TearFree isn't used, how would that be beneficial?

@steinex
Copy link
Author

steinex commented Nov 18, 2019

I think if picom would just unredirect the whole screen if it detects NET_WM_BYPASS_COMPOSITOR would be great already.

@steinex
Copy link
Author

steinex commented Nov 18, 2019

Aren't you a bit biased here? I mean this hint exists for a reason and it's a real use-case. Just brushing it off doesn't sound very constructive to me. It could be an opt-in option just like the others and a second (and probably proper) way of unredirecting instead of just looking for fullscreen windows.

Because why would I like to lose vsync just because I fullscreened a window?

@aufkrawall
Copy link

Just stating my opinion, no need to get sensitive. It would make sense if Picom honored it by default for fullscreen windows, sure.

You btw. don't lose vsync for fullscreen windows in general, only of the compositor.

@valters-tomsons
Copy link

This would be great! Playing any games while picom with i3 is running is not a great experience, as I don't want any games running exclusive fullscreen. Also never had any luck with --unredir-if-possible even in fullscreen games.

Currently, my solution is dynperf because killing/restoring picom manually gets tiresome.

@Ropid
Copy link

Ropid commented Nov 20, 2019

For the programs that use _NET_WM_BYPASS_COMPOSITOR to tell the compositor to keep redirection enabled for their fullscreen window, you can write a rule for the "unredir-if-possible-exclude" config entry:

unredir-if-possible-exclude = [
    "_NET_WM_BYPASS_COMPOSITOR@:c = 2",
];

Chrome/Chromium uses this. That's the program I tried to use to test that this rule here actually works.

@Faithlv: About "exclusive fullscreen", from what I understood that method doesn't actually exist in X. Fullscreen in X is actually always what's called "borderless windowed" in Windows. I'm guessing the games that show both an "exclusive" and a "borderless" option in their menus, that's just because the game inherits the setting from its Windows version.

@yshui yshui closed this as completed in b026708 Jan 18, 2020
@yshui
Copy link
Owner

yshui commented Jan 18, 2020

I have implemented the _NET_WM_BYPASS_COMPOSITOR = 1 case.

@aufkrawall if you want picom to ignore this property, you can either not use --unredir-if-possible, or add this to your config:

unredir-if-possible-exclude = [
    "_NET_WM_BYPASS_COMPOSITOR@:c = 1",
];

@yshui
Copy link
Owner

yshui commented Jan 18, 2020

This should help i3/i3lock#204

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants