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; 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. 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.
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.
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 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 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 .design file is written in.
png
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.
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 the server feature, the Designs service’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 a Drawing ([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 through crate::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 Scene is a tree of Nodes — each with its own attributes, colours in both Themes, and an id that survives saves — with the image and font files it shows, read through the Files port. An Edit names its nodes by id; Edits are 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. Applied says 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::Scene and back, and Edits to the proto::Patch the 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.

Structs§

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