SystemBackdropElement does not handles theme changed event

[HO-COOH]

Describe the bug

SystemBackdropElement does not handle RequestedTheme changes at all from the source code.

Why is this important?

If the user toggles app theme at runtime, the backdrop is broken, causing a very bad readability.

Steps to reproduce the bug

1. Open winui 3 gallery to SystemBackdropElement page
2. Toggle the control example theme

Actual behavior

No response

Expected behavior

No response

Screenshots

NuGet package version

2.0.12

Windows version

Windows 10 (1809): Build 17763

Additional context

I have an almost identical implementation that handles this correctly.

[niels9001]

@Jay-o-Way is bringing up a great point here: microsoft/WinUI-Gallery#2166 (comment)

This feels like it's actually expected behavior?

Would be good to point this out though in the docs and in the WinUI Gallery.

[HO-COOH]

Obviously this control is supposed to be used as a workaround where the acrylic brush being unavailable in winui3. It is supposed to be placed inside a popup as a background element to provide the acrylic effect (otherwise it would not be made into a control in the first place, since we already have DesktopAcrylicBackdrop). So it should really listen to theme changed events to be useful.

[Jay-o-Way]

@HO-COOH words like "obviously", "should" and "supposed" are very dangerous. If that is what the community want, then so be it, but at the moment it's still a matter of "is this in line with specs or not". Those are two different things. And no, so far it is not a bug. A request for a change is a whole different category.

(Edit)
And also...

• A backdrop is not an ordinary control. It's a system backdrop. You don't call mica a control either, or do you?
• Noticed how the name starts with SYSTEM backdrop?

[mdtauk]

As it is an element you place in the visual tree, to display a surface material, I for one, assumed it would inherit the parent container's RequestedTheme, and as the WinUI Gallery demonstrares this by adding another control on top of the surface, that does inherit the theme, it looks like that is bad UX guidance if this control by design does not inherit.

If it could be made to inherit, and it is not technically impossible - then I think this should be done. Most elements in WinUI have a RequestedTheme, and inherit - and the WinUI controls expect this inheritence to ensure child controls display correctly.

If its as technical limitation, then the example should show a use case that wont look broken, and the text should make it super clear this control has limitations.

TLDR - make it inherit the requested theme, and if it can't make the example show how to use it properly so child controls render correctly and make this limitation explicit.