Introduce StaticFacet/ThemeFacet to reliably assign themed resources to components in an UWP app.

Proposal: Drop ThemeResource functionality

Summary

Currently, when referencing theme colors, UWP comes with two different flavors of resource references:

1. StaticResource
2. ThemeResource

… with ThemeResource being the one that’s reacting to user session theme changes.

I suggest to drop ThemeResource and to simply redraw an open application’s app window when the user changes his/her user session theme, forcing any StaticResource to draw its appropriate theme value accordingly anyway.

Additionally, the Page class may come with a new SessionThemeChanged event, so color caches created in app code may be invalidated and repopulated.

Rationale

Currently, it’s the responsibility of the app programmer to choose ThemeResource over StaticResource to have app theme color references change a component’s color. This puts additional burdon to programming an UWP app.

I believe this is unnecessary, because when a user changes his/her user session theme, any colors referencing a theme color MUST be changed, regardless of the programmer’s choice.

So, it doesn’t make sense to differenciate between theme color references that follow a user’s demand and theme color references that don’t. (The Photo Viewer app, for instance, apparently lacks to utilize ThemeResource - It doesn’t adhere to user session theme changes. I tend to believe that this is not a feature but rather a programming flaw.)

There are only two situations when a user session theme changes colors:

1. It’s when the user takes action to change the user session theme. So, when this happens (usually less than “once in a while”), the most easy implementation would be to just have Windows Runtime invalidate the app window’s client area and have the app redraw itself.

2. When Microsoft Windows Themes are enabled, the theme changes every couple of minutes. When this happens, the app window’s system are is invalidated and repainted. When this happens, the client area is invalided, too.

Currently, this results in a noticable stutter. The system has to (a) search for ThemeResource references first and then (b) to redraw the application anyway. I believe that step (a) is an unnecessary step, just wasting time.

Benefits

1. Apps will reliably react to user session theme changes.
2. App programmers will be lifted from the burden to manually decide to use ThemeResource when they are referencing theme colors.
3. Windows Runtime will become a tiny little bit less sluggish, more lean and clean.

[jevansaks]

Not sure how this is specific to ProjectReunion, this is specifically about the UWP UI framework, not the UWP app model/sandbox. @jevansaks Does it make sense to move this to the WinUI repo?

@chingucoding Sure I can move this to WinUI if it won’t disrupt this conversation. I have limited experience with this issue transfer feature. 😃

[chingucoding]

There are a few things here, so I’ll create a list.

1. Not sure how this is specific to ProjectReunion, this is specifically about the UWP UI framework, not the UWP app model/sandbox. @jevansaks Does it make sense to move this to the WinUI repo?
2. Not all resources referenced through the ThemeResource reference are colors, they can also be styles, strings, numbers. So when removing ThemeResource references, ANY theme change would requireyou to reevaluate any resources, not just colors. That would have a significant performance impact.
3. Theme changes are not only caused by the user, they can also be caused from inside the app by setting the RequestedTheme property.
4. Why should only a page have a ThemeChanged event? That seems a bit arbitrary. There is no guarantee that a page is the control that needs to handle that, every control decide their own theme. You can even write an app without using pages at all.
5. An app does not respect users selected theme. Changing the system wide theme should not affect an app which has the light theme hardcoded.