The math behind Brilliant's renderer: a budget of nanoseconds per pixel

Every architectural decision in Brilliant's renderer comes down to one piece of arithmetic. A display frame at 60 Hz is 16.7 milliseconds. A modern laptop viewport is somewhere between 2 and 15 million device pixels. Divide, and you get the entire budget for everything the engine does, end to end: between one and eight nanoseconds per pixel, per frame.

One nanosecond is about three clock cycles. That number is the renderer's whole worldview, and this post is a tour of the thinking that follows from it: what things cost, why some caches are provably a bad idea, and what happens on hardware where the arithmetic stops working.

The two currencies

GPU work is paid in two currencies, and they fail differently.

Bandwidth is bytes moved. A backdrop-reading effect like frosted glass reads the pixels behind it, blurs them, and writes them back, which is a lot of traffic per pixel. On a discrete GPU that is almost free. On an integrated GPU with a fifth of the bandwidth, it's the first thing that saturates.

Driver overhead is the sneaky one: fixed per-operation costs that don't care how many pixels you touch. We learned this the expensive way. A user's canvas with a few hundred glass elements produced frames where the GPU work measured fine but the frame took 170 milliseconds anyway. The fix wasn't faster shading; the per-pixel math was already cheap. The overhead lived on the driver's side of the line, and a structural change to how that work was handed off dropped the same content from 170 ms to half a millisecond. Same pixels, same math per pixel, two orders of magnitude difference, because we had been paying in the wrong currency.

Sharp at every zoom, without a cache

Curves in Brilliant stay sharp from 2% zoom to 5300%, and the engine never pre-renders anything per zoom level to get there. When a user once photographed faint waviness on a wide shallow curve, the fix stayed inside that same approach rather than bolting on a special case, and the waviness went away everywhere at once instead of at one hand-picked zoom. Sharpness that holds across the whole range, not a table of pre-rendered levels.

That is also the case against zoom-keyed caches, the ones that render something at one zoom and reuse it at another. Stretched reuse blurs in proportion to how far you zoomed, and re-baking on a zoom change costs a full render right when the gesture needs the frame. Live evaluation has neither failure mode, and when we finally benchmarked our most sophisticated zoom-keyed cache against it on real documents, live won on speed too. That story, with its numbers, is in the rust engine post.

The worst case is not the real case

Here is the lesson from this year's work that we find genuinely instructive. Our most demanding effect needs to know, for every pixel near a shape's rim, how far that pixel is from the shape's edge. A complex shape (a boolean of a whole word of text, say) can have tens of thousands of edge segments. Budget naively, cost per pixel against total segments, and the arithmetic collapses: we measured the worst constructible cases at hundreds of milliseconds per frame.

But worst-constructible is not what real shapes cost. Once we stopped trusting the scary arithmetic and measured what the effect actually does on real "monster" shapes, the honest cost came in orders of magnitude lower than the naive budget implied. A document that used to route to a lower-quality fallback now evaluates exactly, live, in 0.2 to 0.3 milliseconds per frame across the entire zoom range.

The general lesson is duller than the scary number and more useful: measure the real work before you believe a worst case, because a global count is how you scare yourself into building caches you don't need.

What the measured anchors say

Numbers, from our reference workstation (an M4-class Mac driving up to 15 megapixels; treat these as one machine's measurements, not universal constants):

• Full glass effect, all-in, at total-viewport rim coverage: about 1.2 ns per device pixel. Of that, only a small slice is the exact geometry evaluation; the bulk is the bandwidth-bound optics tail (backdrop grab plus blur) that any implementation pays.

• 1.2 ns/px × 14.7 Mpx ≈ 17.6 ms: right at the frame budget, and that is the worst constructible case, a rim covering every pixel on a 5K display. The same scene at a more typical 7 Mpx viewport is ~8.5 ms, comfortable.

• Real documents are nowhere near the worst case: a 4,919-element production document measured 0.10 ms of glass evaluation at the median across a 0.02-to-53 zoom sweep.

Now the extrapolation, clearly labeled as such. An integrated GPU has roughly a tenth of the compute and a fifth of the bandwidth of that workstation, so both halves of the cost get several times worse. Sounds fatal, except for the law that quietly rescues every budget in this post: weaker machines drive smaller viewports. An integrated-GPU laptop pushes 2 to 4 megapixels, not 15. At the small end, even worst-case saturation lands right at budget; partial glass coverage, the actual common case, fits with a wide margin.

And at the top of the iGPU range, full-viewport saturation honestly does not close: the arithmetic says tens of milliseconds no matter how clever the code, and the caches we deleted wouldn't have closed it either, since the bandwidth tail dominates. That case is why our rendering contract has an honest-degradation value: when the math says no, the answer is a deterministic, visible, reported reduction that settles back to exact one frame after rest, never a silent quality trade.

Measuring without fooling yourself

One more family of math matters here: the statistics of measurement, because per-pixel nanoseconds are exactly the kind of number a machine will lie to you about.

Thermals move everything. We measured the same workload 5.5x slower hot versus cold, uniformly. So no performance gate in our suite asserts absolute milliseconds; every gated measurement is a ratio against a reference workload measured under the same conditions, and the ratio stays put while the absolute numbers swing. GPU timing has its own failure modes on top (asynchronous readbacks, saturation, debug-build inflation), and every report is stamped with enough context that nobody judges a number captured under conditions that invalidate it. The full philosophy is in the jank post; the one-line version is that a measurement pipeline needs error analysis exactly like any other instrument.

The point

None of this math is exotic. It's division, a cost model, and some care with statistics. What makes it valuable is that it's written down and every renderer decision has to survive it: features get a cost model before they get an implementation, optimizations get an A/B against the thing they claim to beat, and when a beautiful idea loses to arithmetic, the arithmetic wins. The nanosecond budget isn't a limitation we resent. It's the sharpest design tool we have.