On Wed, 6 May 2026 15:48:41 GMT, RealCrystalNight <[email protected]> wrote:

>> Martin Fox has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into osbackdrop
>>  - Backdrops are now objects created by specifying a material. The
>>    list of materials is now open-ended.
>>  - Merge remote-tracking branch 'upstream/master' into osbackdrop
>>  - Merge remote-tracking branch 'upstream/master' into osbackdrop
>>  - Merge remote-tracking branch 'upstream/master' into osbackdrop
>>  - Removed unused import
>>  - Merge remote-tracking branch 'upstream/master' into osbackdrop
>>  - OS supplied translucent window backdrops
>
> For Linux/Wayland support, the ext-background-effect-v1 protocol (which is 
> now implemented in KWin, with KDE Plasma 6.7 shipping this support on June 
> 16, 2026, 
> [wlroots](https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/include/wlr/types/wlr_ext_background_effect_v1.h)
>  and [Niri](https://github.com/niri-wm/niri/pull/3483) with planned support 
> coming to other DE's such as 
> [Cosmic](https://github.com/pop-os/cosmic-comp/pull/2179) and 
> [Hyprland](https://github.com/hyprwm/Hyprland/pull/13211) as well as others) 
> could be a viable path forward. Unlike some of the platform-specific 
> constraints discussed above, this protocol supports dynamically 
> adding/removing background effects, which aligns with the goal of supporting 
> setBackdrop() after the window is shown. 
> 
> Reference: https://wayland.app/protocols/ext-background-effect-v1
> 
> Real-world implementations in Ghostty 
> (https://github.com/ghostty-org/ghostty/pull/10727) and Quickshell 
> (https://github.com/quickshell-mirror/quickshell/pull/566) demonstrate how 
> this works in practice.
> This would only cover Wayland, of course X11 would likely need a separate 
> mechanism or remain unsupported for backdrops. Most major desktop 
> environments now default to Wayland, so this would cover the majority of 
> Linux users. 
> 
> Additional notes:
> KDE 6.7, which includes 
> [ext-background-effect-v1](https://www.phoronix.com/news/KDE-Brings-Back-Air-Theme),
>  is planned for release on [Tuesday 16th June 
> 2026](https://9to5linux.com/kdes-new-css-based-style-engine-union-is-coming-to-kde-plasma-6-7).
> 
> For testing purposes you can test this on KDE Neon Unstable edition as a Live 
> ISO or in a VM:
> https://neon.kde.org/download

@RealCrystalNight Thank you for the details, I'll take a look at the PR's you 
linked to. Last time I looked it seemed that the Wayland protocols only handled 
blurring the content behind the window. On macOS and Win11 the OS starts there 
and then layers other effects on top of the blur to improve text legibility, 
handle light and dark mode, and provide feedback on the window's active state. 
If that's still the case it will take some effort to get Wayland in line with 
macOS and Win11.

My plan is to keep the current Stage.installBackdrop API rather than switch to 
a dynamic Stage.setBackdrop call. This won't be an issue if we ever want to 
enable CSS support for specifying the backdrop. For popups like menus changes 
to the stylesheets are processed before the platform window is created so the 
desired backdrop is known at window creation time anyway. I don't currently 
have a use case for Stage.setBackdrop and it does simplify matters to know the 
backdrop at window creation time and only handle setting it up once.

And, yes, I'm working on the CSR.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-4390509523

Reply via email to