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
State of Text Rendering 2024
31–40 of 77 posts
Re: State of Text Rendering 2024
#32I'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.
Re: State of Text Rendering 2024
#33Re: State of Text Rendering 2024
#34Nice 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.
Here's a quick picture from a few days ago: https://imgur.com/a/GLohlj1
Re: State of Text Rendering 2024
#35Re: State of Text Rendering 2024
#36Earlier 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…
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
#37Earlier 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
Re: State of Text Rendering 2024
#38Earlier 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…
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
#39RustyBuzz 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.
But I think the power of legacy and a bigger community is not to be underestimated.
Re: State of Text Rendering 2024
#40Earlier 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.…