Fix #105891: Faster Font Fallback Finding #106011

Harley Acheson · 2023-03-22T20:04:30+01:00

Harley Acheson commented

2023-03-22 20:04:30 +01:00

An improved strategy for finding glyphs within our font fallback stack.

When a text character is requested to be be drawn in the UI, but is not found (or cached) in our regular font, we look in a list of fallback fonts. This allows us to support far more glyphs than any one font can contain.

However this bug report indicates that our current strategy for looking through those fonts can be improved. In the example in the report there are strings containing "🙂" and "🍔". Our current strategy "works" in that not all the fonts need to be searched to find them, but more are searched than necessary. First we look in our monospaced font, because that font indicates that it contains some characters in that range. Then it looks in our big "CJK" font because that also gives that indication. Then it finally finds them in our "NotoEmoji" font.

Current code goes through our list of fonts in one go, mostly just checking the font's coverage bits. But not all of our fonts should be treated the same and it helps a lot to break this into multiple searches. First it looks through the fonts that are currently loaded. Our font caching system only loads fonts that are needed and can unload fonts once they are no longer so. It is MUCH faster to look in the loaded fonts first because the glyph lookups are also cached. Basically if we have already printed an emoji we might as well look in that font for any others, rather than looking through all fonts that hint that they might have one - especially since these other files might need to be loaded to check.

If the above fails only then do we look in the fonts that are NOT loaded (currently without a face) but that also match the coverage bit of the needed character. Basically if we are looking for a character that is in the Unicode block for Phoenician we only look in unloaded fonts that say that they include Phoenician.

In the unlikely event that both searches above find nothing then we look through fonts that weren't included in the above two searches. Then if not found we reply with a last-resort character.

This also makes a change that when looking for a character while outputting proportion text, do not look in the monospaced font. We want to do the reverse (include proportional fonts when outputting monospaced), but there are no times when we want to use a fixed-pitch glyph for a proportional use. Our mono font does not contain many characters, but no need to even look in most cases.

Because of the changed strategy this PR also changes the coverage bits for our "CJK" font so as to not include bit 57. This bit is called the "Surrogates" bit and is very "blunt" in that it only indicates that the font contains any codepoints above U+10000. I don't want to look in this big font just because the codepoint is somewhere in the Supplementary Multilingual Plane. Checking on this bit was useful with the old strategy, but not now. Now when we loaded the CJK font for any Chinese, Japanese, or Korean characters we are going to look in that font first anyway for anything with a regular coverage bit. Anything without a specific bit will still be loaded and cached.

With these changes the example in this bug report is substantially faster. The first emoji character is found immediately in the unloaded emoji font (and loaded) without checking any others. And the second emoji is then immediately loaded from that same emoji font rather than searching anywhere else.

An improved strategy for finding glyphs within our font fallback stack. --- When a text character is requested to be be drawn in the UI, but is not found (or cached) in our regular font, we look in a list of fallback fonts. This allows us to support far more glyphs than any one font can contain. However this bug report indicates that our current strategy for looking through those fonts can be improved. In the example in the report there are strings containing "🙂" and "🍔". Our current strategy "works" in that not all the fonts need to be searched to find them, but more are searched than necessary. First we look in our monospaced font, because that font indicates that it contains some characters in that range. Then it looks in our big "CJK" font because that also gives that indication. Then it finally finds them in our "NotoEmoji" font. Current code goes through our list of fonts in one go, mostly just checking the font's coverage bits. But not all of our fonts should be treated the same and it helps a lot to break this into multiple searches. First it looks through the fonts that are **currently loaded**. Our font caching system only loads fonts that are needed and can unload fonts once they are no longer so. It is MUCH faster to look in the loaded fonts first because the glyph lookups are also cached. Basically if we have already printed an emoji we might as well look in that font for any others, rather than looking through all fonts that hint that they might have one - especially since these other files might need to be loaded to check. If the above fails only then do we look in the fonts that are NOT loaded (currently without a face) but that also match the coverage bit of the needed character. Basically if we are looking for a character that is in the Unicode block for Phoenician we only look in unloaded fonts that say that they include Phoenician. In the unlikely event that both searches above find nothing then we look through fonts that weren't included in the above two searches. Then if not found we reply with a last-resort character. This also makes a change that when looking for a character while outputting proportion text, do not look in the monospaced font. We want to do the reverse (include proportional fonts when outputting monospaced), but there are no times when we want to use a fixed-pitch glyph for a proportional use. Our mono font does not contain many characters, but no need to even look in most cases. Because of the changed strategy this PR also changes the coverage bits for our "CJK" font so as to not include bit 57. This bit is called the "Surrogates" bit and is very "blunt" in that it only indicates that the font contains any codepoints above U+10000. I don't want to look in this big font just because the codepoint is somewhere in the Supplementary Multilingual Plane. Checking on this bit was useful with the old strategy, but not now. Now when we loaded the CJK font for any Chinese, Japanese, or Korean characters we are going to look in that font first anyway for anything with a regular coverage bit. Anything without a specific bit will still be loaded and cached. With these changes the example in this bug report is substantially faster. The first emoji character is found immediately in the unloaded emoji font (and loaded) without checking any others. And the second emoji is then immediately loaded from that same emoji font rather than searching anywhere else.

❤️ 2 🎉 1

Harley Acheson added 1 commit 2023-03-22 20:04:40 +01:00

9a04d57f3c Fix #105891 : Faster Font Fallback Finding

An improved strategy for finding glyphs within our font fallback stack.

Harley Acheson requested review from Brecht Van Lommel 2023-03-22 20:05:11 +01:00

Brecht Van Lommel approved these changes 2023-03-24 11:51:50 +01:00

Harley Acheson added 1 commit 2023-03-24 19:27:16 +01:00

buildbot/vexp-code-patch-coordinator Build done. Details

cfa8d3d4d9 Merge branch 'main' into FallbackStrategy

Harley Acheson commented

2023-03-24 19:30:10 +01:00

@blender-bot build

Harley Acheson merged commit 1d84216c09 into main

2023-03-24 19:55:38 +01:00

Harley Acheson deleted branch FallbackStrategy

2023-03-24 19:55:38 +01:00

Harley Acheson referenced this issue from a commit

2023-03-24 19:55:39 +01:00

Fix #105891: Faster Font Fallback Finding

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fix #105891: Faster Font Fallback Finding #106011