Content aside, I've got to give Mr. acko.net credit for that header. It's been there for, what, almost twenty years now? And yet it somehow still feels really fun and cool and not particularly dated, which is something that cannot be said for more mid-00s web art kinds of stuff!
It's a very nicely-done blog, having looked at some of the other articles in more detail. But I wish I'd stuck to the technical entries and steered clear of the political ones. "Who doesn't go Nazi?" turns a pleasant rabbit hole into an intellectual Superfund site.
It wasn't obvious to me what this was about from the title but it's very relevant to my interests:
> In this post I will describe Use.GPU's text rendering, which uses a bespoke approach to Signed Distance Fields (SDFs). This was borne out of necessity: while SDF text is pretty common on GPUs, some of the established practice on generating SDFs from masks is incorrect, and some libraries get it right only by accident. So this will be a deep dive from first principles, about the nuances of subpixels.
Super big fan of SDF text rendering and their ability to get effects like soft-shadows and hard bevels, essentially for free by baking Multi Channel and Single SDFs into one RGBA texture.[1] was surprised to see emojis work without being decomposed into separate parts, albeit the colors losing their sharpness above the texture's 1:1 resolution.
Maybe if GTK4 is so bent on GPU rendering and all about edge cases like slightly rotated text, it should be using this technique so that fonts are not blurry shite by default?
Having worked with GTK4's renderer and glyph cache a bit, the reason that GTK4 has blurry text is that some text is positioned at non-integer Y coordinates (unsure if a bug or not), and text isn't grid-snapped vertically while rendering (even when hinting is on, which is useless unless grid-snapping is enabled). For some reason they're considering disabling subpixel horizontal positioning as well as vertical on non-HiDPI displays (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190).
Jump flood is multi-pass and approximate not exact. I wouldn’t assume it’s faster for small input images, which is what the article is aiming for.
Also the distance transform algorithm in the article could be implemented on a GPU using a thread per row & column rather than per pixel. (At least in CUDA - I’m not immediately certain how to do it in GLSL but I guess someone could do it.) This is not optimal, of course, but parallelizing rows is perhaps a lot better than a single-threaded loop over the image.
I'm sure the animated rendered background is there to drive the following point home: "if you're reading this on a device that can't keep up then this is not for you"
I believe that Daniel Huttenlocher and Pedro Felzenszwalb should be credited for the multi-pass (first X, then Y) transform based on quadratic distance:
That second paper from 1996 references an even older paper from 94, saying “Dividing rows and columns alternately, Chen and Chuang reduced the time complexity to O(N^2) which is optimal.”
Distance to a Bezier curve is an interesting one. For an n-degree Bezier it's easy to turn it into a problem to find a root for a 2n-1 degree polynomial, but that means anything for n>2 is going to be tricky to do in closed form. A few iterations of Newton's method with a good initial guess could go quite far though.
Yes, tricky, a.k.a. impossible. ;) There is a neat closed-form solution for the n=2 quadratic Bezier floating around on ShaderToy, based on the trig solution of the cubic equation [1] and I’m fascinated by the link between cubics and circles [2]
I did some experiments with shaders to stroke bezier curves many years ago, and iirc, the easiest (reasonably efficient) route I found if you have a cubic spline is to fit a quadratic spline to it first, then just transform and solve it as distance to a parabola.
The FreeType library can generate SDFs from TrueType fonts. I am not sure whether it uses the Bezier curves directly though, or first renders to a bitmap.
I've only glanced at slug but it looks far too heavyweight for the 'just render this bitmap of a glyph but with sharp edges' use case that SDF attempts to fulfil; especially since browsers are already excellent text rendering engines.
