Microsoft-ui-xaml: Proposal:Background acrylic should still be rendered if the program is in the foreground.

[mike0891]

Proposal: Background acrylic should still be rendered if the program is in the foreground.

Summary

As proposed here: https://github.com/Microsoft/calculator/issues/397
A application that is on a second monitor should not lose background acrylic when it is still the main visible application on that screen but does not have focus.

Rationale

A application that is visible and being looked at is a distraction if transparency is turned on and off as it is being used.

A alternative solution that might help, is to keep a frosted pane look with 0% transparency. Going straight to a solid colour from the frosted glass look is both distracting and look unpolished.

[jevansaks]

Unfortunately this behavior is a performance-based limitation. The shell imposes a policy that acrylic for inactive windows will be forced to be opaque, so there's not much we can do here.

The suggestion to try to choose a better opaque color is interesting, that certainly could be something that we can improve if we can figure out what the predominant color is. Or maybe we can freeze acrylic for background apps instead of forcing it to opaque.

[be5invis]

How slow could it be? Are there any measurements?

[mdtauk]

Has the idea of _Always_ Acrylic been profiled on a Desktop PC, rather than a Laptop? Also in Tablet Mode Acrylic is just turned off, which is unfortunate.

Rather than be a live rendered Acrylic, could there be a pre-rendered version, just taking the Background colour - which Tablet Mode could use, as well as inactive windows?

[landonth]

Echoing the ideas of @jevansaks and @mdtauk to cache the last active buffer for acrylic on inactive windows, one could take inactive acrylic a step further into the middle ground by setting a low quality acrylic profile with reduced resolution / lower blur quality and maybe even reduce the rate of the shader / effect execution to once every n frames. Perhaps with frame interpolation up to the current refresh rate to make any background motion appear smooth, the lower update rate and slight increase in latency perceptually invisible for a blurred out background element.

And of course set a hard cap on the maximum number of layers of real-time acrylic, just one is probably fine.

This would cover the case of some video or animation being behind the inactive acrylic with a small, calculated impact on performance for desktops and mid to high end portable devices, before being forced to resort to a completely static cached acrylic for inactive windows (or none at all, as it is currently.)

A lot of possibilities for further optimization as well, like spreading the GPU work over multiple frames, utilizing async compute / multi-engine sync with DirectX. And block / region schemes, similar to video compression schemes, to coarsely check if the background content is currently static or animated before executing the blur shader kernel and writing new results to the buffer.

[dragonwolf83]

Use the Power Preferences and Battery mode to dynamically configure how transparency and background affects work. You see this today with the Desktop Slideshow paused on battery and enabled when plugged in.

Battery Mode and Maximum Battery Life settings could freeze the transparency or change latency to values best suited for that mode. Possibly kick it back in if the window is moved around if it can be done smoothly.

Medium/Mixed/Better Performance modes wouldn't need to be frozen, the latency could hit a better suite spot to still favor battery life but give it a smoother feeling if there is activity.

Best Performance, regardless of battery mode let it run as normal.

Battery Saving mode regardless of setting on battery freezes it. It also makes sense to include Focus Assist options for Game Mode / Fullscreen on this for better performance in those conditions.

There is likely already known configurations from existing work to optimize battery life with animations and video. They can serve as a baseline to fine the right settings for this.

[yaichenbaum]

@Sergio0694 has added a brush to the Windows Community Toolkit https://github.com/windows-toolkit/WindowsCommunityToolkit/pull/3112 that doesn't have the same limitation with acrylic being disabled when the app loses the focus.
The limitation isn't so much a limitation but rather a policy in Windows that only the focused app should have acrylic, however as mentioned in the issue description there are cases where you might still want the app to have acrylic even if it isn't focused.

[jt-github]

Considering the average performance of hardware now is far beyond what it was only a few years ago, I have to imagine that multiple layers of acrylic would not be that intensive. It would not be difficult for the OS to determine how much negative impact layers have and automatically set a maximum count of stacked acrylic layers (keeping the most recently used apps acrylic).

Frankly, I would love to be able to automatically make the _inactive_ apps _acrylic_ and the active one opaque. For example, the great new Windows Terminal application can activate acrylic (only on the terminal area; the title bar stays opaque, which I think looks best) but only when it's the active window. When it's inactive, it goes opaque. This is the opposite of what most users want. See https://github.com/microsoft/terminal/issues/593 (it's closed, but only because it's a system limitation).