Text looks trivial until you have to draw it on a GPU. A glyph is not a bitmap; it is a set of closed vector outlines—quadratic or cubic Bézier curves plus straight segments—filled by a winding rule. On a CPU you rasterize once at the target size and you are done. On a GPU you want thousands of glyphs per frame at arbitrary scales, ideally without re-rasterizing anything. That constraint is where every technique makes its trade.
The article opens by explaining that a glyph is a set of closed vector outlines filled by a winding rule, not a bitmap. This diagram illustrates that fundamental concept with on-curve and off-curve points marked.
**1. Texture atlas (bitmap glyphs)** The oldest and still most common approach. Rasterize each glyph once, at one size, into a shared texture atlas, then draw each character as a textured quad. It is fast, trivially portable, and runs on anything with a texture unit. The problems appear the moment you scale: enlarge past the baked size and the glyph blurs; shrink it and stems shimmer or drop unless you bake mip levels. Every crisp size needs another atlas. For Chinese, Japanese, and Korean, with tens of thousands of glyphs, baking several sizes becomes a memory disaster. And a bitmap has no notion of perspective, so text on a 3D surface looks soft.
**2. Signed distance fields (SDF)** Valve’s Chris Green introduced SDF at SIGGRAPH 2007. Instead of pixels, each texel stores the signed distance to the nearest edge (positive inside, negative outside). In the shader you sample the field and threshold at zero. Because distance interpolates smoothly, a small SDF texture scales up dramatically with a clean edge, and cheap antialiasing comes from softening the threshold. For a decade this was the default for crisp UI and HUD text.
But an SDF is still a baked texture at fixed resolution, and it lies about corners. A sharp corner is a discontinuity in the distance field; bilinear interpolation rounds it off. Every hard corner—the point of an "A", the notch of a "K"—gets softened. Push magnification far enough, or make the glyph small enough that the field is only a few texels wide, and thin stems break up and detail smears.
**3. Multi-channel SDF (MSDF)** Viktor Chlumsky’s 2015 thesis and 2018 paper fix the corner problem. Instead of one distance channel, MSDF stores three (red, green, blue), each encoding distance to a different subset of edges chosen so that sharp corners survive. The shader takes the median of the three channels, reconstructing corners almost perfectly. MSDF is the current sweet spot for many teams; Chlumsky’s `msdfgen` is MIT-licensed and widely adopted.
It is still an atlas, though. You bake each glyph at a chosen resolution ahead of time, so dynamic or user-supplied text and enormous glyph sets like CJK still mean baking pipelines and memory budgets. Generation is more expensive than plain SDF. At very small sizes you sample too few texels to hold fine detail; at extreme minification you still fight aliasing. The three-channel lookup costs more bandwidth. MSDF raises the quality ceiling but keeps the atlas constraint.
**4. Tessellation and coverage (Loop–Blinn, NV_path_rendering, Pathfinder, Rive)** This family skips textures entirely and turns the outline into geometry the GPU can rasterize. Loop–Blinn feeds curved triangles to the GPU with a per-pixel discard shader and stencil winding. NV_path_rendering uses a two-pass stencil-then-cover approach. Pathfinder tessellates edges into micro-triangles and accumulates coverage in a compute pass. Rive’s renderer (open-sourced 2024) reduces antialiased vector paths into unique triangle patches and rasterizes them through a massively parallel pipeline with pixel local storage, hitting 120 fps on animated vector art.
These methods are genuinely resolution-independent and, for animated designed vector graphics, often the right answer. The costs are the tessellation itself (redone when geometry changes), geometry blowup for complex glyphs, the difficulty of clean analytic antialiasing, and in some cases dependence on specific hardware features or extensions. Rive in particular only accepts 2D affine transforms; a perspective projection is not affine, so its best approximation is exact at the center and drifts toward the edges.
**5. Slug: rendering straight from the outline** Eric Lengyel published Slug in 2017, patented it in 2019, and dedicated the patent to the public domain on March 17, 2026. Slug skips the atlas and per-frame tessellation. It keeps the glyph as a list of quadratic Bézier curves and line segments in a small GPU buffer, alongside a lightweight per-glyph acceleration structure that partitions the glyph into horizontal bands so a given pixel only considers the handful of curves near it.
Coverage is resolved directly in the fragment shader. For each pixel the shader effectively casts a ray, finds where that ray crosses the nearby Bézier curves, and counts those crossings to compute the winding number and therefore coverage. Lengyel’s key innovation is a *root-eligibility* test: a precise rule for which curve–ray intersections should count, so the winding math is exact at the shared endpoints where curves meet and where naive approaches produce cracks or double-counts. Because the shader solves the curve equations analytically rather than sampling a baked field, it produces exact coverage and clean antialiasing at any scale.
There is no baked resolution, so the same glyph is razor-sharp at 6 pixels or 6,000, and it stays sharp under arbitrary 2D and 3D transforms, including perspective, because coverage is computed per pixel *after* the transform. There is no atlas, so a hundred thousand CJK glyphs cost a font’s worth of outline data, not an atlas the size of a video. Text can change every frame at zero baking cost—exactly what you want for live data, user input, and localized content. And it all happens in a single draw with an ordinary fragment shader, no vendor extension required.
This matters when you cannot predict how the text will be viewed. Atlas, SDF, and MSDF all bake a fixed resolution ahead of time, quietly assuming a bounded range of on-screen sizes and viewing angles. When the relationship between the text plane and the camera is not known in advance—a free 3D camera, arbitrary zoom, close-up, or steep off-axis grazing angle—those baked approximations break down: magnify past the baked resolution and the atlas blurs while SDF and MSDF round and smear; at oblique angles the sampled field aliases. You cannot pre-allocate enough resolution for every possible view without storage exploding. Slug computes coverage analytically, per pixel, after the transform, so it stays exact no matter how close, far, or oblique the viewer gets. Tessellation is the only other family that shares this property, and it pays for it in tessellation cost and harder antialiasing.
**Seeing the difference** AlphaPixel rendered the same capital **R** with their `osgSlug` integration (Slughorn) next to single-channel SDF, MSDF, Rive, and `osgText` bitmap (plus its bitmap-derived SDF). Every texture-based panel got the same budget: 64 texels per em.
The article's 'Seeing the difference' section first describes a face-on comparison at the baked size where five of six renderers are practically identical, with only the bitmap showing its limitations when magnified.
*Face-on at baked size:* five of six are practically identical—Slughorn, Rive, and MSDF reproduce the outline; single-channel SDFs differ only by slightly rounded corners at the foot of the leg. The outlier is the bitmap, magnified ~4×, which cannot recover detail it never stored.
The article explains that under oblique 3D perspective, atlas-based methods blur, SDF/MSDF hold up well, but Rive's affine-only transform causes the glyph to drift toward the edges, while Slug's analytic approach stays exact.
*Tilted into grazing perspective:* Slughorn and the three distance-field panels keep the **R** in place with clean edges, because they compute coverage per pixel inside the glyph’s own plane. The bitmap blurs as it recedes. Rive’s **R** is the wrong shape—its renderer only accepts 2D affine transforms, so a perspective projection drifts toward the edges.
The article describes how at extreme magnification, analytic curve evaluation (Slug, Rive) remains perfectly sharp while sampled distance fields exhibit notching artifacts and bitmaps lose all structure.
*Zoomed in on a single edge at extreme magnification:* only the curve-based renderers (Slughorn and Rive) still produce a straight, clean edge. The distance-field panels notch where interpolating between stored samples no longer matches the true curve. The bitmap has dissolved into a single grey gradient.
**Head-to-head summary**
| Concern | Bitmap atlas | SDF | MSDF | Tessellation / Rive | Slug | |---|---|---|---|---|---| | Sharp at any scale | No | Partly | Mostly | Yes | Yes | | Sharp corners | At bake size | No | Yes | Yes | Yes | | Tiny sizes | Bake per size | Weak | Better | Good | Good | | Memory for CJK | Very high | High | High | Low | Moderate | | Dynamic / changing text | Rebake | Rebake | Rebake | Re-tessellate | Free | | 3D and perspective | Soft | OK | OK | Good | Excellent | | Heavily animated vector art | No | No | No | Excellent (Rive) | Good | | Runs on low-end GPUs | Excellent | Excellent | Good | Varies | Needs capable shader | | Implementation complexity | Low | Low | Medium | High | Medium–high |
**So which one should you use?** There is no single winner—there is a right tool per job.
*Reach for Slug (via Slughorn or another implementation) when* you need text that is crisp at every scale and under 3D and perspective (VR/AR/XR), when you have huge or dynamic glyph sets, when the text changes constantly, or when you are rendering mixed vector UI in 3D scenes.
*Choose MSDF when* you need crisp scalable 2D UI text, can accept an atlas bake pipeline, and want the current best balance of quality, performance, and portability on a wide range of hardware.
*Choose Rive or another tessellation renderer when* your primary workload is animated, designed vector artwork that moves—Rive’s pipeline is built for that.
*Stick with a bitmap atlas or SDF when* you are on constrained/older hardware, your text sizes and viewing angles are bounded and known in advance, or you need the simplest possible integration.
**A note on hinting** Traditional CPU renderers like FreeType adjust curves to snap to the pixel grid at specific sizes (bytecode hinting). Slug’s pitch is that it doesn’t require per-size glyph prep, so its output is effectively unhinted. As monitors have grown denser, major renderers have moved toward auto-hinting (ignoring bytecode and deriving hints from the outline) or no hinting at all. Implementations such as the Zig port *Snail* have added GPU auto-hinting to replicate this behavior, but it remains an open area for Slug adopters.
**Shader effects trade-off** SDF/MSDF make it trivial to add outlines, glows, or softening in a few lines of shader code because the distance value tells you "how far" you are from an edge. Slug’s analytic winding test only tells you "in or out." On very high-resolution displays and large sizes this is a strength—exact coverage without distance-field artifacts—but you lose the cheap distance-based effects and must handle antialiasing separately.
**Slughorn: a production-ready Slug implementation** AlphaPixel’s `slughorn` is a modern C++20 library implementing the public-domain Slug technique. It makes no assumptions about the graphics environment (OpenGL, Vulkan, WebGL, WebGPU, DirectX, Metal) and focuses on simplifying ingestion of vector data from multiple backends—FreeType, NanoSVG, Skia, Cairo, Blend2D—plus a native Canvas-like API. It supports COLRv0/ COLv1 emoji compositing, PBR/IBL materials, gradients, masking, HUD elements, and both 2D orthographic and 3D perspective projection. Companion projects like `osgSlug` assist with OpenSceneGraph/VulkanSceneGraph integration.