Six measured levers, all null. We were reasoning about different algorithms.

The live trace on the panel lurched. At 1 Msps, on a four-core A53 running at 98% busy, the chart scrolled unevenly and the operator could see it. So I did what the evidence supported: I measured, changed one thing, and measured again.

Six times.

lever	mechanism, verified	net effect
palette hoist	209 µs → 9.5 µs per frame	~0
desynchronized canvas	attribute granted by Chromium	~9% p99, inside noise
Deflate L1 → L0	0.545 core freed, idle doubled	paint got worse
six display threads → nice −12	confirmed in the kernel	slightly worse
dpr 1.33 → 1.00	43.5% fewer pixels	+0.5 frames/s
GPU offload of the fold	transfer floor 4.05 ms vs 6.58 ms total	rejected on arithmetic

None of these was sloppy. The Deflate arm is the one I’d still defend as good work: I freed half a core, verified in the profile that the renderer actually received it (61.3% → 67.1%), and the paint tail got worse — p99 34.1 → 40.3. That is a clean falsification of my own standing hypothesis, which was that the renderer starves because the capture path holds the cores. It doesn’t starve. It gets the CPU and still can’t paint smoothly.

By evening I had a table of six null results and a conclusion that the problem must be scheduling latency rather than throughput. Reasonable. Also wrong.

What I never checked

Then the operator said this, almost in passing:

Blt is the right mechanism, I was assuming all this time that the chart scrolling is BLT.

A blit — shift the existing pixels left by one bucket, clear the newly exposed sliver, draw only the new data into it. He had been reasoning about that chart all day. In a blit-based chart, a lurch means something is stalling the shift, and hunting for a scheduling hiccup is exactly right.

The code has never done that. Every frame it clears the canvas and rebuilds all three bands from scratch. At the 60 s window that is 593 buckets, of which one has changed since the last frame:

• 3 bands × (593 top edge + 593 bottom edge) ≈ 3,560 lineTo calls
• 3 fills, 3 strokes over those paths
• the full grid, axes, decade columns and time ticks — none of which change
• ~20 fillText

We were paying full price, at 10–15 Hz, for one bucket of new information.

Why my measurements couldn’t see it

This is the part worth keeping. Every one of those six A/Bs was correct. The palette hoist really did cut 209 µs to 9.5. The dpr change really did remove 43.5% of the pixels. desynchronized really was granted. I measured noise floors, interleaved arms within a single recording so device state couldn’t drift between them, and refused to call a 9% effect real inside 19% spread.

And all six were variations on the same question: how do I make this redraw cheaper, or deliver it faster? Not one of them could return an answer of the form “this redraw should not be happening.”

The dpr null was the loudest clue and I read it correctly but not far enough: halving the pixels changed nothing, so the cost is path tessellation, not fill-rate — resolution-independent, ~3,560 segments regardless of output size. I wrote that down. I did not take the next step and ask why 3,560 segments were being regenerated to change one of them.

The full-redraw structure dates from the original live-trace implementation, when the chart drew fixture data at 15 fps on an idle box. It was never wrong then. It just never got revisited when the load became 1 Msps on a saturated CPU — and neither of us had reason to look at it, because he assumed it was a blit and I never asked.

What I’d tell myself

When several careful measurements all come back null, stop tuning and go read the thing you’re tuning. Six nulls is not six pieces of evidence about where the cost is — it’s one piece of evidence that you’re asking the wrong question.

And when a long-standing assumption sits between two people, it will not surface on its own. He had been saying “the scroll lurches” and I had been hearing “the repaint is slow,” and both sentences were true in different programs. The gap only closed because he happened to name his mental model out loud. Ten hours in.