Microsoft-ui-xaml: Reveal, Acrylic, etc. always use the fallback color when using WinUI in a custom control hosted in a Win32 Desktop Application

[AzAgarampur]

Describe the bug
Whenever a XamlCompositionBrushBase is used from Microsoft.UI.Xaml.Media after following the steps at Custom XAML Control, all of the brushes use their fallback color instead of the correct color. This does not happen when using XamlCompositionBrushBase brushes from Windows.UI.Xaml.Media

Steps to reproduce the bug

1. Follow the steps at Custom XAML Control
2. Set the background of the custom control to an AcrylicBrush from Microsoft.UI.Xaml.Media using HostBackdrop.
3. Build and run the program. Notice how the brush always uses the fallback color.
4. Try again, but with AcrylicBrush from Windows.UI.Xaml.Media. But now, notice how the brush works and does not use fallback.
5. You can also test the above steps with a RevealBorderBrush, reveal brushes from Microsoft.UI.Xaml.Media also always use the fallback color.

Expected behavior
The XamlCompositionBrushBase should work just like the platform brush;it should not always use the fallback color.

Version Info
WinUI Version: 2.4.0-prerelease.200422001 (using prerelease because my application is unpackaged)
Windows 10 version 1909 OS Build 18363.778
Desktop Only

NuGet package version:
Microsoft.UI.Xaml: 2.4.0-prerelease.200422001

[AzAgarampur]

Is there any progress investigating this issue?

[AzAgarampur]

Update on the issue: Even when using the platform control brush, the brushes always use fallback. I found out that excluding XamlControlsResources from the App resources solves the problem.

[DmitriyKomin]

Apologies about the delay here - I somehow lost track of this issue, and thankfully was reminded now. The behavior you describe is by design. AcrylicBrush & RevealBrush/Lights require a good deal of extra handling to work correctly on islands (eg reflecting island-level DPI changes, reacting to island activation (HostBackdrop Acrylic), showing expected RevealBorder lighting on island approach, among other issues). In addition, there is a class of issues specific to A/R brushes shared across islands. In WinUI 2.x, this support is not present at this time, so when used in an island, the Microsoft.UI.Xaml.* brushes immediately go into fallback mode.

It's an insightful observation that the OS versions (Windows.UI.Xaml.*) of the brushes do work - Acrylic/Reveal is supported in Windows.UI.Xaml.Controls.dll on 19H1+, with the requirement that brushes are not shared across islands (once that happens, they go into fallback). It's technically possible to use those in a Win UI 2.x app to get a level of A/R on islands support, but this is not recommended as it can easily lead to confusion and a disjointed "zebra" Fluent experience - more recent controls originating in WinUI don't have counterparts in Windows.UI.Xaml.Controls.dll and would end up using A/R brushes from Microsoft.UI.Xaml.Controls.dll that render with the fallback color.

Our intention is to bring proper support for island Acrylic and Reveal in a future release of WinUI. If this functionality is particularly important for you, please let us know - we are looking for feedback to gauge interest in this area.

[mdtauk]

@DmitryKomin Acrylic is possibly the single most iconic design element of Fluent Design and WinUI. WinUI 3 seems like it will launch without support for HostBackdrop Acrylic initially, as extricating it from the OS appears to be a technical challenge still to be figured out.

[AzAgarampur]

Finally, thanks for your response @DmitriyKomin I feel like fluent brushes, especially Acrylic and Reveal are important to XAML islands, as it prevents the "zebra" fluent experience you mentioned across multiple apps running on the operating system.

Also, I don't fully understand the the "isolation from the OS" initiative of WinUI 3. How can we separate WinUI from the underlying OS? We need OS functionality because WinUI is rendered by DirectX... I don't see how we can "decouple" from the OS, because nothing would function if we did. If anybody can clarify that that'd be great.

[mdtauk]

Finally, thanks for your response @DmitriyKomin I feel like fluent brushes, especially Acrylic and Reveal are important to XAML islands, as it prevents the "zebra" fluent experience you mentioned across multiple apps running on the operating system.

Also, I don't fully understand the the "isolation from the OS" initiative of WinUI 3. How can we separate WinUI from the underlying OS? We need OS functionality because WinUI is rendered by DirectX... I don't see how we can "decouple" from the OS, because nothing would function if we did. If anybody can clarify that that'd be great.

Well they are taking the Xaml parsing, rendering and controls that live in the Windows.UI.Xaml namespace right now, and making it a stand alone framework in Microsoft.UI.Xaml.

That means the code will be made open source, and anything that relies on undisclosed OS code - is being re-written.

The idea behind it is to enable the community to add features outside of OS updates, downport controls and features to older OS versions (possibly even Windows 8.1), and to enable both Win32 apps and UWP apps to use the same UI.

There is also a broader project called Project Reunion which is about creating wrapped APIs that both UWP and Win32 apps will be able to use.

[AzAgarampur]

Update: Using the latest WinUI 3 preview in a Desktop Application does the same thing: No reveal and no acrylic.

Is this issue dead for now?

[shaheedmalik]

I don't know why Microsoft keeps avoiding answering the question on having a faux acrylic to cover HostBackdrop Acrylic until the problem is fully fixed.

[AzAgarampur]

@DmitriyKomin If possible, can the brushes use their normal mode if the parent of the XAML Desktop Window correctly handles things like activation requests, dpi changes, etc?

@shaheedmalik It's pretty clear that HostBackdropAcrylic won't and cannot be decoupled from the OS, (I hope they prove me wrong) because it depends on DirectCompositionand the DirectX frame buffer & swapchain.

[shaheedmalik]

@DmitriyKomin If possible, can the brushes use their normal mode if the parent of the XAML Desktop Window correctly handles things like activation requests, dpi changes, etc?

@shaheedmalik It's pretty clear that HostBackdropAcrylic won't and cannot be decoupled from the OS, (I hope they prove me wrong) because it depends on DirectCompositionand the DirectX frame buffer & swapchain.

Then a faux acrylic brush needs to be made to fill in for it in WinUI3.

[mdtauk]

I have advocated for a FauxCrylic mode being added, but rather than be seen as a stop gap, it should be used as a performance mode, so the development time and effort can be better justified, and Tablet Mode on devices like the Surface Go will benefit from not being full of Fallback Solid Colours.

If it persists after Live Acrylic is restored for WinUI 3.X - then the work does not go to waste, as the performance mode can still be there, and still be useful.

[shaheedmalik]

I have advocated for a FauxCrylic mode being added, but rather than be seen as a stop gap, it should be used as a performance mode, so the development time and effort can be better justified, and Tablet Mode on devices like the Surface Go will benefit from not being full of Fallback Solid Colours.

If it persists after Live Acrylic is restored for WinUI 3.X - then the work does not go to waste, as the performance mode can still be there, and still be useful.

I 10000% agree with this. It should replace the current battery mode.

[AzAgarampur]

Woah, that's a great idea - using FauxCrylic as fallback! (is it FauxCrylic or FauxAcrylic)?

[mdtauk]

I 10000% agree with this. It should replace the current battery mode.

If not replace, then be an intermediate option on lower performance modes and Tablet Modes.

The Solid Colour fallback is a good idea for the lowest spec or for Transparency turned off in system settings