feat CoreFont & CoreFontManager

[jfboeve]

• Added CoreFont
• Reintroduced Fontmanager
• Unique font family names
• You can change fontfamily during runtime
• removed textRendererOverride (family names are unique now)

[wouterlucas]

I feel we stripped this out to reduce layers, now reintroducing this again 🫣

why do we need a font manager exactly?
is changing font families really a need during runtime?
does this slow stuff down again or is it neglible?

[jfboeve]

why do we need a font manager exactly?
So the CoreNode can get fonts without having to check all available textrenders. Now a fontFamily is unique in the renderer eliminating the need to check renderer type sinces it already neatly linked in the Font.

is changing font families really a need during runtime?
For accessibility I would say yes.

does this slow stuff down again or is it negligible?
so far it's faster in some things and faster in other, will test / tweak a bit more.

[frank-weindel]

Long time no see 👋

The point of using a single font family name that can support multiple text renderers is so the renderer can seamlessly fallback to using a different text renderer when needed without the app developer needing to also account for that in the font family name they're using. Are you sure you want to eliminate that capability?

[wouterlucas]

Hello Frank!

Well - the available font paths are determined by the capabilities of the platform you are running it on. This can be entirely determined at configuration time of the target you are deploying to. As such this is predetermined fact and not needed to be supported by a runtime fallback, it's only extra code that slows things down.

Once you deploy to a target, the need to "fallback" is never going to be used. Ie. a MSDF font will always render fine on device X and the chances it will "fallback" are 0. If you deploy to to a new device, say device Y the app developer will need to figure out what available font engines to use that work for the fonts in question. Though generally, MSDF works in most cases except exotic fonts or non-WebGL devices. We could consider some utility to help determine this, but that's aside the conversation.

So yeah - I think this is luxurious sugar that only makes the font rendering more complicated/layered for functionality that in practice isn't going to be used for a critical path piece of functionality that needs the shortest path possible to render with the least amount of impact.