---
title: "The Acceptance Bar That No Implementation Could Ever Clear"
canonical: https://dxdev.com/blog/2026-09-07_the-gate-that-was-arithmetically-impossible/
datePublished: 2026-09-07
---
## The gate that no implementation could pass

Exit code 4. That was `Spike.Meter`'s verdict on the first real matrix run against the gate we'd written into the phase-1 spec for a Windows shell decorator: two physical pixels of error for 99.9% of sampled frames during a drag, no sustained lag past one refresh interval. Two separate passes had signed off on that same number, a design review of the original ticket and then the phase-1 slicing document that turned the review into a testable spec. It read as rigorous. It also turned out to be arithmetically impossible for any implementation to pass.

The thing being built is a small overlay window, `Spike.Tracker` in the spike, that has to sit flush above another process's window and follow it in real time as it's dragged around the desktop, the way an existing Windows window-tabbing utility already does. The design review had already flagged a real constraint on the mechanism: `SetWinEventHook` on another process is normally delivered out-of-context, queued through the registering thread's message loop, with no guarantee about which composited frame the callback lands in. We built the first spike to find out whether that mattered in practice. `Spike.Target` is a plain popup window with four 16x16 fiducial markers baked into its corners. `Spike.Tracker` is the WinEvent-hook decorator under test. `Spike.Meter` runs DXGI Desktop Duplication on the same monitor, scanning every composited frame for those markers and computing error and lag from pixels, never from `GetWindowRect`. `GetWindowRect` tells you what the window thinks its position is. The meter tells you what actually got drawn.

We spent the better part of a week assuming the gate was reachable and that a failing run meant a bug. `Spike.Tracker` ships four strategies: `A` chases the WinEvent hook, `B` rides an owned window that needs nothing per frame, `D` polls every 250ms, and the spec's default pick was A. Runs against strategy A came back consistently short of 99.9% inside 2px, so we did what you do when a number looks close: we tuned. Different z-order modes (`after-target` versus `keep` versus `topmost`), tighter coalescing in the hook callback, stripping every allocation out of the render path so GC would never fire mid-drag. Each change moved the histogram a little. None of them touched the tail. We burned real spike time chasing a number that had nothing to do with the tracker's code.

The `--inject-delay` flag is what broke the assumption. It applies every placement N nominal refresh intervals late on command, a known deliberate lag, so you can confirm the meter actually detects lag instead of just reporting favorable noise. Running it at `--inject-delay 0`, no injected lag at all, on top of an already-optimized strategy A, still failed the pixel gate under `--synthetic drag` at real drag speeds. That's the point the question flipped from "why is the tracker slow" to "what is this gate actually demanding."

The arithmetic is short. Positional error on a moving target is velocity times lag. A hand-driven drag isn't a fixed speed, the first spike's own `drag` mode drives the real cursor through `SendInput` with a hand-like wobble, and normal fast drags land somewhere around 500 to 1800 pixels per second. At 60Hz, one refresh interval is 16.7ms. A single frame of lag, the same frame that the WinEvent hook's out-of-context delivery already costs before any of our code runs, works out to 8 to 30 pixels of positional error at those speeds. The gate asked for under 2 pixels, 99.9% of the time, during exactly the condition that produces 8 to 30. No z-order mode, no allocation-free render path, no amount of hook coalescing closes that gap, because the gap was never in the implementation. It was in treating pixel error and frame lag as the same measurement.

What replaced it measures the thing that's actually true or false about the mechanism: lag counted in frames, and the variance of that lag, not its pixel translation. A decorator that's reliably one frame behind, every time, at any drag speed, reads to a human eye as attached, because the offset is constant and the brain folds a fixed lag into the object. A decorator that's sometimes zero frames behind and sometimes three, same average lag, reads as broken, because the *change* in offset is what your eye actually tracks. `Spike.Meter` already had the raw material for this in `frames.csv` and its per-segment lag fields; the fix was to stop collapsing that into one pixel-error number and start reporting the distribution and its spread instead.

A gate that a correct implementation can't pass isn't a stricter bar, it's a broken instrument, and it will fail people for the wrong reason every time it runs.