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. Reuse is held to a strict correctness gate against the true current state, and 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 engine architecture we described in the engine post: keep per-frame work proportional to the pixels actually on screen rather than to the size of the file. 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 we rebuilt the input path so the freshest input reaches the renderer 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 engages only on real measured evidence of a wall, and resuming is an honest retry that backs off 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. Each value above has its own automated gate: correctness has strict oracles, sharpness has checks that a frame drawn mid-gesture matches the same frame at rest, smoothness is measured as ratios over real captured documents so a noisy CI machine can't fake a regression or hide one (the jank post covers why), immediacy has a probe that fails if input latency creeps back up, and degradation is counted so every degraded frame shows up 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 comes down mostly to one idea: the relationship between world space and screen space is simple, and worth trusting rather than caching around. Caches keyed on zoom fight that simplicity: 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: work proportional to the pixels on screen and to how much you changed, never to the size of the file. 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.