SDF vs. MSDF vs. Slug: GPU Text Rendering
AlphaPixel releases Slughorn, a C++20 implementation of Eric Lengyel's Slug algorithm for GPU vector rendering, following its recent dedication to the public domain.
summary is enough The article offers a clear technical taxonomy of GPU text rendering, while the comments provide valuable real-world critique and alternative implementations.
summary
The article compares five GPU text rendering techniques—bitmap atlases, SDF, MSDF, tessellation/Rive, and Slug—evaluating them on scaling, performance, and perspective handling. It highlights Slug, which computes coverage analytically in the fragment shader directly from Bezier outlines without atlases or per-frame tessellation. Following the patent's dedication to the public domain, AlphaPixel presents Slughorn, their new C++20 implementation. Commenters debate the trade-offs of Slug versus MSDF, note the absence of text hinting, and discuss alternative curve renderers like Windfoil and Snail.
key points
- Slug renders glyphs directly from quadratic Bezier outlines in the fragment shader using an acceleration structure and analytic root eligibility tests, avoiding atlases and tessellation.
- While texture-based approaches like MSDF struggle or distort under extreme perspective and scale, outline-based methods maintain razor-sharp edges.
- Commenters point out that Slug lacks font hinting support and standard SDF-style effects like built-in drop shadows without extra shader work.
who should read it
Graphics, game, and engine developers looking for high-performance, resolution-independent text and vector rendering solutions.
discussion mixed
consensus
Commenters appreciate the release of the Slug patent to the public domain and find the comparative breakdown useful, though many critique the article's apparent AI-generated prose and overly dismissive claims regarding MSDF.
pushback
Some developers argue that MSDF handles small sizes better and can be dynamically streamed, making Slug unnecessary overhead for standard UI use cases.
This article has some inaccurate information since MSDF atlas doesn't have to be baked statically, so the "CJK character means huge atlas" is not really an issue if you can async upload them to the atlas.（Async outline extraction is a bit harder for C libraries, so that's why the pipeline is mostly restricted to atlas upload).
The other thing is MSDF rendering is fairly cheap and can be done on the CPU quite easily without GPU shaders, the atlas generation/upload is the expensive part, but it's a one-time cost per character per font as the atlas is just a normal bitmap texture file, MSDF …
It counters the article's generalization about MSDF atlas limitations by explaining how async updates solve CJK memory issues without needing Slug.
Generated by an LLM from the article and thread. Check the sources before relying on it.