Cache synthetic/nearest glyph typefaces under the requested family name

[ronnycohen]

What does the pull request do?

FontCollectionBase.TryGetGlyphTypeface only caches the resolved typeface under the requested family name when synthesis fails. When TryCreateSyntheticGlyphTypeface succeeds, the synthetic typeface is registered by TryCreateSyntheticGlyphTypeface itself — but only under the source font's own family names, never under the name the caller asked for.

As a result, a request that arrives through a different name never hits the cache and re-enters synthesis on every single call. Synthesis goes through IPlatformTypeface.TryGetStream, which reads the entire font file into memory and hands it to SKTypeface.FromStream, which copies it again natively. Every resolution therefore costs one retained copy of the whole font file.

Two common shapes reach this path:

• a platform alias — a family the font manager can resolve but that is absent from GetInstalledFontFamilyNames(). Android declares several in /system/etc/fonts.xml: <alias name="arial" to="sans-serif"/>, plus helvetica, tahoma, verdana, times, courier;
• a "Family Style" composite decomposed by Typeface.Normalize (e.g. "Arial Black" → family arial + FontWeight.Black), which makes the requested key differ from the key the platform returns.

When the bare family has already been resolved at another weight, the lookup finds it as a nearest match, synthesizes, and returns — with the requested key still absent from the cache, so the next call repeats everything.

The fix caches under the requested family name in both branches (the TryAddGlyphTypeface call moves out of the else).

Why is it needed / measured impact

Found while investigating unbounded native memory growth on Android digital-signage devices (Avalonia 12.1.1, .NET 10, arm64).

• The leaked object was identified by byte comparison: consecutive chunks of /system/fonts/Roboto-Regular.ttf (2 372 548 bytes = 29 × 81 812), copied in SkDynamicMemoryWStream blocks — the whole font file, once per resolution call, roughly 90 times per screen redraw.
• Reproduced as an on/off switch on the device: a text widget set to "Arial Black" grew the native heap by +1187 MB over ~14 redraws; the same widget set to Roboto, Archivo Black or bare Arial stayed flat; switching back to "Arial Black" restarted the growth (+479 MB in 2 minutes) until the platform memory guard killed the process at 2.6 GB.
• Directed confirmation that this is not specific to Arial: with helvetica (another Android alias) resolved once at normal weight first, "helvetica black" on the same process grew the heap by +570 MB in 2 min 30 — a font that had been flat in every earlier test.
• Windows/DirectWrite is structurally immune, which is likely why this went unnoticed: there, every resolvable family is also an installed family, so the case-insensitive family-name search in TryGetGlyphTypeface finds the synthetic (registered under its real name) on the second call, and the missing cache entry repairs itself after a single copy. With a platform alias, nothing repairs it.

Tested platforms

• Avalonia.Skia.UnitTests, filter *FontCollection*: 39/39 pass with the fix; 1 failure (the new test) without it — the second resolution returns a different instance, i.e. re-synthesis.
• Field validation on Android 13 / arm64 (Sunmi FLEX3): an equivalent redraw burst costs +6.6 MB instead of +1187 MB once the alias no longer reaches this path.
• Existing synthetic-caching tests (EmbeddedFontCollectionTests.Should_Cache_Synthetic_GlyphTypeface, FontCollectionTests.Should_Cache_Nearest_Match) are unaffected.

The added test uses an IFontManagerImpl that models a platform alias — a family that resolves through TryCreateGlyphTypeface but is absent from GetInstalledFontFamilyNames() — and asserts that repeated resolutions return the same instance and perform no further stream-based typeface creation.

Breaking changes

None. The change only adds a cache entry that the non-synthetic branch already added.

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0068376-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[cla-avalonia]

• All contributors have signed the CLA.

[ronnycohen]

@cla-avalonia agree

[Gillibald]

This test should be written platform-independently. There is no need to use Arial.

[ronnycohen]

Good point, thank you — you are right, and the dependency on Arial was a leftover from how I found the bug in the field rather than anything the test needed.

Rewritten in a3ef02b: the alias is now backed by an embedded test font (resm:Avalonia.Skia.UnitTests.Assets, same pattern as CustomFontManagerImpl) and the test is a plain [Fact], so it runs on every platform. That also matches the defect better, since FontCollectionBase is platform-agnostic — behind [Win32Fact] the Linux and macOS legs were not covering it at all.

The fake font manager is a little more faithful too: it now always resolves the alias to the regular face of the embedded font whatever weight is requested — which is what a platform alias does — instead of delegating to the real font manager.

Verified both ways locally: *FontCollection* is 39/39 with the fix, and the new test is the single failure without it.

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0068380-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[ronnycohen]

Second real-world reproduction of this defect, measured on a production Android 11 kiosk (Avalonia 12.1.1).

A TextBlock with FontWeight="SemiBold" and no FontFamily resolves to the platform default family (sans-serif). The device only ships a static Roboto 400, so the nearest match differs from the requested key: TryCreateSyntheticGlyphTypeface synthesises a faux-bold and caches it under the source family names (Roboto@600), never under the requested one (sans-serif@600). Every subsequent lookup misses and re-synthesises, and each synthesis copies the entire font file through SkDynamicMemoryWStream.

Measured with heapprofd on the device: 6 copies of Roboto-Regular.ttf (305 608 B) = 1 834 224 B retained per screen rebuild — 24 allocations, zero frees, byte-identical across rebuilds and across two different screens. Dumping SystemFontCollection._glyphTypefaceCache right after a rebuild shows both halves of the mechanism:

'sans-serif' -> [FontCollectionKey { Style = Normal, Weight = Normal,   Stretch = Normal }]
'Roboto'     -> [FontCollectionKey { Style = Normal, Weight = DemiBold, Stretch = Normal }]

Removing that single SemiBold attribute drops it to 0 allocations on the same screen and device, which confirms the path end to end.

Worth noting for anyone hitting this: it only shows up where the platform font set is poor. The same application, same screen, on an Android 13 device (variable Roboto, real 600 available) and on Windows/DirectWrite allocates nothing — no nearest-match, no simulation, no copy. That is probably why this has stayed unnoticed.

Caching under familyName, as this PR does, is what breaks the loop.

[Gillibald]

This picks whichever asset GetAssets happens to enumerate first (currently AdobeBlank2VF.ttf).

Please name the font explicitly resm:Avalonia.Skia.UnitTests.Assets.NotoMono-Regular.ttf?assembly=Avalonia.Skia.UnitTests, matching the style of GlyphTypefaceTests.InterFontUri and add Assert.Equal(FontSimulations.Bold, first.FontSimulations) after the first Black resolution. Without that, a backing font that fails synthesis makes the whole test pass against unfixed code, since the old else branch cached the nearest match.

[ronnycohen]

Good catch, and the second half is the important one — thank you.

You are right that the test could pass against unfixed code. I checked what GetAssets actually enumerated first: AdobeBlank2VF.ttf, a blank variable font — about the worst possible backing face for a test about bold synthesis. Both points are addressed in c8b03f0:

• the font is now named explicitly, resm:Avalonia.Skia.UnitTests.Assets.NotoMono-Regular.ttf?assembly=Avalonia.Skia.UnitTests;
• Assert.Equal(FontSimulations.Bold, first.FontSimulations) is asserted right after the first Black resolution, with a comment explaining precisely why it is there — a font that cannot be emboldened would send the lookup down the old else branch, cache the nearest match, and make everything below vacuous.

I also dropped the now-unused using System.Linq.

Verified both ways locally: FontCollectionTests is 4/4 with the fix, and Should_Cache_Synthetic_Match_Under_Requested_Family_Name is the single failure without it (reverting only FontCollectionBase.cs).

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0068651-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[ronnycohen]

Gentle bump — this has been sitting since 16 August and has had no reviewer yet.

Recap of what it is, since the thread is long: on a font collection whose platform resolves a
family through an alias (every Android system alias: arial, helvetica, tahoma, times…),
asking for that family with a style that the device cannot match makes
FontCollectionBase.TryGetGlyphTypeface synthesise a typeface on every call and never cache it
under the requested key — TryAddGlyphTypeface(familyName, key, …) sits inside the else branch,
so it only runs when the synthesis fails. Each call copies the whole font file into native
memory.

Two independent real-world reproductions are in this thread, both on production kiosks, one of them
costing 1.2 GB of native memory in an hour. The fix moves the caching call out of the else; the
existing *FontCollection* tests stay green (39/39), and the added test fails without it.

Happy to rebase or split if that helps it move.

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0069437-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[Gillibald]

LGTM

There are still some issues related to synthetic font lookup but we can fix them later