Notice that for performance reasons, we've a feature to suspend the compositor alltogether while certain windows are on screen.
This is controllable by rules[1], scripts[2] and the clients themself[3]

Unredirection is
a) buggy upstream (we forcefully disabled it because notably the intel driver would constantly crash)
b) hardly a performance gain (if all - and not compared to freeing all resources)

[1] kcmshell4 kwinrules
[2] http://kde-look.org/content/show.php/GameMode?content=156659
[3] http://api.kde.org/frameworks-api/frameworks5-apidocs/kwindowsystem/html/classNETWinInfo.html#ac264bd0ff15058b4158ea2932ea2fda2

This option is the opposite of what kwin offers. With this option you unredirect all fullscreen windows except the one you choose. Don't need to modify this settings each time you install a new game.

I use unredirect fullscreen windows because of this bug (by the way I hope it will be fixed ;) ) :

Stutter @23.976hz, likely du to wrongly reported refresh rate 
https://bugs.kde.org/show_bug.cgi?id=344864

I tried to use a kwinrules to disable compositing when I use MPV but sometimes it seems to don't work and I had stutter. Maybe an other bug ?

I still think this little addition can be useful to some people ;)

To check whether compositing is suspended do
  qdbus org.kde.KWin /KWin supportInformation | grep "Compositing is not active"

If it is and you still perceive stutter w/ mpv, it's not due to KWin.

I don't know when but I will try

I just wanted to say that the bug I talked about in comment 2 (Stutter @23.976hz) seems to be fixed (see bug 344864 for more infos). Still in comment 2, the use of a kwin rule to disable compositing when I use MPV seems to works every time (KDE 4.13).

I still think this feature can be usefull in complement of these one :

- Add "Fullscreen window" matching : useful to manually handle some kwin rules for "Fullscreen window"

https://bugs.kde.org/show_bug.cgi?id=356557 

KWIN doesn't respect _NET_WM_BYPASS_COMPOSITOR application window property: useful to have a standard and automated behavior for disabling compositing for compatible apps.

https://bugs.kde.org/show_bug.cgi?id=349910

Any chance this will be implemented ?

> Any chance this will be implemented ?

Very unlikely, On Wayland this is not needed and on X11 we think to already provide more suited solutions like turning compositing off. The comparison to Compiz/Unity or Mutter/GNOME just doesn't hold as those don't provide the functionality to turn compositing off.

Wayland won't be mainstream until some more months or years for some distros. There is no feature in Kwin to say "disable compositing for all windows except these one" too. I prefer the unredirected windows thing than totally disabling compositing (plasma need to "restart/reload" or something like that).

Anyway I'm again frustrated by the open source devs. You can't help the open source world by proposing useful features that will make the softs better. The devs do only what they want without giving a shit of what users needs (eg. different wallpapers for virtual desktops, systray icons, plasma slow as hell to load, kcalc, konsole that keep running in background, blurry wallpapers, etc...).

Sorry Martin my rant is not against you particularly and I'm thankful for the incredible work you and others already make but it's so frustrating that devs far too often say you WONTFIX. It's like you are saying "I DONT GIVE A SHIT".

Jeremy: I think you have a wrong assumption about the Open Source world. We devs are not waiting for users to propose ideas to implement. If you expect that you can propose ideas and they will be implemented, you will end up frustrated.

Open Source very often means that you can suggest ideas, that's already a huge difference to the closed source world. But still devs will evaluate the idea and then decide whether it should be implemented or not.

In  this case for me the evaluation is simple: doesn't make sense with Wayland, won't get implemented. Yes it takes time till we get to Wayland, but each change which is done for X11 only, will move the switch to Wayland further down. So at least I for myself do not consider X11-specific solutions at all any more. Anything that hinders Wayland adoption will not be implemented by my. This might not be what you as a user wish, but it's what I as driving the project need to do.

Now it's open source, this also means that you can grab the code and modify as you wish. You can convince others to do that for you, you can even pay people to do that. If a patch gets written which is side effect free and improves the situation the chances are good to include it. And if not: open source gives you the possibility to fork the project and apply the patch there.

But Open Source doesn't give you the possibility to tell devs what they should work on. Sorry about that. Don't expect it, don't be frustrated about it.

What I expect is if an user suggest a good idea that is not so hard to do it should be implemented. In the end it's the users that deals everyday with limitations/problems/bugs of the softs the devs make. Maybe when you evaluate an idea you should try to think more as a user. The feature I suggested should be really easy to implement for someone like you that can make something like kwin and has nothing to do with the adoption rate of Wayland.

You should already be aware, and it's probably not the only one, but take a look here to see that I'm not the only one that can be frustrated with nonsense, for the users, decisions.
https://bugs.kde.org/show_bug.cgi?id=341143

> What I expect is if an user suggest a good idea that is not so hard to do it should be implemented

How do you know that it's "not so hard" to implement? You are a user, please trust the evaluation we devs knowing the code put into it.

> In the end it's the users that deals everyday with limitations/problems/bugs of the softs the devs make.

If you are not satisfied with the quality of the free product we provide, I highly suggest that you switch to another software provider. I'm sorry that our software doesn't fit your expectation for software.

Yes I'm a user but I'm not stupid ;) The feature I suggest is simply a list of windows that should not be unredirected. You already have the necessary features in kwin.

You take it wrong. I choose to use free software. I love the softwares you make and because of this I want to help to improve them even further. Like I already said on an other bug report, the open source softwares are often 99% perfect but they lack this one last percent of polish. It's a pity because the devs have already done the hard work and it's amazing but I can't understand why they don't want to go further and make it as perfect as it can be for the most people.

This "1% of polish" is different for every user, though.

To me as a by-stander, this particular wish seems to be about a feature that only a very limited subset of users want or need. That means, given limited resources, Martin is right and his time can better be spent in another way.

Your sense of entitlement is wrong, as well. Open source enables you to scratch your own itch. Contributing by filing feature suggestions only goes so far (it's perhaps 0.01% of the work involved, the rest is implementation and maintenance of that feature. As soon as you start harrassing developers, this even tips to the negative and instead of "contributing", you're doing harm since a developer like Martin now has to deal with you on top of doing his normal work. At that point, your contribution is means that you're actually hindering the progress of the software you say you're caring so much about.

The most productive thing to go about this thread is to accept its resolution state and live with it (or perhaps use another piece of software that satisfies your wish (you mentioned compiz)).

ok, that's now my last reply to this thread. Thomas and I have both explained to you that unredirection fullscreen is not a good idea. It's not useful, it's not an improvement - in fact I'm considering to remove the implementation all together.

In KWin/X11 block compositing is the solution. This is fully scriptable, so you can write your own script which does all you want.

In KWin/Wayland there is neither an unredirection nor a block compositing. The compositor will do the right thing once I implement it (TM).

Unredirection is a solution for compositors not supporting turning compositing off. It's not an improvement! The point where you started from is wrong. Thus the whole idea just doesn't make any sense to implement. Why should we spend time on something which is just wrong in our opinion?

I understand perfectly Martin, so I agree to forget my idea, but in the mean time (mainstream Wayland) Kwin will lack a feature to "disable compositing for all windows except these one".

There're two reasons to avoid compositing:

a) Spare resources
b) Work around a bug

(a) is *not* reasonably gained by unredirection.
(b) is a bad approach to deal with problems

Unredirection is in KWin "because compiz had it" (but compiz cannot work w/o compositing at all) and error prone like shit.
It can only be applied to 24bit fullscreen windows and only as long as they're completely on top of things.
A dialog or popup menu opens? => re-redirection.
Another window is activated? => re-redirection.
You'd like to transform the desktop rendering (present windows etc.)? => re-redirection.
...

Alternative approaches are "don't redirect unmananged windows or transients for an active fullscreen window". The result is that those windows show up uncomposited (and we got bugreports about missing shadows)


Now Jeremy, lets try to get to the bottom of this:
Leaving the unredirection stuff aside, and reg. the other bug report: you're apparently looking for a way suspend the compositor for all fullscreen windows but some exceptions, because your fullscreen windows are typically a pleathora of games and only in very few specific occasions eg. "fullscreen firefox" should execptionally not suspend the compositor.

Thus the wish for a rule to match all fullscreen windows - you would have created a general one and trumped that by specific rules for eg. firefox etc.

=> Does this describe your functional goal?


NOTICE: I removed you from my SA blacklist to get your reply.
Please stay on topic and avoid emotional discussions or generic comments.

(In reply to Thomas Lübking from comment #16)
> you're apparently looking for a way suspend the compositor for all fullscreen
> windows but some exceptions, because your fullscreen windows are typically a
> pleathora of games and only in very few specific occasions eg. "fullscreen
> firefox" should execptionally not suspend the compositor.
That is exactly the use case I'm thinking of !

> Thus the wish for a rule to match all fullscreen windows - you would have
> created a general one and trumped that by specific rules for eg. firefox etc.
> 
> => Does this describe your functional goal?
Yes, perfectly.

> NOTICE: I removed you from my SA blacklist to get your reply.
> Please stay on topic and avoid emotional discussions or generic comments.
Thank you for that. I'm really sorry for what happened and I'm glad that is over.

(In reply to jeremy9856 from comment #17)
> (In reply to Thomas Lübking from comment #16)
> > you're apparently looking for a way suspend the compositor for all fullscreen
> > windows but some exceptions, because your fullscreen windows are typically a
> > pleathora of games and only in very few specific occasions eg. "fullscreen
> > firefox" should execptionally not suspend the compositor.
> That is exactly the use case I'm thinking of !

Ok, neither scripting nor rules are ready for this since they only deal with managed clients, but several games (engine) create "fullscreen" windows as an override_redirect window spanning the root geometry (and grabbing input)


Notably with a game context in mind, I strongly suggest to abort any approach reg. unredirection and focus on a solution that skips the compositor.
The unredirection gain isn't worth it. You still have +1 active GL context and rather heavy usage of texture memory. Redirection or rather texture_from_pixmap caused quite some load in early compositing ages but is neglectable as of today and redirected gl contexts should sync to the compositor.

=> What needs to happen:
1. port https://git.reviewboard.kde.org/r/111771/ to KWin/5 => bug #357565
2. adapt the gamemode script to support unmanged windows (local version still does. no idea whether I ever published that - worthless w/o above patch, though. Unmanaged clients cannot be matched, only globally toggled)
---
3. add a config GUI to the gamemode script
4. let the user switch between whitelist and blacklist behavior there
---
5. check whether the script should be shipped w/ kwin (which scripts should be anyway?)
6. recheck w/ HIG team why scripting is "hard to use" (hard to find? clicking the GHNS button cannot be harder than setting up a window rule, can it?)

That seems very good. The point 6 is very important, it should be very easy to use like a checkbox to activate the "gamemode" and a simple field to enter the windows that should not disable the compositing.

It need some work but it worth it I think and it's a lot easier than the Martin suggestion too.
http://blog.martin-graesslin.com/blog/2015/12/gaming-on-linux-move-to-next-generation/

(In reply to jeremy9856 from comment #19)
> to use like a checkbox to activate the "gamemode" and a simple field to
> enter the windows that should not disable the compositing.

The checkbox is already there (this is how scripts are triggered)
Please understand that everybody wants "his" feature to activate by sheer will, but we lack a brain interface.

> It need some work but it worth it I think and it's a lot easier than the
> Martin suggestion too.
> http://blog.martin-graesslin.com/blog/2015/12/gaming-on-linux-move-to-next-
> generation/

Sorry, I don't follow. It is *exactly* what's described in the "X11 workaround" section (and the rest is irrelevant to the topic) - the only question is "who activates the block" and *obviously* the ideal solution would be the client in question would just say "make me uncomposited".
In a less than ideal world it's really a matter of scenario.
I assume that for the vast majority of users only blocking some specific clients is the ideal solution. Only if you use your box predominantly to play resource intense games you require a blacklist approach to this (since it's obviously suddenly the more convenient way)

(In reply to Thomas Lübking from comment #20)
> The checkbox is already there (this is how scripts are triggered)
> Please understand that everybody wants "his" feature to activate by sheer
> will, but we lack a brain interface.
That's not what I meant. I mean a checkbox easily discoverable, like the one "unredirect windows" or even easier to find and use because the scripts are in their own windows and for a "normal" user it's not really obvious that in order to play game in good condition he need to activate a script in this particular window.

> Sorry, I don't follow. It is *exactly* what's described in the "X11
> workaround" section (and the rest is irrelevant to the topic) - 
The suggestion of Martin is "When a fullscreen game starts, it can create a “sub-session” on a new virtual terminal and become the logind- session controller for that session. Etc...". It seems that is not really easy to do and not exactly the same thing that simply disabling compositing. But nevermind, it's not important here.

> the only question is "who activates the block" and *obviously* the ideal solution
> would be the client in question would just say "make me uncomposited".
As you know, that's the point of this _NET_WM_BYPASS_COMPOSITOR (bug 349910). But unfortunately not every software that can take benefit of it will use it, therefore the blacklist.
By the way I see that you have submitted a review request https://git.reviewboard.kde.org/r/126561/ Does this mean that it will be implemented ?

(In reply to jeremy9856 from comment #21)

> I mean a checkbox easily discoverable, like the one "unredirect windows" 
It actually was the dedicated intention of the HIG team to stash this particular dialog.

> in their own windows and for a "normal" user it's not really obvious that in
> order to play game in good condition he need to activate a script in this
> particular window.

He doesn't - the game can signal its demands and the user can setup a rule (as you originally intended to do, just that you could not match "all fullscreen windows" there)
Bear in mind that yours really is a corner case from all I can say about our regular userbase.

It might be possible (should b? Really no idea) to make the scripts searchable in systemsettings (so "game" would find you "game mode" if installed) and maybe they should be renamed "extensions" (to align the popular browser concepts)?


> The suggestion of Martin is "When a fullscreen game starts, it can create a
> “sub-session”

That's a brainstorm on how games could be implemented on/next to Wayland.
You will neither be able to unredirect nor suspend compositing on wayland, so this may require a completely new infrastructure anyway and is completely unrelated to your concern.

> By the way I see that you have submitted a review request
> https://git.reviewboard.kde.org/r/126561/ Does this mean that it will be
> implemented?
It /is/ implemented (and a good sandbag died for it), but the patch not yet approved. Interestingly, the property seems just as much unused as the original KDE property (at least I couldn't find a testcase)

(In reply to Thomas Lübking from comment #22)
> It /is/ implemented (and a good sandbag died for it), but the patch not yet
> approved. Interestingly, the property seems just as much unused as the
> original KDE property (at least I couldn't find a testcase)
Thank you very much ! I hope it will be approved.

MPV use it : https://github.com/mpv-player/mpv/commit/ad3f75cc94adac9781fda93cc2a7c0c23ac0a606
By the way I think it's not "fully" implemented in MPV. Not all cases are handled.
If you want you can help there because I think (if I'm right) wm4, the MPV developer, don't seem to really "understand" the use of the hint : https://github.com/mpv-player/mpv/issues/2582
Of course if I'm wrong I will be happy if you explain it to me ;)

The "confusion" / conflict over there occurs because, and I will repeat myself, the NETWM property is outmost rubbish.

It says:
"The compositing manager MAY bypass compositing for both fullscreen and non-fullscreen windows if bypassing is requested, but MUST NOT bypass if it would cause differences from the composited appearance."

So, leaving aside the "MAY", there's for once a "MUST" condition and it points an impossibility: unredirecting the window will /always/ "cause differences from the composited appearance" in a global context.
Even windows on top of the client stack are covered by unmanaged clients (popups), panels - and eg. KWin has an extra "OSD" layer. There's discussion on mpv about tearing depending on compositing available. You'd have to redirect the window (if you went for the non-resource saving unredirection) to get a thumbnail into tabboxes or effects like exposé etc.

=> The spec virtually says: "this property has to be ignored" m(

KWindowSystem is currently (patch in rb) taking the hint as "I'd strongly benefit from an uncomposited environment", analogue to the KDE property.
The fullscreen state doesn't matter as either the client does benefit from an uncomposited environment or it does not - and it has no impact on "differences from the composited appearance" (mpv would now suspend the compositor for kwin/dowsystem w/ the "--x11-bypass-compositor" hint and that seems to be a problem on other compositors already)