Say you are adding a brush to a drawing app that gets thinner the faster you move. On every mouse move you measure speed and set the width from it. Yet even when you draw at the same slow pace, the line is thick in some places and suddenly thin in others. Your hand moved evenly; the line still jitters. The problem is not the hand. It is the instantaneous value.
Why does reacting to instant readings cause jitter?
A system that reacts directly to instantaneous readings amplifies measurement noise, not the real motion. Pointer speed, path direction, and single-frame time all jump by several times in the same situation, because the samples arrive at uneven intervals or the source data itself zigzags. Feed those values straight into brush width, a camera, or quality settings, and the jumps appear on screen.
So before reacting, decide one thing: what axis will you pick the value along? The answer depends on the case.
- Smooth over time when the value flows with time and can lag a little (brush width, a displayed number).
- Average over distance (position) when the value belongs to a place and the same place must always give the same answer (a camera following a path).
- Compare against a baseline when the absolute value differs by device or environment (frame time, response time).
What to watch for when smoothing over time
Browser pointer events do not arrive at even intervals: one after 1 ms, the next after 16 ms. Instant speed is distance divided by elapsed time, so a single short-interval sample can multiply the speed several times. (MDN's pointer events docs also note that browsers coalesce events.)
- Run speed through exponential smoothing (a moving average that mixes in only a little of each new value) before it touches width.
- Shape the speed-to-width curve so its slope never breaks — a half-distance exponential, for example — rather than "decrease linearly, then clamp at a floor." Small jumps become big changes at a kink.
- Reset the smoothed value to zero when a new stroke starts. Otherwise the new stroke inherits the last stroke's fast speed and its head comes out thin.
Why shouldn't a position-bound value be smoothed over time?
Picture a camera following a zigzag line such as a GPS track. If the camera faces "the direction of the segment I'm on" (the instant tangent), it snaps every time it passes a point.
A time-based filter reduces the shake but makes two things worse:
- On long curves the camera lags at an angle, because the filter drags past values along.
- The answer depends on the path taken. Arrive at the same place at the same moment by a different route and the camera points differently. Rewind, seeking, and syncing multiple screens break.
Instead, use the direction of the chord between two points a fixed distance ahead and behind on the path. That value is decided by "where on the path" alone, so the shake drops and the same place always gives the same answer.
Why do absolute thresholds misjudge some devices?
If you add "adaptive quality" that lowers resolution on slow devices, it is tempting to use an absolute rule like "lower it when a frame exceeds 20 ms." But browsers draw in step with the display's refresh rate. A healthy 30 Hz display shows 33 ms frames. An absolute threshold cuts quality on devices that are fine.
- Judge by how far frames fall behind this display's refresh rate.
- Estimate the refresh rate from the shortest observed frame interval, but after a warm-up. The very first short frames will pull the baseline off.
- Performance comparisons are the same. On a machine running other programs, the same code's frame time swings 3–4x. Don't compare absolute numbers; measure before and after alternately in the same session and compare the ratio.
Instructions to give your agent
Before driving or judging anything from a measured value:
1. Check whether it jumps because of sample timing or noisy source data
(repeat the same action and record the distribution).
2. Pick the axis:
- Flows with time and may lag -> exponential smoothing; reset when a new action starts.
- Bound to a position -> average over position (path distance) ahead and behind;
keep "same place = same answer".
- Absolute value differs by device or environment -> ratio to a baseline
(refresh rate, previous version); measure the baseline after warm-up.
3. Keep kinks out of the response curve.
4. After the fix, re-measure the same metric (e.g. 99th percentile of direction change)
and confirm it dropped.
Cases we ran into
- Brush width: setting brush width from mouse speed made fast strokes thin out far too abruptly. Pointer intervals varying from 1 to 16 ms were the cause; exponential smoothing, a kink-free curve, and a per-stroke reset fixed it.
- Path-following camera: a camera following a zigzag path kept snapping its view. Switching from the instant tangent to the chord ahead and behind on the path cut the 99th percentile of camera direction change from 15.2° to 0.5° (measured along the same path).
- Adaptive quality: we realized a quality controller judging by absolute frame time would degrade naturally slow displays that were fine, so we switched to a ratio against refresh rate and delayed the refresh estimate until after warm-up.
- A side case: in an agent-launched automated browser, the same code's frame time swung 3–4x between loads, so we moved performance judgments to alternating before/after measurements.