Live data from Hacker News

State of Text Rendering 2024

behdad.org

31–40 of 77 posts

Re: State of Text Rendering 2024

#31
post #6

making your article force a tiny, fixed, unchangeable font size seems like a good way to convince people that you should be nowhere near text rendering infrastructure

actually read the very beginning where it's clear why he's using this google doc thingy which the bad text...

Re: State of Text Rendering 2024

#32
post #5

I'm not sure how this gets rendered, but the lack of hinting makes it a strain to read. What irony that an article about progress in text rendering has such awful rendering quality. PS: That is in Firefox. In Chrome it uses what appears to be a bitmap font, which is much worse.

I think the author could've used "Publish to web" instead of preview mode, for a more accessible article view with better font rendering and keyboard control (though it changes image size and breaks right-aligned text).

Re: State of Text Rendering 2024

#33
RustyBuzz is quite limited when compared with HarfBuzz. The Rust fonts scene also seems to lack the necessary momentum to drive things through. I’m not sure whether it’s because the Rust community is mostly interested in webtech or whether Rust itself makes it hard to solve such complex problems. But I don’t see the sands shifting in less than 10 years to come.

Re: State of Text Rendering 2024

#34
post #4

Nice article but sometimes I don’t know what’s worse - the state of linux audio drivers, or the state of linux text rendering. It’s very easy to see when FreeType is used because it just looks off in a few, but significant ways. I’ve used it with and without Harf. DirectWrite has been a joy by comparison.

I never had particular issues with Linux or Windows, but I have to say that I was surprised at how bad my MacBook looks when connected to an external 1080p monitor. I know Apple wants you to buy one of their fancy high resolution monitors or whatever, but it was so odd that one with a 1920x1080 resolution would look so bad. Even toggling the hi-dpi setting in BetterDisplay didn't help much.

Here's a quick picture from a few days ago: https://imgur.com/a/GLohlj1

Re: State of Text Rendering 2024

#36
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…

It's more about the nature of the problem, not that you can't do it in shaders. After all, I think you can do pretty much anything in shaders if you try hard enough.

Even if you already have a GPU renderer for glyphs and any other vector data, you still want to know where to actually position the glyphs. And since this is highly dependent on the text itself and your application state (that lies on the CPU), it would actually be pretty difficult to do it directly on the GPU. The shader that you would want should emit positions, but the code to do that won't be easily ported to the GPU. Working with text is not really what shaders are meant for.

Re: State of Text Rendering 2024

#37
post #29
post #21

Earlier quoted context omitted.

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

Slug preprocesses font curve data into something without the need for the global parse with the .slug file format.

Re: State of Text Rendering 2024

#38

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…

> 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).

Re: State of Text Rendering 2024

#39

RustyBuzz is quite limited when compared with HarfBuzz. The Rust fonts scene also seems to lack the necessary momentum to drive things through. I’m not sure whether it’s because the Rust community is mostly interested in webtech or whether Rust itself makes it hard to solve such complex problems. But I don’t see the sands shifting in less than 10 years to come.

I can't quite see why Rust would make it harder, it's always a breeze compared to working on C++ projects, especially as the project matures. The compiler catches a lot of issues early, which otherwise slow down C++ projects as they accumulate silently, because they should have fixed all warnings, should have used ASan, TSan, MSan, religiously, and should have agreed on a manageable subset of C++, ... but of course didn't.

But I think the power of legacy and a bigger community is not to be underestimated.

Re: State of Text Rendering 2024

#40
post #38

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…

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

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)
Post reply on HN