Expand description
The design engine: parses .design files, resolves them into scenes, lays
them out and paints them. It does no I/O, so the same code runs natively
in devpage and compiled to WebAssembly in the browser.
The core links no rasterizer: text → syntax tree (parse) → scene
([resolve], fonts) → layout, the painter’s commands and a kept,
updatable drawing (render) → chunks under property trees with their
index, the one paint entry point and hit testing (display) → tiles,
their cache and the damage that makes them stale (tiles); with the
shadows’ sampling (shadow), the GPU atlas’s model (atlas), the
wire form of scenes and patches (wire, proto) and the rule two
drawings are compared by (compare). Its geometry and colours are
kurbo’s and peniko’s, depended on directly.
Adapters plug into its one port, display::Target — paint this area
at this scale: cpu, vello_cpu; the module’s vello on WebGPU. And
bands writes the PNG band by band from whatever gives it tiles. The
core names no adapter; a test holds it to that.
Re-exports§
pub use render::Damage;pub use render::Drawing;pub use render::Renderer;pub use resolve::Files;pub use resolve::Scene;pub use resolve::Theme;pub use resolve::resolve;
Modules§
- atlas
- Whether a drawing’s images fit the GPU, and where.
vellocopies every image a frame paints into one atlas texture, at mostSIDEpixels a side, and an image that finds no room there is silently left out of the frame. So the engine asks this model first, and a drawing whose images don’t fit is the design’s problem rather than a picture with holes. - bands
- The PNG, written band by band: each band as many rows as fit in
BAND_BYTESof pixels, its rows streamed into thepngcrate’s encoder as it is had, so what is held at once is one band — whatever paints or caches its pieces, and however wide the drawing is. - compare
- Comparing two drawings of the same scene, by the engine’s one rule.
- cpu
- The
vello_cpubackend — an adapter ofcrate::display::Target: any area of a display list painted into a pixmap, and a tile’s straight-alpha pixels, for the server’s tiles, the PNG and a browser without WebGPU. - display
- The display list: drawing commands in chunks — one per scene node, in the
node’s own coordinates — under property trees, and the two-level index
over them. A command doesn’t nest layers; it names its clip and its
effect, and
paintopens and closes exactly the layers each command it paints needs, so any subset of the list paints in order. Every tile, PNG band and click goes through here. - fonts
- Fonts: a design’s text is set in Inter, which the engine embeds, or in a
font file from the served folder — a
.ttfor.otfof one font, checked as it is read and known by its content, so a scene holds and sends it once however many texts use it. - ids
- Element ids kept across edits: a file’s new parse matched against its
last, sibling list by sibling list, so an element keeps its id however
the lines around it change. Siblings with a
keyare matched by it; the others by a shortest edit script over the list (Myers’ diff), comparing each element’s name and own attributes, and then, among what is left between two matches, an element with one of the same name, in order, as an edit of it. A matched element’s children are matched the same way; an element left over is new and takes the file’s next id. - parse
- Text → syntax tree: the JSX subset a
.designfile is written in. - proto
- The watch stream’s messages, generated from
proto/design.proto— with theserverfeature, theDesignsservice’s server side too — and the conversion of a scene into them and back. - render
- Scene → pixels. The engine lays a scene out ([
layout]: taffy, parley), paints each node’s own commands ([painter]) into aDrawing([drawing]): its display list in chunks under property trees, kept and brought up to date by what changes ([update]). A backend paints any area of it throughcrate::display::paint. This module holds the renderer — its fonts and text shaping — and the commands’ types. - resolve
- Syntax tree → scene: imports and props substituted, every attribute checked, typed and defaulted.
- shadow
- Shadows: a box’s shape blurred by a true Gaussian, as display-list commands both backends replay.
- sums
- A sequence in key order that knows the summary of every prefix in log time: a treap whose every node holds the summary of its subtree. What a run keeps its children’s sizes in, so a child’s change of size, an insert before the first of 100,000 or a search for the child at a place along the run costs log time, and moves no sibling.
- tiles
- Tiles: squares of a drawing, 256 device pixels a side, painted at one scale in one theme — where each is in the design, the pyramid’s levels, and the cache that keeps them and marks the ones damage makes stale.
- tree
- A scene’s tree as a tree: each node’s identity, its place among its siblings, and the index that finds a node by its identity. Nothing here knows what a node draws.
- wire
- Scenes on the wire: a scene to its
proto::Sceneand back; the patch between two scenes ispatch’s. Each image file and font file travels once: a scene carries every one its nodes use, a patch only those the scene before it didn’t have.
Structs§
Functions§
- png
- Paints a scene’s whole drawing at 1× in
themeand encodes it as a PNG, band by band, or says why it can’t: seeRenderer::drawing. A drawing made afresh and kept by nothing: the server’s PNG comes from its kept drawings and tiles instead. This is the reference the engine’s, the module’s and the canvas’s tests compare a drawing against — one call, from a scene, with nothing kept.