Flutter terminal
The reference terminal renders 2D and 3D ops directly to a Flutter Canvas, with software-rasterized depth testing for 3D primitives.
Graphics vocabulary
PostGraphics
PostGraphics is a frame-oriented graphics vocabulary. A frame is a vector of operation records: datoms describing what to draw, not how to draw it. Producers emit frames; terminals render them.
Where traditional engines couple authoring, layout, and painting in one runtime, PostGraphics keeps them apart. An op like :draw/fill-circle is a value with center, radius, and color, nothing more. It can be inspected, diffed, replayed, sent over a network, or fed to any backend that knows the vocabulary.
The result is graphics that behave like data: explicit, composable, transport-independent.
PostGraphics frames flow through DaoStream . To understand why semantic streams beat pixel streams in the right contexts, read Structure vs Interpretation .
Inspired by PostScript
The name is a nod to PostScript, the language that pioneered the idea that graphics should be a program the renderer interprets, not a buffer the producer fills. Display PostScript and Sun's NeWS carried the conviction to live displays.
PostGraphics keeps that conviction and changes the form. Where PostScript is a stack-based source language parsed and executed by an interpreter, PostGraphics is a bytecode of op records driven by a VM. A frame is bounded (a finite vector of ops), data-shaped (each op is a map with explicit fields), and ships through DaoStream rather than embedded in document files.
The architectural conviction is the same: send the renderer an interpretable program, not a finished image. The execution model and packaging are what differ.
The Frame is Data
Each frame is a vector of op maps. Every op carries everything it needs: an :op/kind discriminator and the parameters relevant to that kind. There are no hidden draw calls and no implicit state outside the frame.
Because the frame is a value, you can:
- Replay it . The same frame input produces the same image, every time.
- Diff it . Compute what changed between two frames at op granularity.
- Annotate it . Wrap ops with metadata for inspection or telemetry.
- Transport it . Ship the frame over WebSocket, UDP, or the filesystem.
- Render it elsewhere . Producers do not pick the backend.
This is graphics in the Plan 9, Datomic, and Lisp lineage: programs as data, time as a sequence of values, identity by content rather than reference.
Stream-Based Rendering
Producers append frames to a DaoStream . Consumers read the latest frame and render it. That decoupling is the architecture: the producer does not call into the renderer, it publishes the next frame.
This makes ordinary patterns natural:
- Local animation: a timer pushes a frame each tick, the widget reads the latest.
- Remote rendering: a server emits frames over WebSocket, a thin client renders them at native fidelity.
- Replay: persist a stream of frames and re-render the session frame by frame.
- Inspection: tap into the stream from a debugger or recorder without modifying the producer.
PostGraphics defines the frame vocabulary, not how producers and consumers connect. The same producer can drive a Flutter widget, a screenshot job, or a remote viewer with no producer-side change.
Beyond Pixel Streams
AI visual browsers like Flipbook show a compelling direction: prompt for a page, click anywhere, and branch into the next visual world. The usual implementation path is to generate each page as pixels. PostGraphics suggests a stronger architecture.
Let the LLM do the semantic work. It interprets the prompt, decides what regions mean, chooses what a click continues into, and emits the next frame program. PostGraphics then carries that decision as explicit drawing ops instead of a full pixel buffer.
That changes the economics. A compact frame program is usually cheaper to emit, cheaper to transport, and cheaper to replay than a complete generated image. Text stays crisp, geometry stays precise, interaction regions stay explicit, and the same frame can be cached or re-rendered without rerunning image synthesis.
This does not mean giving up imagery. PostGraphics already supports images, but image payloads travel through DaoStream . That lets a frame mix vector structure, typography, transforms, clips, and streamed images in one causal pipeline. Use primitives where structure matters, use images where density matters, and keep both as inspectable values.
In that sense, the stack is not LLM versus renderer. It is LLM as interpreter, PostGraphics as bytecode, DaoStream as transport, and the terminal as executor. Compared with page-sized pixel generation, that buys lower latency, better caching, explicit provenance, and stable clickable semantics.
See the Flipbook website and the live demo . The key architectural question is not whether an LLM can paint pixels, but whether it can emit a structured visual program. PostGraphics is built for that case.
For Developers
PostGraphics gives you graphics that behave like the rest of your data: small, declarative, inspectable, transport-independent. You stop thinking about draw calls and start thinking about what the frame is.
Backend-neutral vocabulary
The op set is small and explicit. SVG emitters, TUI renderers, GPU command encoders, and headless rasterizers can all interpret the same frames.
Validation at the boundary
Terminals validate frames as they arrive. A malformed remote frame surfaces as an error, not a corrupted image.
PostGraphics is an interpreter, not an engine. It does not own your scene graph, your authoring layer, or your input system. It owns the vocabulary that crosses the wire between whatever produces frames and whatever paints them.
Explore DaoStream for the substrate that carries frames, or revisit Yin to drive frame producers from agents.