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

[carmellolb]

Background acrylic is a key feature of Fluent Design, and without it, it will never be the same.

I feel there must be a deeper reason than performance alone, because there must be a way to improve performance, it seems so unlike the WinUI team to simply give up on something so huge like this.

Simply go around to people (family, friends, coworkers, etc) that use Windows 10, and ask them this question: "Do you know the acrylic (blur like) texture on the sidebars and different other areas of apps on your computer?"
I'll guarantee you that they will respond with something along the lines of "yes, I do. It came around a while ago and it is so nice and is a great addition!" In fact, someone I know who doesn't even know much about technology at all commented "Yeah, I do. It kind of has become part of the whole brand of the system, it wouldn't be the same without it." This person doesn't even know much about it, she just likes it. This along with many other incidents are a clear example of the impact it has on users.

Also, it can have an impact on users without them even realizing it's there, but using the software. When you then remove it, they will feel like something is missing, because it provides depth and hierarchy and without that, they will be confused.

It has BECOME part of the brand of Fluent Design. You can't just remove it, it would be like removing all of the red from YT, or removing the blue from FB. It's not a color, it's a texture, but it has a similar impact.

Also, software that previously was stunning and gorgeous and showed aesthetic will now be a plain, bland, grey surface with no texture at all. And wasn't one of the components of Fluent "Material"? Plain grey is not "material". There is no texture at all.

BG Acrylic was brilliant, because it provided depth and was also gorgeous. Everyone I know loves it. There is a similar thing on macOS and iOS, without many components though, simply just the blur. Acrylic is so much nicer. but don't you think that if there is something like it on those systems and it works just fine and has for years, that it must be possible on Windows as well?

What is really going on here? Why is it being discontinued? Do you realize the impact that this change will have on thousands, maybe even millions of users?

In my opinion, this is a TERRIBLE thing to do. First, you removed it from NavigationView. It's still not on TabView. And now you plan to simply remove it altogether, rendering it impossible for people to even have this key feature placed anywhere? Why? Just why?

I surely hope that a way to improve it and not cancel it will be devised before WinUI 3, or at least in time for a release shortly after. Because I don't think removing it is the right choice. In fact I think it's the worst thing that could be done.

P.S. - I use apps with background acrylic on a daily basis and not a single one of them as any performance issues.

[mdtauk]

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.

[carmellolb]

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

[marcelwgn]

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

[mdtauk]

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.

[marcelwgn]

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.

[mdtauk]

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

[weltkante]

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.

[shaheedmalik]

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

[carmellolb]

I agree with this.

[StephenLPeters]

@Austin-Lamb for FYI

[shaheedmalik]

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.

[mdtauk]

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

[niels9001]

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!

[Felix-Dev]

@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.

[shaheedmalik]

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

[carmellolb]

I agree.

[carmellolb]

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.

[mdtauk]

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%

[ryandemopoulos]

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.

[mdtauk]

@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]

@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.

[carmellolb]

@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.

[mdro]

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).

[marcelwgn]

Also it's been said, including here, that Win UI 3 is somehow de-coupled from the OS, but I've been looking at the source code in this repo and I don't see how that is the case at all. The C++ code is still extensively relying on the underlying WinRT APIs which only ship with Windows. In fact it looks like mostly wrappers for WinRT classes that allow the latter to be used in Win32 apps.

Therefore I don't understand when people refer to re-implementing something like the AcryllicBrush for Win UI 3; it's not like they're re-implementing Button or Grid or anything else low level.

Am I missing something here?

This is because the source code of this project is WinUI 2.x as of right now, not WinUI 3. Once WinUI 3 goes open source, it's source code will be merged into this repository, until then, all you can see is the WinUI 2.x source code which still relies on UWP XAML Controls and WinRT APIs.

[marcelwgn]

Sorry for asking a dumb question here, but I am just starting to experiment with the newest WinUI 3 preview and I tried the AcrylicBrush. It is always just going straight to the fallback color and never giving me an effect. This is expected behavior at this point correct? And it sounds like that's not going to change before release?

Yes this is more or less expected and will be fixed with a WinUI 3.x release according to the roadmap.

[legistek]

This is because the source code of this project is WinUI 2.x as of right now, not WinUI 3. Once WinUI 3 goes open source, it's source code will be merged into this repository, until then, all you can see is the WinUI 2.x source code which still relies on UWP XAML Controls and WinRT APIs.

Ohhh, ok that explains a lot, thanks! I got thrown off by the fact that the repo has so many recent commits but I guess they're still actively maintaining 2.x too.

Well that's exciting. I wonder if it'll be feasible to (unofficially) port to other platforms like web and mobile then.

[marcelwgn]

Ohhh, ok that explains a lot, thanks! I got thrown off by the fact that the repo has so many recent commits but I guess they're still actively maintaining 2.x too.

Yes WinUI 2.x is being actively developed with new features and style updates being added. This will also be the case for multiple months even while WinUI 3 has been released.

Well that's exciting. I wonder if it'll be feasible to (unofficially) port to other platforms like web and mobile then.

I have excellent news for you! This is exactly what the Uno Platform team is doing! You can check their website out https://platform.uno/ or view their source code here: https://github.com/unoplatform/uno

[legistek]

I have excellent news for you! This is exactly what the Uno Platform team is doing! You can check their website out https://platform.uno/ or view their source code here: https://github.com/unoplatform/uno

Oh yes I've had 3 eyes on Uno for awhile now. :) They're recreating the XAML syntax though, and not necessarily actually porting Microsoft's actual open source code right?

[marcelwgn]

Oh yes I've had 3 eyes on Uno for awhile now. :) They're recreating the XAML syntax though, and not necessarily actually porting Microsoft's actual open source code right?

It's more or less a recreation and no port, yes. Though for WinUI 2 controls iirc, they closely use look at the WinUI 2 code base and copy the existing code instead of reinventing the wheel. Maybe @MartinZikmund can weigh in on this as he is a very active contributor to the Uno platform and helped porting WinUI 2 controls to Uno!

[MartinZikmund]

Hey, yes, that is true 🙂 . While the majority of the codebase is a custom implementation, we are trying to port the open-source parts of WinUI line-by-line (by translating to C#), to achieve exact functional parity. When the rest of WinUI gets open-source, we will definitely revisit the base controls as well 👍 . The ultimate goal is for you to not have to care about the platform-specifics and just write your Windows app to have it run everywhere. There is still a lot of work to do, but we are not planning to slow down 🚀

[legistek]

Hey, yes, that is true 🙂 . While the majority of the codebase is a custom implementation, we are trying to port the open-source parts of WinUI line-by-line (by translating to C#), to achieve exact functional parity. When the rest of WinUI gets open-source, we will definitely revisit the base controls as well 👍 . The ultimate goal is for you to not have to care about the platform-specifics and just write your Windows app to have it run everywhere. There is still a lot of work to do, but we are not planning to slow down 🚀

I think the work you guys are doing is extremely impressive, don't get me wrong. You're doing what Microsoft really should have been doing on their own for 10 years now. I think it's a great idea to port as much FOSS code from Microsoft as you can. No hard feelings against them for not doing it, it's their prerogative how they spend their resources, but if they don't someone should!

[AnderssonPeter]

I was soo hyped when winui3 0.5 launched, but then saw that background acrylic was planned as post 0.8.
How sad now I'm not hyped at all any more, I hope they manage to get it working for 0.8.

[ryandemopoulos]

Hello @AnderssonPeter, background acrylic has been planned as a post 0.8 thing for quite a while, but perhaps you haven't followed (or weren't aware) of our public roadmap which is here: https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

We added in-app acrylic for 0.5 -- that should be working -- and we're still sorting out the timeframe & technical solution for background acrylic post-0.8. It's being evaluated alongside a lot of other vital work that needs to be done, including unpackaged deployment support, XAML Islands, multi-window support (using separate threads), and more. Once we have the plan nailed down we'll update the public roadmap.

[mgoyalitm]

What about using IHostbackdropProvider interface in dotnet 5 and use dll import somehow and wire it up for windows at least, probably a nuget package WinUI.Lasthope.Windows?

Or Just do it in your own way.

[johngagefaulkner]

Hello @AnderssonPeter, background acrylic has been planned as a post 0.8 thing for quite a while, but perhaps you haven't followed (or weren't aware) of our public roadmap which is here: https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

We added in-app acrylic for 0.5 -- that should be working -- and we're still sorting out the timeframe & technical solution for background acrylic post-0.8. It's being evaluated alongside a lot of other vital work that needs to be done, including unpackaged deployment support, XAML Islands, multi-window support (using separate threads), and more. Once we have the plan nailed down we'll update the public roadmap.

Slightly off-topic here, but, I'm having a hard time finding any mention of XAML Designer support on any roadmap. It's definitely listed under "Known Issues" with the patch notes of each release but I'm curious if you can speak to its priority amongst the myriad of other tasks being worked on? Thanks in advance!

[chrisgull]

Still no AcrylicBrush. This is sorely needed for us who use transparency extensively in our UI.
I'm just now porting my Xamarin apps (which have acrylic or similar working on UWP/iOS/Android) to MAUI, and the lack of support for AcrylicBrush in WinUI 3 will affect my user experience in a negative way.
Please get this done soon.

[sharpninja]

It seems to me that the OS code that does Acrylics could be exposed as an API which would return a primitive that would be applied to a FrameworkElement as the BackgroundBrush. If the primitive moves, the OS would be notified so it can rerender without any extra work by the App. The API could be public or cryptographically tied to the public thumbprint of a Store app.

[Foxlider]

I've been searching everywhere for Acrylic support for Windows10 on WinUI3 but still no luck sadly...

[dajbych]

According to Windows App SDK roadmap Mica & Background Acrylic should be already available since the first half of 2022. Planned features on the product dashboard includes it in the version 1.1 in Q2 2022. Microsoft documentation is mentioning that the current version is 1.1.3. I'm confused. Upgrading from UWP to the Windows App SDK is difficult to plan.

[KaibaiToday]

I agree. Why did acrylics brush discontinue the "BackgroundSource" property?

[lyahdav]

Per https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#winui-3 in WinAppSDK 1.1:

Mica and Background Acrylic are now available for WinUI 3 applications

If someone can verify this works, can we close this issue?

[dajbych]

It does not work (at least on Windows 10). AcrylicBackgroundFillColorDefaultBrush does not make transparent window. When I tried it by code, the AcrylicBrush's property BackgroundSource is not defined. The HostBackdrop class cannod be found in WinAppSDK 1.1 documentation. Apply Mica or Acrylic documentation is mentioning Windows 11 only. Transparent windows are supported since Windows Vista. And I want just upgrade my Windows 10 compatible UWP app to Windows App SDK (and keep Windows 10 compatibility).

[lyahdav]

Someone might want to investigate getting the HWND for the WinUI 3 window and using win32 APIs to make it transparent.

[codendone]

Window transparency is not currently supported in WinAppSDK. Adjusting HWND properties will not be able to enable transparency.

Background Acrylic is supported now in WinAppSDK 1.1, as @lyahdav linked to above. However, it works differently in WinAppSDK than it does in WinUI 2 (docs and sample code), and it is only supported on Windows 11 in WinAppSDK 1.1. The upcoming WinAppSDK 1.2 release adds support for Background Acrylic (via DesktopAcrylicController) on Windows 10; this is available for testing in 1.2-preview2 (see #7112).

[lyahdav]

@codendone I was able to get window transparency working in WinAppSDK, at least for our needs. We need the window to not be rectangular and have parts of it transparent. I was able to get this working with the code below. This was on
WinAppSDK 1.0.4. Are you saying that this functionality breaks in newer versions of WinAppSDK?

Similarly I was able to get a fully transparent window following the approach here, but then all elements inside the window are transparent, which isn't what we want.

HWND GetHWNDFromWindow(MUX::Window const &window) {
  HWND nativeWindow{nullptr};
  winrt::check_hresult(window.as<IWindowNative>()->get_WindowHandle(&nativeWindow));
  return nativeWindow;
}

...

  const auto hwnd = GetHWNDFromWindow(window);
  SetWindowLong(
      hwnd,
      GWL_STYLE,
      GetWindowLong(hwnd, GWL_STYLE) & ~WS_CAPTION & ~WS_THICKFRAME); // remove title bar and sizing border

  RECT windowRect;

  auto hOrgRgn = CreateRectRgn(0, 0, 0, 0);
  GetWindowRgn(hwnd, hOrgRgn);
  GetWindowRect(hwnd, &windowRect);

  auto hRoundRectRgn = CreateRoundRectRgn(
      0,
      0,
      windowRect.right - windowRect.left,
      windowRect.bottom - windowRect.top,
      windowRect.right - windowRect.left,
      windowRect.bottom - windowRect.top);
  winrt::check_hresult(SetWindowRgn(hwnd, hRoundRectRgn, TRUE));

Here's a screenshot:

[lyahdav]

Actually I just tried with WinAppSDK 1.2.220930.4 and the code above still works.

[chrisgull]

Actually I just tried with WinAppSDK 1.2.220930.4 and the code above still works.

The topic here is Acrylic (blurred), not transparency.

[castorix]

SetWindowRgn

Transparency with Regions has always worked, but it is an old method, which does not use anti-aliasing like Layered windows.

[bogdan-patraucean]

This is now part of WinUi 3. Maybe the issue could be closed?

[codendone]

Desktop Acrylic can now be easily applied to the window WinAppSDK 1.3 via DesktopAcrylicBackdrop.

[Crypties]

Having read this thread one has to wonder: is this 2020 thread the genesis of Mica, inspired by a user coming with this idea, calling it then "Faux Acrylic"? @mdtauk I think you may have inspired Mica.