Skip to main content

Crate devpage_design

Crate devpage_design 

Source
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. vello copies every image a frame paints into one atlas texture, at most SIDE pixels 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_BYTES of pixels, its rows streamed into the png crate’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_cpu backend — an adapter of crate::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 paint opens 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 .ttf or .otf of 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 key are 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 .design file is written in.
proto
The watch stream’s messages, generated from proto/design.proto — with the server feature, the Designs service’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 a Drawing ([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 through crate::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::Scene and back; the patch between two scenes is patch’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§

KRect
A rectangle.
Problem
Something wrong with a design, at a place in one of its files.

Functions§

png
Paints a scene’s whole drawing at 1× in theme and encodes it as a PNG, band by band, or says why it can’t: see Renderer::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.