Volume 05
Rendering Text at Scale
The engine layer underneath all of it. Putting a few hundred buildings on screen is a solved problem; putting tens of thousands of legible glyphs on screen, at sixty frames a second, in a browser, is the actual hard part — and it's the part that historically broke the would-be members of Volume 01. Here's the toolbox, and where it's been pointed.
This volume is about how you draw the text, not what you draw it for. Most of these have never been aimed at a codebase — which is itself worth knowing.
The city tradition reached for buildings in part because rendering a repo's worth of readable text was considered out of reach. So for anything that renders the text instead, the rendering technique is load-bearing rather than an implementation detail. This volume is a tour of that layer: the signed-distance-field lineage, the GPU-bezier lineage, what Three.js does and doesn't do with text out of the box, the production code editors that prove GPU text works at editor scale, and the shaping layer that turns Unicode into glyph positions.
The signed-distance-field lineage
The dominant trick for "sharp text at any zoom without a glyph-per-pixel atlas": store the font as a distance field, sample it in the fragment shader, threshold for the edge. Cheap, scales beautifully, and the foundation of most GPU text on the web.
Valve — "Improved Alpha-Tested Magnification for Vector Textures and Special Effects" the origin paper
Chris Green · Valve · SIGGRAPH 2007 course · the paper that put SDF text in every game engine
The eight-page note that started it. Encode a glyph (or any vector shape) as a low-res signed distance field, and a single texture lookup plus a threshold gives you a crisp edge at any magnification — with a few extra lines you get outlines, glows, soft shadows. Half-Life 2's UI shipped on it; Unity, Unreal, and basically every "TextMeshPro"-style system descend from it. If you've ever wondered why game text stays sharp when you walk up to a sign, this is why.
GLyphy alive-ish
Behdad Esfahbod · SDF-on-the-GPU using arc-spline approximations rather than a sampled texture · influential; not heavily maintained
A clever variant: instead of baking the distance field into a texture, approximate each glyph's outline with circular arcs and compute the distance analytically in the shader — so it's resolution-independent with no atlas at all. From the author of HarfBuzz, which tells you something about the company this lineage keeps.
github.com/behdad/glyphy
MSDF — Chlumský's multi-channel SDF alive · the workhorse
Viktor Chlumský · msdfgen · msdf-atlas-gen · msdf-bmfont · the de facto standard for crisp SDF text with sharp corners
Plain SDFs round off sharp corners (the distance field can't represent them). Chlumský's fix — pack distance information into three color channels and reconstruct the median in the shader — keeps corners crisp at any size, and the msdfgen / msdf-atlas-gen tooling around it is what most modern GPU text pipelines actually use, including Makepad's code editor. The awesome-msdf list is the map of who's built on it.
github.com/Chlumsky/msdfgen · msdf-atlas-gen
The GPU-bezier lineage — render the curves directly
The other school: don't approximate the glyph as a distance field at all — feed the actual Bézier outlines to the GPU and compute coverage per pixel. Sharper, heavier, and the home of one piece of very recent news.
Will Dobbie — "GPU text rendering with vector textures" the key blog post
Will Dobbie · 2016 · the most-cited practical writeup of resolution-independent GPU glyph rendering
The blog post everyone in this corner has read: store a glyph's curves in a small texture, and in the fragment shader walk the curves crossing the current scanline to compute exact coverage — pixel-perfect at any zoom, no atlas regeneration. The direct intellectual precursor to the commercial bezier renderers below.
wdobbie.com — GPU text rendering with vector textures
Slug alive — and as of March 2026, public domain
Eric Lengyel · Terathon Software · i3D 2018 paper · patent released into the public domain, March 17, 2026
The most refined commercial implementation of "render the actual Bézier curves on the GPU" — crisp text at any scale, any rotation, any perspective, with proper anti-aliasing, in a single pass. Its client list is games (Activision, id), CAD, planetariums, video editors. What it has conspicuously never been pointed at: codebase-scale code rendering.
And the recent news that makes it newly relevant: in March 2026 Lengyel released the underlying patent into the public domain, and there's already a WebGPU port (slug-webgpu) and an open CPU+GPU reference implementation (Sluggish). For a project with a experiment/webgpu branch and a HarfBuzz-shaping pipeline, that timing is hard to ignore — the highest-quality glyph-curve technique just became free, in the same year, on the same API.
sluglibrary.com · "A Decade of Slug" — the public-domain announcement · i3D 2018 paper
Pathfinder · Vello / piet-gpu mixed
Patrick Walton (Pathfinder, Mozilla) · Raph Levien & the Linebender group (Vello, formerly piet-gpu) · Pathfinder dormant; Vello active
The "general GPU 2D renderer that happens to do text really well" branch. Pathfinder was Mozilla's GPU font/vector rasterizer (influential, now largely superseded). Vello is the active successor in spirit — a compute-shader-based 2D renderer (paths, gradients, text) targeting wgpu, i.e. WebGPU. If glyph3d-js ever wants "arbitrary 2D vector content, not just glyphs, composited at scale," this is the lineage to watch.
Text in Three.js / WebGL — and why the standard libraries fall over
The popular Three.js text libraries are built for "some labels in a scene," not "a codebase's worth of glyphs," and they break in instructive ways.
troika-three-text renders text alive — but it chokes around 500 instances
ProtectWise (now community-maintained) · SDF text for Three.js; SDFs generated on-demand in a Web Worker, fonts parsed via Typr, patches any Three.js material · the most-used Three.js text library
Excellent for what it's for — a few dozen, a few hundred labels — and the standard answer when someone asks "how do I put text in Three.js." But the open issue #117 — "Performance issue when rendering many Text instances" is the tell: each Text is its own mesh, its own draw call, and the whole thing grinds to a halt somewhere around 500 of them. That ceiling is precisely why a repo-scale text renderer can't just be "a lot of troika texts" — it has to be a different architecture: one draw call across all the glyphs, which is the approach glyph3d-js takes. The fork countertype/three-text adds WebGPU and p5 adapters but doesn't change the per-Text-mesh model.
three-mesh-ui renders text VR-oriented dormant-ish
Félix Mariotto · flexbox-style text panels for Three.js, built for VR UI · widely used in WebXR projects
The go-to for "menus and labels in a VR scene" — boxes, wrapping text, layout. Same structural limit as troika here: it's a UI-panel library, not a corpus renderer; there's no "render a whole repo" mode and the per-block model wouldn't scale to one. Listed so the Three.js text landscape is complete.
Instanced Rendering of Parameterized 3D Glyphs with three.js the technique paper
Limberger et al. · HPI / FH Potsdam · Web3D 2024 · tested up to ~50,000 glyphs with a large frame-rate gain over per-mesh approaches
Not about code — about data-visualization glyphs — but it's the published version of exactly the move glyph3d-js makes: instead of N meshes, one InstancedBufferGeometry with per-instance attributes, so the whole field is one draw call. The paper measuring "50,000 glyphs, fine; per-mesh, dead at a fraction of that" is the academic backing for "yes, the instanced approach is the one that scales, and the standard libraries don't do it."
ACM DL — Web3D 2024
GPU-rendered code editors — proof points at editor scale
These don't render multiple files spatially, so they aren't direct precedents for whole-repo work. But they're the production-grade evidence that "GPU-render the text yourself, don't lean on the DOM or a UI toolkit" is a real, shipping engineering choice — and they're where the techniques above show up in production.
Zed / GPUI renders text alive
Zed Industries (the former Atom team) · custom GPUI framework; text, cursors, syntax all rendered directly on the GPU · handles million-line files at native refresh
The clearest case of "GPU-render the text because latency matters" in a real product. Zed's GPUI draws the entire editor surface — glyphs, selections, decorations — as GPU primitives, which is how it stays smooth on files that make DOM-based editors stutter. The reference point for what serious GPU text rendering looks like when correctness and latency both matter.
github.com/zed-industries/zed
Makepad renders text alive
Rik Arends, Eddy Bruël et al. · Rust, live-editable UI framework; makepad-code-editor crate renders with MSDF · online editor demo includes an alt-click minimap zoom
A from-scratch Rust UI framework with a code editor built on MSDF text, and a talk — "Building a Code Editor from Scratch in Makepad" (Eddy Bruël, July 2023) — that walks the whole rendering stack. Also the source of the "Sublime minimap, but you can actually navigate into it" interaction that keeps coming up as a UX touchstone. If you want to see MSDF text doing real editor work, this is it.
github.com/makepad/makepad · "Building a Code Editor from Scratch in Makepad"
Lapce · Glamorous Toolkit (Bloc/Sparta) renders text alive
Lapce (Floem-based, Rust) · Glamorous Toolkit (Pharo + Rust; the Sparta canvas → Bloc scene graph) · two more "build the rendering stack yourself" data points
Lapce is another Rust editor that renders its own text rather than leaning on a widget toolkit. Glamorous Toolkit's rendering tree (Sparta does the drawing, Bloc is the scene graph, Brick the widgets) is the Smalltalk-side equivalent — and notably, the GToolkit text editor was rebuilt in Bloc specifically to carry attribute spans and live inline previews. Different ecosystems, same conclusion: if you want rich, fast, programmable text, you end up owning the renderer. (More on GToolkit's analysis side in Volume 03.)
The layer that isn't rendering: shaping & layout
HarfBuzz · cosmic-text · swash · fontdue alive
the "Unicode → glyph IDs → positions" layer that has to happen before any of the above can draw anything
Worth a line because it's easy to forget the rendering technique is only half the stack. HarfBuzz is the universal text-shaping engine — it turns a string plus a font into the sequence of glyphs and their positions, handling ligatures, kerning, complex scripts. (glyph3d-js uses it for shaping.) In Rust-land, cosmic-text (shaping + layout, used by a lot of Rust GUIs), swash (shaping + scaling), and fontdue (fast rasterization) cover the same ground. If a code-rendering project ever needs to handle non-Latin source, comments in CJK, or fancy typographic features, this is where that work lives — independent of whether the glyphs end up drawn via SDF, MSDF, Bézier, or a plain atlas.
The deep cuts
PABR — Linux kernel in 3D 3D historical (2002, predates WebGL)
pabr.org · circa 2002 · the Linux kernel's source tree as a 3D dependency graph — boxes and lines, no text
The closest thing to a "torvalds/linux at scale, in 3D" precedent — from 2002, a Java applet's worth of boxes-and-lines, not a glyph of source in it. The historical marker that people have wanted to see the whole kernel spatially for over twenty years; what's been unattempted is rendering it as readable code rather than a wireframe of file nodes, which is the target of glyph3d-js's streaming-load work.
pabr.org/kernel3d
The Sublime / VS Code minimap — and the DOM-editor contrast renders text (tiny) 2D alive (everywhere)
Sublime Text's minimap, copied into VS Code, Atom, and basically every editor since
The UX ancestor worth naming: the minimap proved that a shrunk rendering of the actual text — not an abstraction, the real lines — is a navigable overview people use constantly. It's per-file, not per-repo, but "scale it up to the whole codebase" is the obvious extrapolation, and one almost nobody has made — largely because the standard way to render code on the web is the DOM (CodeMirror, Monaco, Ace), and the DOM falls over long before "the whole repo, visible at once." DOM-text doesn't scale, GPU-text does, and very little code on the web is rendered with GPU-text — which is most of why the "renders text at repo scale" column in this survey is so short.
Where this volume lands. The techniques to render a codebase's worth of legible text at sixty frames a second exist and are well-understood — SDF (Valve, Glyphy), MSDF (Chlumský), GPU-Bézier (Dobbie, Slug, Vello), GPU-instanced glyph fields (Web3D 2024). What's rare is combining them for that purpose: the Three.js text libraries are built for labels and stall at hundreds of instances; the GPU code editors render one file well but don't go spatial; Slug and the bezier crowd render games and CAD; HarfBuzz shapes for everyone but draws for no one in particular. glyph3d-js uses the instanced-glyph approach — one draw call across the whole repo, atlas-backed, browser-deliverable — i.e. the proven technique pointed at a target it hasn't been before. Slug entering the public domain in 2026, with a WebGPU port already, is an opening for the next iteration.
→ Volume 06: the synthesis — where glyph3d-js falls on this map, and the company in that neighbourhood.
Continue → 06 · Where glyph3d-js Sits