6 ms·

> they rely on libraries to rasterize glyphs of a font into a bitmap once Unfortunately it's not this simple. Unicode and multilingual support means you can't

by _gabe_ 4y ago

> they rely on libraries to rasterize glyphs of a font into a bitmap once Unfortunately it's not this simple. Unicode and multilingual support means you can't possibly generate a single bitmap to contain all possible characters. Modern UIs (including text editors and terminals) generally support various zoom levels, which requires re-rasterizing glyphs at different zoom levels. This means you typically have to rasterize vector graphics (your font) on the fly as needed and then update your bitmap. Edit: Also, emojis and certain scripts require composting multiple glyphs together. This means you have to figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately. Then throw in mathematical notation and all bets are off. My point is, rendering text is not a simple done deal, but it's also not an impossible feat and it can be done efficiently.

naikrovek 4y ago
that is a very pedantic argument. you completely overlooked the point i was trying to make. vector graphics are not rendered directly to the screen. fonts are rasterized first, then the rasterization is what the GPU receives.
- _gabe_ 4y ago
  > vector graphics are not rendered directly to the screen. What difference does it make if you're caching the rasterization or not? You're still rendering vector graphics. And you're not just rasterizing once. Modern font renderers can't get away with rasterizing glyphs once and reusing them anymore than arbitrary vector graphics renderers can. I sure hope my vector graphics editors cache the rasterizations instead of re-rasterizing needlessly.
  - naikrovek 4y ago
    once, twice, two hundred times, whatever. it's not every frame. that's my point. that you missed twice because you can't see past details to the point of the statement.
- rileyphone 4y ago
  > that is a very pedantic argument. you completely overlooked the point i was trying to make. lmao welcome to HN, if you don't enjoy that experience I don't recommend you try to argue here.
audidude 4y ago
a huge amount of emoji are embedded png in font files. newer ones, however, do require more work. > figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately. this is all done in shaping though, the renderers just see "put this thing there" and (at least in GTK) we just maintain texture atlases that are updated on the fly. you're correct that it doesn't solve the same glyph at lots of scales though. but glyphy does (and at high FPS too).
- kilburn 4y ago
  GTK's implementation of text rendering is is admittedly broken in several subtle ways that nobody seems to know how to properly fix. [1] Also, this is while _not_ supporting fractional scaling, which is something that users definitely want. To be clear, I'm not bashing on GTK. I'm saying that it definitely isn't as simple as the above comment implies ;) [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3787 https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
  - audidude 4y ago
    That issue is literally why I have a branch integrating GLyphy. But yes, your casual drive by comment is definitely more knowledgeable than the people who work on the stuff.

by _gabe_ 4y ago

naikrovek 4y ago

that is a very pedantic argument. you completely overlooked the point i was trying to make. vector graphics are not rendered directly to the screen. fonts are rasterized first, then the rasterization is what the GPU receives.

_gabe_ 4y ago
> vector graphics are not rendered directly to the screen. What difference does it make if you're caching the rasterization or not? You're still rendering vector graphics. And you're not just rasterizing once. Modern font renderers can't get away with rasterizing glyphs once and reusing them anymore than arbitrary vector graphics renderers can. I sure hope my vector graphics editors cache the rasterizations instead of re-rasterizing needlessly.
- naikrovek 4y ago
  once, twice, two hundred times, whatever. it's not every frame. that's my point. that you missed twice because you can't see past details to the point of the statement.
rileyphone 4y ago
> that is a very pedantic argument. you completely overlooked the point i was trying to make. lmao welcome to HN, if you don't enjoy that experience I don't recommend you try to argue here.

audidude 4y ago

a huge amount of emoji are embedded png in font files. newer ones, however, do require more work. > figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately. this is all done in shaping though, the renderers just see "put this thing there" and (at least in GTK) we just maintain texture atlases that are updated on the fly. you're correct that it doesn't solve the same glyph at lots of scales though. but glyphy does (and at high FPS too).

kilburn 4y ago
GTK's implementation of text rendering is is admittedly broken in several subtle ways that nobody seems to know how to properly fix. [1] Also, this is while _not_ supporting fractional scaling, which is something that users definitely want. To be clear, I'm not bashing on GTK. I'm saying that it definitely isn't as simple as the above comment implies ;) [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3787 https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
- audidude 4y ago
  That issue is literally why I have a branch integrating GLyphy. But yes, your casual drive by comment is definitely more knowledgeable than the people who work on the stuff.