Currently the 'suspend desktop effects for fullscreen windows' option in system settings only disables drawing of effects on a window. This is not the desired reason for most people wanting to disable compositing for games. Compositing hits game performance. I have benchmarked around a 10% slowdown with Xonotic. Alt+Shift+F12 is not appropriate as it is not automatic. Currently I use some dbus calls in the shell script to run any game: if [[ "$(qdbus org.kde.kwin /KWin org.kde.KWin.compositingActive)" = "true" ]] ; then qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing fi exec "$@" & wait $! if [[ "$(qdbus org.kde.kwin /KWin org.kde.KWin.compositingActive)" = "false" ]] ; then qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing fi This has the full desired effect but is messy and every game developer shouldn't have to be doing this and targetting different code at different WMs. An additional option could be added like 'Disable compositing for fullscreen games' which would control org.kde.KWin.toggleCompositing any time a fullscreen game is running. This is important for allowing KDE to be a gaming platform.
Despite the name is does and has always only referred to unredirection of the window. You're looking for kcmshell4 kwinrules / "Appearance & Fixes" / "Block Compositing" Suspending compositing for all fullscreen windows is far to much a broadsword, eg. hitting fullscreen browsers etc.
(In reply to comment #1) > You're looking for > kcmshell4 kwinrules / "Appearance & Fixes" / "Block Compositing" Rest assured I have already tried this option with a KWin rule and extensive Xonotic benchmarking with all three variants of the 'block compositing' option do not affect the performance hit at all. The 10% slowdown is still there and very consistent. This option simply doesn't work. It is also not a helpful way of doing this even if it did work. Is a user seriously expected to set up a rule for each and every game they have? It is no easier to do that my set of dbus calls in the game startup script. It is clearly not in the interest of game developers to do so as there are multiple WMs out there, they'd just rather we all ran xterm ;-) . > > Suspending compositing for all fullscreen windows is far to much a > broadsword, eg. hitting fullscreen browsers etc. I think what you are talking about there is maximised windows or aborderless window? A game is very different as there is no window being drawn and often a different resolution/refresh rate/buffering is being run so there are ways of detecting this happening. So maybe the title of this issue is not correct but still there is a clear need for controlling this.
(In reply to comment #2) > Rest assured I have already tried this option with a KWin rule and extensive > Xonotic benchmarking with all three variants of the 'block compositing' The only reasonable is the "force" one. The others are for rule level management. And it /does/ work. What does not work is xonotic (just checked), because the SDL variant does not set any identifying items (class role or title) at all and the glx variant sets it on the existing window. Since such changes are so far not tracked by the rules (can happen /really/ often with some clients - esp. on the title. Also runtime tracking would alter existing behavior...) actually no rule will work on that particular window :-( > It is also not a helpful way of doing this even if it did work. Is a user > seriously expected to set up a rule for each and every game they have? Yes. Unless the game exports the hint to block the compositor itself. The "simple" way is shift+alt+f12 since (aside that various drivers fail on unredirection) globally unredirecting or even blocking compositing for fullscreen windows turned out to be unusable and rather annoy most users :-( > I think what you are talking about there is maximised windows or aborderless > window? No. Actual "fullscreen" windows and there's no difference. Game, screensaver or firefox - all just set _NET_WM_STAT_FULLSCREEN (we want to assume that i've at least a slight idea about window management on X11 and know the difference between "maximized" and "fullscreen", ok?) > A game is very different as there is no window being drawn KWIn disables the decoration because the windows is tagged _NET_WM_STAT_FULLSCREEN - that is all. (using a screen geometry and motif hints to remove the deco has been a hack to do fullscreen - like 10 years ago) > and often a different resolution/refresh aside that nobody really uses different resolutions in games since there are TFTs, there are various reasons to change the "resolution" - most often by adding, replacing or removing a screen or rotating it. We cannot just suspend compositing everytime this happens, not to mention that it will not cover full resolution games. > rate/buffering is being run "buffering" is a client internal information, nothing the WM would know. > so there are ways of detecting this happening. Nope. Unless you can actually -and technically- point one. Just what you "feel" would be a usable hint does unfortunately not cut it, sorry. > So maybe the title of this issue is not correct but still there is a clear need for controlling this. And there is. Have the game set the _KDE_NET_WM_BLOCK_COMPOSITING property on the window (anytime, even during runtime) Done.
(In reply to comment #3) > And it /does/ work. What does not work is xonotic (just checked), because > the SDL variant does not set any identifying items (class role or title) Thanks you for your experience on best practice here. I will feed this back to Xonotic as a point for improvement there. Checking in some other games (ioQuake3 based) I see the same thing. > Game, screensaver or firefox - all just set _NET_WM_STAT_FULLSCREEN Why then not add the ability for a rule to identify on _NET_WM_STAT_FULLSCREEN rather than for a specific application window? Then a rule could be created by a user to block compositing on any window that is _NET_WM_STAT_FULLSCREEN. Would a feature request on this be more reasonable then? Alternatively window geometry is known by x (the stuff printed by xwininfo) and maximised and fullscreen do have different geometry. Allowing a window rule to be based on height/width would enable the same thing. I know this ignores non-fullscreen windows but could be an intermediary. I am looking into other ideas. Or some way of enabling blocking on all SDL windows would be interesting... > Have the game set the _KDE_NET_WM_BLOCK_COMPOSITING property on the window I'm afraid that is not realistic for many games developers. If that was a Free Desktop standard that would be more workable but I find it unlikely that they will code specifically for one WM. KDE does still lead in this area by offering the Alt+Shift+F12 (though I think not many people know of it) and my Compiz experiences in this area were much worse. Windows Aero has the ability to disable application specific compositing but ONLY for 32-bit applications! Thank you again for your wisdom on this. :-)
(In reply to comment #4) > to Xonotic as a point for improvement there. Checking in some other games > (ioQuake3 based) I see the same thing. Yes, unfortunately. Most games do not use toolkits and handling WM hints is hardly on game developers todo lists. !!! I was however wrong regarding xonitic-sdl (looked up the wrong WinID, my bad) It *does* set the class as "xonotic-sdl" and does so in time, so a window rule matching this class will successfully suspend the compositor. > > Game, screensaver or firefox - all just set _NET_WM_STAT_FULLSCREEN > Why then not add the ability for a rule to identify on > _NET_WM_STAT_FULLSCREEN kwin rules are not prepared for _NET_WM_STATE matching, there's a wish regarding this: https://bugs.kde.org/show_bug.cgi?id=271856 The change would be quite invasive (it's not sth. you'd do passing by) and most important, it wouldn't solve the particular issue because you'd still simply hit all fullscreen windows at once (unless there're additional hints ....) > Alternatively window geometry is known by x (the stuff printed by xwininfo) > and maximised and fullscreen do have different geometry. +heuristically +hack -performance if you want to check for fullscreen windows, you use that flag nowadays. > I know this ignores non-fullscreen windows but could be an intermediary. I > am looking into other ideas. Or some way of enabling blocking on all SDL > windows would be interesting... Too broad. SDL (games) can be windowed (non fullscreen) and non resource demanding as well (eg. scummvm) Technically one had to check the application for the pid, carve out the executable from the cmdline (linux only, does afaik not work on BSD) and ldd it for libSDL... it's simpler and more robust if the application sets a hint.
Not yet tested, but in ReviewRequest https://git.reviewboard.kde.org/r/104448/ you can find the extension to have it in scripts. You can easily write your own script to block for all fullscreen windows.
(In reply to comment #5) > !!! I was however wrong regarding xonitic-sdl (looked up the wrong WinID, > my bad) > It *does* set the class as "xonotic-sdl" and does so in time, so a window > rule matching this class will successfully suspend the compositor. There might actually be something going wrong here specifically with Xonotic now you say this. I've now found that although 'detect properties' does pick the window class up properly, using window class does not allow rules to work for Xonotic. Even trying regular expressions didn't give anything. Detecting the window title 'Xonotic' does however enable composite blocking properly though so a rule can be used even if window title isn't best practice. Not sure if this is common with other programs at all? And thanks Martin for the code.
(In reply to comment #7) > (In reply to comment #5) > > !!! I was however wrong regarding xonitic-sdl (looked up the wrong WinID, > > my bad) > > It *does* set the class as "xonotic-sdl" and does so in time, so a window > > rule matching this class will successfully suspend the compositor. > I've now found that although 'detect properties' does pick the window class up properly, using > window class does not allow rules to work for Xonotic. At least i cannot detect the window because it attempts to grab the entire server (ie. if you press detect before, xonotic will hang unless you click, then create the actual window. If you detect after -using a delay- that will simply fail because xonotic has successfully frabbed the server.... *sigh*) using "xonotic-sdl" (w/o quotes!) as class works fine. --- snip kwinrulesrc -------------- Description=Settings for xonotic-sdl blockcompositing=true blockcompositingrule=2 wmclass=xonotic-sdl wmclasscomplete=false wmclassmatch=1 ---------- /snip -----------------------
Git commit 7595ab5480d3710b6e95bfac800ba7f580788866 by Martin Gräßlin. Committed on 31/03/2012 at 19:09. Pushed by graesslin into branch 'master'. Export blocking compositing as a Client's Q_PROPERTY Allows to block compositing on Client's from scripts. Usecase: window rule cannot properly identify buggy clients and scripting allows to just act on fullscreen windows. FIXED-IN: 4.9.0 REVIEW: 104448 M +11 -4 kwin/client.cpp M +16 -0 kwin/client.h http://commits.kde.org/kde-workspace/7595ab5480d3710b6e95bfac800ba7f580788866
Git commit 72718ceef7ca07d80434386d5cae52c243b9b4a0 by Martin Gräßlin. Committed on 01/04/2012 at 08:30. Pushed by graesslin into branch 'master'. Example script to block compositing for fullscreen windows Requires kde-workspace as of 7595ab5480d3710b6e95bfac800ba7f580788866 A +27 -0 kwin/scripts/blockcompositingfullscreen/contents/code/main.js A +17 -0 kwin/scripts/blockcompositingfullscreen/metadata.desktop http://commits.kde.org/kdeexamples/72718ceef7ca07d80434386d5cae52c243b9b4a0