[Feature] Dynamic Liquid Glass — real-time desktop refraction (Apple-quality, clone-based)

[NB-Group]

tl;dr

Real-time, Apple-quality liquid glass for the panel, dash-to-dock and popups — refracting the live desktop (wallpaper and windows, dynamic or static) through a clone-based backdrop + single-pass GLSL shader. Plus three-way coexistence with applications blur and dynamic wallpapers (e.g. waywallen).

🎬 Demo:

a3e0abb1babe07e6801b56154bd9cedc.mp4

📹 Handheld phone capture — OBS is bugged on this machine so I had to film the screen by hand. The actual on-screen effect is smooth; any flicker/tearing is a capture artifact, not the effect itself.

This is not BMS's existing "Liquid Glass" (refraction.glsl, which blurs a static wallpaper snapshot). That one can't follow windows or dynamic wallpapers. This is a new, clone-based pipeline that samples the actual live stage behind the widget, every frame.

What it does

• Live refraction: the glass shows what's actually behind it right now — drag a window under the panel, switch workspaces, run a video wallpaper — it all refracts through the glass in real time.
• Single-pass shader: gaussian blur + refraction bands + top-bright/bottom-dark sheen + rounded-rect mask (ported from the apple-inspired-glass-effects-library reference).
• Three-way coexistence (the genuinely hard part): liquid-glass panel/dock/popup + applications blur + dynamic wallpaper — all at once, with windows showing through the glass.

How (technical)

• New conveniences/liquid_glass_pipeline.js (clone-based see-through architecture): each glass widget clones _backgroundGroup + a shared window_group capture, then runs the LiquidGlassEffect shader on the widget.
• Shared window_group capture (one offscreen-cached clone of window_group in uiGroup): N glass widgets sample one cached texture, so the desktop is composited once per frame, not N times (avoids the mutter multi-clone pollution / window-shadow corruption you'd get from each widget cloning window_group directly).
• applications blur coexistence: applications keep BMS's native Shell.BlurEffect(BACKGROUND) inside window_actor. The whole-window_group capture includes that blur_actor → a mild render loop, deliberately accepted.

Known limitations (this is the "experimental" part)

Mutter/Clutter impose real constraints here. Most are worked around, but two remain:

1. Applications blur actor desyncs during motion — when a window is dragged or the workspace snaps (3-finger swipe), the applications-blur blur_actor (native Shell.BlurEffect(BACKGROUND) inside window_actor) outruns the window and briefly disappears, exposing the solid wallpaper layer behind it for a beat ("purple veil"). Root cause is the accepted render loop (the whole-window_group capture includes the blur_actor, which itself samples _backgroundGroup) plus mutter's blur position sampling during motion. BMS-side fix is blocked: the capture can't exclude the blur_actor without losing window see-through, and GNOME 50's gesture snap doesn't emit the standard workspace_manager::workspace-switched signal so a freeze/hide hook can't reliably catch the moment. Small, motion-only; static at rest.
2. Performance — single-pass 21×21 (441-tap) gaussian per widget per frame, tuned to avoid grain on high-frequency window content. Fine on discrete GPUs; heavy on low-end / integrated. A separable 2-pass blur would cut this ~4× at the same quality (future work).
3. GNOME version — developed & tested on GNOME 50.3, NVIDIA, Wayland. Older versions untested.
4. Rounded corners — shader mask reads the host's corner radius (panel = rect, dock = dash-to-dock's dash-background radius, popup = menu radius); AA tuned, may need per-theme tweaks.

The code comments also document the dead-ends that don't work under mutter, so the next person doesn't re-walk them: clone-based ShaderEffects don't apply below window_group; per-child Clone(MetaWindowActor) doesn't bind its texture; GaussianBlurEffect's chained FBO can't render a clone backdrop; etc.

Try it

Fork: NB-Group/blur-my-shell, branch feature/dynamic-liquid-glass.

Per-component "Liquid glass" toggle (dynamic mode). The Other page exposes three hero params: blur / tint / refraction.

Discussion

This deliberately pushes against mutter's compositing model. It works and (imo) looks genuinely great — but the applications-blur coexistence leans on an accepted render loop. Flagging for community discussion:

• Is this direction welcome upstream?
• Any cleaner way to break the applications-blur / glass-sees-windows loop without changing waywallen?

---

[NB-Group]

a huge thank you to @dashersw for the incredible Liquid Glass JS library!

[MeguMario]

@NB-Group Thanks for the cool showcase. We already have an implementation of Liquid Glass, and while right now it's static blur only, it's also meant to use with #896 as well, which make the current static blur pipeline compatible with dynamic blur as well, you are welcome to improve on the current and your own implementation ofc.

Personally while I'm not on behalf of the project, I would like for #896 to have some help as well, since the proposal here overlap a lot with that PR

[NB-Group]

Thanks for the kind words, and for the pointer to #896! 👍

Took a look — the LiveWindowGroupSource (per-window clone) refactor is the cleaner long-term direction. #931 went the shippable route instead: one whole Clone(window_group) cached offscreen + a liquid-glass shader (refraction/sheen), tuned for three-way coexistence on GNOME 50 (applications blur with native BACKGROUND + waywallen dynamic wallpaper + glass, all at once), at the cost of a mild render loop.

I documented the mutter clone pitfalls hit along the way (per-child Clone(MetaWindowActor) not binding its texture, Cogl offscreen negative-coord REPEAT-wrap, the applications ↔ whole-clone loop) in the proposal + code comments — happy to share if any of it's useful for #896.

Looking forward to seeing #896 land.

[NB-Group]

One more on quality: side-by-side with the current static Liquid Glass, the refraction here is a step up on its own — not just dynamic-vs-static. The live backdrop gives real depth (windows actually refract behind the glass, not a frozen wallpaper snapshot), and the refraction-band + sheen tuning tracks closer to the apple reference. Happy to record a side-by-side if useful.

[MeguMario]

In my opinion, I think it's better to improve the current liquid glass implementation, since not only it's much easier to maintain because we don't have two seperated implementation of the same thing, but also to make it work well with future improvements as well (#896). I think combine the improvement of your work to both the current liquid glass implementation and #896 would be nice, up to you ofc.

Also here's the current liquid glass implementation with #896, rather broken because it is currently unfinished but it's functional

lq_demo.mp4

Sorry for the anime-ish live background since that's the only one I have in my Wallpaper Engine collection 😞

[NB-Group]

Makes sense, and agreed — two parallel glass stacks would be a maintenance burden, and #896's per-window live source is the better backbone than my whole-group clone. Happy to fold the quality pieces from #931 into the current pipeline + #896 rather than push a separate implementation.

Concretely what I'd port over:

• the refraction-band + sheen tuning (the apple-feel) into the current refraction.glsl
• the mutter clone pitfalls documented in [Feature] Dynamic Liquid Glass — real-time desktop refraction (Apple-quality, clone-based) #931 (per-child Clone(MetaWindowActor) texture binding, Cogl negative-coord wrap, the applications ↔ clone loop) — directly relevant to Refactor blur surfaces and preferences #896's LiveWindowGroupSource
• the three-way coexistence (applications blur + dynamic wallpaper) findings

What's the best entry point — PR against #896's branch, or improve refraction.glsl on master first? And thanks for the demo, good to see where #896 is at.

[MeguMario]

For improvement to #896, you should discuss with @krissedout since he's the one behind that PR, feel free to play around with that branch first if you like, improvement to refraction.glsl can be done at anytime (I would prefer this first since it can be tested with the current pipeline)

[NB-Group]

Got it, thanks! I'll start with refraction.glsl improvements (testable on the current pipeline now), and reach out to @krissedout about the #896 side separately.

[krissedout]

Just to clarify the current state of #896: it was closed primarily because I wasn’t able to continue working on it at the time. The approach will likely be revisited soon, but please don’t open PRs against #896 or treat its branch as a usable foundation as the PR is effectively dead, and that branch contains a number of known bugs that still need to be addressed.

Before I can restart that work, !5165 needs to be merged in Mutter to fix the underlying bug I’m currently blocked by. After that, #920 needs to land so I have a clean and stable base to work from. I run Mutter directly from source, so until those pieces are merged, further work on this is impractical.

I’m also currently away from home and unable to contribute for the moment. Once I’m back and the upstream blockers are resolved, I intend to return to it. GNOME development can move fairly slowly, unfortunately, but I’m hoping there will be some progress within roughly the next week.

[NB-Group]

Thanks for the heads-up! I'll leave #896 alone. Worth noting: the #931 route (and the refraction.glsl work) is pure extension/GJS — no mutter changes — so it stays usable on current Mutter while #896 waits on !5165 + #920. I'll keep the refraction improvements moving independently. Good luck with the unblocks, travel safe.

[treebarkbr]

Seems good, to be fair my implementation was mainly just a port from an existing iOS jailbreak tweak (https://github.com/winaviation-tweaks/liquidass). The main reason why it was a port and not just a from scratch thing is due to the fact that I'm already really familiar with Metal and GLSL and I already know what the shader from LiquidAss looks like and it's pretty nice. Open for suggestions though

Just to repeat it though, my fork never made it natively support dynamic blur as I was waiting for #896 to complete since it adds pipeline support to dynamic blur. Would appreciate it if you were to add dynamic blur support though, but I think it'd be a better choice to wait for #896 to reopen

I might add improvements soon, currently juggling multiple work related things

Checking your fork, the implementation is fine but here's some feedback:

Yours seems more art directed, three exponential falloff bands tuned by sliders. Mine's more physically grounded mainly because it uses actual IOR/Snell's law refraction plus real surface normals based off the bezel profile. Yours is cheaper and easier to customize but mine's closer to how light actually behaves

My blur method is also cheaper. Not only because I'm on a 3400GE/Vega 11 but also the 441 tap method will be heavy on iGPUs, as you already said. I built the method with low spec hardware in mind

About the highlights/sheen, my implementation seems better but could use some improvements because it can be harsh if strength is set too high. Yours is a flat top to bottom UV gradient rather than something that reacts to a light direction or surface normal, so it won't change based on where the light is coming from. Might be worth tying it to the refraction normal

Cheers

[NB-Group]

Thanks for the detailed writeup, genuinely useful — especially coming from the person who wrote the thing.

The sheen point is fair, and honestly it's the part I felt least good about. Mine's basically a flat top-to-bottom UV gradient, it doesn't care where the light comes from. Tying it to the refraction normal + a light direction is the next thing I'm gonna do — should get most of the way to yours without rewriting the whole shader.

On blur, yeah 441 taps isn't great on iGPUs, I knew that going in. Mine was built on a discrete NVIDIA and it shows. Gonna take a real look at your method.

The art-directed vs physical framing makes sense. I went the cheap, tunable route because for a thin panel bar it reads fine and users can dial it in, but I'm not precious about it — if the normal-driven sheen lands well I might fold more of the physical bits in.

Per MeguMario I'll keep the refraction.glsl work on the current pipeline since it's testable now, and the dynamic side of mine is pure GJS (clone-based, no mutter changes) so it keeps running while #896 waits upstream. I'll ping you when the sheen change is in — would value a look.

[krissedout]

@NB-Group Not trying to be rude but, can we please keep the AI prose out of the thread? Use it to help organize your thoughts if needed, but at least rewrite and review the response yourself. We're trying to have a technical conversation with you not your agent.

[NB-Group]

@NB-Group Not trying to be rude but, can we please keep the AI prose out of the thread? Use it to help organize your thoughts if needed, but at least rewrite and review the response yourself. We're trying to have a technical conversation with you not your agent.

OK. Thanks for being direct. I use it just because my English is not great you know, sorry for bother you. I'll rewrite everything myself before posting like this comment.

[treebarkbr]

Here's a short comparison of both shaders, by the way. Bottom one is mine with few tweaks, top one i tried to make it look close to mine.
To be fair the edges are more pleasant on @NB-Group shader, but I have my feather value cranked down to 0.