click to photon
Dotted: where people notice latency, by task and device: Ng et al. 2012, dragging, direct touch, 6 ms; Jota et al. 2013, tapping, direct touch, 24 ms; Forch et al. 2017, mouse, median observer, 60 ms.
hand
The hand moves the mouse with the button held.
The chain starts as biomechanics. No coordinate exists yet; the computer will only ever receive what a sensor makes of the surface sliding under it, and whether a switch is closed.
Time across, rows down. Each refresh is a vertical blank, then a sweep from the top row to the bottom. The stroke's row, 50% of the way down this screen, is reached where the sweep crosses it.
A page sees none of the mouse, the cable, the monitor or the light: those stages are the model's.
Work and waiting
Between a hand moving a mouse and light leaving a subpixel, every stage is one of two kinds. Some are work and take a fixed time: a sensor frame, a driver, a render, a monitor's scaler. The others wait for a clock that runs without regard to the hand: the USB host polls the mouse every , an application starts a frame every frame interval, the display latches a new buffer at each vertical blank. An event arrives at a random phase of each clock and waits a time uniform between zero and the period , so the latency is
The fixed costs move the distribution; only the waits widen it. Its exact shape is the convolution of the waits' boxes, computed here on a 10 µs grid and checked against a sampler of the same stages.
Most of it is the display
An application drawing in a window waits half a refresh, on average, for the vertical blank at which its buffer is latched. The compositor builds the desktop from it on that refresh and the result is scanned out on the next: one more refresh. The scan then takes a fraction of a third refresh to reach the row. At 60 Hz that is about 33 ms before the pixel even starts to change. Casiez and colleagues put a photodiode on such a setup in 2017 and measured 36.6 ms from button press to light; doubling the refresh rate saved 15.5 ms, and the model, with no fitted constant, gives 35.9 and 16.7.
The mouse
A USB mouse cannot send a report; it waits to be polled. At 125 Hz the wait averages 4 ms and spreads every click over 8 ms with a standard deviation of ms; the measured spread was 2.1. At 1000 Hz the wait averages half a millisecond, and past that the mouse is no longer where the latency is.
Frames in flight
A game reads input once per frame, so the click waits up to a frame to be read, then the render. When the CPU can prepare frames faster than the GPU or the display consumes them, the queue between them fills, and every input waits behind the frames already in it. The frame rate does not show it: a game that is GPU-bound at 72 frames a second with three frames allowed in flight spends 27.8 ms of its 63 ms waiting in the queue, and limiting the queue to one frame removes them without costing a single frame per second.
Where on the screen
With vsync the display draws top to bottom, so a stroke at the bottom of the screen appears most of a refresh after one at the top; the playground reads the stroke's row from where it is on the physical screen. Turning vsync off flips the buffer mid-scan: the row updates on the scan's next pass, a uniform wait of up to one refresh whatever the row, and the frame is torn where the old and new images meet. A strobed backlight goes the other way: every row is lit at once after the whole panel has settled, so the motion is sharp and the full scan is always paid.
What people notice
The threshold depends on what is being done and with what. Dragging an object under a finger on a touchscreen, people notice latencies down to about 6 ms (Ng et al. 2012); tapping, about 24 ms (Jota et al. 2013). With a mouse the median observer notices about 60 ms in total, and observers with fast-game experience notice less (Forch et al. 2017). The distribution's tail matters as much as its mean: a click that lands just after a poll, a frame start and a vertical blank waits for all three.
What a page can see
A web page sees three of the clocks: animation frames, which fire once per refresh; input timestamps, taken when the browser receives the event; and, where the Event Timing API exists, the time from a slow event to the next paint, rounded to 8 ms. The probe beside the scan diagram measures this machine's refresh rate and the wait from each stroke's events to the next frame, which the model says is uniform over one refresh. The mouse, the cable, the monitor and the light are beyond what a page can measure; they stay the model's.
Limits
Compositors differ: on Windows at 144 Hz the measured latency is 5 ms above the model's, so that compositor adds more than one refresh or more fixed time. Pixel transitions are exponential here and shaped by overdrive in real panels. The values in the layer stack that a page cannot observe, addresses, voltages, packet contents, are marked illustrative. Each assumption is listed with what would falsify it.
Eight of the ten calibration cases are photodiode and probe measurements from one published study; the model is set to the measured machine and fitted to none of them.
Model
- the ideation assigned each layer an invented cumulative time, 0 to 4.7 ms in all. Here each layer belongs to a stage of a latency model, and its time is the model's: the chain from mouse to light takes tens of milliseconds, most of them waiting for clocks.
- waits for clocks independent of the hand, the poll, the frame, the refresh, are uniform between zero and the period; fixed costs are constants. The total's distribution is their convolution, computed exactly on a 10 µs grid and checked against a Monte Carlo sampler of the same stages.
- a composited window costs one more refresh than a fullscreen application. With it, the model reproduces the 15.5 and 15.9 ms that Casiez et al. saved by doubling the refresh rate, and their 36.6 ms at 60 Hz to 2%, without a fitted constant; on Windows at 144 Hz it falls 5 ms short, and says so.
- the scanout delay depends on where the stroke is on the physical screen, read from the pointer event: a stroke at the bottom of the screen reaches the panel most of a refresh after one at the top.
- frame loops are modelled separately from event-driven applications: input waits for the next frame, and when the CPU outruns the GPU or the display, frames queue ahead of it. The GPU-bound preset shows the queue as the largest stage, and limiting it to one frame removes it without changing the frame rate.
- the ideation's placeholder screen coordinates and window offsets are replaced by the ones the browser reports for the stroke; byte offsets are computed for the canvas's real width. Addresses, voltages and packet contents remain illustrative and are marked so.