Vello: three Rust 2D renderers, and how to pick one

Who Vello is for, and what it replaces

Vello targets the slot in the graphics stack that Skia, Cairo and the Linebender predecessor project Piet occupy. The README is explicit about that positioning, and about the imaging model: shapes, images, gradients and text drawn through a PostScript-inspired model, the same family of operations that sit behind SVG and the browser canvas element. If you are writing a Rust application that needs to draw vector content rather than assemble a widget tree, this is the layer you would be considering.

The audience is narrower than "anyone who needs 2D graphics". Vello is a library, not an application or a service. It exposes renderers that a Rust program links against, and the repository is a Cargo workspace with more than twenty members. You are expected to be comfortable with Rust, with GPU backend selection, and with reading crate-level READMEs, because the top-level README deliberately does not repeat the per-package setup instructions. It points at vello_cpu, vello_gpu and research/vello_research for those.

The unusual part is that the project no longer presents a single renderer. It presents three with different hardware requirements and different maturity profiles, and it tells you to choose. That is a more honest arrangement than a single crate with feature flags, but it also means the first decision you make is an architectural one.

Sparse Strips: what vello_cpu and vello_gpu share

vello_cpu and vello_gpu are the two user-facing renderers, and they are built on the same architecture, called Sparse Strips, with shared infrastructure in vello_common. The repository layout reflects this directly: vello_common and vello_gpu_shaders support both, glifo provides text and glyph-run support for both, and vello_tests holds their shared development tests, snapshots, scenes and browser tooling. ARCHITECTURE.md is where the README sends you to learn how the renderer families actually differ.

The division of labour between the two is the interesting part. vello_cpu is CPU-only and optimized for multithreading and SIMD. vello_gpu preprocesses paths on the CPU and uses the GPU for rasterization and compositing, and it does so without requiring compute shaders. That last constraint is what buys it broad GPU compatibility, including a native WebGL2 backend alongside the wgpu backend. A renderer that avoids compute shaders can run on hardware and browser contexts where a compute-centric design cannot.

The third renderer sits outside this family. The vello crate under research/ is the original compute-centric implementation, performing most rendering work in GPU compute shaders. It does not share the Sparse Strips architecture, and its source and supporting crates live under research/ along with its encoding and shader crates, examples, tests, historical design documents and changelog. Treat the directory name as the signal it is.

Installing Vello and running your first renderer

The README gives no cargo add step and no published-crate installation instructions. What it gives is a workspace and a set of windowed examples, run from a checkout of the repository. The MSRV note states this version of Vello has been verified to compile with Rust 1.89 and later, so confirm your toolchain before anything else.

The quick start is three commands, one per renderer. Each runs a windowed example for the renderer named. The release flag matters here, since these are rendering workloads.

# Vello CPU
cargo run -p vello_cpu_winit --release

# Vello GPU
cargo run -p vello_gpu_winit --release

# Compute-centric research renderer
cargo run -p with_winit --release

You should see a window open and draw a scene. If the GPU example fails to start, that is the compatibility boundary doing its job rather than a build error; the CPU example is the fallback that does not depend on a suitable GPU.

From there the README directs you to the package-specific READMEs for vello_cpu, vello_gpu and vello for setup and API examples. That is where the actual drawing API lives. The top-level README does not document it, and it does not document how to embed a renderer in your own application rather than in an example.

One practical note the README does include: if compilation fails because a dependency has raised its own Rust requirement, you can pin that dependency back rather than upgrading your toolchain.

# Use the problematic dependency's name and version
cargo update -p package_name --precise 0.1.1

Replace the placeholder name and version with the dependency cargo reported.

The maturity gap between the three renderers

The README ranks its own renderers, which is rare and useful. vello_cpu is described as the most mature choice when predictable CPU rendering, software rendering, or support for devices without a suitable GPU is required. vello_gpu is described as intended to become the primary renderer for production GPU use cases as it matures, with the qualification that vello_cpu is currently overall more mature. The compute renderer is described as remaining an experimental implementation for compute-capable GPUs.

Read those three sentences together and the trade-off is clear. If you need GPU acceleration today, you are choosing a renderer the project itself places behind the CPU one on maturity, and you are doing so on a stated roadmap rather than on a shipped guarantee. That is a real risk for a production dependency, and it is worth pricing in before you commit.

The second limitation is hardware reach. The compute renderer needs compute-capable GPUs, which is why it lives in research rather than alongside the other two. vello_gpu avoids compute shaders but still needs a GPU and a working wgpu or WebGL2 path. Only vello_cpu runs without a suitable GPU at all. If your deployment target includes machines where GPU access is unavailable, sandboxed, or unreliable, the CPU renderer is the only one of the three that answers that requirement.

The third limitation is documentation scope. The top-level README is a map, not a manual. It tells you which crate to read and which architecture document to open. Nothing at the top level tells you what the drawing API looks like, how to integrate a renderer into an existing event loop, or what happens on backend initialization failure. Those answers are in per-crate READMEs and in ARCHITECTURE.md, and you should read them before evaluating the project rather than after.

Vello compared with Skia and Cairo

The README names Skia and Cairo as the projects Vello intends to fill the same place as in the graphics stack, alongside Piet, Linebender's predecessor. The comparison is worth taking literally, because the difference in approach is architectural rather than a matter of features.

Skia and Cairo are mature C and C++ rendering libraries with long release histories and wide language bindings. Vello is a Rust workspace whose renderers are selected at build time rather than configured at runtime, and whose newest GPU path is still described by its own README as maturing toward production. A team already shipping Skia through an existing binding is not the audience for this project. A team writing Rust and unwilling to carry a C++ dependency through its build has a reason to look.

The more instructive comparison is internal. vello_cpu and vello_gpu share Sparse Strips, vello_common, glifo and a common test suite, so moving between them is a change of backend rather than a change of renderer model. The compute renderer under research/ shares none of that. Its encoding and shader crates, examples and tests sit in their own tree. Choosing it is not choosing a faster Vello; it is choosing a different lineage that happens to live in the same repository.

Licence, releases and what upgrades cost

Vello is dual-licensed under Apache-2.0 and MIT, at your option, and the workspace manifest records the same expression. That is the permissive arrangement most Rust projects use and it imposes no copyleft obligation on your own code. Two details complicate the picture slightly.

First, the files under research/vello_shaders/shader and research/vello_shaders/src/cpu, and their subdirectories, are alternatively licensed under the Unlicense. The README is careful to state that those files are also licensed under either Apache-2.0 or MIT, and that the intent is for the research to be usable in as broad a context as possible. So the extra option is additive, not a restriction. Second, files in subdirectories of the assets directory are licensed solely under their own licences, recorded in a LICENSE file in each directory. If you ship example assets, check those files individually. This is a description of what the repository states, not legal advice.

On releases, the workspace version is 0.10.0, and the most recent tagged release listed is v0.10.0, dated 2026-08-14. Two companion releases, sparse-strips-v0.2.0 and glifo-v0.3.0, are dated 2026-08-07. The last push to the default branch was on 2026-09-22.

Upgrade cost is where the workspace layout matters. Release histories are maintained separately in the vello changelog under research/, the vello_cpu changelog, the vello_gpu changelog and the vello_common changelog. If you depend on vello_cpu, the changelog that describes your breaking changes is vello_cpu/CHANGELOG.md, not the one at the repository root. The MSRV policy also deserves attention: the README states future versions might increase the Rust version requirement, that this will not be treated as a breaking change, and that it can happen in a small patch release. A toolchain upgrade can therefore be forced on you by a patch bump.

Editorial conclusion

Adopt vello_cpu if you need software rendering, predictable CPU output, or a machine without a suitable GPU; the README calls it the most mature of the three. Adopt vello_gpu if you want GPU acceleration without compute shaders, and accept that the README says it is intended to become the primary production GPU renderer as it matures. Do not start new work on the compute renderer under research/ unless you are specifically studying compute-centric rasterization; the README labels it experimental. Verify first that your toolchain is Rust 1.89 or later, and check the per-crate changelogs for the renderer you pick before pinning a version.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. linebender/vello on GitHub
3. Project website
4. README
5. Releases