Pathfinder splits a rasterizer into thirty crates and admits two of its names are fiction

A canvas API subset, published under one name prefix

What the library exposes is described as a subset of the HTML canvas API, which is the useful way to think about the integration: you get the familiar drawing surface, from a Rust or C application, without giving up the ability to run the same code on a phone. Availability is the package registry rather than a vendored copy, and the crates all share a prefix, with the canvas crate given as the example. The design decision behind that is spelled out in the feature list: the project is built for simplicity and generality rather than a large number of specialised fast paths, and because it is a set of modular crates an application picks the components it needs to keep its dependency list short. A minimal example is named as the starting point, and the demo application has its own directory with a release build command.

The two rendering mode names are a documented fiction

Two rendering modes are described, one called after a Direct3D version that uses compute shaders and one called after an older version that uses hardware rasterization. The parenthetical note is the interesting part, and it says these names are purely convenient ways to refer to hardware levels because the project does not have a proper Direct3D backend yet. So the naming describes what the underlying hardware can do rather than an API being called. The compute path is described as achieving large reductions in CPU usage, and the older path is where the CPU does real work: the tiling step runs with SIMD and a work-stealing scheduler to get parallelism out of the CPU, and that step is pipelined with the GPU so its latency is hidden. The available backends are the four you would expect from a cross platform library: OpenGL, its embedded variant, Metal and WebGL.

Antialiasing is computed exactly, per pixel

The antialiasing claim is the one with a number attached: exact fractional trapezoidal area coverage computed on a per pixel basis, which the file describes as effectively two hundred and fifty six times oversampling without supersampling. That matters for a rasterizer whose whole purpose is text, because text quality at small sizes is decided by how coverage is estimated at the edge of a glyph, and an exact analytic answer beats a sample grid. The related font features are listed in the same spirit: slight hinting, subpixel antialiasing on liquid crystal displays, and stem darkening, which the file names as the technique used by two specific text stacks so the reader can compare implementations rather than guess. Gamma correction is supported as well, so the pipeline can be told what the display is doing before it computes coverage.

Overlapping vector paths are the workload it is built for

The scalability claim is scoped precisely, which is what makes it checkable. The project says it is designed to handle workloads consisting of many overlapping vector paths, of the kind found in complex SVG and PDF files, and the technique it names is tile based occlusion culling. The contrast is with software renderers that use the painter's algorithm, where every shape is drawn in order and overdraw is paid for each time. Culling at tile granularity means the expensive decision is made once per tile rather than once per shape. A loader is included that leans on an external parsing library to render a subset of SVG, which keeps the library itself out of the business of parsing path data. The same shape of thinking appears elsewhere in the tree, which has crates for animation formats and for a legacy binary format, both of which are mostly overlapping paths.

Thirty workspace members, twenty six built by default

The workspace manifest is where the modularity claim becomes concrete, and it is worth reading the two lists rather than counting directories. The members list is around thirty entries and includes every example, every utility and the demos. The default members list is shorter, roughly twenty six, and it is the set that a plain build at the top level produces. So the same repository supports a full build with all the samples and a default build with the library proper, and the difference is declared rather than discovered. One demo is commented out of the members list with an inline note that it is severely out of date, which tells you the demos are not all maintained. Two patch sections at the bottom redirect both the registry and the project's own git address to local directories, so a build uses the working tree rather than published crates of the same name.

The C bindings need a separate tool and a package config name

The C side is not just a header file, and the instructions say so. The bindings are built with a third party tool that has to be installed first, and then the build writes into a destination directory that you copy over the system root yourself:

$ cargo cinstall --destdir=/tmp/pathfinder-destdir --manifest-path c/Cargo.toml
$ sudo cp -a /tmp/pathfinder-destdir/* /

After that the library is discovered through a package configuration file under the name pathfinder, which is the name a build system will look for. Examples for the C side are the ones whose names start with a prefix indicating the language, so they are easy to filter for in the examples directory. The tool has a prefix option as well, noted as useful for packagers, which is the only hint in the file about how this is meant to reach a distribution. The feature list also says plainly that the C bindings are currently less complete than the Rust ones and that pull requests are welcome there.

Three preview tags from 2019, and a push in 2026

The release history is the first thing a new user should look at, and it is strange. The three tags in the repository are named as a first, second and third preview build, and all three were published in the first half of June 2019. The last push to the default branch is dated 2026-04-23, and the repository is not archived, so there is roughly a seven year gap between the newest tag and current work on the branch. That is consistent with the warning at the top of the README, which says the project is under heavy development and incomplete in various areas, and it is why the build section suggests using the main branch for the latest features and fixes rather than a tagged release. The licence is dual, matching the two licences the Rust language itself uses, and one third party note covers icon assets under a different licence and a different holder.

Editorial conclusion

Pathfinder suits an application that needs to render text and many overlapping vector paths on a GPU, and that can live with an incomplete canvas API subset and a project that says it is under heavy development. It does not suit a project that needs a Direct3D backend, because there is not one, or a team that needs a stable tagged release, since the newest tag is a preview build from 2019. Before depending on it, build from the main branch rather than a tag, pick only the crates you need, and read the third party notice for the icon assets.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. servo/pathfinder on GitHub