Once prediction is in effect, the extrapolated path must be rolled back with real data, producing a slight pull-back

What it is

After a predicted segment is painted, real samples arrive, and they almost never coincide with the prediction. The engine must replace fake ink with the true path. On screen that replacement is a slight pull, jump, or overwrite at the front—the pull-back. Pull-back is the necessary close of extrapolation, not an extra effect. Without it, fake ink stays in the wrong place forever.

Why it happens

The cleanest rollback clears the prediction layer each frame and redraws from the latest real points to the estimated nib: fake ink never enters final geometry, and pull-back is “last frame’s extra stub vanished”. If the predicted segment was already baked into the stroke mesh, geometry surgery is required: delete the tail, join to the new real point, or move tail vertices over. Interpolating the surgery across frames makes pull-back a smooth shrink; snapping in one frame is a jump. People more often notice a reversal: fake ink overshot a corner, the real point sits inside, ink is hauled back from the outside. Amplitude is how wrong last frame’s extrapolation was, so pull-back is bound to window length, but the mechanism itself is replacement, not the window. Animating the shrink turns a geometric correction into a noticeable motion; cutting to the true path in one frame is equally large in error but lacks the cue “the ink moved”. Final strokes must be real points; prediction must not change stored geometry.

Studying it

Label prediction and real layers frame by frame around a corner. Measure tail-vertex displacement from predicted to real position, and whether it spans frames.

Independent variables: rollback strategy (drop layer / edit mesh / interpolated shrink), prediction length. Dependent measures: pull-back pixels, visible frame count, “the ink pulled back”, whether saved strokes contain predicted points.

If exported vectors contain vertices that existed only on the prediction layer, baking failed.

Where it stops holding

When delay is tiny and the predicted segment is a pixel or two, pull-back hides in nib width and strategy differences vanish. Pull-back stacked on the writer’s own reversal (a hook, a return stroke) makes it unclear which segment they wrote. Collaborative ink that broadcasts predicted segments lets remote peers see the pull-back, or keeps fake ink forever.

Applying it

• Keep prediction on a per-frame disposable layer; commit, undo, and export real points only.
• If the mesh must be edited, prefer a one-frame cut to the true path over a multi-frame shrink animation.
• A debug view should draw both layers so replacement is visible when pull-back happens, rather than “the ink came alive”.
• How to check: a sharp turn, played back slowly; fake ink should be replaced by the true path in the frame real points arrive. The exported path must not contain the overshoot through the corner. Contrast interpolated shrink and see whether subjective pull-back is stronger.

Related

• Same group: C5.11.1 Prediction extrapolates unreported path from speed and heading · C5.11.3 A longer window follows better but errs more at turns · C5.11.4 Prediction only eases perceived latency, not real end-to-end delay
• Adjacent: C5.08 Inking Latency · C5.12 Visual Offset Between Nib and Ink
• Search: prediction rollback · snap-back · predicted stroke