Drag directness requires end-to-end latency below a perceptual threshold
Aliases: end-to-end latency · directness · direct manipulation
What it is
Directness in touch dragging requires end-to-end latency from finger motion to screen update below a perceptual, control-disrupting threshold. It includes sampling, system processing, app logic, rendering, composition, and display scan; optimizing one stage alone does not make an object feel directly attached to a finger.
Why it happens
People continually correct finger trajectories from visual feedback. Latency makes displayed position trail the real finger, slowing the control loop; people move farther or brake early, producing oscillation and overshoot. What is genuinely easy to underestimate in this chain is not each stage's own computation time but the fact that every stage runs on its own fixed tick: touch sampling has its own refresh interval, the app's event loop is pinned to the display's refresh cadence, and the compositor and display panel each have their own presentation cycle. When data hands off from one stage to the next, it often has to wait for the receiving stage's next tick before being processed, even if the actual computation for that step is instantaneous — wasting nearly a full cycle for nothing. These waits accumulate across multiple hand-offs, so even when every individual stage is fast, total end-to-end latency can be far higher than simply summing each stage's processing time.
Studying it
Measure finger-to-photon timing, not event-handler cost alone. Across speed, direction, and drag tasks, record path error, corrections, perceived directness, and dropped frames. Test light load, concurrent animation, and network updates to find latency spikes, not only averages. A genuinely reliable method films the finger and the screen simultaneously with a high-speed camera and counts, frame by frame, how many frames elapse between the finger reaching a position and the screen responding — this motion-to-photon measurement captures presentation delay that software timestamps cannot see; a short event-processing time recorded in software does not guarantee an equally short true end-to-end latency.
Where it stops holding
Acceptable threshold varies by task, refresh rate, speed, and sensitivity; no single millisecond value is absolute. Static taps tolerate more delay than drawing or fast dragging. Prediction can mask some lag but cannot replace stable low latency.
Applying it
- Shorten the input-to-presentation path and avoid main-thread or layout blockage during drags.
- Maintain frequent stable visual updates and monitor long-tail frame time.
- Move complex computation, network commit, and nonessential animation outside the gesture-critical loop.