Comment by kevingadd
4 years ago
Simply shaping text using state of the art libraries (like harfbuzz) can take an INCREDIBLE amount of time in some cases. If you're used to rendering text in western character sets you may think it can always be fast, but there are cases where it's actually quite slow! You get a sense for this if you try to write something like a web browser or a word processor and have to support people other than github posters.
Of course in this case it seems like it was possible to make it very fast, but people who think proper text rendering is naturally going to be somewhat slow aren't always wrong.
Saying that text rendering is "largely solved" is also incorrect. There are still changes and improvements being made to the state of the art and there are still unhappy users who don't get good text rendering and layout in their favorite applications when using a language other than English.
> naturally going to be somewhat slow
Naturally slow for a text renderer might mean it renders in 4ms instead of 0.1.
Yes, and for a terminal like discussed in the article, 4ms is considered unacceptably slow
I dunno what framerate you expect your terminal to run at, but 250hz should be enough for everyone.
You are right in the general case. But terminals are a specific niche, not requiring the full extent of text rendering edge cases as a browser, wysiwyg editor, etc “experience”. It renders “strictly”* monospaced fonts, which makes it trivial to cache and parallelize.
* as it was brought up, one might use a non-monospace font, but that case can just use the slow path and let the “normal” people use a fast terminal