staging: add ext-blur-v1
This protocol allows the client to specify a region behind the surface that should be blurred, with the intention to improve the visuals of for example panels or terminals.
This protocol is based on the org_kde_kwin_blur protocol, which has been in use since 2015.
Signed-off-by: Xaver Hugl xaver.hugl@kde.org
The changes vs !43 are:
- I adjusted the naming and "unstable" disclaimer to how newer protocols are done
- The object becomes inert when the surface is destroyed, instead of having an error for that case
- the initial region is empty, which is more similar to how other protocols deal with this sort of extension (=don't change anything by default)
Merge requirements:
-
2 ACKS -
one compositor implementation: https://invent.kde.org/plasma/kwin/-/merge_requests/4890 -
one client implementation
Merge request reports
Activity
- Resolved by Xaver Hugl
- Resolved by Xaver Hugl
- Resolved by Xaver Hugl
how to deal with anti-aliased rounded corners? Using a whole alpha buffer for the blur mask seems like the only option for that
From experience, you can't without an alpha mask, realistically.
In hyprland we have an
ignorealpha
mechanism where blur will not be applied ifa
of the buffer at that place is <= a user-defined valueI don't think this would be a great mechanism here, as it feels more like a hack, but can't think of a better method.
added New Protocol label
As it's been a year without any movement, I'd like to ignore the mentioned issues and just leave it as a nearly exact copy of the KDE protocol. Additions to this protocol or a v2 can always be done to improve the situation or add more features, but the issues aren't noticeable enough in practice to drag this out even longer.
Any objections to that? Or, to make that question more actionable, would the people that asked me about upstreaming this, IIRC @emersion and @Drakulix, still ACK and implement support for it?
On the mentioned issues:
- I like the proposal for a "blur-mask", but I agree that this could be added backwards-compatible in a new version.
- I don't think the issues with fraction-scaling are deal-breaking, but I would like to hear some ideas at least on how we could tackle this later? If you need to bumb the major version of the protocol, that would be unfortunate, when we knew the issue upfront.
On the question: Yes I would. We already had people implement kde-blur support for libcosmic and discussions/experiments on how to implement it in smithay are on-going.
Lastly I wondered, if it would make sense to have a way to feedback to the surface, if blur has been applied? Doing this when software-rendering is employed is most likely bad for performance and users might want to toggle blur as a feature at runtime. So there might be cases, where a compositor might advertise the protocol and later would like to revoke that capability without killing clients. As a client this is valuble information as contrast might be lacking, when you expect blur but get a simple transparent surface instead. (Maybe this should be a separate thread?)
I don't think the issues with fraction-scaling are deal-breaking, but I would like to hear some ideas at least on how we could tackle this later?
!149 would solve it for example, or you could add a buffer-local instead of surface-local region (which would be a lot more annoying to implement in KWin at least, but probably doable), or the blur mask buffer could make it work too. It's hard to imagine anything that would require breaking backwards incompatible changes.
Lastly I wondered, if it would make sense to have a way to feedback to the surface, if blur has been applied?
In Plasma we just make it dependent on the global - if the compositor removes it, plasmashell assumes blur is not applied anymore. Do you think documenting that assumption is enough?
In Plasma we just make it dependent on the global - if the compositor removes it, plasmashell assumes blur is not applied anymore. Do you think documenting that assumption is enough?
So the availability of the global is treated as the capability available? I guess that works, but should indeed be documented as most clients probably don't monitor globals after initially binding it.
added 74 commits
-
992a3286...20bcf732 - 73 commits from branch
wayland:main
- 29ad48b5 - staging: add ext-blur-v1
-
992a3286...20bcf732 - 73 commits from branch