Microsoft-ui-xaml: Why must background acrylic be discontinued in WinUI 3? That will surely devastate and disappoint many, for obvious reasons

I believe it is just temporarily unsupported - whilst more of the code which handles Acrylic is removed from the OS and coded anew in the open source project.

Really? What about this then? https://twitter.com/WithinRafael/status/1230192945355096064

While I am not sure what document he is referring to in the screenshot, @ryandemopoulos said this:
https://twitter.com/WithinRafael/status/1230197954280951808?s=20

I believe the OS provides the backdrop which the Acrylic Brush uses as its underlying layer, which it then adds the noise, tint, and luminosity layers on top of. The In-App Acrylic is given it's underlying layer by the app renderer.

The HostBackdrop can't be done outside of the OS providing the layer - and so finding a new way to do that is the technical challenge being mentioned.

This will probably require some re-engineering of the OS, and so would also need to be backported to all the OS versions that WinUI 3 will support.

This may not actually happen, and instead the WinUI team may need to write some low level code, which can run in userspace, to replicate the same features.

I'm not sure how they could do it that second way, but I am certainly not a proper programmer, nor do I know the Windows source code :) Only that it probably requires UXTheme access, which is a protected OS component.

I certainly hope we get it for WinUI 3.1 onwards - because to lose that visual material would be devastating to Fluent design, and it seems like Windows 10X has found a way to do it / or the applications are calling into the Windows.Xaml namespace, which apparently wont be possible from WinUI 3.x apps made by others.

If I recall correctly WPF apps can have transparent backdrop. Since the actual calculation of an AcrylicBrush is already (partially) contained in WinUI 2, the main problem is probably "only" supporting this transparent backdrop. But since WPF apps are able to do it, there should already exist some kind of interface for that.

How this will be implemented however with WinUI 3 is nothing I can comment on, so take my comment with a grain of salt.

If I recall correctly WPF apps can have transparent backdrop. Since the actual calculation of an AcrylicBrush is already (partially) contained in WinUI 2, the main problem is probably "only" supporting this transparent backdrop. But since WPF apps are able to do it, there should already exist some kind of interface for that.

How this will be implemented however with WinUI 3 is nothing I can comment on, so take my comment with a grain of salt.

If the Composition layer could be given the screen "framebuffer" minus the app window itself, then sure a new Acrylic Brush could be implemented. WPF runs with a more permissive system by default, and so I suspect it is the UWP side of the equation, which will have the hardest time.

WinUI Desktop may have some work-arounds which could allow it.

Again, let's hope it is not too far behind WinUI 3.0

As far as I remember WPF transparent windows also aren't native, they are hacked around UpdateLayeredWindow, not using direct rendering but transferring a snapshot image through a GDI surface for every single rendered frame. It will probably cause lots of technical problems for WinUI when you try to mix this hack with the composition API and animations.

Also it is using plain alpha rendering, I think for the acrylic effect you need some kind of blurring, which needs to read out background surface pixels for mixing them.

I don't think there is any facility to hand out intermediate compositions of the screen either, so before WinUI can do anything here the OS needs to provide entirely new infrastructure.

In my opinion, WinUI shouldn't be released until it's right. Something like Acrylic Brush is vital on creating consistency.

I agree with this.

@Austin-Lamb for FYI

If it can't be done correctly, make a faux version of it that emulates it until it is done correctly, and then when it is updated it will still show.

That would be much better than not having it at all.

If it can't be done correctly, make a faux version of it that emulates it until it is done correctly, and then when it is updated it will still show.

That would be much better than not having it at all.

I have suggested this in the past by taking the Desktop Wallpaper/Colour and using that as a base layer. I thought it would be good as a fallback for Tablet Mode, Mobile, and for low powered devices.

Inactive Acrylic effect (CreateHostBackDropBrush) - alternative options/fallback

Example

_Current Acrylic_

_Faux Alternative Acrylic_

Would be great to get some clarity on this. It's one of the key visual elements that make Fluent apps recognizable (and visually very pleasant to look at :)). Additionally, it's one of the most common visual effects in Windows with default controls supporting it out of the box.

This feature should be in 3.0, or at least 3.1!

@niels9001 The team has said HostBackdrop acrylic won't be in WinUI 3.0 because of technical challenges arising by lifting the WinUI components out of the OS stack. They also said they want to get this working in the future. I don't think they can currently give any new update on this.

In the meantime, I would suggest to get the upvotes on this issue (or a new issue meant for tracking) started so that by the time WinUI 3.0 is out, the team can see this is a highly requested feature from the community, making it more probable that support will be added sooner rather than later post WinUI 3.0 release.

A faux one like @mdtauk posted should be used in the interim should be used then.

I agree.

If it can't be done correctly, make a faux version of it that emulates it until it is done correctly, and then when it is updated it will still show.
That would be much better than not having it at all.

I have suggested this in the past by taking the Desktop Wallpaper/Colour and using that as a base layer. I thought it would be good as a fallback for Tablet Mode, Mobile, and for low powered devices.

Inactive Acrylic effect (CreateHostBackDropBrush) - alternative options/fallback

Example

_Current Acrylic_

_Faux Alternative Acrylic_

This looks great - except it appears to be missing the noise layer - correct me if I'm wrong.

This looks great - except it appears to be missing the noise layer - correct me if I'm wrong.

Its there, here is the image zoomed 800%

Thanks for raising this issue @carmellolb. I think you speak for a lot of folks--including people on the WinUI team itself--by expressing that Background Acrylic is a loved feature and a very important piece of the Fluent story.

@mdtauk and @weltkante both did a great job describing the high level technical details about why this is really hard to do after we decouple from the OS. As I wrote in the #winui channel of the UWP Community Discord server, my hope is that we can get this addressed asap after WinUI 3.0; I don't know the post-3.0 timeframe because we have more dev engineering to do to settle on how to address it. But it's a top ask and the community has been very clear that they care about this a whole lot. I also like the suggestion of us exploring some kind of "faux effect" in the interim; perhaps after //build we can start having deeper discussions on that idea.

@shaheedmalik, I sympathize with your sentiment of not wanting to ship until things are ‘right’; I often feel this way myself and it’s always a balancing act. We’ve been working with a lot of customers over the last few months, and one thing I’m often reminded of is that WinUI 3.0 will provide a viable path forward for a wide swath of UWP and Win32 apps, and there are many who will be able to use it without relying on the specific effect that background acrylic achieves. I don’t want to delay unlocking the huge range of features that 3.0 will bring for these customers, so that’s why I continue to push for shipping 3.0 this year and then look to solve the biggest missing pieces (like BG acrylic) as soon as we feasibly can afterward. I hope that makes sense.

@ryandemopoulos If the AcrylicBrush Xaml element can be present, even if it only returns some kind of faux brush fill initially. Those on 10X, Xbox and Tablet mode devices will look almost identical as there are no overlapping windows. It is only on Windows 10 devices where the effect will be obviously fake - but if it is only for a 3.0 or 3.1 launch frame, before it is fixed - then at least it wont break code, and will still give the right feel.

If this can be achieved for 3.0 - then that is great. It will be less jarring than a solid colour fallback. Also it will allow for the affect to not be disabled on low power devices, or in Tablet mode as currently happens, which is a step up IMO.

@shaheedmalik, I sympathize with your sentiment of not wanting to ship until things are ‘right’; I often feel this way myself and it’s always a balancing act. We’ve been working with a lot of customers over the last few months, and one thing I’m often reminded of is that WinUI 3.0 will provide a viable path forward for a wide swath of UWP and Win32 apps, and there are many who will be able to use it without relying on the specific effect that background acrylic achieves. I don’t want to delay unlocking the huge range of features that 3.0 will bring for these customers, so that’s why I continue to push for shipping 3.0 this year and then look to solve the biggest missing pieces (like BG acrylic) as soon as we feasibly can afterward. I hope that makes sense.

Then a faux version of the effect needs to be made in the mean time until the correct effect is worked out. The incremental changes of Fluent Design in the past led to the current inconsistency problem that Windows 10 is currently experiencing. If the whole point of WinUI 3 is to fix it, then creating a problem such as this defeating the whole purpose of consistency. Apps with acrylic and without is one of the biggest inconsistencies in Fluent Design.

@shaheedmalik, I sympathize with your sentiment of not wanting to ship until things are ‘right’; I often feel this way myself and it’s always a balancing act. We’ve been working with a lot of customers over the last few months, and one thing I’m often reminded of is that WinUI 3.0 will provide a viable path forward for a wide swath of UWP and Win32 apps, and there are many who will be able to use it without relying on the specific effect that background acrylic achieves. I don’t want to delay unlocking the huge range of features that 3.0 will bring for these customers, so that’s why I continue to push for shipping 3.0 this year and then look to solve the biggest missing pieces (like BG acrylic) as soon as we feasibly can afterward. I hope that makes sense.

Then a faux version of the effect needs to be made in the mean time until the correct effect is worked out. The incremental changes of Fluent Design in the past led to the current inconsistency problem that Windows 10 is currently experiencing. If the whole point of WinUI 3 is to fix it, then creating a problem such as this defeating the whole purpose of consistency. Apps with acrylic and without is one of the biggest inconsistencies in Fluent Design.

I completely agree. I don’t think WinUI 3 should be released until something is worked out.

I actually prefer @mdtauk's static fallback over real transparency. Background acryllic is just distracting when dragging windows, especially with a dark wallpaper and light theme, and led me to disabling transparency completely.

Maybe we should reinterpret coloured backgrounds for non-transient elements (sidebars, title bars, shell etc.) as pure decorations, not as semi-transparency to symbolise a short interruption. This would be more like the titlebar themes for MS Office or Firefox (or IIRC the Vista control center's sidebar). When seen this way, it makes more sense to just use the wallpaper.

It might even be better-looking (and improve performance further?) to make the acryllic backgroud independent of the window position: The wallpaper could either be stretched over the window area or cropped to the top-left corner (or whichever corner makes most sense for the app's resizing behaviour).

I actually prefer @mdtauk's static fallback over real transparency. Background acryllic is just distracting when dragging windows, especially with a dark wallpaper and light theme, and led me to disabling transparency completely.

Maybe we should reinterpret coloured backgrounds for non-transient elements (sidebars, title bars, shell etc.) as pure decorations, not as semi-transparency to symbolise a short interruption. This would be more like the titlebar themes for MS Office or Firefox (or IIRC the Vista control center's sidebar). When seen this way, it makes more sense to just use the wallpaper.

It might even be better-looking (and improve performance further?) to make the acryllic backgroud independent of the window position: The wallpaper could either be stretched over the window area or cropped to the top-left corner (or whichever corner makes most sense for the app's resizing behaviour).

I would still use the brush surface as a mask so the background stays aligned to the desktop, and remains in place as the window is moved around and resized. It would just not include any of the windows being visible, just the wallpaper.

This would also have to work with Slideshow backgrounds, as the wallpaper changes, so would the Faux Acrylic.

I think it would be a bit strange to see the desktop wallpaper behind a window when the other windows are behind the window. It would defeat the purpose of depth - and showing layers, which was one of the main purposes of acrylic. It should be identical in appearance to real acrylic.

I think it would look unprofessional, and a bit messed up if it were to not show what's directly behind it like it does currently, because the material aspect of Fluent Design is meant to bring aspects of real life, and in real life, something transparent DOES shine to what's right behind it.

I think if this becomes a thing, it should appear visually identical to normal acrylic.

Something like described before, a faux acrylic but that shines to windows behind and behaves and appears visually identical?

Is that not possible?

Why not use semi-transparency like currently?

How is it distracting? I find it to be the opposite - depth-creating, which Microsoft also said it is when they announced it.

Changing it to simply a decoration like this would be a step backwards.

We need acrylic.

I think it would be a bit strange to see the desktop wallpaper behind a window when the other windows are behind the window. It would defeat the purpose of depth - and showing layers, which was one of the main purposes of acrylic. It should be identical in appearance to real acrylic.

I think it would look unprofessional, and a bit messed up if it were to not show what's directly behind it like it does currently, because the material aspect of Fluent Design is meant to bring aspects of real life, and in real life, something transparent DOES shine to what's right behind it.

I think if faux acrylic becomes a thing, it should appear visually identical to normal acrylic.

Is there no way to show windows behind?

Why not use semi-transparency like currently?

How is it distracting? I find it to be the opposite - depth-creating, which Microsoft also said it is when they announced it.

Changing it to simply a decoration like this would be a step backwards.

At the moment, there are technical hurdles to getting the HostBackdrop AcrylicBrush working in WinUI 3.0

The hope is that those hurdles will be overcome in the future, but not initially for the WinUI 3.0 launch.

What we are discussing is if it is possible to have something other than the standard fallback grey colours until they can get it working.

I think if this becomes a thing, it should appear visually identical to normal acrylic.

Something like described before, a faux acrylic but that shines to windows behind and behaves and appears visually identical?

Is that not possible?

Why not use semi-transparency like currently?

How is it distracting? I find it to be the opposite - depth-creating, which Microsoft also said it is when they announced it.

Changing it to simply a decoration like this would be a step backwards.

We need acrylic.

Current acrylic isn't possible due to the a technical limitation. We are suggesting a faux acrylic for consistency purposes.
The point is to have something temporary that will not the break the current apps and future apps use of Acrylic until the technical limitation is fixed.

Something is better than nothing.

I think if this becomes a thing, it should appear visually identical to normal acrylic.
Something like described before, a faux acrylic but that shines to windows behind and behaves and appears visually identical?
Is that not possible?
Why not use semi-transparency like currently?
How is it distracting? I find it to be the opposite - depth-creating, which Microsoft also said it is when they announced it.
Changing it to simply a decoration like this would be a step backwards.
We need acrylic.

Current acrylic isn't possible due to the a technical limitation. We are suggesting a faux acrylic for consistency purposes.
The point is to have something temporary that will not the break the current apps and future apps use of Acrylic until the technical limitation is fixed.

Something is better than nothing.

I agree - I just think it would be a bit odd if windows not showing through. I guess this would be the best approach if nothing else is possible though.

I don't believe this should be used after a solution to the problem is found though, because I'm not sure it would be good for consistency or even just visuals in general long term. I think it would be best just until acrylic can function normally after WinUI 3. @mdro

I don't believe this should be used after a solution to the problem is found though, because I'm not sure it would be good for consistency or even just visuals in general long term. I think it would be best just until acrylic can function normally after WinUI 3. @mdro

When they fix it in 3.1, the developers of the apps won't have to do anything and the app will just update uniformally.

I don't believe this should be used after a solution to the problem is found though, because I'm not sure it would be good for consistency or even just visuals in general long term. I think it would be best just until acrylic can function normally after WinUI 3. @mdro

At the moment Apps running in Tablet Mode fall back and lose their Acrylic. Low powered devices and VMs also fallback to a solid colour. If this Faux Acrylic is implemented, it could be used in those scenarios as a performance fallback.

I don't believe this should be used after a solution to the problem is found though, because I'm not sure it would be good for consistency or even just visuals in general long term. I think it would be best just until acrylic can function normally after WinUI 3. @mdro

At the moment Apps running in Tablet Mode fall back and lose their Acrylic. Low powered devices and VMs also fallback to a solid colour. If this Faux Acrylic is implemented, it could be used in those scenarios as a performance fallback.

Yes, I agree with this. I was referring to that it shouldn't replace normal acrylic once it is fixed.

How is it distracting?

I don't know exactly. I guess the blending of two layers moving relative to each other means that it registers in my brain as changing rather than just moving, which makes it a reason to focus my eyes there.

Anyway, this isn't a huge issue for me, I don't mind the "no transparency" style.
But if you add the fallback anyway, it would be nice if you would take a small bit of extra time and split the transparency effects setting:

1. Interaction effects (reveal etc.) - on/off
2. Transparency (acrylic) - full/reduced (the fallback discussed here and intra-app)/off

(I'd use Interaction on + transparency reduced.)

BTW I noticed a few oddities while playing around with the settings a bit more:

• Acrylic on the sidebar of Settings is only active as long as the window has focus. When it looses focus, it instantly switches to the non-transparent gray. So when I have Settings maximized and interact with the tray or notifications, in the corner of my eye I see a large area on the other side of the screen blink to another color. Maybe it should just keep its current acrylic texture when updating the acrylic is suspended due to performance?
• Turning on transparency effects while in powersave mode makes the taskbar background disappear (icons and hover highlights appear on the pure, non-darkened, non-blurred wallpaper).
  
  (seen on Surface Pro 6, Update 1909)
• On the same Surface I temporarily saw a dark gray sidebar in Settings as long as transparency was enabled; maybe the background texture didn't get filled and stayed black? The issue disappeared while I played around further .

I've just discovered this issue while testing WinUI3.

For me, the main reason why I've been looking at WinUI3 is precisely to have an easy access to the backdrop brush and to the acrylic brush (which every customer expect) based on it, outside of UWP with a plain unpackaged C# app.

This is something that's today technically impossible to have w/o using Dcomp (and it's intimacy with DWM, and that's probably the reason why it's difficult to keep in WinUI3 if WinUI3 wants to be independent from Windows). Today, this is accessible using public WinRT API (C#, etc.) though the methods Windows.UI.Composition.Compositor.CreateBackdropBrush / CreateHostBackdropBrush.

If it's not in WinUI, I can (must) continue to use and build a custom acrylic+backdrop brush manually (in fact, reusing WinUI 2 recipes since they're open source). But since Dcomp is so low level technically, everything is based on it, or not at all. So I can't use WinUI3 at all. Kinda chicken and egg thing.

@mdtauk and @weltkante both did a great job describing the high level technical details about why this is really hard to do after we decouple from the OS. As I wrote in the #winui channel of the UWP Community Discord server, my hope is that we can get this addressed asap after WinUI 3.0; I don't know the post-3.0 timeframe because we have more dev engineering to do to settle on how to address it. But it's a top ask and the community has been very clear that they care about this a whole lot. I also like the suggestion of us exploring some kind of "faux effect" in the interim; perhaps after //build we can start having deeper discussions on that idea.

Build has come and gone. I'm not sure if this was addressed at Build or the Community call right afterwards, but this needs to be done before WinUI3 releases on a at least faux level for at least consistency purposes.

If not, there will be a whole bunch of apps that are inconsistent which will deem WinUI3 a giant waste of time.

lol so the one think that makes this framework not useless is being pushed up. Windows sure as fuck don't know how to prioratise stuf ( unless this version allows me to toggle title-bars universally because then all is forgiven. and they made the correct thing the nr 1 priority.)

I'm not really experienced with the internals of Windows UI, but maybe instead of completely omitting background acrylic for the original release, why not make it internally reuse the old acrylic on Windows 10, and fall back to a solid colour on older Windows versions? I think that would be a better compromise until it can be implemented properly.

Since Background Acrylic will not make 3.0, can we have a faux Acrylic in 3.0 in the meantime?

I'm not really experienced with the internals of Windows UI, but maybe instead of completely omitting background acrylic for the original release, why not make it internally reuse the old acrylic on Windows 10, and fall back to a solid colour on older Windows versions? I think that would be a better compromise until it can be implemented properly.

A placeholder background acrylic brush which just renders the fallback colour would also be acceptable in my mind - that way, the brush can start being used in interfaces right away. Later when the background acrylic brush is properly implemented with proper translucency effects, it would then retroactively apply to those interfaces which used the placeholder, without requiring any code changes.

Something else that contributes (or so far as I can tell) to this is #1247

Also related: #761

@mdro

it would be nice if you would take a small bit of extra time and split the transparency effects setting:

• Interaction effects (reveal etc.) - on/off
• Transparency (acrylic) - full/reduced (the fallback discussed here and intra-app)/off

I pointed out something similar in #816 but they said that it's not their problem. Welcome to the Microsoft world. The most I've seen Microsoft do for itself recently is adding APIs to Windows for Edge (Chromium) and improving WinUI for PowerToys and Terminal. They refuse to update the styles of their other UIs which they obviously still use in Windows. lol

Is Microsoft seriously going to launch WinUI 3.0 without a faux acrylic to cover background acrylic for consistency purposes?

If they want it to be independant they just need to do what linux does and have a compositor that always works and runs that handles acrylic ? Blurring.

If they want it to be independant they just need to do what linux does and have a compositor that always works and runs that handles acrylic ? Blurring.

Apple seems to be able to handle it's translucency without any significant performance hit - I know Windows is an older code base in many ways - but there is already a Composition Visual Layer, WinUI just needs to be able to call on it and for it to be as performant as can be.

If they want it to be independant they just need to do what linux does and have a compositor that always works and runs that handles acrylic ? Blurring.

Apple seems to be able to handle it's translucency without any significant performance hit - I know Windows is an older code base in many ways - but there is already a Composition Visual Layer, WinUI just needs to be able to call on it and for it to be as performant as can be.

Here`s to hoping upstream wil not point fingers to other people asking them to fix it in a shitty way because they can make a shitty workaround.

I wonder if going back to Windows 7 - WinUI/Reunion could provide a driver, which provides the Rendered layer needed to handle Acrylic. WinUI apps on deployment and new OS versions could include the driver which provides the base layer render visual, via the Store.

Windows 7 and Vista before it must have had the capability for the Aero Glass rendering. Windows 8/8.1 had the Visual Composition Layer. So perhaps this is more of a Reunion ask, but if the driver handled the OS dependent stuff, the rest could all remain User level right?

Yea so I found this concept of fluent ui on Reddit and thought looked clean and "fluent".

Fluent was originally created due to the lack of transparency complains from users. But now you are removing it entirely.

Fluent was originally created due to the lack of transparency complains from users. But now you are removing it entirely.

Microsoft has said they need more time to make Acrylic work, when WinUI is no longer part of the OS, but running separately

I don't care about acrylic anyway, however, hope they will not remove it completely.

I don't understand why WinUI 3 can't support Acrylic. WinUI 3 doesn't need to do the work, let it handle it the compositor on the supported platform and no need to make it open source.