Closed shaozi closed 2 years ago
Those aren't garbage chars, they are last-resort placeholder glyphs.
What's happening is that when those characters are first used, wezterm needs to find a font that contains the glyphs for them. To do that, it has to get the system list of fallback fonts and examine each of them until it finds a font that contains them, and that can take a noticeable amount of time. While the search is in progress last-resort placeholder glyphs are used.
Nightly builds made significant improvements in the speed of the fallback lookup, but if that is still not fast enough for you, then you can explicitly add your choice of font as described here:
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
What Operating System(s) are you seeing this problem on?
macOS
WezTerm version
20211004-231321-49d77138
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When there is Chinese characters in display, it took a few seconds to update the char from garbage char to the right ones. Nightly is faster, but still noticeable. Consequential display is fine.
See attached screencast.
To Reproduce
No response
Configuration
Expected Behavior
No response
Logs
No response
Anything else?
No response