26 ms·

programmable hinting was already a thing. it's just switching to wasm from a bespoke language

wokwokwok 2y ago
It's still just doing exactly what shaders do, which is crazy. Explain to me exactly why, other than 'I guess someone already implemented some kind of basic version of it' that you would have to have custom CPU code rendering glyphs instead of a shader rendering SDF's like literally everyone does with shaders already? It's not a good solution. It's a bad, easy solution. We have a solution for running arbitrary GPU accelerated graphics instructions; it has a cross platform version with webGPU. This font thing... looks a lot like 'not invented here' syndrome to me, as an uninvolved spectator. Why would you chose or want not to use GPU acceleration to render your glyphs? What 'arbitrary code' does a font need to do that couldn't be implemented in a shader? Maybe the horse has already bolted, yes, I understand programmable fonts already exist.. but geez, its incomprehensible to me, at least from what I can see.
- behdad 2y ago
  Hi. As mentioned, I'll expand on my motivations in a future paper. -behdad
  - adrian_b 2y ago
    While this presentation is extremely interesting, it would have been far more useful if you would have exported this view into a downloadable PDF file, instead of giving access to just this ephemeral preview.
- bsder 2y ago
  > CPU code rendering glyphs instead of a shader rendering SDF's 1) Because SDFs suck badly (and don't cover the whole field) when you want to render sharp text. SDFs are fine when used in a game where everything is mapped to textures and is in motion at weird angles. SDFs are not fine in a static document which is rendered precisely in 2D. 2) Because GPUs handle "conditional" anything like crap. GPUs can apply a zillion computations as long as those computations apply to everything. The moment you want some of those computations to only apply to these things GPUs fall over in a heap. Every "if" statement wipes out half your throughput. 3) Because "text rendering" is multiple problems all smashed together. Text rendering is vector graphics--taking outlines and rendering them to a pixmap. Text rendering is shaping--taking text and a font and generating outlines. Text rendering is interactive--taking text and putting a selection or caret on it. None of these things parallelize well except maybe vector rendering.
  - wokwokwok 2y ago
    I feel like, looking at the complexity of the programs that can be implemented in shaders (eg. https://dev.epicgames.com/documentation/en-us/unreal-engine/nanite-virtualized-geometry-in-unreal-engine https://dev.epicgames.com/documentation/en-us/unreal-engine/...) that it's unreasonable, bordering on disingenuous to suggest that the GPU pipeline is not capable enough to handle those workloads, or produce pixel perfect outputs. Be really specific. What exactly is it that you can't do in a shader, that you can do in a CPU based sandbox, better and faster? (There are things, sure, like IO, networking, shared memory but I'm struggling to see why you would want any of them in this context) I'll accept the answer, 'well, maybe you want to render fonts on a toaster with no GPU'; sure... but that having a GPU isn't good enough for you, yeah... nah. I'm not buying that).
    - Jasper_ 2y ago
      Vector graphics are really hard to do on a GPU in an efficient manner. The way the data is stored as individual curve segments makes it difficult to parallelize the coverage problem, it's equivalent to a global parse; the best approaches all do some form of parsing of curve data on the CPU, either rasterizing fully on the GPU, or putting it in a structure the GPU can chew on. But again, this has nothing to do with HarfBuzz or wasm.
      - jordo 2y ago
        https://sluglibrary.com/ https://sluglibrary.com/ - game library used in many engines to do vector graphics and fonts directly on the GPU
        Jasper_ 2y ago
        Slug preprocesses font curve data into something without the need for the global parse with the .slug file format.
        moonchild 2y ago
- Jasper_ 2y ago
  It has nothing to do with shaders? Despite the name, shaping is not the same thing as a shader, shaping selects and places individual glyphs given a collection of code points. No part of the rasterizer or renderer is configurable here. As mentioned above, the rasterizer is already programmable with up to two different bespoke stack bytecode languages, but that has nothing to do with shaping through wasm.
  - slimsag 2y ago
    I agree shaders would be a terrible choice for this. However, the article clearly states there are intentions to move towards much more than just shaping in wasm: > I proposed that the future of font shaping and drawing/ painting will involve a fully-programmable paradigm. > Bad Apple will become much easier and faster when we introduce the draw API in Wasm. > Drawing and painting API will eventually come to HarfBuzz, probably in 2025.
    - khaled 2y ago
      This is still not rasterization, but a way to modify glyph outlines on the fly. How they are rasterized eventually should be mostly unchanged.
- fyrn_ 2y ago
  You have to shape the text even if you render the glyphs with an SDF or MSDF. You're conflating varius things
- vg_head 2y ago
  > Explain to me exactly why, other than 'I guess someone already implemented some kind of basic version of it' that you would have to have custom CPU code rendering glyphs instead of a shader rendering SDF's like literally everyone does with shaders already? Shaping is different compared to rendering glyphs themselves. SDF renderers (and other GPU text renderers like Slug) still do shaping on the CPU, not in shaders. Maybe some experiments have been done in this area, but I doubt anyone shapes text directly in the GPU in practice. Think of it like a function that takes text as input, and returns positions as output. Shaders don't really know anything about text. Sure you could probably implement it if you wanted to, but why would you? I think it would add complexity for no benefit (not even performance).
  - moonchild 2y ago
    lengyel told me he has implemented some sort of hinting on the gpu for slug (i suspect it's not programmable, but didn't ask)
    - vg_head 2y ago
      Very interesting. Honestly I don't know much about hinting, but I suspect the whole shaping stack that Slug supports: > kerning, ligature replacement, combining diacritical mark placement, and character composition. Slug also supports a number of OpenType features that include stylistic alternates, small caps, oldstyle figures, subscripts, superscripts, case-sensitive punctuation, and fractions. Probably still uses the CPU.

It's still just doing exactly what shaders do, which is crazy. Explain to me exactly why, other than 'I guess someone already implemented some kind of basic version of it' that you would have to have custom CPU code rendering glyphs instead of a shader rendering SDF's like literally everyone does with shaders already? It's not a good solution. It's a bad, easy solution. We have a solution for running arbitrary GPU accelerated graphics instructions; it has a cross platform version with webGPU. This font thing... looks a lot like 'not invented here' syndrome to me, as an uninvolved spectator. Why would you chose or want not to use GPU acceleration to render your glyphs? What 'arbitrary code' does a font need to do that couldn't be implemented in a shader? Maybe the horse has already bolted, yes, I understand programmable fonts already exist.. but geez, its incomprehensible to me, at least from what I can see.

behdad 2y ago
Hi. As mentioned, I'll expand on my motivations in a future paper. -behdad
- adrian_b 2y ago
  While this presentation is extremely interesting, it would have been far more useful if you would have exported this view into a downloadable PDF file, instead of giving access to just this ephemeral preview.
bsder 2y ago
> CPU code rendering glyphs instead of a shader rendering SDF's 1) Because SDFs suck badly (and don't cover the whole field) when you want to render sharp text. SDFs are fine when used in a game where everything is mapped to textures and is in motion at weird angles. SDFs are not fine in a static document which is rendered precisely in 2D. 2) Because GPUs handle "conditional" anything like crap. GPUs can apply a zillion computations as long as those computations apply to everything. The moment you want some of those computations to only apply to these things GPUs fall over in a heap. Every "if" statement wipes out half your throughput. 3) Because "text rendering" is multiple problems all smashed together. Text rendering is vector graphics--taking outlines and rendering them to a pixmap. Text rendering is shaping--taking text and a font and generating outlines. Text rendering is interactive--taking text and putting a selection or caret on it. None of these things parallelize well except maybe vector rendering.
- wokwokwok 2y ago
  I feel like, looking at the complexity of the programs that can be implemented in shaders (eg. https://dev.epicgames.com/documentation/en-us/unreal-engine/nanite-virtualized-geometry-in-unreal-engine https://dev.epicgames.com/documentation/en-us/unreal-engine/...) that it's unreasonable, bordering on disingenuous to suggest that the GPU pipeline is not capable enough to handle those workloads, or produce pixel perfect outputs. Be really specific. What exactly is it that you can't do in a shader, that you can do in a CPU based sandbox, better and faster? (There are things, sure, like IO, networking, shared memory but I'm struggling to see why you would want any of them in this context) I'll accept the answer, 'well, maybe you want to render fonts on a toaster with no GPU'; sure... but that having a GPU isn't good enough for you, yeah... nah. I'm not buying that).
  - Jasper_ 2y ago
    Vector graphics are really hard to do on a GPU in an efficient manner. The way the data is stored as individual curve segments makes it difficult to parallelize the coverage problem, it's equivalent to a global parse; the best approaches all do some form of parsing of curve data on the CPU, either rasterizing fully on the GPU, or putting it in a structure the GPU can chew on. But again, this has nothing to do with HarfBuzz or wasm.
    - jordo 2y ago
      https://sluglibrary.com/ https://sluglibrary.com/ - game library used in many engines to do vector graphics and fonts directly on the GPU
      - Jasper_ 2y ago
        Slug preprocesses font curve data into something without the need for the global parse with the .slug file format.
        moonchild 2y ago
Jasper_ 2y ago
It has nothing to do with shaders? Despite the name, shaping is not the same thing as a shader, shaping selects and places individual glyphs given a collection of code points. No part of the rasterizer or renderer is configurable here. As mentioned above, the rasterizer is already programmable with up to two different bespoke stack bytecode languages, but that has nothing to do with shaping through wasm.
- slimsag 2y ago
  I agree shaders would be a terrible choice for this. However, the article clearly states there are intentions to move towards much more than just shaping in wasm: > I proposed that the future of font shaping and drawing/ painting will involve a fully-programmable paradigm. > Bad Apple will become much easier and faster when we introduce the draw API in Wasm. > Drawing and painting API will eventually come to HarfBuzz, probably in 2025.
  - khaled 2y ago
    This is still not rasterization, but a way to modify glyph outlines on the fly. How they are rasterized eventually should be mostly unchanged.
fyrn_ 2y ago
You have to shape the text even if you render the glyphs with an SDF or MSDF. You're conflating varius things
vg_head 2y ago
> Explain to me exactly why, other than 'I guess someone already implemented some kind of basic version of it' that you would have to have custom CPU code rendering glyphs instead of a shader rendering SDF's like literally everyone does with shaders already? Shaping is different compared to rendering glyphs themselves. SDF renderers (and other GPU text renderers like Slug) still do shaping on the CPU, not in shaders. Maybe some experiments have been done in this area, but I doubt anyone shapes text directly in the GPU in practice. Think of it like a function that takes text as input, and returns positions as output. Shaders don't really know anything about text. Sure you could probably implement it if you wanted to, but why would you? I think it would add complexity for no benefit (not even performance).
- moonchild 2y ago
  lengyel told me he has implemented some sort of hinting on the gpu for slug (i suspect it's not programmable, but didn't ask)
  - vg_head 2y ago
    Very interesting. Honestly I don't know much about hinting, but I suspect the whole shaping stack that Slug supports: > kerning, ligature replacement, combining diacritical mark placement, and character composition. Slug also supports a number of OpenType features that include stylistic alternates, small caps, oldstyle figures, subscripts, superscripts, case-sensitive punctuation, and fractions. Probably still uses the CPU.