rem units support

[ickshonpe]

Objective

Add rem units support.

Fixes #21208

Solution

• Base rem units on the root UI Node's TextFont component's font_size value, or, if not present, the size of the default font.
• Add a Rem variant to Val and a rem helper construction function.
• Add a rem field to ComputedUiRenderTargetInfo.
• Update all the Val resolve functions to support rem units.

Based on #21181 for the default text style implementation.

Testing

[viridia]

Is this truly the root element of the hierarchy, or the default size in the resource? Normally the "r" in "rem" stands for "root" and everyone knows what it means, but perhaps in our case it should stand for "resource".

[ickshonpe]

It uses the value of the font size from the root UI node (if it has a TextFont component), or the DefaultTextStyle resource (if not).

I'm wondering if "rem" is the right name to use. I think it probably is, but "root element' is more web terminology again, which I want to avoid. I can only come up with ugly or silly alternatives though, like "rent" for "root entity".

[viridia]

Unfortunately, I think we are dealing with conflicting needs here: a tradeoff between simplicity and flexibility.

Unlike the web where there's a single root element (html), in Bevy you have multiple roots. This means that if font size is tied to the UI root, then globally adjusting the font size requires updating every root instead of adjusting a single parameter in a resource.

There's also a concern about cost: for something like an editor or app with nested panels, UI hierarchies can get fairly deep, with a depth of 10-15 levels not being uncommon. Calculating the effective font size for a leaf node could require looking up components on every ancestor.

[ickshonpe]

Unfortunately, I think we are dealing with conflicting needs here: a tradeoff between simplicity and flexibility.

Unlike the web where there's a single root element (html), in Bevy you have multiple roots. This means that if font size is tied to the UI root, then globally adjusting the font size requires updating every root instead of adjusting a single parameter in a resource.

Unless the root node is also a leaf text node, most of the time the only reason for setting a font size on the root would be to override the default font size from the resource. It feels to me like it would be very unintuitive if "rem" values weren't based on the font size of the node's root ancestor. Maybe we could have a seperate "gem" (or something) unit based on the global font size?

There's also a concern about cost: for something like an editor or app with nested panels, UI hierarchies can get fairly deep, with a depth of 10-15 levels not being uncommon. Calculating the effective font size for a leaf node could require looking up components on every ancestor.

The final implementation will do propagation on changes. When no font size is set, there won't be any need to walk up the tree. It will just access the default font resource directly.