Window transparency (dev-doc)

[kekekeks]

Alpha-transparency and blur behind have various support across platforms, the support for those features can also be sometimes turned on and off during a singe user session due to various reasons.

So Avalonia should support different transparency requests from the application and apply the best matching mode supported by the current platform.

Transparency requests:

• DoNotCare - window has no preference regarding the transparency, Avalonia is free to choose mode as it sees fit
• WantsTransparency - window needs transparency
• RequiresTransparency - window really needs transparency, Avalonia should use APIs with poor performance like UpdateLayeredWindow with GPU->CPU->GPU transfer if necessary. Note, that some platforms will still not provide transparency support even if requested this way.

Blur-behind requests (only take effect if transparency is enabled):

• DoNotCare - window has no preference regarding the blurbehind, Avalonia is free to choose the mode as it sees fit
• WantsBlurBehind - window wants blur-behind on the window, Avalonia is free to fall back to transparency without blur behind
• WantsNoBlurBehind - some window areas want to be completely transparent. Avalonia is free to fall back to a mode with blur behind for performance or compatibility reasons.
• RequiresNoBlurBehind - some window areas has to be completely transparent, so blur behind must be disabled. If it's not possible to fulfill such request, transparency will not be enabled at all. Note that low-performance transparency still has to be enabled separately by RequiresTransparency request, so WantsTransparency+RequiresNoBlurBehind will result in no transparency rather than low performance transparency.

When application runs on a particular platform and the mode is chosen or changed later, Avalonia should set Transparency.CurrentMode attached property on the window to inform it that transparency/blurbehind are enabled. The property should hold a class like this:

class TransparencyMode
{
    public bool TransparencyEnabled {get;}
    public bool BlurBehindEnabled {get;}
}

X11

Transparency

Transparency works kinda out of the box when one uses ARGB visual. The problem is that the window manager should support compositing and not all of them do. Some window managers like KWin turn compositing off when they see a GPU-intensive application (usually full-screen games) running and keep it disabled even if user has alt-tabbed from said application.

Avalonia should detect if _NET_WM_CM_Sn selection is held by the window manager. n is the number of the screen. Since Avalonia only uses one screen, such number should be obtained from XDefaultScreen.

When window manager turns composition on or off or when window manager is replaced by another one, Avalonia should track _NET_WM_CM_Sn selection ownership by subscribing to XFixesSelectionNotify event via XFixesSelectSelectionInput function. See /usr/include/X11/extensions/Xfixes.h for more details.

Blur behind

Blur behind is currently supported by KDE and Deepin Linux via setting _KDE_NET_WM_BLUR_BEHIND_REGION and _NET_WM_DEEPIN_BLUR_REGION_ROUNDED properties.

Windows

Transparency can be enabled by:

• Using WS_EX_LAYERED style and UpdateLayeredWindow function. While compatible with almost all Windows versions this approach is extremely slow and doesn't support DirectX rendering to the window. GPU acceleration can still be used, but will require transferring pixel data from GPU to CPU memory.
• Using DwmExtendFrameIntoClientArea API and WS_EX_COMPOSITED. This approach is compatible with Windows Vista+, but stops working when DWM is disabled (e. g. by switching to classic theme on Windows 7, note that Windows 7 will be still be relevant at least till 2025). The problem is that it forces blurbehind. According to this thread it's possible to get completely transparent windows by setting WS_POPUP style. This approach needs further investigation.
• Using undocummented SetWindowCompositionAttribute function. Also seem to enforce blurbehind

OSX

It seems that setting opaque property to false on both NSWindow and NSView should enable transparency. Needs further investigation.

Blur-behind can be enabled via NSVisualEffectView.

[Splitwirez]

Not sure if this is still up for consideration, but just in case, I figure I may as well note a few things that were missed here regarding Microsoft Windows:

1. DwmEnableBlurBehindWindow ( https://docs.microsoft.com/en-us/windows/win32/api/dwmapi/nf-dwmapi-dwmenableblurbehindwindow ) exists. It is similar to DwmExtendFrameIntoClientArea, but rather than extending the native frame into the body/client area of the window, it simply blurs the specified area with no concern for the frame. Likely useful at least for Windows which lack system decorations, as using DwmExtendFrameIntoClientArea on such a window will actually restore the system drop shadow and system decorations...sort of.
2. SetWindowCompositionAttribute only exists as of Windows 8, and does not enforce blurbehind at all. It can be used to achieve several different behaviours. More specifically... 2a. On Windows 8.x, you can use it to produce a completely transparent Window, a completely opaque window, a window with a translucent but non-blurred theme-coloured background, and some other weird stuff I don't even understand, but blur is NOT one of the options it provides. 2b. On Windows 10, two different types of blurbehind were added, one with a fairly small blur radius, the other with a much stronger blur radius. If memory serves, the latter option takes the place of one of the options present in Windows 8.x, though I don't recall which. Also it should be noted that the stronger of the two blur options was added in a feature update, not in the initial release of Windows 10.
3. Any APIs which would produce blurbehind on Windows Vista and 7 will instead produce opaque theme-colour on Windows 8.1 and 10. 3a. If the user has that Aeroglass for Windows 8.1+ program ( http://glass8.eu/ ) installed and active on Windows 8 or 10, the Windows Vista/7 behaviour will apply instead in these cases.

[danwalmsley]

2b. On Windows 10, two different types of blurbehind were added, one with a fairly small blur radius, the other with a much stronger blur radius. If memory serves, the latter option takes the place of one of the options present in Windows 8.x, though I don't recall which. Also it should be noted that the stronger of the two blur options was added in a feature update, not in the initial release of Windows 10.

seems to be the ACCENT_ENABLE_ACRYLIC option... the performance is absolutely terrible and we probably wont be able to use it.

[yatli]

performance is absolutely terrible

Especially when you move/resize the window. The lag feels similar to resizing a vertical, blurbehind task bar. UWP windows don't exhibit this lag though.

[kekekeks]

the performance is absolutely terrible

I think it used to work faster but got broken in relatively recent windows builds (>1900)

[Splitwirez]

...it just hit me that I forgot to mention in my previous post here that SetWindowCompositionAttribute is also an undocumented Windows API, meaning it could potentially change, break, vanish, or whatever at any time.

Also...

performance is absolutely terrible

Especially when you move/resize the window. The lag feels similar to resizing a vertical, blurbehind task bar. UWP windows don't exhibit this lag though.

tbh I'm pretty sure it is what the Taskbar uses.

[sudongg]

In 2022, translucent windows are still unavailable under Windows 7, or are they not intended to be supported?

[maxkatz6]

Windows 7 is not a priority anymore for the core team. But we can review PRs from the community, if anybody wants to bring some missing features for the Win7.

[maxkatz6]

@kekekeks do we still need this issue open? Or should we leave it for future refactoring of API? In that case description probably should be updated with some new ideas.

[kekekeks]

My current idea is to make the application to specify an array of requested modes in order or preference and then use the first one that can be satisfied by the platform. That would be way more simple and less error-prone, IMO.