The said hint tells if an application would benefit from running with or without composition: (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45446104333040) Examples: - A web browser indicates to always run composited, to prevent screen tearing. - A game indicates that it will benefit its performance to run without composition. This may greatly help scripts that manage composition: (https://gitlab.com/es20490446e/kwin-script-autocomposer/-/issues/1) Or even Kwin to decide by itself.
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