Slug HLSL for Vector Font Rendering

What Slug solves in a GPU font pipeline

Slug addresses the problem of rendering vector glyph outlines in a shader-based graphics pipeline. Its scope is narrower than that of a complete text renderer. The repository contains reference implementations of the Slug Algorithm, written primarily in HLSL, rather than font parsing, layout, glyph caching, or an application-level API. A team considering Slug would already need a way to obtain glyph outlines and convert them into the data structures expected by the shaders.

The algorithm is described in the README through its input data rather than through a high-level command-line interface. Glyph contours are represented with quadratic Bézier curves, and the rendering process depends on a curve texture plus a band texture. This makes the repository relevant to engine work, custom user interfaces, graphics experiments, and implementations that need font rasterization to run inside GPU shaders. It does not provide the surrounding text system needed to display a complete document.

Curve and band data layout

The README specifies a concrete texture format for curve coordinates. Each curve texture texel should have four 16-bit floating-point channels containing x1, y1, x2, and y2. For a quadratic Bézier curve, the first two control points are packed into one texel, while the third control point occupies the first two channels of the next texel. Connected curves can share the intervening data because neighboring curves use the same endpoint.

The band texture uses two 16-bit unsigned integer channels. A glyph can contain multiple horizontal and vertical bands. The number of bands should be selected to reduce the maximum number of curves in any one band. Curves are assigned using an epsilon such as 1/1024 in em-space so that bands overlap slightly. Within a horizontal band, curves are sorted by descending maximum x coordinate. Vertical bands use the corresponding descending maximum y coordinate. These rules define the shader's expected input organization rather than leaving texture interpretation to an implementation detail.

Band reuse and ray contributions

Slug's band data can be compressed without changing the documented structure. All bands for one glyph should have the same thickness. Adjacent bands containing the same curve set may point to the same data. A band may also reference a contiguous subset of curves from another band, which the README identifies as an optional optimization intended to reduce data size and improve texture cache performance.

Directional constraints affect which curves belong in each band. Curves that are straight horizontal lines should not be included in horizontal bands, and straight vertical lines should not be included in vertical bands. The README explains that these lines cannot contribute to winding-number calculations for rays parallel to them. Straight segments should be encoded as quadratic Bézier curves by duplicating the second endpoint. A line from p1 to p2 uses control points {p1, p2, p2}. This conversion matters when building data for either shader.

Pixel and vertex shader responsibilities

The repository layout identifies `SlugPixelShader.hlsl` and `SlugVertexShader.hlsl` as the two shader files. The README does not publish a complete integration tutorial or document a public function signature, so the exact entry points, resource bindings, and host-side setup cannot be confirmed from the README. The repository description does establish that these files are reference shader implementations and that the source comments explain their inputs and calculations.

The data flow implied by the README is still specific. Host-side font processing must produce quadratic curves and band assignments, then place them into the curve and band textures. The vertex and pixel shaders consume that prepared data during glyph rendering. Because the repository is a reference implementation, integrators should treat the shader code as the authority for compile-time interfaces and inspect it alongside the README rather than assuming a conventional library initialization process.

Font hinting and pixel-grid alignment

Slug explicitly ignores font hinting. That boundary matters for typography. Hinting commonly adjusts outlines for the rasterizer's target size and pixel grid, while Slug works from curve and band data without applying that process. The algorithm can still align the tops and bottoms of many glyphs vertically by choosing an appropriate font size. The README recommends reading `sCapHeight` from the original font's `OS/2` table and choosing a size for which `font size multiplied by sCapHeight` is an integer.

This approach also depends on display DPI when translating font-space measurements into physical pixel dimensions. Radical Pie is cited by the README as an example of applying this scaling throughout a user interface. The guidance concerns cap-height alignment, not complete hinted rendering. Projects that require per-glyph hinting, precise control over stems, or platform-specific rasterization behavior should not treat Slug as a replacement for a full font rasterizer.

Licence and maintenance constraints

The repository lists a custom licence that GitHub cannot classify, with `LICENSE` as the relevant file. The README says the code may be used for any purpose and that the patent has been dedicated to the public domain. It also requires credit when the code is used in software distributed in any way. This is not equivalent to an unmodified MIT or Apache licence, so an organization should read `LICENSE` and `NOTICE` directly before shipping Slug-derived code. `LICENSE-APACHE` and `LICENSE-MIT` are present at the repository root, but the README does not say that those files replace the custom terms for this code.

The repository is not archived. Its last push was on 2026-04-15, and the repository has no GitHub releases. That means there is no published release history to use for upgrade planning. Integrators should record the shader files they copy and review the root licence files whenever the repository changes.

How to evaluate Slug against a conventional renderer

A practical alternative is a conventional CPU or platform font rasterizer that accepts font outlines, performs hinting, and produces glyph bitmaps or coverage masks through an established graphics or UI API. The difference is architectural. Slug keeps its rendering implementation in HLSL and expects font data to be converted into curve and band textures, while a conventional rasterizer handles outline preparation and rasterization as part of a text-rendering stack. Slug may suit a project that already owns GPU glyph rendering. It is a poor fit when the main requirement is simply loading a font and displaying text.

There is no documented installation package, executable, or host-language binding in the README. The project instead points readers to the shader files, the 2017 paper, and a later blog post for algorithm background. Before writing host-side integration code, check that the chosen font pipeline can emit quadratic Bézier data in the required packing order and can generate the band assignments without violating the directional exclusions.

Editorial conclusion

Slug suits graphics engineers who already understand glyph outlines, quadratic Bézier curves, texture layouts, and shader integration. It is not a standalone font loader, renderer, or hinting implementation. Before adoption, inspect the custom `LICENSE`, verify the shader interfaces, and confirm that the font pipeline can produce the documented curve and band data.

Frequently asked questions

Official sources

1. EricLengyel/Slug on GitHub
2. Issues
3. README