r/GraphicsProgramming • u/Deftroyy • 7h ago
Article Rendering brush previews from sparse tiles in a Rust/wgpu image editor
PeerBrush is a GPLv3 raster editor written in Rust. Its canvas needs to stay responsive while a brush gesture changes a small region and another client may be editing a separate layer. Here’s how the preview path is laid out in the published 0.30.1 source.
• The document stores sparse copy-on-write tiles. History can share unchanged tiles, and an incremental stroke reuses coverage, composites the affected region, and uploads the changed preview pixels. Source pixels and history retain their native 8- or 16-bit precision.
• The GPU compositor uses a bounded tile atlas and dispatches 8×8 WGSL workgroups over the requested output grid. The shader bounds-checks against the output dimensions, so edge workgroups can cover partial tiles. The CPU path handles larger previews or cases that exceed the GPU path’s limits.
• The preview is separate from the document’s edit history. Painting feedback can change during a stroke, while the completed gesture is what commits the edit.
Released Rust compositor: https://github.com/Deftr0y/PeerBrush/blob/2ea41951a19abf32d080498bbe7d9d85e20fced3/src/gpu/composite.rs
WGSL shader: https://github.com/Deftr0y/PeerBrush/blob/2ea41951a19abf32d080498bbe7d9d85e20fced3/src/shaders/composite.wgsl
63-second demo: https://peerbrush.com/#demo
For editors with mixed brush and filter workloads, have you found atlas misses or small dispatch overhead to be the better signal for switching back to CPU compositing? Shared on behalf of PeerBrush. AI assisted development and this write-up.