Yawn

Yawn Core is two things: a generic structure-of-arrays arena in a SharedArrayBuffer, and a Rust render graph that turns externally supplied WGSL into an up-front WebGPU loadout.

JSO or FXNode → AST → S-expression → worker messages → Rust/WebGPU
                                                   ↑
any thread → direct shared row writes ─────────────┘

The arena starts with only one eight-float signals row for frame timing and render invalidation. Messages create or delete other { name, rows, stride, format } arrays, allocate named slots, compile graphs, switch loadouts, and control render pacing. Existing render data is changed by writing f32, u32, or i32 rows directly, then setting the shared-data dirty signal. Allocations are 64-byte aligned, row strides are multiples of 16 bytes, and compatible non-overlapping transient textures share physical allocations.

WGSL, pipelines, glTF import, and conventional mesh/camera/material handles live in addons/; core contains no shader or scene model.

Run the Go website, in-memory package server, SQLite-backed playground, and tutorial:

npm run server

The server rebuilds @yawn/core and @yawn/handles at startup and serves the public CDN modules at https://yawn.heaust.org/pkg/core.js and https://yawn.heaust.org/pkg/handles.js. Handles keeps Core as a separate module dependency instead of bundling it. Map and import both URLs as shown in server/examples/basic.html; their workers and WASM stay on the CDN automatically. The complete editor is at /playground; saved revisions use /playground/{id}/{revision} URLs. Set PORT or YAWN_DATABASE to override the default port and server/data/yawn.db database path.

Run the previous VitePress documentation site with npm start.

Run npm run coredocs for the raw worker-message, shared-memory, and render-graph reference intended for custom handles, editors, and direct SAB clients.