Input smoothing introduces latency, conflicting with directness

What it is

One straightforward way to suppress the jitter physiological tremor leaves on a cursor or stroke is to smooth the raw input signal — a moving average, a low-pass filter — but any such processing necessarily introduces latency, making the interface's feedback lag behind the user's actual hand position and undermining directness (the felt immediacy of correspondence between input and feedback). Jitter and latency thus form a trade-off: no smoothing method can drive both to their minimum at once.

Why it happens

Any smoothing algorithm is fundamentally basing its current output on multiple historical samples within some time window, trading "averaging over several points" for "diluting single-point noise." A longer window averages out more tremor, but the output also reflects a position from several frames ago rather than the present moment — latency grows linearly with window length. A shorter window has less latency but averages fewer samples, leaving more residual jitter. Neither can be optimized simultaneously, because they are simply two consequences of the same parameter — window length — in opposite directions; adjusting it can only move the operating point between residual jitter and latency, not shrink both together.

Studying it

Evaluating a smoothing algorithm typically measures two metrics at once: residual jitter amplitude (the smoothed trajectory's deviation from the intended true trajectory) and perceived latency (the time gap between input and feedback, measurable objectively via high-speed camera or timestamp comparison, or subjectively via a rating of "felt directness"). Different filters (simple moving average, exponentially weighted, Kalman) suppress different amounts of jitter for the same latency budget, which is a common axis for comparing them.

Methodological note: subjective directness ratings are sensitive to latency — even a difference of a few tens of milliseconds can be clearly perceived — so evaluating a smoothing scheme cannot look only at whether jitter went down; the added latency must be measured and reported separately.

Where it stops holding

This trade-off holds for scenarios requiring continuous, real-time feedback where the jitter is on the order of physiological tremor; for discrete event judgments (deciding whether a click occurred) rather than continuous trajectory display, smoothing costs less, because a latency of a few tens of milliseconds usually doesn't affect the judgment outcome. Pathological tremor, whose amplitude is far beyond the physiological-tremor scale, is also only partially compensated by this kind of general-purpose smoothing.

Applying it

• For ordinary scenarios where physiological tremor is the dominant noise source, handle small jitter first with a tolerance radius or dead zone, and only layer on light smoothing if the dead zone alone isn't enough — don't reach straight for a long-window filter and trade away latency up front.
• Continuous operations that need high directness (dragging, drawing) should keep the smoothing window within a latency threshold that stays imperceptible — leaving a bit of residual jitter is preferable to a noticeable "my finger moved but the cursor hasn't caught up" gap.
• To verify: measure residual jitter amplitude and perceived latency separately across several window lengths, plot the trade-off curve, and pick an operating point where latency stays under an acceptable threshold while jitter has already dropped substantially — rather than optimizing either metric alone.

Related

• Same group: A8.15.1 An unremovable baseline jitter with a characteristic frequency exists even at rest · A8.15.2 Fatigue, cold, stress, and caffeine all amplify tremor · A8.15.3 Tremor amplitude grows with arm extension distance · A8.15.4 Hover and dwell interactions must set a tolerance radius
• Nearby: A8.16 Pathological and intention tremor · C9.11 Latency in physiological input
• Search terms: input smoothing · low-pass filter · directness · latency-jitter trade-off