Skip to content
Snippets Groups Projects

staging: add ext-blur-v1

Open Xaver Hugl requested to merge Zamundaaa/wayland-protocols:work/ext-blur into main
1 unresolved thread

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:

Edited by Xaver Hugl

Merge request reports

Members who can merge are allowed to add commits.

Merge request pipeline #1351039 passed

Merge request pipeline passed for ec4fffae

Approval is optional
Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • vaxry
    • Contributor
      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 if a of the buffer at that place is <= a user-defined value

      I 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.

    • Author Reporter

      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?)

    • Author Reporter

      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.

    • Author Reporter

      yes. I added matching documentation.

    • Please register or sign in to reply
  • Xaver Hugl added 74 commits

    added 74 commits

    Compare with previous version

  • Xaver Hugl added 1 commit

    added 1 commit

    Compare with previous version

  • Xaver Hugl changed the description

    changed the description

  • ACK from cosmic

  • Please register or sign in to reply
    Loading