# glyphon: 2D text rendering for wgpu in Rust

> glyphon is a Rust crate that renders 2D text on wgpu by shaping and rasterising glyphs with cosmic-text, packing them into a texture atlas with etagere, and sampling that atlas inside an existing render pass. It is a small, single-purpose library rather than a text engine.

**grovesNL/glyphon** — 🦅🦁 Fast, simple 2D text renderer for wgpu

- Repository: https://github.com/grovesNL/glyphon
- Stars: 771 · Forks: 118
- Language: Rust
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/grovesnl-glyphon

## What glyphon does in three steps

The README describes the crate as a simple way to render 2D text with wgpu, and the three bullets give the whole pipeline. It shapes and calculates layout and rasterises glyphs with cosmic-text. It packs the glyphs into a texture atlas with etagere. And it samples from that texture atlas to render text with wgpu.

That division of labour is the design. cosmic-text is a text shaping and layout library that handles the hard part, working out where a glyph goes in a shaped run of text, including the script-specific rules that make Arabic, Indic and complex scripts render at all. etagere is a texture packing library, so the atlas is filled without wasted space. wgpu does the drawing. glyphon itself is the assembly plus the plumbing that keeps the atlas in sync with the glyphs it has seen.

The fourth point in the README is about efficiency rather than features. To avoid extra render passes, rendering uses existing render passes, following the middleware pattern described in the wgpu Encapsulating Graphics Work wiki page. So glyphon draws text during a pass you already have rather than scheduling its own, which matters on a GPU-bound application where an extra pass per frame is not free.

The scope is narrow on purpose. There is no document model, no paragraph layout and no text editing here. It renders a line of text into a scene you are already drawing.

## The dependency set and what each crate is for

The manifest is small and every dependency earns its place.

```toml
wgpu = { version = "30.0.0", default-features = false, features = ["wgsl"] }
etagere = "0.3.0"
cosmic-text = "0.19"
lru = { version = "0.16.2", default-features = false }
rustc-hash = "2.1.1"
```

The wgpu dependency is declared with default features turned off and only the wgsl feature enabled, which is the interesting choice in the list. A text renderer does not need the full wgpu surface area, and trimming the feature set keeps compile times down and the dependency surface small.

The LRU cache and the hash crate are the memory management layer. An atlas has to hold previously rasterised glyphs so that a repeated character does not have to be shaped and rasterised again, and a bounded cache with a fast hasher is how you keep that from growing without limit as a user scrolls through arbitrary text.

The dev dependencies tell you what the examples and benchmarks are built on. winit 0.30.12 for a window, pollster 0.4.0 to block on async GPU work, resvg 0.45.1 for rendering SVG assets, and criterion 0.8.1 with html_reports for the benchmark harness. The bench target is declared with a custom harness.

```toml
[[bench]]
name = "prepare"
harness = false
```

The bench is named prepare, which suggests it measures the preparation step, the shaping and atlas work, separately from the drawing.

## The examples and what they cover

The examples directory is where the crate is easiest to judge, and the file names say what each one does.

hello-world.rs is the obvious starting point, and text-sizes.rs exercises the same rendering across a range of font sizes, which is where atlas packing and scaling behaviour show up. custom-glyphs.rs is the interesting one, because it covers the case where the text is not plain characters, which is where shaping and rasterisation get involved rather than just measuring a string.

There are two SVG files, eagle.svg and lion.svg, which look like the graphics that get rasterised into the atlas, and two text files, ligature.txt and mono.txt, which read as inputs for the custom glyph and the monospace case respectively. A font file, Inter-Bold.ttf, sits alongside them, so the examples render with a real typeface.

The samples/ directory at the top level is separate from examples/ and appears to hold a fuller application rather than focused demonstrations. The repository also carries benches/ for the criterion measurements.

Together, the layout suggests a crate that treats the examples as the specification: each file isolates one capability, and a reader can pick the one that matches the problem in front of them instead of reading a long API tour.

## Where glyphon is the wrong choice

The first limitation is the version coupling. The crate pins wgpu to the 30.0.0 line, and wgpu's API changes between major versions. If your application is on a different wgpu major, glyphon does not drop in, and the version skew inside the project itself shows how fast the ecosystem moves. The manifest says version 0.12.0 while the published release history in the repository shows 0.9.0 from April 2025 as the most recent tag, and 0.8.0 and 0.7.0 before it, so the manifest version and the tagged release are not the same thing, and a reader pinning a version has to know which one they are getting.

The second is that the crate is a glyph renderer, not a text engine. There is no paragraph layout, no wrapping policy, no rich text, no inline images and no editing model. If the requirement is a document viewer, a chat bubble that reflows, or an application with a cursor, this is a building block at the wrong level.

The third is the wgpu commitment. The crate is deliberately narrow, and that narrowness cuts both ways. The payoff is a small dependency set with only the wgsl feature enabled, and the cost is that it does nothing outside wgpu, so a project on Vulkan directly, on Metal directly, or on a different GPU abstraction has no path in.

The fourth is the unknown maintenance picture. The repository's last push was on 2026-07-09 and the most recent tag is from April 2025, and the README does not state a development status. The README is a short document with a what-is-this, a licence section and a contribution note, and it does not describe a roadmap, so there is no stated plan to judge against.

The fifth is that the benchmarks are in the tree but no results are quoted, so the word fast in the project description is not backed by a published figure in the README.

## Licence, versioning and the cost of adding it

The README states the licence as a choice of three, the Apache License Version 2.0, the zlib Licence or the MIT Licence, at your option, and the manifest expresses it as a single OR expression.

```toml
license = "MIT OR Apache-2.0 OR Zlib"
```

That matters more than usual for a rendering crate, because the code it links against is not uniformly permissive. cosmic-text, etagere and wgpu each carry their own terms, and a project with a policy about licences in its dependency tree needs to check the full set rather than just this crate. The contribution note is explicit that any contribution is triple licensed the same way, with no additional terms, so the option set stays stable for adopters.

The three licence files, LICENSE-APACHE, LICENSE-MIT and LICENSE-ZLIB, are all present at the top level, and GitHub shows the licence field as unknown, which is a classification artefact rather than a statement about the terms.

The cost of adding glyphon is the dependency set. cosmic-text in particular pulls in font parsing, shaping and layout machinery, which is a substantial dependency for a project that only wants to draw a HUD label. The cache configuration and the atlas sizing are the two things to look at first if memory becomes a concern, since a text atlas that is allowed to grow without a bound is the failure mode that a 2D renderer is prone to.

## Conclusion

glyphon suits a Rust developer already rendering with wgpu who needs labels, HUD text or a debug overlay and does not want to write a text stack, since the shaping, atlas packing and sampling pipeline is already assembled. It does not suit a project that needs document layout, because it is a glyph renderer and not a typesetting engine. Verify the wgpu version you are on first, since the crate pins the 30.0.0 line, and note the version skew between the published release and the manifest.

## FAQ

### What is glyphon and how does it render text?

It is a Rust crate for 2D text on wgpu. It shapes, lays out and rasterises glyphs with cosmic-text, packs them into a texture atlas with etagere, and samples that atlas with wgpu, using existing render passes so no extra pass is needed.

### Which wgpu version does glyphon require?

The manifest declares wgpu at version 30.0.0 with default features disabled and the wgsl feature enabled. The dev dependency set uses wgpu 30.0.0 as well, along with winit 0.30.12, pollster 0.4.0, resvg 0.45.1 and criterion 0.8.1.

### What licence applies to glyphon?

The README states the project is licensed under either the Apache License Version 2.0, the zlib Licence or the MIT Licence, at your option, and the manifest sets license to MIT OR Apache-2.0 OR Zlib. Contributions are triple licensed the same way.

### Does glyphon do text layout and wrapping?

It does shaping and layout through cosmic-text for a run of text, but the crate is a 2D glyph renderer rather than a document engine. The examples cover hello world, text sizes, custom glyphs, ligatures and monospace input, using Inter-Bold.ttf as the typeface.

## Sources

- [grovesNL/glyphon on GitHub](https://github.com/grovesNL/glyphon)
- [Issues](https://github.com/grovesNL/glyphon/issues)
- [README](https://github.com/grovesNL/glyphon/blob/main/README.md)
- [Releases](https://github.com/grovesNL/glyphon/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grovesnl-glyphon