Lyon

Lyon is a Rust library that tessellates 2D vector paths — lines, quadratic and cubic bezier curves, arcs — into triangle meshes suitable for rendering on the GPU. It doesn’t render anything itself; it hands back vertex and index buffers that you feed into OpenGL, Vulkan, WebGPU, or any other graphics API of your choosing.

The crate is organized as a workspace of focused sub-crates — lyon_path, lyon_tessellation, lyon_algorithms, lyon_geom, lyon_extra — that the top-level lyon crate re-exports, so consumers can depend on only what they need. It grew out of, and continues to serve, rendering-engine use cases like Servo and game or graphics prototypes built on wgpu.

What You Get

• FillTessellator and StrokeTessellator for arbitrary paths made of lines, quadratic/cubic beziers, and arcs
• lyon_path, a path builder and iterator API kept decoupled from tessellation logic
• lyon_geom primitives for beziers, arcs, lines, and triangles with curve-flattening utilities
• lyon_algorithms helpers for hit-testing, measuring, walking, and rasterizing paths
• An optional lyon_extra crate with debugging and testing utilities, gated behind a feature flag

Common Use Cases

• Rendering vector icons or complex SVG-like shapes inside a custom wgpu/Vulkan/OpenGL renderer
• Building game engines and UI toolkits that need GPU-friendly 2D vector graphics without a full SVG rendering stack
• Converting bezier-based path data into triangle meshes for browser/WASM graphics via WebGPU
• Prototyping 2D rendering pipelines, as shown in the bundled wgpu and wgpu_svg example renderers

Under The Hood

Architecture Lyon is organized as a Cargo workspace of focused crates rather than a monolith: lyon_path (crates/path) owns path construction and iteration via a builder/iterator split (builder.rs, iterator.rs, events.rs), lyon_geom (crates/geom) supplies the underlying bezier/arc/line math, lyon_tessellation (crates/tessellation) consumes paths and applies fill.rs (a large monotone-decomposition fill algorithm) and stroke.rs to emit vertex/index buffers through a pluggable GeometryBuilder trait (geometry_builder.rs), and lyon_algorithms (crates/algorithms) layers higher-level operations — hit-testing, measuring, walking, rasterizing — on top. The top-level lyon crate (crates/lyon/src/lib.rs) is a thin re-export facade with no logic of its own; the gated extra feature pulls in lyon_extra for debugging/testing helpers, and cli/ and examples/wgpu*/ are separate workspace members that consume the library rather than being part of it. Swapping out the core tessellation algorithm in fill.rs or stroke.rs would ripple into every consumer crate since GeometryBuilder is the sole output contract, while path construction and math stay decoupled from tessellation, keeping changes to lyon_geom comparatively contained.

Tech Stack The workspace targets Rust edition 2018 with resolver = “2” (Cargo.toml), and each core crate (lyon_path, lyon_tessellation, lyon_geom) declares #![no_std] to stay usable in constrained or WASM targets. Feature flags wire in a serde-based serialization mode, a debugger mode, and the optional extra utilities per sub-crate, threaded through from the meta-crate. CI (.github/workflows/main.yml) runs cargo test --all --verbose --all-features on both stable and nightly toolchains plus a dedicated wasm32-unknown-unknown check job, confirming the no_std/WASM story is actually exercised. The examples/wgpu and examples/wgpu_svg workspace members pull in the wgpu crate and raw WGSL shaders to demonstrate feeding tessellated output into a real GPU pipeline, while bench/ holds separate benchmark crates for tessellation, path, and geom work, kept out of the default build via the workspace exclude list.

Code Quality Testing is embedded per-module rather than centralized: the crates/ tree has dozens of #[test] functions and #[cfg(test)] blocks across path, tessellation, and geom, plus dedicated files like fill_tests.rs, earcut_tests.rs, and fuzz_tests.rs specifically targeting the fill algorithm’s edge cases. Error handling favors an explicit TessellationError type (error.rs) returned from tessellate calls rather than panics on malformed input. Naming is consistent and descriptive (FillTessellator, StrokeTessellator, GeometryBuilder), and crate headers set #![deny(bare_trait_objects)] and #![deny(unconditional_recursion)] as lint gates, with a handful of narrowly scoped clippy allow-attributes rather than blanket suppressions. CI covers the full test suite across two toolchains and a WASM check, though there’s no separate clippy or formatting job visible in the workflow, so style enforcement leans on source-level lint attributes rather than a CI-gated lint step.

API Design Lyon’s developer experience centers on a clean separation between path construction and geometry output: users build a Path with a chainable builder, then hand it to a FillTessellator or StrokeTessellator alongside a GeometryBuilder implementation for their own vertex type — demonstrated directly in the crate-level doc example, which tessellates a rounded rectangle into a custom vertex struct in a handful of lines. This keeps lyon unopinionated about vertex layout, buffer format, or GPU backend, unlike higher-level SVG renderers, at the cost of requiring callers to write their own GeometryBuilder glue. The tessellation algorithms themselves are a genuine technical asset — long-running use by Servo and various wgpu-based renderers is evidence the approach holds up on complex, self-intersecting real-world paths, not just textbook cases — though monotone-polygon-decomposition fill is an established computational-geometry technique rather than something lyon invented outright.