Design declarative Brush and Font specs to avoid WinRT object construction in render

[codemonkeychris]

Problem

Reactor render bodies can currently force authors to construct relatively expensive WinRT objects directly, especially for things like brushes and fonts.

Examples of the shape we should think through:

• Brush values often require constructing WinRT objects such as SolidColorBrush.
• Font-related values can also involve non-trivial WinRT objects or lookups.
• This is different from simple WinRT structs like Thickness, which are cheap value types and feel fine to construct inline in render.

In a React-like render model, render bodies should stay cheap and declarative. If authors repeatedly create brushes/fonts during render, we risk unnecessary allocation and object churn, but caching every realized WinRT object forever could leak an unbounded number of brush/font instances.

Design questions

This needs design, not a slam-dunk implementation:

• What is the right declarative model for a "brush spec" or "font spec" that feels natural in Reactor/React-style UI?
• Should specs be immutable records/value types that Reactor realizes to WinRT objects during reconciliation?
• Which objects are safe and useful to cache, especially for non-animated/static values?
• What cache lifetime model avoids leaking every brush/font ever requested? Do we need an expiring cache, weak cache, theme-aware cache, or per-host cache?
• How should theme resources, high contrast, dynamic system brushes, and animated brushes interact with any cache/spec model?
• How do we preserve escape hatches for callers that really do need to provide a concrete WinRT Brush or font object?

Expected outcome

Investigate and design an API/model that lets authors express brush and font intent declaratively without constructing expensive WinRT objects in render bodies, while avoiding unbounded object retention and preserving correct behavior for theme/dynamic/animated cases.

[HMO-SOUL]

This is really interesting
I think brushes and fonts should be generally immutable records even for themes (a single record that holds light and dark mode values) the only exception should be dynamic brushes and fonts so the app users can change fonts and use multiple dark and light themes in runtime

For cache solutions why not a multi-cache solution that use each of the above, admittedly this will add extra complexity but giving a specific cache for each resource with specific rules will result in an almost optimal solution, I don't think a single cache will serve reactor right and you will need to use some hacks and tricks to make the cache accomadate some resources

Questions
1- does reactor plan to support changing themes and fonts in runtime, this was a big problem for many devs, since the apps required the user to restart ?

2- does reactor plan to make it easy to support multiple dark and light modes themes ?