State of Text Rendering 2024 • Hacker News Board

Re: State of Text Rendering 2024

#41

Post by moonchild » Tue, Jul 09, 2024, 8:17 AM UTC

Jasper_ wrote: post #37

jordo wrote: post #29

Earlier quoted context omitted.

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.

what exactly do you mean by 'global parse'? it's very usual, i think, when operating on data stored in files, to parse them into in-memory structures before operating on them? but it feels like you are talking about something specific to vector rendering

slug builds acceleration structures ahead of time. the structures are overfit to the algorithm in a way that ttf should be but which is economical for video games. that doesn't seem like an interesting concern and nothing about it is specific to the gpu

Re: State of Text Rendering 2024

#42

Post by vg_head » Tue, Jul 09, 2024, 8:25 AM UTC

moonchild wrote: post #40

vg_head wrote: post #38

Earlier quoted context omitted.

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

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.

Re: State of Text Rendering 2024

#43

Post by larschdk » Tue, Jul 09, 2024, 9:32 AM UTC

KronisLV wrote: post #34

hi_dang_ wrote: 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 fro…

I believe they don't even try to do hinting or sub-pixel rendering, where were key to Windows' crisp font rendering on low resolutions all the way back on Windows XP.

Re: State of Text Rendering 2024

#44

Post by forgotpwd16 » Tue, Jul 09, 2024, 9:48 AM UTC

Lammy wrote: post #14

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 :/

I'm on Firefox and zoom/page up/down work but space doesn't. Also using own font (disabling allow pages choose their own fonts) results in broken page.

Re: State of Text Rendering 2024

#45

Post by forgotpwd16 » Tue, Jul 09, 2024, 9:54 AM UTC

larschdk wrote: post #43

KronisLV wrote: post #34

Earlier quoted context omitted.

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

I believe they don't even try to do hinting or sub-pixel rendering, where were key to Windows' crisp font rendering on low resolutions all the way back on Windows XP.

They don't indeed. Subpixel rendering was removed from macOS few years ago.

Re: State of Text Rendering 2024

#46

Post by SSLy » Tue, Jul 09, 2024, 10:34 AM UTC

slimsag wrote: post #22

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

> doesn't want to introduce a dependency on a Rust compiler

you can link against pre-built .dll/.so/.dylib from your C++ code base.

Re: State of Text Rendering 2024

#47

Post by mhd » Tue, Jul 09, 2024, 12:24 PM UTC

I really have to install an old system with the Infinality patches again, I remember them to be quite excellent, but that was a few years, monitors and contact lense upgrades ago…

Maybe I'll put RiscOS on a Raspberry Pi at the same time, which (IIRC) had one of the first antialiased font rendering engines ever.

(I do have some old Macs running currently, and weirdly enough still prefer some of the old "blurry" font renderings to a lot of modern ones, at least on regular displays)

Re: State of Text Rendering 2024

#48

Post by adrian_b » Tue, Jul 09, 2024, 12:38 PM UTC

behdad wrote: post #12

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…

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

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.

Re: State of Text Rendering 2024

#49

Post by [deleted] » Tue, Jul 09, 2024, 2:25 PM UTC

techn00 wrote: post #30

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

[deleted]

Re: State of Text Rendering 2024

#50

Post by [deleted] » Tue, Jul 09, 2024, 2:26 PM UTC

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.

[deleted]