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; what a scene is, and the edits from one to the
next, are scene’s) → 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) — and a
design as it is held while shown, its scene and its drawings brought
along by each edit, with one rule for a scene that can’t be drawn
(design); with the
shadows’ sampling (shadow), the GPU atlas’s model (atlas), the
wire form of scenes and their edits (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
png 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 design::Design;pub use render::Damage;pub use render::Drawing;pub use render::Renderer;pub use resolve::resolve;pub use scene::Files;pub use scene::Scene;pub use scene::Theme;
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. - 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. - design
- A design as it is held while it is shown: its scene, how many nodes use each of its files, and its drawing in each theme a caller asks for — every one brought along by each change to the scene, the damage it does to their tiles kept until it is taken. It answers what a canvas or a PNG asks of a drawing: its size, the interaction at a point, the tiles a view needs, and an area to paint — rounded first where an update left a run’s children a fraction of a pixel off, so what is painted there is a fresh drawing’s.
- 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 whole — its name, its own attributes and everything in it — 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. - png
- 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. - prefix_
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.
- 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 → drawing. 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]). No pixels are made here: a backend paints any area of it throughcrate::display::paint. This module holds the renderer — its fonts and text shaping. - resolve
- Syntax tree → scene: imports and props substituted, every attribute checked, typed and defaulted.
- scene
- What a resolved design is, and how one becomes the next. A
Sceneis a tree ofNodes — each with its own attributes, colours in bothThemes, and an id that survives saves — with the image and font files it shows, read through theFilesport. AnEditnames its nodes by id;Editsare a list of them with the files they bring, and applying them (apply) is all or nothing, undone on a refusal, at the cost of the edits alone.Appliedsays what they did, for a drawing kept beside the scene to follow. - shadow
- Shadows: a box’s shape blurred by a true Gaussian, as display-list commands both backends replay.
- 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, the cache that keeps them and marks the ones damage makes stale, and the frame plan a browser canvas carries out.
- tree
- A scene’s tree as a tree: each node’s identity, its place among its siblings, and its children under their keys. Nothing here knows what a node draws.
- wire
- Scenes and their edits on the wire: a scene to its
proto::Sceneand back, andEditsto theproto::Patchthe watch stream sends and back (patch). 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. It does no I/O.