Bad font visisibility performance on Windows and macOS

Not sure how whitelist is engineered differently .. but there is no such performance cliff

Font async fallback basically says render the character with "whatever" and then fallback (reflow) to the correct font later on. The mappings are now cached for the session. This is why I run the unicode char tests (glyphs, textmetrics) as late as possible on TZP, and they are hardcoded for display in HTML so they can render and fallback ASAP. You should be able to load TZP in a new session, note the FP hash, hit F5 and get the same FP hash - stability matters.

With whitelist, this has worked well.

With font.vis on windows (and lets assume mac as well), this has dramatically regressed. It takes up to a second for fonts to correctly render. Linux is not affected, because the font dir (bundled fonts) is treated as the system font dir so it must be treated differently. But on windows/mac gecko would expect most/all fonts to be system ones and bundled to be minimal (e.g. twemoji). But TB is not Firefox and most of our fonts are bundled.

My assumption is that the code only uses system fonts and is then slow to fall back if the fonts are "bundled" - but IANAE. And it doesn't explain why whitelist wouldn't also be slow - maybe how the available fonts are cached on startup or something?

I can work around it - just add an artificial 1 second delay on TB windows and mac (which sucks - code tested and working). But I would rather we fix this cliff upstream. I know jfkthame has done a lot of perf improvements, but IDK if he would be willing to change anything just for TB having a heap of bundled fonts.

cc @pierov