https://bugs.kde.org/show_bug.cgi?id=452780
--- Comment #4 from Alberto Salvia Novella <es204904...@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
