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

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

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

@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 HostBackdrop Acrylic won’t and cannot be decoupled from the OS, (I hope they prove me wrong) because it depends on DirectComposition and the DirectX frame buffer & swapchain.

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