Why maintain an engine fork? Swap your text shaper or layout solver with a single line in Cargo.toml, or wrap the frame pipeline to pace it and read every pass. Your existing div() views stay completely untouched.
The distinction is not stylistic: it decides which seam a crate can plug into and what publishing it commits the project to. Everything below is one of the two.
Implements one of the seam traits and is installed at bootstrap in place of the default. One implementation per seam, chosen when the application is built.
Implements FramePipeline and delegates: handed every pass of every frame it admits, it forwards the ones it does not change and wraps whatever pipeline is already installed.
Every swappable boundary is defined in a standalone layer crate, backed by a default implementation, and re-exported under use gpui::*. Two have a published second implementation; the other three do not, and this page says so rather than implying one.
Text shaping, line layout, and glyph rasterization.
Application::with_text_system(Arc<dyn TextSystem>)
Translating the reactive element tree into positioned layout boxes.
Application::with_layout_engine(impl Fn() -> Box<dyn LayoutEngine>)
Pacing, presentation order, and render instrumentation.
Application::with_frame_pipeline(impl Fn(WindowId) -> Box<dyn FramePipeline>)
The frame governor the one-pager shows is configuration of this default — ThrottledPipeline and InstrumentedPipeline, both in gpui_runtime — rather than a second implementation. Nothing out of tree publishes one. It is also the one seam a wrap can plug into.
The open seams →OS event loop, display handles, clipboard, and input routing.
Application::with_platform(Rc<dyn Platform>)
The hook is the constructor, so a platform is chosen with the application rather than chained onto it.
The open seams →Lowering the scene intermediate representation (IR) into GPU drawing commands.
none — the trait is the boundary
No Application setter installs one today: the trait is the boundary, and the platform picks the implementation. A second one needs a door before it can be a crate.
The open seams →One wrap is published from its own repository; two ship inside the facade as decorators you can stack without depending on anything. All three implement the same trait, and all three forward the passes they do not change.
Reads the frame's passes and the asks that did not draw: a policy-driven rate on one side, a ledger of what each pass cost on the other. A decorator you install without changing a view.
lib: gpui_pass
Using gpui_pass →The facade's own rate cap: draw every Nth ask, decided from one number and the last frame.
lib: gpui_runtime
The facade's own accounting: an Instant around each root pass, summed into running phase totals.
lib: gpui_runtime
A wrap implements FramePipeline and delegates. Every pass has a default that calls the Window method behind it, so a decorator is only as transparent as the passes it explicitly forwards — which is the whole of the contract.
A wrap goes where any pipeline goes — the factory you hand to with_frame_pipeline — and stacks in any order and any number. Nothing in the tree is forked, so there is no patch to rebase when the engine moves. The published one is bite-gp-pass, and cargo add bite-gp-pass is the whole of its install.
The two published swaps are ordinary crate dependencies. Nothing in the tree is forked, so there is no patch to rebase when the engine moves — and because each published package keeps its library target name, use gpui_parley::… and use gpui_morphorm::… are what your code already says.
# both published swaps, one manifest
[dependencies]
bite-gpui = "1.21"
bite-gp-parley = "1.21"
bite-gp-morphorm = "1.21"use gpui::*;
use gpui_morphorm::MorphormLayoutEngine;
use gpui_parley::ParleyTextSystem;
fn main() {
application()
.with_text_system(ParleyTextSystem::new())
.with_layout_engine(|| Box::new(MorphormLayoutEngine::new()))
.run(|cx: &mut App| { /* the same div() tree */ });
}We explicitly document the three unbuilt seams so external contributors know exactly where the architectural boundaries lie:
| seam | what it would take | filed as |
|---|---|---|
| FramePipeline | An out-of-tree pipeline. The shipped decorators are the pattern: a decorator forwards the passes it does not change and decides the ones it does, so a third-party one would wrap or replace StandardImmediatePipeline at the same hook. | pipeline-decorator |
| Platform | A platform that needs no display, so a CI job can render. The built-in route is the facade with its platform bundle dropped — default-features = false — plus the TestPlatform the test harness already runs on. | headless-platform |
| SceneRenderer | A renderer out of tree, which is what a raw render-pass blit would actually have to be — and a door at the facade first, because there is no setter to install one through. | scene-renderer |
These are the categories the project files its own work under — a new flavour of a swappable, a decorator, a new authoring surface — and the demos page carries the whole taxonomy with what each category is for.
The wgpu renderer and the frame governor are on the one-pager's shelf,
but neither is a swap: WgpuRenderer is the scene renderer
the Linux platform installs, and the governor is
StandardImmediatePipeline.max_fps(60) with
.instrumented(…) — shipped decorators, configured rather
than installed. The seam that replaces the renderer is
SceneRenderer, and it has no hook yet.
The Combo Studio is the interactive version
of this shelf: it stacks the add-ons and the platform backend, and shows
the
main.rs they produce. Two of its four add-ons are the
published crates above; the others are shipped configuration, as the
panel itself says.
The three crates, and the repositories they are developed and released from.