The preview is not a mock

Every configurable display device shows you a preview. Almost all of them are lying a little: the preview is a web rendering, the device is a firmware rendering, and the two are maintained by different code written by different people with different bugs. It is usually close. It is never the same.

On this panel, the picture in the browser is produced by the firmware’s own scene interpreter. Same C, compiled for the host. Not a port, not a reimplementation, not a designer’s mockup — the preview and the panel run one renderer, so there is nothing for them to disagree about.

Even the interactive hero on deskboy.sh is built that way. Those are not screenshots and not a designer’s file; they are frames the firmware’s scene interpreter produced, via the same simulator, exported one per second.

Keeping it true cost more than building it

For a while there really were two renderers. The device drew scenes; the companion’s card preview drew a set of C templates. (The companion was a desktop app then. It is a web page now, and the preview survived the move because it never belonged to the app.) To stop them drifting I built a parity gate: 1,581 lines of test comparing the two, backed by 2,170 lines of oracle C that existed for no reason except to be compared against.

It worked. Six faces, byte-identical.

Then I moved the preview onto scenes — and the gate was suddenly comparing a thing to itself. So it went, and the oracle went with it, in one commit.

The evidence that the deletion was safe is the repin. Pointing the golden tests at the scene path reproduced every surviving frame byte-for-byte, with exactly one frame moving — a mid-countdown progress ring, whose divergence the deleted code had already documented, because the oracle advanced from the simulator’s fake-tick anchor while a scene consumes the snapshot it was handed. That one got re-blessed to the deterministic value.

The gate was not wasted work. It was the scaffolding that let the second renderer die without anyone noticing a pixel move.

Why this is the claim I care about

A competitor can copy a feature list in a sprint. What they cannot copy in a sprint is the decision, taken early and paid for repeatedly, that there is exactly one renderer. It is the kind of property you either have from the start or spend two years retrofitting.

And the landing page is itself the demonstration: the panel you can tap in the browser is drawing through the same interpreter the hardware on my desk is.

One thing it does not prove. These are honest about rendering — they are the pixels the scene renderer produces, from the C the device runs. They are not photographs. That the object exists and works on a real desk is a separate claim, and photographs have to carry it.