Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Text Rendering 2024

behdad.org

Post reply on HN
Print view View original

21–30 of 77 posts

Re: State of Text Rendering 2024

#21

Post by Jasper_ »

wokwokwok wrote: post #17
bsder wrote: post #15

Earlier quoted context omitted.

> 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 zill…

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/... ) 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 CP…

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.

Re: State of Text Rendering 2024

#22

Post by slimsag »

> Moreover, the fontations platform, which is the Rust framework Oxidize is producing, will unify font compilation and consumption, reducing the number of places new font-format features need to be implemented from three (FontTools, FreeType, and HarfBuzz) to one (Fontations), which would reduce development cost and overhead.

Will FreeType and HarfBuzz remain supported as C/C++ projects long-term, I wonder? Asking as someone who depends on these and doesn't want to introduce a dependency on a Rust compiler :)

Anecdotally, I notice a lot of game developers avoid FreeType and Harfbuzz entirely, instead opting for much worse text rendering in the form of stb_truetype.h only (Dear Imgui uses this, for example) - which 'is nice because it is a single header C file' but sucks with international languages; many people use SDFs for similar reasons.

I think the proposed move to WASM fonts, if done right, could make it easier to reduce the amount of code people need to render fonts (if the WASM font does the heavy lifting, and a small C program could render it) and alleviate this trend of people not using a good text rendering stack

Re: State of Text Rendering 2024

#23

Post by slimsag »

Jasper_ wrote: post #18
wokwokwok wrote: post #11

Earlier quoted context omitted.

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 ac…

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.

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.

Re: State of Text Rendering 2024

#24

Post by fyrn_ »

wokwokwok wrote: post #11
moonchild wrote: post #10

Earlier quoted context omitted.

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

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 ac…

You have to shape the text even if you render the glyphs with an SDF or MSDF. You're conflating varius things

Re: State of Text Rendering 2024

#25

Post by forrestthewoods »

wokwokwok wrote: post #7

This is a lovely write up, but oh boy... when I see: > Finally, I proposed that the future of font shaping and drawing/ painting will involve a fully-programmable paradigm. > Two tongue-in-cheek mis-uses of the HarfBuzz Wasm shaper appeared recently: the Bad Apple font, and llama.ttf. Check them out! See... the thing about solving problems is that, eventually you realize that any kind of problem can be solved by simp…

I don't disagree. But I have kind of the opposite take.

I can't count how many times I've seen simple code get turned into a hideously complex declarative language that has serious gaps.

Simple UI library code? Turn it into a custom declarative syntax that is now limited!

Simple build system that works and is debuggable? Turn it into a declarative syntax that can't be debugged and can't handle all the edge cases!

And so on and so forth.

I will admit that the idea of a font programming language sounds genuinely awful to me. So I don't really disagree with your premise. But I'm increasingly annoyed with declarative system when vanilla code is often simpler, more flexible, and more powerful (by necessity). :)

Re: State of Text Rendering 2024

#26

Post by khaled »

slimsag wrote: post #23
Jasper_ wrote: post #18

Earlier quoted context omitted.

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.

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…

This is still not rasterization, but a way to modify glyph outlines on the fly. How they are rasterized eventually should be mostly unchanged.

Re: State of Text Rendering 2024

#29

Post by jordo »

Jasper_ wrote: post #21
wokwokwok wrote: post #17

Earlier quoted context omitted.

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/... ) 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 CP…

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 Ha…

https://sluglibrary.com/ - game library used in many engines to do vector graphics and fonts directly on the GPU

Re: State of Text Rendering 2024

#30

Post by techn00 »

To everybody complaining about the awful text rendering, it's literally in the first paragraph

> [It is ironic indeed, that a text about text rendering, is presented in such an inaccessible and badly-typed environment. This is a Google Docs Preview page. I am still yet to find a solution that provides the same features (collaboration, commenting, live edits) and is presented better. Suggestions are appreciated.]

Post reply on HN