One has to wonder if this due to the global memory shortage. ("Oh - changing our memory allocator to be more efficient will yield $XXM dollar savings over the next year").
We found it was roughly on par performance wise for simple text (latin), and faster for more complex scripts (thai, hindi, etc). It also is more correct when there is kerning across spaces, hyphenation, etc.
For the word-by-word approach to be performant you need a cache for each word you encounter. The shape-by-paragraph approach we found was faster for cold-start (e.g. the first time you visit a webpage). But this is also more difficult to show in standard benchmarks as benchmarks typically reuse the same renderer process.
Blink's (Chromium) text layout engine works the following way.
1. Layout the entire paragraph of text as a single line.
2. If this doesn't fit into the available width, bisect to the nearest line-break opportunity which might fit.
3. Reshape the text up until this line-break opportunity.
4. If it fits great! If not goto 2.
This converges as it always steps backwards, and avoids the contradictory situations.
Harfbuzz also provides points along the section of text which is safe to reuse, so reshaping typically involes only a small portion of text at the end of the line, if any.
https://github.com/harfbuzz/harfbuzz/issues/224
This approach is different to how many text layout engines approach this problem e.g. by adding "one word at a time" to the line, and checking at each stage if it fits.
> "At this point, the engineers in Australia decided that a brute-force approach to their safe problem was warranted and applied a power drill to the task. An hour later, the safe was open—but even the newly retrieved cards triggered the same error message."
What happened here (from what I recall) was far funnier than this does it credit.
The SREs first attempted to use a mallet (hammer) on the safe (which they had to first buy from the local hardware store - don't worry it got expensed later), then after multiple rounds of "persuasion" they eventually called in a professional (aka. a locksmith) who used a drill+crowbar to finally liberate the keycard.
The postmortem had fun step by step photos of the safe in various stages of disassembly.
One thing to keep in mind when developing these large lists of fonts is that they are generally terrible for performance if the appropriate glyphs for what you are trying to display aren't present in the first font (and the font is available - this isn't an issue if the font isn't available at all).
This is generally more of an issue with non-latin scripts (or when emoji is present for example), and developers adding a font which doesn't have glyph coverage - or sparse glyph coverage.
Chrome/Firefox devtools both have a section "Rendered Fonts"/"Used Fonts" which show which gylphs are used from which font.
`font-family: sans-serif` if not language tagged with incur a similar fallback perfromance penalty (the browser will have to change the "english" sans-serif font, find no glyphs, then use the "other-lang" sans-serfic font).