4 ms·

The font atlas is definitely still worth it. For example: your comment, which fits in a single browser tile, is made up of 735 drawn glyphs. There are 50 dist

by panic 11y ago

The font atlas is definitely still worth it. For example: your comment, which fits in a single browser tile, is made up of 735 drawn glyphs. There are 50 distinct glyphs used (not counting italics because I'm lazy). Assuming it takes twice as long to draw a glyph into an atlas but half as long to draw it once it's in the atlas, an atlas that starts completely empty will speed up text drawing for your comment by 66% (735 divided by 50 * 2 + (735 - 50) * 0.5, which is 442.5). And this underestimates the savings by a lot (drawing glyphs from an atlas is much more than two times as fast, and some glyphs are probably in the atlas already).

derefr 11y ago
The question is about amortized time-cost, though. • Most frames won't involve zooming or text-change—and therefore will be handled at "zero" time-cost by re-using the pre-composited tile. • The frames that do involve text-change (but not zoom) can benefit from font-atlasing. • The frames that involve discrete zoom, where text goes from one integral font size (represented in the atlas) to another integral font size (also in the atlas) can also benefit from font-atlasing. • The frames that involve continuous zoom—such as in this demo—can't benefit from font-atlasing, because the frames where the font is e.g. 7.037773pt large can't be served from the atlas. Keep in mind that the only reason we do discrete zoom-levels in PDF readers, text editors, etc. is that font-atlasing is "the optimization we have", and it calls for discrete zoom levels. When the UX affordance is for continuous zoom—think about pinch-to-zoom in Mobile Safari, or about zooming into Google Earth—font-atlasing doesn't and can't work. But this technique can. Now, in games in particular, "continuous zoom" is a pretty rare edge-case. GUI elements don't tend to get zoomed into[1]. And "in-VR" elements, like street signs in an FPS, aren't usually designed as a bunch of geometry[2], but rather as a very high-detail flat texture that maybe gets mipmapped from far away. "Zooming" by approaching a street sign doesn't make the fonts on it re-render themselves; there are no fonts on it, they're just baked into an image. --- [1] Well, maybe; I could see a case for continuous zoom of the fonts—and other GUI geometry—plastered over units in RTS games. "Pan up" with units selected, they stay selected but their unit names+stats get smaller and smaller and eventually get obscured by draw-distance and atmosphere effects, just as if they were actually "there" in the scene instead of part of the GUI. (Makes me think of the windows in the TV show ReBoot.) [2] This does make me imagine a Blade Runner-esque game full of holographic signs, though. Those could definitely benefit from this approach.)
- panic 11y ago
  Font atlasing can and does work during pinch-to-zoom: that was the point I was trying to make. You have to generate a new atlas each time you paint, but drawing multiple "e" glyphs from an atlas is much cheaper than rasterizing each "e" individually.
  - derefr 11y ago
    Huh; I almost don't think of that as font-atlasing. If you know you're continuously zooming—and therefore are going to throw out the atlas at the end of the frame—it's almost more like a "glyphs rendered this frame" cache. Which changes things a bit, because you don't need to preload the entirety of the "font"—which might be a unicode font!—into the atlas, but only what you're rendering. I have no argument against that kind of font-atlasing as a process; it's fairly more stateless, more like a secret cache inside the black box of the glyph-rendering kernel.
  - wjd 11y ago
    Consider that each "e" may be slightly differently aligned to the pixel grid though. So using an atlas is lower quality than drawing each "e" from scratch exactly as it aligns to the screen.
    - deleted 11y ago
      [deleted]

by panic 11y ago

derefr 11y ago

The question is about amortized time-cost, though. • Most frames won't involve zooming or text-change—and therefore will be handled at "zero" time-cost by re-using the pre-composited tile. • The frames that do involve text-change (but not zoom) can benefit from font-atlasing. • The frames that involve discrete zoom, where text goes from one integral font size (represented in the atlas) to another integral font size (also in the atlas) can also benefit from font-atlasing. • The frames that involve continuous zoom—such as in this demo—can't benefit from font-atlasing, because the frames where the font is e.g. 7.037773pt large can't be served from the atlas. Keep in mind that the only reason we do discrete zoom-levels in PDF readers, text editors, etc. is that font-atlasing is "the optimization we have", and it calls for discrete zoom levels. When the UX affordance is for continuous zoom—think about pinch-to-zoom in Mobile Safari, or about zooming into Google Earth—font-atlasing doesn't and can't work. But this technique can. Now, in games in particular, "continuous zoom" is a pretty rare edge-case. GUI elements don't tend to get zoomed into[1]. And "in-VR" elements, like street signs in an FPS, aren't usually designed as a bunch of geometry[2], but rather as a very high-detail flat texture that maybe gets mipmapped from far away. "Zooming" by approaching a street sign doesn't make the fonts on it re-render themselves; there are no fonts on it, they're just baked into an image. --- [1] Well, maybe; I could see a case for continuous zoom of the fonts—and other GUI geometry—plastered over units in RTS games. "Pan up" with units selected, they stay selected but their unit names+stats get smaller and smaller and eventually get obscured by draw-distance and atmosphere effects, just as if they were actually "there" in the scene instead of part of the GUI. (Makes me think of the windows in the TV show ReBoot.) [2] This does make me imagine a Blade Runner-esque game full of holographic signs, though. Those could definitely benefit from this approach.)

panic 11y ago
Font atlasing can and does work during pinch-to-zoom: that was the point I was trying to make. You have to generate a new atlas each time you paint, but drawing multiple "e" glyphs from an atlas is much cheaper than rasterizing each "e" individually.
- derefr 11y ago
  Huh; I almost don't think of that as font-atlasing. If you know you're continuously zooming—and therefore are going to throw out the atlas at the end of the frame—it's almost more like a "glyphs rendered this frame" cache. Which changes things a bit, because you don't need to preload the entirety of the "font"—which might be a unicode font!—into the atlas, but only what you're rendering. I have no argument against that kind of font-atlasing as a process; it's fairly more stateless, more like a secret cache inside the black box of the glyph-rendering kernel.
- wjd 11y ago
  Consider that each "e" may be slightly differently aligned to the pixel grid though. So using an atlas is lower quality than drawing each "e" from scratch exactly as it aligns to the screen.
  - deleted 11y ago
    [deleted]