Bug 380010

Summary:	Compositing is turned off completely and abruptly while windows with _NET_WM_BYPASS_COMPOSITOR 1 exist.
Product:	[Plasma] kwin	Reporter:	unsuspicious.fakename+kdebugs
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	kdelibs-bugs-null
Priority:	NOR
Version First Reported In:	5.9.5
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description unsuspicious.fakename+kdebugs 2017-05-19 14:45:17 UTC

( See https://bugs.kde.org/show_bug.cgi?id=349910 for when this was implemented.  )

As far as I can tell, ALL compositing is turned off completely if a window has "_NET_WM_BYPASS_COMPOSITOR flag 1". In contrast to that, the specifications (https://specifications.freedesktop.org/wm-spec/latest/ar01s05.html#idm139870829920368) might encourage applications to use the flag "generously" ("The Client MAY set this property to hint the compositor that the window would benefit from running uncomposited"). Nothing suggests that this might / should trigger actions which are generally disruptive to the user experience or able to affect the whole Desktop / other windows. Accordingly, there is no indicator that the flag should or would be used sparingly or carefully by applications.

P.E.: SDL and allegro appear to use it by default, because - according to the code comments: "/* This seems like a good idea */". Even for windowed applications that work perfectly fine with compositing enabled. Considering this, what does not seem like an especially good idea is: deactivating essential features of KDE without asking the user first - as a default - every time an application uses that flag.

There should probably be - at the very least - a clear indicator that makes it obvious to the user that compositing has been turned off due to a window hint, so users know why their [Desktop Switching / Accessibility Features / WM Hotkeys] suddenly stopped working, can find out how to fix it (shift+alt+F12) and how to deactivate the behavior (more actions => window manager settings => "allow application to block compositing"). 

According to the specifications it appears to be the responsibility of the compositing manager to decide wether it is a good idea to grant the "wish" of the application with the flag at a given time. One relatively simple addition to mitigate potential problems therefore might be to honor the flag only from visible full-screen windows that have input focus ("steam" appears to have a heuristic detection as a counterpart that does that and goes a bit further, I think?). Also a more prominent, system-wide option to "disallow applications to block compositing by default" could be useful for people who prefer to remain in full control of it.

Optimally, if it is possible at all, then all reactions to "_NET_WM_BYPASS_COMPOSITOR 1" should probably affect ONLY the window that has the flag and nothing else (**I haven't encountered any problems with compositing for a long time though, so I can't guess what trade-offs would be of allowing the necessary kinds of redirection).

Comment 1 Martin Flöser 2017-05-19 18:05:37 UTC

This is the expected behavior. For users disliking this behavior there is a config option to disable.

Comment 2 unsuspicious.fakename+kdebugs 2017-05-19 18:58:48 UTC

Sorry, maybe I wrote too much gibberish and failed to sum up the problem clearly enough again, so here you go:

* When applications that use the window hint are started, Desktop switching features, accessibility features and more that are provided through compositing suddenly stop working without any indication as to why - or how to restore basic Desktop functionality. 

Are you sure this is all included in expected behavior? As in "the end user should be able to expect it and deal with it without problems"? 

Or is it just not the compositing managers job / should the applications that use the flag take care of the resulting problem somehow?



Also I can't find a config option to change the behavior (for all applications at once). The only one in the GUI that mentions compositing is "Display_and_Monitor>Compositor>Allow_applications_to_block_compositing" and that one does not appear to affect the BYPASS_COMPOSITOR-behavior at all (had the system option disabled all along, applications are still able to block compositing with the flag and I still have to change it in the "more Actions menu" for each one).

Comment 3 Martin Flöser 2017-05-19 20:41:27 UTC

Yes that option is the one. If that doesn't have an effect the applications are disabling compositing in another way.

And yes it is totally fine that compositing gets disabled in that case.

Comment 4 unsuspicious.fakename+kdebugs 2017-05-20 08:35:03 UTC

Thanks, the config option works as advertised (file permissions were messed up)! 


Would it be possible to get the wm-specs updated to include the KDE behavior? So applications that contemplate using the window hint know that it might cause changes in appearance of the window?

Getting the last half sentence removed from the specs should be enough - at the moment it says: "...but MUST NOT bypass if it would cause differences from the composited appearance." which sounds - among other things - a lot as if the feature would not interfere with accessibility features etc.