Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

wisp

A Pixi-shaped 2D scene graph + filter chain library on top of wgpu. Native Rust, no JavaScript, no DOM. Scene tree, sprite batcher, filter chain, mask system, text.

What it gives you

  • Scene treeContainer / Sprite / Graphics / Text, with transforms inherited from the parent.
  • Sprite batcher — single draw call per atlas, scene-tree order preserved.
  • Filter chain — composable post-process passes (blur, drop shadow, motion blur, color matrix), each with a passes() method so the renderer can allocate scratch RenderTextures on demand.
  • Mask system — rounded clip, privacy blur, solid redaction, spotlight, dim-outside, ellipse, freehand path. Works on raster AND vector primitives.
  • Text — atlas-cached bitmap text for HUDs + a Cosmic-Text / Glyphon-backed FlexibleText for high-quality body copy.
  • Headless export — render any scene to a RenderTexture, read pixels back as BGRA bytes, or push them straight into a GStreamer appsrc for video encode.

What it costs you

  • A wgpu adapter. Anything Metal / Vulkan / DX12 / GLES 3 capable.
  • Rust 1.82+ (some examples use newer features).
  • Awareness of wgpu's Queue::submit rhythm — wisp gives you the scene API but expects you to drive the frame loop.

What it is not

  • A game engine. There's no input handling, audio, networking, asset pipeline, or ECS.
  • A web canvas library. wisp targets native; the web works via wgpu's WebGPU backend but is not a primary surface.
  • A reactive UI framework. Wisp draws what you tell it to draw.

Why it exists

It's the renderer behind Screen Studio — a native Rust screen recorder. The full project is in the screen monorepo; this book is the renderer-only deep dive. If you want context on how the recorder uses wisp, the project book at /Screen/ has the integration story.

**`wisp` does not depend on `media`, `decode`, `playback`, `capture`,
or any application crate.** The dependency arrows go one way:

- `media` / `decode` / `playback` produce data (BGRA frames, audio
  histograms, geometry) and hand it to `wisp` via standalone types
  it already owns (`VideoTexture`, `Sprite`, `Graphics`).
- `wisp` provides the scene graph; everything else composes against it.

Any change that makes wisp pull from a higher-level crate breaks the
ability to publish wisp to crates.io as a standalone renderer. See
`_docs/wisp-book/src/intro.md` for the publishable-crate contract.
This is one of **two** sibling mdBooks deployed to the same GitHub
Pages site:

- **Project book** — `/Screen/` (recorder + capture + encoder + Tauri shell).
- **Wisp book** — `/Screen/wisp/` (renderer-only reference; publishable to crates.io independently).

Cross-references in either book go through the
`mdbook-preprocessor-cross` preprocessor so URLs adapt per book:

- `\{\{wisp-link path/to/chunk\}\}` — emits a relative URL inside
  the wisp book, an absolute `/Screen/wisp/path/to/chunk.html` URL
  from the project book.
- `\{\{shared path/to/fragment.md\}\}` — inlines a markdown
  fragment from `_docs/shared/` (this snippet you're reading is
  one).

Plain markdown links from the wisp book back to the project use
absolute URLs (`/Screen/...`) since the inverse direction is
single-target.

Get started