A file format, the machine that runs it, and the proof that it works.
Sean “Mook” DiMarco · source on GitHub · sfdimarco.github.io
Most graphics formats ship the finished picture — every point, every frame, written down. This one ships the recipe: a 2,320-byte program that the machine runs to bake the picture fresh, 135× smaller than what it produces.
The recipe is not the interesting part. Normally a program says “keep going until you’re done,” so the computer cannot know how much memory to reserve — it grabs some, fills it, throws it away, grabs more. That scrambling is where the time goes. So the language has no way to say “keep going until.” You can only write things whose size can be counted before execution starts. One allocation, chosen up front, never replaced.
The language was made weaker on purpose. That is the thing that made it fast.
.geo program builds and poses the figure. Drag to orbit it. The pose is resolved inside the VM — JavaScript resolves nothing.
Sprint 0
The instrument
The engine with its own measuring rig attached. Move the resolution slider and watch each phase of the frame cost respond live.
Readout
2,320 Bytes
The written result: what was built, what was measured, how it was measured, and what the measurement does not cover.
| Result | |
|---|---|
| Mesh build, this runtime vs. the JavaScript engine it replaces | 0.195 ms vs 1.960 ms — 10.0× |
| The whole program that draws the character | 2,320 bytes |
| Output checked against the original, point by point, at 14 moments along the plan | byte-identical |
| Deliberately corrupted programs thrown at the loader | 4,000 → 0 crashes |
Full proof suite, one command (./test.sh), six gates | ~90 s, all green |
The 10.0× was measured on one reference machine. The live demo above reports its own timings on yours — and measures the GeoV baseline in the same frame — so the multiple it shows will differ from this one. That in-frame comparison is the honest number; this row is the one from the recorded run.