xpui-embedded-graphics

An xpui backend that draws through any embedded-graphics DrawTarget — which is most of the embedded Rust display ecosystem: e-paper panels, SSD1306 and friends, colour TFTs, and the desktop simulator.

Using it

[dependencies]
xpui-embedded-graphics = { git = "https://github.com/XPUI-Framework/xpui-backends", branch = "main" }

let backend = Backend::leak(display, Palette::new(BinaryColor::On, BinaryColor::Off));
unsafe { xpui::host::install(backend) };

let mut app = App::new(MainMenu::new());
while app.is_running() {
    backend.begin_frame(millis_since_boot());
    backend.press(Button::Down);        // from wherever your input comes from
    app.tick();
    if app.render_if_dirty() {
        backend.clear_dirty();
        backend.with_display(|display| display.flush());
    }
}

It supplies Canvas and TextMetrics itself — the contract for all five is docs/host.md — InputSource and Clock from whatever you feed it — bar has_left_right_keys, which is a fact about the hardware and so is told to it: with_left_right_keys(true). Left unsaid it answers false, which costs a keystroke on a device that has the pair and is the only direction that stays usable if it is wrong. It takes Chrome from xpui-chrome — so a list, a dialog and a slider look like something without you drawing one.

Checking it

The gate is the repository's; run ./build-and-test.sh from the root.

Where next

docs/design.md	monochrome by design, the faces it ships, input, clipping through the target, and bringing your own type
docs/screenshots.md	render to memory and compare against a committed PNG, including why the first run fails
docs/hardware.md	what a parallel-bus panel taught: why PacedFill exists