Performance work has a famous failure mode: you win the benchmark by quietly trading away something the user can feel. The frame rate chart goes up, and the tool got worse. A little blur during zoom. A selection outline that trails the shape it's selecting. An animation that stutters at a lower tick rate instead of stuttering at a higher one. Each trade looks reasonable in isolation, and together they are how fast software ends up feeling cheap.

We decided to write the trades down before they tempted us. Brilliant's engine work is governed by a written rendering contract: seven values that every rendering and performance decision gets judged against, in code review and in tests. The one-sentence version: every presented frame is a sharp, correct, immediate image of your document, regardless of canvas size, gesture, or hardware. The rest of this post is the seven values, and the moments each one earned its keep.

1. Truth

Every pixel on screen derives from the current state of your document and the current camera. Stale content never presents. Not for a frame, not during a gesture, not "just until the cache warms up."

This sounds too obvious to write down, and that is exactly why it's written down. Almost every rendering optimization is, at its core, a scheme for reusing old pixels. Retained layers, damage tracking, incremental updates: all of them are bets that yesterday's work is still valid. The value doesn't forbid the bets. It forbids losing them silently. Our incremental pipeline is continuously tested against a from-scratch render of the same state, and the two must agree to the byte. The moment reuse and truth disagree, reuse loses.

2. Sharpness

Every pixel is correctly sampled at the current camera. No under-sampling, no stretched reuse of something rendered at another zoom, no upscaled stand-ins while the real thing loads. (Blending many tiny elements into one pixel when you zoom far out is not a violation; that's what correct sampling means at that scale.)

Sharpness is the value that keeps catching real bugs, because the tempting way to make zoom fast is to render once and stretch. We shipped a version of that idea for our most expensive effect, and at deep zoom a user photographed the result: a silhouette with visible stair steps, magnified texels pretending to be geometry. The fix wasn't a bigger bake. The fix was evaluating the effect against the live camera, exactly, every frame, and then proving with measurements that exact was also faster. Where a bounded approximation genuinely must exist for pathological content, it's resolution-matched, documented, and scheduled for deletion, not celebrated as cleverness.

3. Smoothness

Every frame fits the display budget, and per-frame cost is a function of the viewport, never of document size. If some work scales with the number of elements in your file and runs every frame, that is a bug by definition, even when the file is small enough that nobody has noticed yet.

This is the value behind the delta wire and retained scene we described in the engine post: serialize only what changed, retain everything else, and keep per-frame work proportional to the pixels actually on screen. A 13,000-element document and a 200-element document should cost the same to pan, because panning shows you the same number of pixels either way.

4. Immediacy

Input-to-photon within one display frame of the compositor's floor. The camera you're zooming and the elements you're dragging are sampled at render time, from the freshest input, not relayed through pipeline stages that each add a frame.

We measured our own drag path and did not love the answer: input was being relayed through the UI pipeline with about two frames of depth before it reached pixels. So the input path was rebuilt to write into live slots the render thread samples directly at frame start, and the measured depth dropped to under a tenth of a frame. The chrome came along too: selection rectangles and handles ride the same live transform the content rides, so during a fast drag the outline stays glued to the shape instead of chasing it.

Immediacy also covers feedback, and this one is a standing rule with a veto behind it: we never gate, pace, or debounce live UI to buy frame time. If the inspector updates live during a marquee sweep, it keeps updating live; an optimization once tried to suppress that and got reverted with a test pinning the behavior so it can't quietly return. The legitimate fix for expensive feedback is making the feedback path cheap, never making it less alive.

5. Uniformity

The contract holds identically across every gesture and every device class at its native resolution. Zoom, pan, drag, resize, rotate, text editing: none of them gets a worse deal than idle. There is no "it's fine, that only happens during zoom."

Uniformity is why we distrust special-case caches keyed on gesture state. A path that only runs during a particular gesture is a path with its own bugs, its own latency, and its own slightly different pixels, which means the contract now has an asterisk. The same reasoning applies across zoom levels: routing decisions in the engine are pure functions of geometry, not of zoom bands, so nothing pops or swaps representations as you move through scale.

6. Honest degradation

Users can construct content that exceeds any hardware: stack enough backdrop-reading effects, animate enough unbounded shaders, and the budget loses. The contract doesn't pretend otherwise. It demands that degradation be deterministic, least visible first, settled back to exact within one frame of rest, and reported. Degradation is a measured event, never a silent one. Correctness is never on the degradation ladder.

The hardest ruling here was about animated shader fills on a machine that's hitting a wall. The obvious move is lowering the animation's tick rate, and we built exactly that before admitting it fails the test that matters: when a single re-render exceeds the frame budget, a lower tick rate doesn't remove the jank, it re-times it into a stutter metronome. So the policy is binary. An animation is either playing at full rate and full resolution, or frozen, byte-exact, at the last rendered instant. Freezing arms only on measured evidence of a real wall, never on a prediction, and resuming is an honest retry with exponential backoff so a struggling machine sees a decaying trickle of attempts instead of a flapping loop. And we never pixelate: no resolution downscale ships on the default path, because a soft frame is a broken promise from value number two.

7. Enforceability

A rule isn't real until a gate enforces it. The gap between what a team claims and what is true is exactly the set of rules without tests, so every value above maps to specific automated checks, and a new rule lands together with its gate, in the same change.

This is the value that makes the other six more than a poster. Truth has its byte-level oracles. Sharpness has parity checks across zoom sweeps, including "gesture frame equals settled frame" comparisons. Smoothness has replay benchmarks over real captured documents, gated on ratios so a noisy CI machine can't fake a regression or hide one (the jank post covers why). Immediacy has a latency probe that fails if input depth creeps back up. Degradation has counters that make every degraded frame visible in the stats. When we retire an old behavior, the old path often stays available behind a switch for one release with its own tests pinning it, so the field can confirm the new way before the old one is deleted.

The math that makes it possible

A skeptical reader should ask: isn't this contract just expensive idealism? The reason it's affordable is mostly one idea: the world-to-screen relationship is simple, and worth trusting. World distance times zoom equals screen distance. A representation of your content that lives in world space and gets evaluated against the live camera is exact at every zoom with zero per-zoom preparation. Caches keyed on zoom fight this math: by construction they either stretch stale pixels (trading sharpness) or re-bake mid-gesture (trading smoothness). When we finally measured our most sophisticated zoom-keyed cache against live evaluation on real user documents, live was faster and exact. The full story, with numbers, is in the engine post.

The other half is the per-frame floor: shading proportional to viewport pixels, uploads proportional to what changed, everything else retained. Budgets then hold on weak hardware for an unglamorous reason: smaller machines drive smaller viewports.

What this buys you

You never think about any of this, which is the point. You zoom to 5000% and edges stay edges. You drag fast and the selection stays welded to the shape. You open a huge file and panning costs what panning costs. And when your content genuinely exceeds your hardware, the tool degrades in a way that is predictable, visible in its own diagnostics, and gone one frame after you let go.

Values are cheap to publish and expensive to keep. This set is enforced by tests we run on every change, and it has already cost us real work we were proud of: caches we measured and deleted, a tick-rate ladder we built and retired, latency we re-architected input handling to remove. That's the standard we intend to keep. If you ever catch a Brilliant frame breaking one of these, we'd genuinely like to hear about it.