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

11–20 of 77 posts

Re: State of Text Rendering 2024

#11

Post by wokwokwok »

moonchild wrote: post #10
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…

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

Re: State of Text Rendering 2024

#12

Post by behdad »

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…

Hi. As mentioned, I'll expand on my motivations in a future paper. -behdad

Re: State of Text Rendering 2024

#14

Post by Lammy »

heftig wrote: 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.

This page breaks zoom and all scrolling keys (page up/down and space bar) in Firefox too on top of being ugly :/

Re: State of Text Rendering 2024

#15

Post by bsder »

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…

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

Re: State of Text Rendering 2024

#16

Post by School-Cotton »

KerrAvon wrote: 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

The author is actually one of the most prominent and respected people in this space.

Re: State of Text Rendering 2024

#17

Post by wokwokwok »

bsder wrote: post #15
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…

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

Re: State of Text Rendering 2024

#18

Post by Jasper_ »

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…

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.

Post reply on HN