Your browser rasterizes fonts on the CPU, pixel by pixel, at a specific size. That works for web pages but not for 3D games, where a street sign might be 5 pixels tall in the distance and 500 pixels tall up close. Slug takes a different approach: it sends the font's mathematical curves to the GPU and evaluates them per pixel, in real time. The result is always sharp, at any scale.
Fonts are not pictures of letters. They are mathematical recipes for drawing curves.
A font file stores each letter as a series of quadratic Bezier curves. Each curve has three control points: a start, an end, and a "pull" point that shapes the arc between them.
Drag the control points above to reshape the letter. TrueType fonts use exactly these quadratic curves, and Slug sends them directly to the GPU.
How the GPU decides whether each pixel is part of the letter.
For every pixel, the GPU asks: "Am I inside or outside the letter?" It answers by casting a ray and counting curve crossings.
A horizontal ray is cast from the test point to the right. Each crossing going upward adds 1; going downward subtracts 1. If the total is nonzero, the pixel is inside. This is the nonzero winding rule.
The winding number gives a binary answer: inside or outside. That produces jagged staircase edges. Slug improves on this by computing how much of each pixel is covered by the glyph.
Here is how it works. When the horizontal ray crosses a curve, Slug measures where that crossing lands relative to the pixel. Imagine the pixel as a 1-unit-wide window:
If the crossing is at the pixel's left edge, coverage is 0 (nothing is filled). At the right edge, coverage is 1 (fully filled). In between, coverage ramps linearly. A crossing at the center means the pixel is half-covered, so it gets drawn at 50% opacity.
Slug does this for both a horizontal and a vertical ray, then blends the two coverage values. This produces smooth edges in all directions, not just horizontally.
The result compared to the binary approach:
The letter "R" has 23 curves. Without optimization, every pixel would test all 23 to find ray crossings. But think about a pixel near the bottom of the letter: its horizontal ray can only cross curves that actually exist at that height. Curves up in the bowl of the "R" are irrelevant because they are nowhere near that ray's Y coordinate.
Slug exploits this by dividing the glyph into horizontal bands (slices at different heights). Before rendering, it pre-computes which curves overlap each band. At render time, a pixel looks up its band and gets a short list of candidates instead of all 23. The same logic applies vertically for the vertical ray.
Click on the glyph below to place a pixel. The highlighted curves are the only ones that band needs to check. Everything else is skipped.
This is purely a performance optimization. It doesn't change the result at all. Every curve that could contribute to a pixel's coverage is still tested. Slug just avoids wasting time on curves that mathematically cannot intersect the ray.
The actual Slug algorithm, ported from the reference HLSL shaders to WebGL2 GLSL, running in your browser.
drag to orbit
Both canvases render the same sign in 3D. The camera orbits automatically. The left maps a pre-rendered bitmap texture onto the sign. The right evaluates Bezier curves per-pixel using the Slug shader. Watch what happens as the sign gets close, far, and viewed at oblique angles.
Slug itself is purely 2D. It has no concept of 3D, perspective, or camera angles. The GPU's standard 3D pipeline handles all of that. It transforms the sign's corners into screen space, then interpolates the glyph's 2D coordinates across the surface, automatically adjusting for perspective foreshortening. By the time the Slug shader runs for each pixel, it just sees a 2D coordinate and evaluates curves there, exactly as described in the sections above. The built-in fwidth function tells the shader how much the glyph coordinate changes per screen pixel, which keeps the anti-aliasing correct even at extreme angles.