[Feature Request] Frosted / Blurry background window support (Windows Acrylic / macOs: Vibrant)

[bric3]

General description
What is the motivation for this suggestion.

In order to integrate better with the OS in some aspects, I wonder if it is possible to modify the underlying frame window to be blurry.

There seems be different wording depending on the OS, e.g on Windows the usual term is "Acrylic", on macOs the term is "Vibrant".

This suggestion is:

• Visual
• Behavioral

From what I've seen elsewhere, it requires a native access to acquire the native window handle in order to modify it. Mich may pose problem if the native symbol is not available, or if the API evolved in some non compatible ways.

• Windows
  One may try to invoke DwmEnableBlurBehindWindow

  https://github.com/krlvm/SwingAcrylic
  https://stackoverflow.com/questions/22027247/java-setting-background-from-jar-and-making-it-transparent

• macOs
  It seems the magic happens with NSVisualEffectView and setting the blending mode to something like NSVisualEffectBlendingModeBehindWindow, which seems to pack some more effects (like corner rounding, whether title bar is vibrant too).
  https://github.com/wailsapp/wails/blob/801cf3c84ae5c07c1ab31b56e420af4861992d14/v2/internal/frontend/desktop/darwin/WailsContext.m#L175-L184
  https://github.com/lukakerr/NSWindowStyles

For Linux I have no idea how this could work, it might depend on Wayland (I don't think this can work on X11) and which compositor is available.

For visual suggestions
How do you want the result to look. If possible provide examples or provide a detailed description.

• Windows
  As I don't have a Windows OS I'm just copying the image from (krlvm/SwingAcrylic)
  

• macOs
  

For behavioral suggestions
Please provide a detailed description of what should happen at what point.

Additional context
Add any other context or screenshots about the feature request here.

[weisJ]

This is a very good idea. Some quick thoughts that I have about it:

• Linux support is probably not feasible IMO.
• I think nowadays Windows uses Mica (on Windows 11) for this kind of effect. Though from the API documentation it is not clear weather it can be enabled after a window is created.
• A component like this would probably need to heavily modify all components above it. Most backgrounds will have to be transparent others probably opaque. Borders most likely can stay opaque (focus rings not so much).
• I‘ll try to add this functionality not be too coupled with the core library so others may make use of it. But in view of my comment above a feature like this will need major cooperation from the LaF to look good (and even be visible)

[bric3]

I believe there's some prior work in particular I've seen stuff o Windows and JavaFX

• https://github.com/dukke/FXThemes (most recent work)
• https://github.com/kieferlam/JavaFX-Blur

That said I'm not sure I've seen macOs work on the matter. I've only seen other language runtime doing that.

• https://github.com/carldea/windowblur (JavaFX)

A component like this would probably need to heavily modify all components above it. Most backgrounds will have to be transparent others probably opaque. Borders most likely can stay opaque (focus rings not so much).

I think the mechanism should only work on top windows ? In order to profit from the mechanism child component need to be transparent (opaque = false) I believe.

I‘ll try to add this functionality not be too coupled with the core library so others may make use of it. But in view of my comment above a feature like this will need major cooperation from the LaF to look good (and even be visible)

Does it ? E.g. Could this work by "patching" the Window, and applying the opaqueness / transparency on specific components ?

Thinking out loud: that said maybe it might problematic some type of popups without LaF support, like:

[weisJ]

A component like this would probably need to heavily modify all components above it. Most backgrounds will have to be transparent others probably opaque. Borders most likely can stay opaque (focus rings not so much).

I think the mechanism should only work on top windows ? In order to profit from the mechanism child component need to be transparent (opaque = false) I believe.

Yes with "components above" I meant child windows. M idea would be to apply this on the level of the JRootPane (which then also needs to become transparent) and provide a convenience component which automatically manages the backgrounds for child components.

I‘ll try to add this functionality not be too coupled with the core library so others may make use of it. But in view of my comment above a feature like this will need major cooperation from the LaF to look good (and even be visible)

Does it ? E.g. Could this work by "patching" the Window, and applying the opaqueness / transparency on specific components ?

Even if they are transparent (non-opaque) some LaFs still paint backgrounds e.g. for textfields, comboboxes etc. which may look out of place on an acrylic surface.

Thinking out loud: that said maybe it might problematic some type of popups without LaF support, like:

[...]

It should be straight forward to detect most of those special cases. For example one could only allow this effect on JFrame and JDialog as this already rules out tooltips and popups. Requirements can be relaxed if necessary (and possible).

[bric3]

provide a convenience component which automatically manages the backgrounds for child components.

Even if they are transparent (non-opaque) some LaFs still paint backgrounds e.g. for textfields, comboboxes etc. which may look out of place on an acrylic surface.

That said this may depend on the intended design, E.g. on macOs usually the sidebar can have the frosted effect and the content panel is opaque.

That said I agree if those components have to be on the forsted/blurry/acrylic surface this may look odd. But this feel like a "second" issue than making the JRootPane able to us the OS API to make a window blurry. And there's the OS variations like accent color title bar transparency.

Maybe adding utility method to patch the background in the first place might be enough for this work, then divide the work in another issue to make the LaF support this.

[Flopgop]

• I think nowadays Windows uses Mica (on Windows 11) for this kind of effect. Though from the API documentation it is not clear weather it can be enabled after a window is created.

I've done something relating to this before so I thought I'd share my own insight. The mica blur effect uses the SetWindowCompositionAttribute func in user32.dll (which isn't exported, you have to use loadlibrary and get the proc address) with a HWND and a pointer to a WINDOWCOMPOSITIONATTRIBDATA struct, which has a WINDOWCOMPOSITIONATTRIB Attrib, LPVOID pvData, and a UINT cbData. Attrib is 0x13 (refers to WCA_ACCENT_POLICY), pvData is an ACCENT_POLICY struct which has an ACCENT_STATE AccentState, UINT AccentFlags, COLORREF GradientColor, and a LONG AnimationId, and cbData is the sizeof that struct. Specifically, in the case of the acrylic blur, AccentState is 0x4, I'm not sure what effect AccentFlags has, I use 2 in my app but I haven't been able to observe a difference, COLORREF is the tint of the acrylic with ABGR format, and I also don't know what AnimationId refers to. The API is largely undocumented and my code is not in C or Java so I don't think sharing it would be of much help however I hope this info may have been insightful to your endeavors. Although its probably important to note that, this being undocumented API, could just randomly change in any windows version and probably isn't a good idea to rely upon.

Some resources:
random github gist
SetWindowCompositionAttribute docs

[weisJ]

I will gladly accept any PRs regarding Windows support on this issue. As of lately I no longer have access to a Windows device which hinders development in this regard. Of course I can assist on how to do the plumbing of patching the native window.