Class ZoomGlide

Where the glide ends: the accumulated total, from the origin.

Fold another wheel tick into a glide already running.

The target ACCUMULATES, so spinning the wheel fast covers the sum of its notches rather than only the last one, and scrolling back the other way genuinely reverses (five notches out after one notch in ends four notches out, which is what the user asked for).

The curve is rebased rather than merely retargeted: it restarts from what has already been applied, at the current time. Without that, changing the target changes appliedAt for times ALREADY sampled, so the next frame computes a delta against a curve the caller never rode and the chart jumps, most visibly when a reversal flips the target's sign. Rebasing does not make a stream of ticks crawl, because each tick also pushes the target further away: it is progress toward a FIXED target that resetting would stall.

Signed log-space zoom applied from the glide's origin up to elapsedMs.

The fraction of a step to apply on the input event itself, before any frame runs.

A glide that starts at zero adds a frame of input latency to every wheel tick, and leaves barSpacing reading its old value to anything that looks synchronously after the event. Both are worse than the jump the easing was meant to fix. The lead is exactly what the first frame would have applied anyway (one 60fps frame of the curve), so the chart responds instantly and the remainder still eases.

Whether a step this large is worth animating rather than applying at once.