Super-refresh report rates feed predictive rendering with earlier samples

What it is

When touch report rate outruns display refresh, at least one extra coordinate arrives between vertical syncs. The compositor or the app can feed that earlier sample into predictive rendering: before pixels actually light, extrapolate where the finger will be next frame from a position that just landed. The surplus samples are not extra UI frames. They shrink the window in which the last frame’s coordinate is already stale.

Why it happens

A display frame has a hard scanout deadline. If touch reports only once at the start of the frame, the predictor extrapolates from a velocity at least one frame old—large window, large error. An extra sample in the same frame lets it swap in a fresher velocity before the deadline, shrinking the extrapolation from “a whole frame” to half a frame or less. That is a different lever from cutting end-to-end latency: the display clock stays put; only the last observation the predictor sees gets newer. Ink prediction, cursor pads, and the initial-velocity estimate for inertial lists all eat those extra samples. A still-higher report rate is wasted if user-space queues the events until after vsync.

Studying it

Hold display refresh fixed and change touch reporting (or drop every other sample in the driver). Compare the predictor’s input age and the error against a high-speed camera of the real fingertip. Independent variables are the report/refresh ratio (1×, 2×, 4×), prediction horizon, and trajectory class (constant speed, hard stop, reversal). Dependent measures are age of the last sample at scanout, prediction error, and overshoot on a stop—the overshoot is a check that extra samples actually entered the predictor, not the quantity this leaf optimizes. If the app drains events once per frame, raising report rate moves no dependent measure; that negative result locates the bottleneck on the read path.

Where it stops holding

Above-refresh reporting does not help tap confirmation or long-press timing, which do not extrapolate across frames. For a nearly stationary drag the predictive gain of extra samples is near zero while the power cost remains. Some OLED panels slow scanout at low brightness; if touch still reports at a high hertz the two clocks diverge again, and the predictor must size its window from actual vsync, not the nominal refresh. Advertising “240 Hz touch” while the compositor takes only the last point each frame and never extrapolates makes the mechanism invisible.

Applying it

• On inking and finger-following cursors, let the compositor read every touch packet in the frame before the deadline, not only the leftover point from the previous frame.
• Track last-sample age as a performance metric: at 120 Hz refresh, a sample older than 8 ms at submit means the extra reports never reached prediction.
• Do not force the highest report rate on static pages; reserve it for ink, games, and scroll-following surfaces that actually extrapolate.

Related

• Same group: C2.17.1 Touch report rate is the sensor's position samples per second · C2.17.3 Undersampled fast swipes look lagged and polygonal · C2.17.4 Software interpolation cannot fully replace a hardware report rate
• Nearby: C2.10 Touch latency and directness · C5.11 Inking latency and predictive rendering
• Search terms: predictive rendering · report rate · input age