C5.11.3Prediction window versus corner errordesignresearch

A longer prediction window follows more tightly, but correction error at turns grows

Aliases: prediction window · look-ahead horizon · corner error

What it is

The prediction window is the time (or equivalent pixel length) extrapolation covers. Lengthening it fills more of the straight-away gap and following feels tighter; the same window sends fake ink farther through a turn, so rollback’s correction error grows. Both ends of the trade have to be visible; tuning the window until “it follows as hard as possible” is not the end.

Why it happens

Gap length is about delay times tangential speed. If the window is shorter than real delay, a straight still shows a gap; if longer, the straight slightly leads and the nib looks buried in ink. Lateral error at a turn is about the length walked along the old tangent during the window, projected on the normal; window, speed, and angle scale it together. There is no fixed window optimal for every path shape: uniform horizontals want long, small-character corners want short. A dynamic policy lengthens when speed is stable and shortens when curvature rises or speed drops. Shorten too slowly and the corner has already happened with a long fake segment out; too sensitive and a bit of straight-away jitter kills the window and the gap returns. The window is also bound by refresh: shorter than one frame at 60 Hz paints almost no extra pixels.

Studying it

Sweep window length (or target fill fraction). Measure remaining gap and maximum lateral corner error on straights, polylines, and small characters, and rate “glued” versus “the corner is ruined”.

Independent variables: fixed window vs curvature/speed adaptive, refresh rate, injected delay. Dependent measures: straight gap, corner error, time series of the adaptive window, both subjective scores.

Plot following and corner cleanliness on one figure; do not optimise a single axis.

Where it stops holding

Signature-like strokes with few corners can take a long window; neat small regular script cannot. Adaptive policies that used future curvature (impossible) would be perfect; using past curvature is always late, so small fast hooks still show. Giving the window to users as a “following” slider usually gets pulled to max, then they complain of barbs—the default must sit inside the trade.

Applying it

  • Default the window so a medium-speed straight just hides the gap, not so the fastest writing has zero gap.
  • Shorten on curvature and deceleration within one or two frames, not with a slow ease.
  • Accept on both a horizontal and on box-like corners, z, and hooks; passing one is not passing.
  • How to check: lengthen the window and the straight gap should fall while corner error rises—that is the trade. With adaptation on, both points should land in a tolerable band; adaptation off and window maxed should clearly wreck corners.

Related

  • Same group: C5.11.1 Prediction extrapolates unreported path from speed and heading · C5.11.2 Extrapolated path must be rolled back with real data · C5.11.4 Prediction only eases perceived latency, not real end-to-end delay
  • Adjacent: C5.08 Inking Latency · C5.02 Pen Tilt and Azimuth
  • Search: prediction horizon · look-ahead window · corner error

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C5.11.3