Partial transparency and blur protocol

[Caellian]

trafficstars

Description

I'm proposing you add a custom protocol (like KDE ones) that allows clients to specify a list of rectangles that should be kept opaque. I know you're a bit overwhelmed with requests and bug reports, this is a low priority suggestion that I think would be nice. It's questionable whether that many clients would support it though, so I guess you've got to add a "-1: when bored" label :smile:

Example usefulness: Code editor with transparent and blurred file tree but opaque text area and terminal.

[vaxerski]

I tried to push an ext- protocol for that back when I wasn't banned from fdo: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/272 -> it died as usual from fdo stuff.

but IIRC @outfoxxed also wanted to work on a similar protocol for the hyprland- namespace.

The implementation is not an issue - a 30 mins job, but the question is whether the kde protocol is good enough for what fox wants to do (if it's good enough it's better to just use the kde one)

[outfoxxed]

Yeah the KDE protocol and linked ext- protocol won't cut it for my use case as I need to be able to control the transparency of the blur. Likely something similar but with a way to set the opacity would work for me. Having an alpha buffer available as another option could also be useful.

I'm also slightly confused about your use case @Caellian, as wouldn't leaving the rectangles opaque already stop a blur from being drawn there?

[Caellian]

similar protocol for the hyprland- namespace.

KDE protocol and linked ext- protocol won't cut

I believed as much while proposing this. I did intend to propose hyprland- namespaced protocol because I can't see any which provide enough knobs and pulleys to cover hyprland features - that's why KDE has its own as well. In time fd might add some generic way to unify these for all compositors, but it could take a lot of time before that actually happens.

This has the benefit of allowing hyprland to add new decoration options in future and adding them to the protocol instead of waiting 3/4 years before being able to do so. A generic protocol might use some kv registry and region IDs to provide a way to set each value for some region ID separately, but that's just extra work and I don't see any benefits to it atm.

I'm also slightly confused about your use case @Caellian, as wouldn't leaving the rectangles opaque already stop a blur from being drawn there?

Having blur and transparency separate would allow removing blur on parts of the window while keeping them transparent. If you're putting in these options it might be little extra work to add support for both. There's definitely UI designs which could want to control them separately:

• blur is necessary to make text legible
• partial opacity without blur can be used for panels containing icons
• mixing both can make very nice looking UIs

Ideally this would work with path regions instead of rectangles, but adding paths to this would be a lot of extra work which is why I'm only proposing rectangles. Adding corner radius to rectangles would be nice, but not necessary for v1 IMO, and can be added later without breaking previous functionality.

Basically something like

struct hypr_decoration_options {
  opacity: f32,
  blur_enabled: bool,
  blur_size: i32,
  blur_passes: i32,
  blur_noise: f32,
  blur_brightness: f32,
  blur_xray: bool,
  // etc., can be extended in future if new options are added
}

event set_region_decoration(region: wl_region, decoration: hypr_decoration_options);
event remove_region_decoration(region: wl_region);
event clear_region_decorations();
// commit and other events...

I'd state that behavior for overlapping regions as undefined, I don't see a sensible way to reason about it. If region is not specially configured by the client, it uses the default decoration values from hyprland.conf.

[outfoxxed]

I was thinking about having two options.

The first option should work for all simple use cases, and mine specifically which is just fixing the opacity of popups as they fade out.

• A region describing where the blur should apply
• An alpha mapping that the blur alpha is clamped to from the surface alpha. (0.5 would cause blur_alpha = min(0.5, surface_alpha) * 2.0)

This second option should be a fallback for when the first is not enough:

• An alpha buffer controlling the opacity of all pixels of the blur.

As for the blur options I'm not sure but if I remember correctly, changing those would force an additional blur with new parameters to be generated per region instead of being able to reuse existing blur, and I can't see it working well at a per-region level. @vaxerski is this correct?

[vaxerski]

correct, thats why options will not be accepted

[Caellian]

changing those would force an additional blur with new parameters to be generated per region instead of being able to reuse existing blur

Ok, that makes sense.

[outfoxxed]

@Caellian does my proposed protocol do enough for your use case?

[Caellian]

@outfoxxed I don't have a use case :smile:, that's why I said "-1: when bored" priority initially.

I do think that storing pre-blur buffer and allowing clients to toggle between both transparency and blur would be cool though, but that's extra memory cost people might not be comfortable paying for. It could be a config setting as well I guess. It's up to you what you want/need as you're implementing it though, my suggestions are purely aesthetic.