Bug 452780

Is it not already?

src/x11client.h:    Q_PROPERTY(bool blocksCompositing READ isBlockingCompositing WRITE setBlockingCompositing NOTIFY blockingCompositingChanged)


(I haven't tried it yet)

They are independent. `NET_WM_BYPASS_COMPOSITOR` (aka the hint) is what the window requests, and `blocksCompositing` (aka the property) is what kwin is currently doing with it.

The hint is inmutable, where the property is mutable. Changing the property doesn't affect the hint, and reading the property doesn't tell what the hint could be.

Furthermore the hint has three settings (unset, true, false), where the property has only two (true, false).

This is relevant because through the kwin api you can't really tell what the windows actually requests. You can only guess, for example, by storing the initial status of composition for a window. But even then it has corner cases where you can't really guess.

The rest of properties are unrelated. They are either signals or refer to different objects. For example for Firefox I get:

resourceClass = firefox
blocksCompositing = false
isBlockingCompositing = undefined
setBlockingCompositing = undefined
blockingCompositingChanged = function() { [native code] }

I see your point. Though I don't want to introduce a two properties on each client which are maybe in sync maybe not and still have it still awkwardly racey.

What I think we would want is:
 - API to write directly to Compositor::suspend/resume (exposed somehow)
 - API to set a flag (maybe generic transient config writing) to disable whether updateClientCompositeBlocking does anything

Then your script would:
 - disable updateClientCompositeBlocking from doing anything so your script takes over control
 - monitor clients
 - call suspend/disable as appropriate

Though in your examples one could also just use Window rules?

I suspect it's just simpler to expose the structure as it is, and let the developer figure out the use case versus anticipating all the plausible scenarios. Aka separating the policy from the mechanism.

The only thing we may need is to name things in a way it doesn't cause confusion, as maybe the hint currently does.

There could be a property called "client.preferredCompositionMode" with the options "no preference", "composed", "not composed".

Likely having a global option to change composition status won't really help further, specially if you cannot tell what the preference for each window is.

For example web browsers tear badly if composition is disabled, where games usually have their own vsync mechanisms and don't benefit whatsoever from composition. So blocking composition per application makes more sense.

We're not adding new features for X11