An SDF atlas cannot store a corner
The standard way to draw crisp scalable text on a GPU is to bake a signed distance field into a texture and threshold it. It is a genuinely great technique and it has one specific, unfixable failure, and knowing exactly what that failure is tells you when to reach for something else.
Watch the apex and the interior corners as it zooms in. The sampled version rounds them off and keeps rounding them no matter how close you get, because the sharpness is not in the texture to recover. The exact version stays sharp at any magnification, since there is no resolution in it to run out of.
Why the corner specifically
A distance field near a straight edge is linear, and linear interpolation between samples reconstructs a linear function exactly. That is the whole reason an SDF atlas works so well: straight edges and gentle curves survive sampling essentially perfectly, which is most of most glyphs.
A corner is where the field stops being linear. Distance to a sharp point is a cone, and bilinear interpolation of a cone gives you a rounded cone. The error is proportional to the sample spacing and it does not shrink as you zoom, so it is the one artifact that gets more visible the closer you look.
Which explains the well-known behavior: SDF text looks superb at body sizes and gets subtly mushy at display sizes, and adding texture resolution helps proportionally rather than solving it.
What direct evaluation does instead
Store the outline itself, as the quadratic Bezier curves the font already contains, and determine coverage per pixel from the curves. The usual approach computes a winding number by counting curve crossings along a ray, with a band structure so a pixel only tests the curves that could possibly affect it.
The properties that fall out:
- Resolution independent. There is no baked resolution, so there is nothing to exceed.
- Corners are exact, because the corner is the intersection of two curves rather than a sampled value.
- No atlas to build, pack or invalidate. No glyph budget, no repacking when a language is added, no CJK problem.
- More per-pixel work, and it is data-dependent: a complex glyph costs more than a simple one, which is not a shape most renderers like.
The honest situation with Slug
The best-known implementation of this approach is Eric Lengyel's Slug, and the algorithm is published: GPU-Centered Font Rendering Directly from Glyph Outlines, Journal of Computer Graphics Techniques. The paper is readable and free.
The library is not. As of checking, sluglibrary.com sells single-engineer licenses at $1,500 and describes enterprise terms by negotiation, with no statement anywhere about open sourcing, public domain release, or a lapsed patent. There is a patent on the technique and this page is not the place to guess at its status. If you intend to implement the algorithm rather than license the library, check the patent situation yourself and do not take a blog's word for it, this one included.
That is worth stating plainly because an earlier draft of this page carried a claim that Slug was public domain. Checking the source took two minutes and the claim was wrong.
Choosing between them
- SDF atlas for body text, UI at normal sizes, anything with a fixed glyph set. It is faster, simpler, and the corner rounding is invisible below display sizes.
- Multi-channel SDF as the middle option. Storing three channels lets a corner be reconstructed as the intersection of two edges rather than as a rounded cone, which recovers most of the sharpness for the cost of a wider texture. This is the right answer far more often than either extreme.
- Direct outline evaluation for large display type, extreme zoom, arbitrary glyph sets, or vector art that is not text at all.
- Analytic shapes, which is what the rest of this site is about, whenever the thing being drawn is not from a font. A rounded rectangle does not need any of this machinery.
Rules of thumb
- An SDF atlas stores a sampled field. Straight edges survive sampling exactly; corners cannot.
- The corner error is proportional to sample spacing and does not shrink with zoom, so it is worst exactly where you look closest.
- Try multi-channel SDF before jumping to outline evaluation. It recovers corners for one extra texture channel.
- Direct evaluation is resolution independent and data-dependent in cost. Both halves of that matter.
- The algorithm is published and free to read. The library is commercial, and the patent situation is yours to verify.
One email when something new goes up. No newsletter, no schedule, nothing else.
Double opt-in, so watch for a confirmation email. Unsubscribe any time.