Predictive rendering can only ease perceived latency; it cannot remove real end-to-end processing delay

What it is

Prediction moves the ink front closer to the nib, so perceived latency falls. Real end-to-end delay—from nib motion to the real sample being processed, written into the final stroke, and consumed by undo or recognition—does not lose a millisecond to prediction. Writing “prediction on” as a passed latency metric treats a perceptual patch as a repaired pipeline.

Why it happens

Real delay sits in reporting, scheduling, recognition, storage, and sync. The prediction layer is composited at the front and only changes pixels seen this frame; it does not make reports faster or give the recognizer points earlier. So: a remote collaborator still receives real points on the real timeline; handwriting recognition still waits for the real stroke; an undo stack of real points does not change its timing. Prediction can even keep the real path busier—an extra extrapolate-and-roll-back each frame. When real delay outruns the window (a stall, a dropped frame, a Bluetooth burst), prediction either shows the gap or extrapolates wildly, both of which expose that the pipeline is still there. A photon measurement aimed at the ink front will count the predicted segment as “low latency”; aimed at pixels that correspond to real samples, or at event timestamps, the number is different. Products need both: the perceived gap, and time from real point to photon / to consumer.

Studying it

Measure three things together: nib to predicted ink front, nib to real ink (prediction off, or real layer only), and real-point timestamp to a recognition or sync consumer. Under injected load and Bluetooth jitter, watch how the three diverge.

Independent variables: prediction on/off, real load, wireless jitter. Dependent measures: perceived gap, real-point delay distribution, time to first recognised character or remote point.

Do not replace a real-delay histogram with “subjective following” alone.

Where it stops holding

Local paint with no recognition and no sync may care only about perceived delay, so prediction as a patch is more reasonable. Once ink enters recognition, legal records, or multi-user writing, the real timeline is the contract. Prediction cannot rescue dropped frames: if the frame is not drawn, no amount of front-end extrapolation emits new photons.

Applying it

• Report metrics apart: camera for the perceived gap, timestamps to the consumer for real delay; prediction must not be allowed to “improve” the second.
• Shorten the real path first (sampling, scheduling, composition); let prediction cover only the stable remainder.
• On stalls and wireless jitter, shorten prediction and show the real path; do not lengthen the window to gamble.
• How to check: with prediction on, the perceived gap should fall, but time to a recognised character and time for a remote peer to see a point should not. Block the composition thread; both delays should worsen, and lengthening prediction must not paint the real histogram green.

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.3 A longer window follows better but errs more at turns
• Adjacent: C5.08 Inking Latency · C5.14 Handwriting Recognition
• Search: end-to-end latency · perceived latency · latency masking