The shipped projects below depend on the published crates by version — not a path into a checkout, not a git revision — and each exercises one of the four ways to extend the engine. The examples further down are checkout programs: visual, specific, and honest about their path dependencies.
All five build today against the published layer crates, by version, resolved from crates.io. Where a card is the crate's own example, the crate under test is the checkout and everything beneath it is the registry. Each card links to the repository that is public; the usage suite they are gathered in is not published yet, so where a copy under it differs from its upstream — or from a repository of its own — the card says which part is which.
A second TextSystem
A text system written outside the tree, selected at startup and drawing real text. It was extracted from the example that still ships in gpui_parley, and now depends on the published bite-gp-parley — library gpui_parley — from crates.io rather than on a vendored copy.
Paint modes over one document
An app that renders one document in several paint modes with motion effects, and reports the frame cost of each. It was repointed off a fork checkout and onto the published crates: no logic changed, and the TextSystem it had written against the fork injects into the published facade and draws with it.
The copy that builds on the published crates is the usage suite's. That repository is the app's upstream and still points at a fork checkout.
Upstream · bite-gpui/bite_gpui_scroll_demoA second LayoutEngine
A layout solver written outside the tree: morphorm, behind the same six-method trait the default engine implements. Two engines that disagree are not two columns, so the bounds are compared before anything is timed — and then a real frame is drawn, because agreeing node for node turned out not to be the same as filling a window. It publishes as bite-gp-morphorm from a repository of its own. The repository's layout_demo renders the swap live: BITE_LAYOUT_ENGINE=taffy cargo run --features demo --example layout_demo runs the same tree on the default engine, and BITE_BUTTONS=1000 makes the difference unmissable.
The layout swap is no longer only something to measure with: bite-gp-morphorm 1.21.2 is on crates.io, so a second LayoutEngine is a dependency line.
Crate source · bite-gpui/gpui_morphormA 24 fps schedule on a 60 Hz panel
A frame-stepped animation at 24 fps — a rate the refresh period does not divide. A carried schedule keeps the half-refresh across frames and lands on the 3:2 pulldown: holds of three refreshes and two, alternating, 121 frames in five seconds. Run it with the demo feature enabled; the naive run is the facade's from-last-frame cap, which can only settle on 30 or 20 fps. The animation advances one step per drawn frame, so the strip shows where the drawn frames put it against wall-clock time.
Where the frame goes
Two windows: one draws a scene whose buttons, paragraphs and canvas primitives are dials; the other draws what each pass of that scene cost, read from the measured window's own ledger. The two do not share a ledger, so the telemetry window's own frames never pollute the measurement. Turn a knob in one and watch its bar grow in the other.
The published bite-gp-engine 1.25.202 carries
PathVertex::content_mask, which a later fork commit dropped
— a real difference between the published artefact and the fork a
consumer may have vendored. It is inert: the published renderer clips by
Path::clipped_bounds() and never reads the field, so a
consumer fills it with Default::default(). It is written
down here rather than smoothed over because that is what
installing instead of vendoring is supposed to surface.
These five are the most visual programs in the workspace, and they are
not published-version consumers: their manifests take the core from a
sibling bite-gpui checkout. They run from a clone, and they
are where the surface path is easiest to see.
A 3D viewport on GPUI's device
An instanced field of lit cubes drawn by an ordinary wgpu pipeline into an exportable image. On the same device as the window, WgpuSurface plus paint_texture composites it with no export, no fence and no CPU copy; the chrome is real GPUI buttons and a frame-interval histogram outside the producer's hitbox.
From a gpui_interop checkout; the core is a path dependency.
Example · interop_wgpuBevy, headless, on GPUI's device
Bevy is built headless — no winit, no window, no event loop of its own — and renders a procedurally spawned 7 × 7 field of lit cubes to an offscreen image on the window renderer's wgpu device. Bevy's meshes and passes run on the device GPUI already draws with, and each paint is one Bevy tick.
From a gpui_interop checkout; the core is a path dependency.
Example · interop_bevyA separate renderer, by the handle
A Vulkan producer owns its device and renders a spinning cube, exports the frame as a dma-buf with its modifier and a sync_file, and GPUI's renderer imports it in place. Dragging turns the cube: the buttons occlude and keep their clicks, while the text panel claims nothing, so a drag across it still reaches the scene.
From a gpui_interop checkout; the core is a path dependency.
Example · interop_cube_dragHardware-decoded video, one element
VA-API decodes into driver-tiled NV12 surfaces, exports them as dma-bufs, and GPUI samples them in place. The application writes video().source(path).controls(true); playback is paced to the stream's frame period and the default control bar is HTML5-shaped.
From a gpui_video checkout; the core is a path dependency.
Example · playerSixteen by sixteen decoders
A wall of independently decoded videos, each pane its own decoder and its own frame, with live FPS and CPU metrics in the header. The mode chip switches the handover between zero-copy dma-buf and CPU read-back; --morphorm, with the morphorm feature, runs the same grid on the second layout engine.
From a gpui_video checkout; the core is a path dependency.
Example · gridA project here is not a showcase. It is the proof of a claim, or a bug report against one — so each is filed by which boundary it tests.
| # | category | what it does | the knobs |
|---|---|---|---|
| 1 | New flavour of a swappable | A second implementation of an SPI that already exists. | TextSystem, LayoutEngine, SceneRenderer, Platform |
| 2 | Decorating a swappable | Wraps an existing implementation, adding a capability. | A FramePipeline wrapper — pacing, tracing |
| 3 | New authoring surface | Adds to the DSL rather than to a backend. | A new element or builder above div |
| 4 | Combined | More than one of the above in one project. | — |
Named so the gaps are visible, not so they can be counted. None of these
has results yet, and none is listed with any.
pipeline-decorator
is no longer pending:
bite-gp-pass
and its pass_demo
and pass_lab examples above are that project.
A Platform that needs no display, so a CI job can render.
A SceneRenderer out of tree, which is what a raw render-pass blit would have to be.
A new element built on the public authoring surface alone.
A benchmark has two columns, or it says why it does not: two implementations of one trait, the same inputs through each, and the difference is the finding. One implementation measured alone is a property of that library; only two, run through the same boundary, is a property of the architecture.
Anything measured is measured by a committed benchmark, and the run is recorded with the exact command, the toolchain and the machine next to the project it belongs to. A number without a record is a claim, and the site cites the record rather than the number.