4 ms·

Are fonts always rendered 'completely' these days? I thought that the fonts would be rendered once to a cache of bitmaps/textures, and then those bitmaps can be

Are fonts always rendered 'completely' these days? I thought that the fonts would be rendered once to a cache of bitmaps/textures, and then those bitmaps can be copied to the screen/buffer pretty much instantaneously. After all, there's no point re-doing all the calculations to draw all the curves in a letter 'g' when the output is going to look just the same as the last time you drew it...

microcolonel 10y ago
There is a point. Subpixel positioning is important and it's hard to know how much memory will be taken up by the full set of characters. Because you can not know the advances(and hence the exact positions) before you render the characters, you can not render them ahead of time without quantizing the position and storing multiple bitmaps. This quickly becomes a non-optimization.
- Ono-Sendai 10y ago
  Sure you could. Just resample the bitmap.
- p0nce 10y ago
  What I do is rounding the glyph position to 1/4 of pixels, in my tests it has not much visual impact. That still mean in the worst case the glyph cache could contains 16x the same glyph, and that's before hinting enters the equation.
- panic 10y ago
  You can get good subpixel rendering from a single bitmap using a larger prefiltered glyph: https://github.com/nothings/stb/tree/master/tests/oversample https://github.com/nothings/stb/tree/master/tests/oversample
zellyn 10y ago
On the parallel Reddit discussion, someone mentioned that the gain is less when rendering CJK scripts, since there are so many different glyphs.
acdha 10y ago
> After all, there's no point re-doing all the calculations to draw all the curves in a letter 'g' when the output is going to look just the same as the last time you drew it... Beyond the sub-pixel aliasing and CJK questions other people asked, a fair number of people use languages like Arabic, Devangari, etc. which have complex rules for how adjacent characters affect rendering (you can see something like this in English with a font like Zapfino which has ligatures: http://download.linotype.com/free/howtouse/ZapfinoTips_e.pdf http://download.linotype.com/free/howtouse/ZapfinoTips_e.pdf). I would imagine all of that would conspire against cache hit rates more than we might guess. That's not to say this isn't great work but just that any time something involves text rendering it seems to inevitably sprout special cases on the special cases.
- posterboy 10y ago
  hard to imagine the code used to render the bitmaps would be smaller and hence less often lead to cache misses than the bitmaps.
  - munificent 10y ago
    acdha is referring to the cache of rendered bitmaps, not the CPU cache. Font renderers that cache keep a cache of bitmaps for glyphs that it has previously rendered. Since you need a separate bitmap for each Unicode codepoint or ligature × font size × subpixel offset, the cache could potentially get huge. So, they cap the number of bitmaps that get cached and evict some. But when you're animating a font's size or dealing with non-Latin languages, you're churning through so many unique bitmaps that you end up not getting much value from the cache.
- witty_username 10y ago
  Devanagari is not a language; it's a writing script.
  - acdha 10y ago
    You're right, I should have been less colloquial in that reference since I was using “Arabic” in reference to the script, which is used by multiple languages.
pcwalton 10y ago
> Are fonts always rendered 'completely' these days? I thought that the fonts would be rendered once to a cache of bitmaps/textures, and then those bitmaps can be copied to the screen/buffer pretty much instantaneously. They are. But (a) non-Latin languages often miss in the cache; (b) subpixel positioning makes cache misses happen more often; (c) sometimes people animate font size, negating the optimization; (d) we care about initial load time.

microcolonel 10y ago

There is a point. Subpixel positioning is important and it's hard to know how much memory will be taken up by the full set of characters. Because you can not know the advances(and hence the exact positions) before you render the characters, you can not render them ahead of time without quantizing the position and storing multiple bitmaps. This quickly becomes a non-optimization.

Ono-Sendai 10y ago
Sure you could. Just resample the bitmap.
p0nce 10y ago
What I do is rounding the glyph position to 1/4 of pixels, in my tests it has not much visual impact. That still mean in the worst case the glyph cache could contains 16x the same glyph, and that's before hinting enters the equation.
panic 10y ago
You can get good subpixel rendering from a single bitmap using a larger prefiltered glyph: https://github.com/nothings/stb/tree/master/tests/oversample https://github.com/nothings/stb/tree/master/tests/oversample

zellyn 10y ago

On the parallel Reddit discussion, someone mentioned that the gain is less when rendering CJK scripts, since there are so many different glyphs.

acdha 10y ago

> After all, there's no point re-doing all the calculations to draw all the curves in a letter 'g' when the output is going to look just the same as the last time you drew it... Beyond the sub-pixel aliasing and CJK questions other people asked, a fair number of people use languages like Arabic, Devangari, etc. which have complex rules for how adjacent characters affect rendering (you can see something like this in English with a font like Zapfino which has ligatures: http://download.linotype.com/free/howtouse/ZapfinoTips_e.pdf http://download.linotype.com/free/howtouse/ZapfinoTips_e.pdf). I would imagine all of that would conspire against cache hit rates more than we might guess. That's not to say this isn't great work but just that any time something involves text rendering it seems to inevitably sprout special cases on the special cases.

posterboy 10y ago
hard to imagine the code used to render the bitmaps would be smaller and hence less often lead to cache misses than the bitmaps.
- munificent 10y ago
  acdha is referring to the cache of rendered bitmaps, not the CPU cache. Font renderers that cache keep a cache of bitmaps for glyphs that it has previously rendered. Since you need a separate bitmap for each Unicode codepoint or ligature × font size × subpixel offset, the cache could potentially get huge. So, they cap the number of bitmaps that get cached and evict some. But when you're animating a font's size or dealing with non-Latin languages, you're churning through so many unique bitmaps that you end up not getting much value from the cache.
witty_username 10y ago
Devanagari is not a language; it's a writing script.
- acdha 10y ago
  You're right, I should have been less colloquial in that reference since I was using “Arabic” in reference to the script, which is used by multiple languages.

pcwalton 10y ago

> Are fonts always rendered 'completely' these days? I thought that the fonts would be rendered once to a cache of bitmaps/textures, and then those bitmaps can be copied to the screen/buffer pretty much instantaneously. They are. But (a) non-Latin languages often miss in the cache; (b) subpixel positioning makes cache misses happen more often; (c) sometimes people animate font size, negating the optimization; (d) we care about initial load time.