Reduce memory retained by parsed Typography typefaces

[charlesroddie]

CSharpMath retains parsed Typography Typeface data for bundled and custom fonts. The original profile predates the current dependency snapshot. The shared, reproducible baseline is tracked in #293 and is a native prerequisite for this issue.

This issue owns reducing memory in the runtime font-loading path, especially custom LocalTypefaces; build-time precomputation for bundled fonts is separate in #191.

Acceptance criteria:

• Use Benchmark math-font startup allocations and retained memory #293's profile to identify which OpenType tables, glyph instructions, outlines, and caches remain reachable after loading.
• Lazily load or release data that the renderer does not need after extracting required metrics/outlines.
• Verify repeated rendering and font switching do not reparse fonts or grow retained caches without bound.
• Keep custom LocalTypefaces and every current rendering output working.
• Record before/after allocations and retained memory for every bundled font and at least one custom font using the same benchmark environment.
• Add deterministic correctness tests for any cache/lifetime policy; do not use fragile performance thresholds as correctness assertions.

A solution must remain compatible with trimming/AOT and must not dispose caller-owned typefaces unexpectedly.

[Happypig375]

Currently CSharpMath stores Typeface objects in memory which is basically an entire otf file parsed into table objects. latinmodern-math.otf weighs 717KiB, and AMS-Capital-Blackboard-Bold.otf weighs 8.51KiB. However, the inclusive size shown is an order of magnitude larger than the size of the source files.

[charlesroddie]

Presumably the issue involves:

1. Loading an entire font at a time rather than characters lazily
2. A memory-inefficient representation of a character

Are both of these issues for the typography repo, or is there anything that can be improved here?

[Happypig375]

@prepare Thoughts?

[prepare]

I think some objects could be unloaded/dispose
eg.

1. List<Type2Instruction> could be unload after you create a glyph outline from it.
2. Unload many openfont tables that are not need by user

but this I have to test it first

[prepare]

please visit and test 'Trimmable features' again, see=> LayoutFarm/Typography#187

[Happypig375]

So there are two ways forward with the Typography submodule:

• Drop Nullables!! LayoutFarm/Typography#192 and update
• Merge latest Typography into Nullables!! LayoutFarm/Typography#192 and resolve conflicts (and do them again for future updates)

@prepare @charlesroddie Thoughts?

[charlesroddie]

I don't believe CSharpMath is affected much by the NRT PR LayoutFarm/Typography#192. That PR makes it easier for Typography to control NRE bugs and to do further development without having to worry about NREs. However it's not worth forking Typography just for that. If the @prepare prefers to do more work to implement features safely that is up to him!

CSharpMath should depend on Typography master branch if possible, through the submodule for now, and through a nuget package when Typography stabilizes.

Note that it can't use the current state of Typography master as UWP support is broken by the netstandard2.1 change.

[prepare]

Hello

Note that it can't use the current state of Typography master as UWP support is broken by the netstandard2.1 change.

I move back to netstandard 2.0, please check again :)

LayoutFarm/Typography@0899ddf

[Happypig375]

@charlesroddie How the NRT PR affects CSharpMath can be seen through the difference between using null-oblivious and null-explicit APIs. By dropping the current submodule reference to LayoutFarm/Typography#192, all Typography APIs currently is use will start ignoring accidental nulls during compile-time, leaving bugs to be caught run-time.

[Happypig375]

@prepare @charlesroddie Seems that LayoutFarm/Typography#192 will never be merged. Should we drop it and update or should we resolve merge conflicts?

[charlesroddie]

That is a shame if true. @prepare it would be good to have your thoughts on that PR even if in an initial form. Maintaining a branch or fork of typography for use in CSharpMath would require a lot of work on @Happypig375 's part, and is unfeasible to maintain indefinitely IMO. So if it will really never be merged then dropping and accepting a less safe typography library for use in CSharpMath is inevitable.

[prepare]

@Happypig375 👍

I want to confirm that the LayoutFarm/Typography#192 is NOT your waste time.

But I can't merge it directly now because of this LayoutFarm/Typography#192 (comment) too.

---

By the way,
The Typography (TextServices, TextSpanPrinter etc.) is now under refactoring-code-arrangement phase again,

It will be released this week.