Transparent Windows

Syntec

Hey Garry, with the addition of plugins I have been trying to use windows acrylic with my UI but for the life of me I cannot punch through Objos window drawing. I was able to do this with Declares in Xojo. I am just thinking back to this https://forum.objo.dev/d/884-canvasclearrectangle-is-clearing-literally-everything and there must be a way to get through Avolina's window drawing.

It would be nice if there was a way to set a windows opacity (ideally just the window independent of it's controls, or to use a key value to mask out portions of the window for custom window shapes)

I totally understand if this is unrealistic and I am only trying to push my UI to the limits of what is possible in Objo. I understand this is probably in a similar vein to my System.MouseX and System.MouseY where it is sort of anti cross-platform (I am mostly doing this for my windows only apps 😛)

Garry

You've diagnosed it correctly. Objo paints an opaque surface across the entire window: the underlying Avalonia window and its content host both carry an opaque theme background, and everything you place on the window (Canvas included) renders on transparent layers above that. So when you apply an acrylic backdrop to the window handle with DWM, our own drawing paints straight over the top of it. There isn't a plugin answer here, I'm afraid. The plugin SDK deliberately doesn't expose native window handles or the Avalonia internals, so declare-based approaches end up fighting the runtime rather than working with it.

Your 884 link is a useful pointer in reverse, though. What happened there was that a Canvas clear operation briefly ran against the window's own framebuffer and erased the window pixels, making the window see-through by accident. We fixed that by confining clears to the Canvas drawing layer, but it does demonstrate that our rendering pipeline already produces per-pixel alpha. The raw capability is there. We just don't expose it deliberately.

So here's where I've landed. I'd be happy to support window opacity and per-pixel transparency for shaped windows. Both are natively supported on Windows and macOS, and on Linux they work wherever a compositor is running, which is every modern Linux desktop, so they'd be honest cross-platform Window features rather than a Windows hack. Controls would keep their own opaque backgrounds on top, which is the "window independent of its controls" effect you asked for. The acrylic/Mica part is the one thing I'd rule out: there is no cross-platform story for blur-behind materials at all (Avalonia offers them on Windows only, macOS's equivalent isn't exposed to us, and Linux has nothing standard), so a unified Window API would carry a property that only ever does something on one platform. If it's the frosted-blur look you're specifically after, I don't want to leave you waiting on that one.

I've logged this as a feature request here: https://feedback.objo.dev/feature/1712. No promises on timing, but this is exactly the sort of thing I want Objo to be able to do.

Syntec

Garry Thanks Garry, I really appreciate it, and totally understand the Acrylic/Mica not being up for consideration. I expected that because you are building Objo to be 100% cross-platform and not expose anything that isn't. I don't mind handling the Arcylic/Mica myself with a plugin I think I have this working already. I am basically grabbing the window handle once when it is activated then having DWM do blurbehind. I can't actually tell if it is doing the blur but the closest I got to punching through Objo was making the window 100% transparent... to mouse clicks lol, so I atleast know I am grabbing the window handle. I thought about rolling back to the version that had the 884 bug (regression?) in it, and grabbing its window handle with the plugin built in a newer objo app but it was late and I wasn't confident 884 wasn't just going to punch through the blurbehind as well.

Garry

Thanks Syntec, and I appreciate you understanding the cross-platform line.

Here's a thought for your DIY route, though. The piece you're actually missing isn't the window handle, it's our opaque window surface painting over your blur-behind. That's exactly what the feature request I logged covers: once per-pixel transparency ships, you'll be able to make the window background transparent while your controls stay opaque, and at that point the DWM backdrop you're applying yourself should finally show through. That's essentially how Avalonia does its own acrylic on Windows anyway: transparent client content over a DWM material. So I'd expect your existing plugin approach to start working then, no SDK changes needed. It stays your Windows-only adventure, but you'd be working with the platform instead of against it.

I'd steer you away from rolling back to the build with the 884 behaviour, though. That bug wasn't a controllable punch-through: the clear ran against the window's whole framebuffer and erased whatever had been drawn, other controls included (which is why it was fixed). You wouldn't get clean holes for your blur to shine through, and you'd be building on a build that's now a couple of months of fixes behind.

Syntec

Garry Hey Garry, Sorry if my post wasn't clear, I was only intending to roll back to test the other functionality of the plugin (grabbing the window handler and passing it to the windows declares to do the Acrylic behind the app (more specifically behind certain elements only), I was going to build a current objo app with the plugin but have it point to a specific titled window compiled from the old version, not actually abandoning the current and future updates to utilize one bug 😛

Garry

No need to apologise, that makes perfect sense now. Using the old build purely as a test target, a titled window your current plugin can find and poke at, is a sound way to isolate whether the handle grabbing and the DWM declares are doing anything at all. Wherever that build's surface got wiped you should see whatever material you have put behind it, so it's a clean pass or fail for that half of the stack. Just read it as a wiring test rather than a preview of the finished look, since the wipe lands wherever the clear happened to run.

One Windows detail worth knowing before you trust a null result: if your declares go through DwmEnableBlurBehindWindow, that function stopped actually blurring after Windows 7. It still returns success on Windows 10 and 11 but draws no blur, so a see-through window with no material behind it does not mean your handle work is wrong. The route that still produces acrylic on modern Windows is the undocumented SetWindowCompositionAttribute accent, ACCENT_ENABLE_ACRYLICBLURBEHIND, so if the rig shows see-through but no blur, swap the call before doubting the plumbing.

That API is also relevant to "behind certain elements only". It applies to the whole window and has no region parameter, so the only thing that decides where the acrylic shows is which parts of the window content are transparent. That is good news for your plan, because per-pixel transparency is the piece I logged in the feature request upthread (https://feedback.objo.dev/feature/1712). Once it ships you would make the surface transparent only behind the elements you want treated and keep the rest opaque, and your plugin supplies the material. On current builds the opaque surface is still the wall, but your test rig should prove everything else is ready and waiting.

Garry

This has been implemented for the next release