Each project here depends on the published crates by version — not a path into a checkout, not a git revision — and exercises one swappable boundary from outside the tree. A boundary that only works from inside is not a boundary.
All three build today against published crates, by version, resolved from crates.io. 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 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_morphorm
The published bite-gp-engine 1.21.0 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.
A 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, FramePipeline, Platform |
| 2 | Decorating a swappable | Wraps an existing implementation, adding a capability. | A FramePipeline or Platform 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.
An out-of-tree FramePipeline wrapper, and what its per-frame overhead is.
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.