glyph-brush and the case for caching what you have already drawn

Four crates, split by what you are allowed to swap out

The repository is a Cargo workspace with four member crates, and the split is the design.

`glyph_brush` is the top level crate and is described as API agnostic rasterization and draw caching text rendering. The word agnostic is the important one: the crate does not talk to a graphics API itself, it produces something you draw with whatever you already use.

`glyph_brush_layout` handles text layout, and the README says it is layout for `ab_glyph` used in `glyph_brush`. `glyph_brush_draw_cache` is the rasterization cache for `ab_glyph`, also used in `glyph_brush`. `gfx_glyph` is the wrapper that binds `glyph_brush` to gfx-rs v0.18, which is the OpenGL path.

So `ab_glyph` does the actual font work, `glyph_brush_layout` turns text into positioned glyphs, `glyph_brush_draw_cache` keeps the rasterized results, and `gfx_glyph` is one concrete way to get those results onto a screen. Each crate has its own readme and its own changelog, which is what you would expect from a design that expects people to pick pieces.

The workspace membership is declared plainly:

[workspace]
members = ["gfx-glyph", "glyph-brush", "layout", "draw-cache"]
resolver = "2"

The cache is the product, rasterization alone is not enough

The repository description is a single phrase, fast GPU cached text rendering, and the title of the top level crate says it again: render API agnostic rasterization and draw caching text rendering.

The reason caching matters for text is specific. A text-heavy interface, a scrolling list, a chart with labels, a document view, all draw the same characters over and over. Rasterizing a glyph every time it appears means paying the cost of curve conversion and rasterization for every repetition, and on a GPU path that cost is often dominated by texture uploads rather than by the drawing itself.

A draw cache inverts that. Glyphs are rasterized once, stored, and then drawn from the stored copy. The cache is what turns a per-frame cost into a per-glyph cost.

The dependency chain shows where the work happens. `glyph_brush_draw_cache` and `glyph_brush_layout` are both built on `ab_glyph`, the font rasterization library, so the shaping and rasterization are not reimplemented here. What this project adds is the caching and layout layer on top, plus the plumbing to get it onto a GPU.

For a reader deciding whether this is the right abstraction, the key question is whether your application draws the same text repeatedly. If it does, a cache is worth real money. If it draws a handful of labels once, the cache is overhead.

gfx_glyph pins the OpenGL path to a pre-release gfx-rs branch

The `gfx_glyph` crate is the concrete integration, and the README is specific about its target: it is the `glyph_brush` wrapper for gfx-rs v0.18 (OpenGL), and the link points at the gfx-rs `pre-ll` tree.

The `pre-ll` reference is the detail to notice. gfx-rs v0.18 was itself a development line, and this wrapper is built against a specific branch of it rather than a final release of the graphics stack. If you are starting a new OpenGL project in Rust today, you will be choosing between that line and something else, and this crate only covers the former.

That is exactly why the top level crate is API agnostic. The `gfx_glyph` crate is one adapter, and the repository lists it as a separate workspace member with its own readme and changelog. The other adapters are expected to live elsewhere or to be written by you, and the caching and layout crates do not depend on gfx-rs at all.

The practical consequence: you can take `glyph_brush` and `glyph_brush_draw_cache` and plug them into a renderer of your own without taking on the gfx-rs dependency, which is the arrangement that keeps this project from being tied to one graphics stack.

The example is one command, and it wants a GPU

The repository ships a single example and the README gives its invocation as `cargo run -p glyph_brush --example opengl --release`.

The `--release` flag is worth keeping. This is a rendering crate, and an unoptimised build of a rasterizer and cache is not representative of anything you would ship.

The example is an OpenGL one, which follows from the `gfx_glyph` crate being the OpenGL adapter. The repository root carries a `fonts/` directory, which is where the example gets its font data from, and a `test/` directory alongside it.

Beyond the example, the README points to the individual crate readmes for the API details, and every crate publishes to crates.io and documents on docs.rs, so the API reference is available without cloning anything. The `glyph_brush` crate readme and changelog are linked directly from the top level README, which is where to look for behaviour changes.

The one thing the top level README does not document is how to point the cache at a different font atlas or a different pixel format. That is the kind of question the crate level documentation exists to answer.

What the workspace configuration tells you about the project

The workspace manifest is short, and each line is informative.

The `resolver = "2"` setting means the workspace uses Cargo's second feature resolution rule, which, for example, stops features being unified between normal dependencies and build dependencies of the same crate.

There is a bench profile with thin LTO:

[profile.bench]
lto = "thin"

The presence of a dedicated bench profile, rather than benchmarking in release mode, tells you the maintainer treats measurement as part of the workflow. For a crate whose entire claim is speed, that is the configuration you would expect, and it is also the configuration you would want to reproduce before believing a performance claim.

The repository layout matches the crate split: `glyph-brush/`, `layout/`, `draw-cache/` and `gfx-glyph/` directories, plus `fonts/`, `test/`, `.github/` and the workspace `Cargo.toml`.

On the toolchain, the README states that all crates are maintained with the latest stable Rust, rather than pinning a minimum version. The trade is simple. You get current tooling and no version constraint to satisfy, and in exchange you cannot easily build these crates on an older toolchain, which matters if your project is pinned to a specific Rust release.

Where the versions actually stand

The published releases are glyph-brush 0.7.12 from 2025-02-21, 0.7.11 from 2024-10-20 and 0.7.10 from 2024-08-28. The repository itself is not archived, and the last push was on 2026-10-05.

Those two facts sit oddly together and are worth reading carefully. Commits are landing on the main branch, but the last tagged release is more than a year older than the last push. For a project whose crates are consumed from crates.io, that means the code on the main branch and the code you would install are different, and the changelogs in each crate directory are where you would find out what changed in between.

So the upgrade cost of this project is not the API, which is versioned and documented, but the gap between a tag and the branch. If you depend on `glyph_brush`, pin a released version, and read the crate changelog before moving past 0.7.12.

The licence is Apache-2.0, with the text in the LICENSE file at the root, and each of the four crates carries its own readme and changelog. Apache-2.0 includes an explicit patent grant, which matters for a library that another organisation may embed in a product.

On the alternative: if all you need is font shaping and rasterization, `ab_glyph` alone is the smaller dependency and it is what both the layout and cache crates are built on. Taking `glyph_brush` on top of it buys you the draw cache and the layout layer, at the cost of two more crates to track. Taking only `glyph_brush_draw_cache` is the middle path, and it is the reason the workspace is split this way.

Editorial conclusion

glyph-brush suits a Rust project that renders substantial amounts of text through a graphics API and is willing to own a glyph cache, and the split into `glyph_brush`, `glyph_brush_layout`, `glyph_brush_draw_cache` and `gfx_glyph` means you can adopt the caching layer without taking the OpenGL binding. It is the wrong choice for a project that draws a few labels, since the cache buys nothing there, and for a renderer that is not among the APIs you care to implement yourself. Verify first that the crate version you pick matches your renderer, since the published releases stop at 0.7.12 from 2025-02-21 while the repository was pushed to on 2026-10-05, and that the `gfx_glyph` binding still targets the gfx-rs v0.18 pre-ll branch.

Frequently asked questions

Official sources

1. alexheretic/glyph-brush on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases