Slug patent now public domain: GPU text rendering methods compared

The authors of Slughorn, a C++20 implementation of the Slug technique, have published a guide to choosing a GPU text rendering algorithm. The occasion is that Eric Lengyel, who published Slug in 2017 and patented it in 2019, dedicated that patent to the public domain on March 17, 2026. The authors say this is why they built Slughorn and why they can now discuss how Slug works.

The problem: a glyph is not a bitmap but a set of closed outlines made of straight lines and Bezier curves (quadratic in TrueType, cubic in OpenType with CFF), filled by a rule such as nonzero winding. A CPU rasterizes each glyph once at its target size. A GPU has to draw thousands of glyphs per frame, at arbitrary scales and 3D transforms, while text may change every frame. Most engines bake glyphs into textures and accept the compromises.

The article walks through five methods.

Texture atlas. Each glyph is rasterized once at one size into a shared texture and drawn as a textured quad. It is fast and portable, but it blurs or blocks when enlarged, shimmers and drops stems when shrunk unless mip levels are baked, needs a separate atlas per crisp size, is a memory problem for CJK (tens of thousands of glyphs), and looks soft when laid onto a 3D surface.
Signed distance fields (SDF). Based on Chris Green's 2007 SIGGRAPH work at Valve, each texel stores the distance to the nearest edge, and the shader thresholds at zero. One small texture scales up cleanly with cheap antialiasing, and it is still the default on constrained hardware. But a sharp corner is a discontinuity in the field and bilinear interpolation rounds it off, so points like the tip of an "A" soften; at high magnification or tiny field sizes, thin stems break up.
Multi-channel SDF (MSDF). From Viktor Chlumsky's 2015 thesis and 2018 paper, MSDF stores three distance channels (red, green, blue) for different subsets of edges, and the shader takes the median, which keeps corners sharp. Chlumsky's msdfgen is MIT licensed and widely adopted. The authors call it the current sweet spot for many teams. It is still an atlas: dynamic or user-supplied text and CJK still need baking pipelines and memory budgets, generation costs more than plain SDF, very small sizes and extreme minification still cause trouble, and three channels cost more bandwidth than one.
Tessellation and coverage. This family turns outlines into geometry. Loop-Blinn uses curved triangles, a discard shader and the stencil buffer, but reliable antialiasing is hard. Stencil-then-cover, exposed as NVIDIA's NV_path_rendering, is high quality but relies on vendor extensions. Pathfinder tessellates edges into microtriangles and accumulates coverage in a compute pass. Rive's renderer, open-sourced in 2024, reduces antialiased paths to unique triangle patches rasterized with pixel local storage, and is credited with 120 fps on animated vector art. The authors say this family is resolution independent and often right for animated vector graphics, with costs in re-tessellating when geometry changes, geometry blowup for complex glyphs, hard analytic antialiasing, and sometimes dependence on specific hardware features.
Slug. It keeps each glyph as quadratic Bezier curves and line segments in a small GPU buffer, plus a per-glyph acceleration structure that splits the glyph into horizontal bands so a pixel only considers nearby curves. In the fragment shader, each pixel effectively casts a ray, finds crossings with nearby curves, and counts them to get the winding number and coverage. Lengyel's key trick, called root eligibility, is a rule for which curve-ray intersections count, so winding is exact where curves share endpoints and naive methods produce cracks or double-counts. Because it solves the curve equations analytically, the authors say coverage is exact at any scale: the same glyph is sharp at 6 pixels or 6000, under 2D and 3D transforms including perspective. There is no atlas, so a hundred thousand CJK glyphs cost a font's worth of outline data; text can change every frame with no baking cost; and it runs in a single draw with an ordinary fragment shader, no vendor extension. The authors argue it matters most when the viewing geometry is unpredictable (free 3D camera, arbitrary zoom, grazing angles), and recommend Slughorn for interactive 3D, AR and VR, flythroughs, moving HUDs, and CAD or digital-twin navigation. Tessellation is the only other family they say shares this exactness, at the price of tessellation cost and harder antialiasing.

The visual test. The authors rendered a capital R with Slughorn (through their osgSlug integration), a single-channel SDF, an MSDF, Rive's renderer, and osgText's bitmap along with its bitmap-derived SDF. Every texture-based panel got the same budget of 64 texels per em. Straight on at baked size, five of the six panels are practically identical: Slughorn, Rive and MSDF reproduce the outline, and the single-channel SDFs differ only by slightly rounded corners at the foot of the leg. The outlier is the osgText bitmap, a 64 px/em image magnified about four times. In grazing perspective, Slughorn and the three distance-field panels keep clean edges because coverage is computed per pixel in the glyph's own plane, while the osgText bitmap blurs as it recedes and Rive's R comes out the wrong shape: its renderer accepts only 2D affine transforms, so under perspective it can only approximate, exact at the center and drifting toward the edges. In the extreme zoom test, only the curve-based renderers, Slughorn and Rive, still give a straight, clean edge (Rive by re-tessellating every frame for this view), while the distance-field panels notch.

Key facts

Eric Lengyel published the Slug GPU text algorithm in 2017, patented it in 2019, and dedicated the patent to the public domain on March 17, 2026.
Slug computes glyph coverage per pixel in the fragment shader from Bezier outlines, with no texture atlas and no per-frame tessellation; the authors say it stays sharp at 6 pixels or 6000 and under perspective.
SDF rounds sharp corners; MSDF (three distance channels, median in the shader) keeps them but is still an atlas, so dynamic text and CJK still need baking.
In the authors' capital R test with 64 texels per em for texture-based panels, five of six renderers look practically identical straight on; under perspective Rive's R is the wrong shape because it accepts only 2D affine transforms.
The comparison comes from the Slughorn developers, who recommend Slughorn for interactive 3D, AR/VR, moving HUDs and CAD or digital-twin navigation.

Why it matters

Drawing text crisply on a GPU at any size and under any 3D transform has long been handled by baking glyphs into textures and living with the compromises. The authors present Slug as a technique that skips that trade by rendering from outlines, and its patent is now dedicated to the public domain, which is what prompted their Slughorn implementation and this write-up. The article is mainly useful as a map of the options: where atlas, SDF, MSDF, tessellation and Slug each win and lose. It is graphics engineering rather than AI news.

Who it affects

Developers of game engines, UI toolkits and real-time graphics applications who have to choose a text rendering path. The authors point to interactive 3D, AR and VR, flythroughs, moving HUDs, and CAD or digital-twin navigation as the cases where the viewing distance and angle cannot be known in advance. Teams with constrained hardware, fixed-size UI text, or animated designed vector art may land elsewhere: SDF remains the default on constrained hardware, MSDF is called the current sweet spot for many teams, and Rive is described as built for artwork that moves.

How to use it

The article is a selection guide. If you need crisp scalable text and can bake an atlas, the authors call MSDF an excellent choice, and msdfgen is MIT licensed. If the text plane and camera relationship is unknown in advance, or text changes every frame, or glyph sets are huge (CJK), they point to Slug, which runs in a single draw with an ordinary fragment shader and no vendor extension. Their own implementation is Slughorn, a C++20 implementation of the Slug technique, with an osgSlug integration. Licence and availability terms for Slughorn are not stated in the article text provided.

How solid is it

The explanations of each method are standard and attributed to published work (Green 2007, Chlumsky 2015 and 2018, Lengyel 2017). The comparison itself is from the developers of Slughorn, an interested party, and no independent test is cited. The evidence is a visual test of one letter, a capital R, with texture-based panels held to 64 texels per em. No performance numbers such as frame times or GPU cost are given for Slug or Slughorn in the text provided, so claims of speed or cost relative to other methods are not quantified here.

Risks and caveats

The authors themselves list tradeoffs for the other methods, but the text provided gives no costs for Slug itself, so the case for it rests on quality arguments rather than measured performance. Rive's poor showing in the perspective test reflects its 2D affine transform limit; the authors frame Rive as well suited to animated vector art, which this test does not cover. The text does not say what the patent dedication means for other implementations beyond explaining why Slughorn was built. Treat the recommendation of Slughorn as coming from its makers.

“MSDF raises the ceiling on quality, but it still uses an atlas.”

— Slughorn developers, in the article