The deceleration curve sets a predictable stopping place

What it is

Once initial velocity is set, content still has to stop. The deceleration curve (friction model, decay function) decides how far and how long the trip from v0 to rest will be. People can expect “this throw will die around there” not by reading code but because the same effort maps to the same travel every time. Change the curve and that muscle memory is worthless.

Why it happens

A common approximation is damping proportional to speed, so position approaches an endpoint exponentially. Piecewise-linear curves and a minimum-speed cutoff also exist. Exponential decay is hard then soft: distant detail slows before rest, which helps scanning. Too slow and the list is ice, the stop is shoved far away, and expectation snaps. Too fast and a fling collapses into tracking that dies on lift. The curve must also integrate stably across refresh rates and dropped frames: treating frame count as time makes the same throw travel differently at 60 Hz and 120 Hz. Deceleration at a bound has to hand off to rubber-banding, or the last pixel hits the wall on the inertial formula.

Studying it

Hold v0 fixed, swap only decay parameters, and have people point to the predicted stop before the coast, then measure error and repeatability. Independent variables include the time constant, frame-based versus clock-based integration, and list length. Dependent measures include absolute error, signed bias (always short or always long), and ratings of “can I still roughly fling to a place.” A non-repeatable control (random damping per frame) shows that expectation rides on stability, not on one particular formula.

Where it stops holding

Predictable is not precise: a stable curve still lands “around there,” and does not replace easing up to a particular row. Paging snaps cut the curve mid-coast and interpolate to the nearest detent; people then expect the detent, not a free stop. Variable-rate games or a janky web main thread will jump a pretty curve by a large slice in one frame, and expectation dies on the spot.

Applying it

• Integrate damping against wall-clock time, not frame count. Check total travel for the same v0 at 60 Hz, 120 Hz, and a build that drops frames on purpose.
• Tune the time constant so a medium throw covers about two to four screens and visibly slows before rest, rather than sliding out of view at constant speed.
• Have a practiced user fling once, then fling again eyes-closed toward “about the same place.” The two stops should land in nearby regions. If the second always overshoots or always falls short, check frame-based integration first, then v0 estimation.

Related

• Same group: C3.06.1 Lift speed sets the inertial initial velocity · C3.06.3 A new touch should brake immediately · C3.06.4 Inertial scrolling is too unpredictable for precise positioning
• Adjacent: C3.07 Pan · C1.11 Scroll wheels and inertial scrolling
• Search: deceleration curve · friction scrolling · coast distance