[This post](http://stackoverflow.com/a/3628949/362702) claims that in Apple's kinetic scrolling, "The velocity of the touch is measured at the exact moment that the finger is lifted."
I tried both this "final velocity" approach and the "max velocity" approach proposed in #2987. Both allow a stronger "fling" than the current "average velocity" approach, but "max velocity" can feel wrong if you slow down at the end of your swipe.
But because the "final velocity" approach uses just one data point it can be unstable, occasionally giving a too-large velocity from a small time delta.
Best is to stabilize that by averaging a few data points, so we're back to "average velocity" but using a shorter time period. Averaging over 50 ms instead of 100 ms gives good results, usually 4 data points on both my iPhone 4s and Chrome on my Windows laptop.
Another reason the current code has a weak fling is that the velocity was being calculated incorrectly. Because `delay` was added to the time delta, time was computed from n+1 points but distance from n points.
I also changed the default value of `inertiaThreshold` (intended to prevent unwanted additional movement if you stop dragging and then lift your finger) to `Infinity`, for two reasons:
1) A fling gesture often failed on my iPhone because the measured `delay` was higher than `inertiaThreshold` (current default 32), sometimes by hundreds of ms.
2) With the updated velocity code I don't see unwanted additional movement when I stop dragging and then lift my finger.
There is a remaining issue (with both the original and updated code). If you fling the map and try to fling it again before it stops moving, no drag events are generated for the second fling so it has no effect. I don't see this problem with e.g. Google or Apple maps. Entered as #3062.
Fixes#2987
Previously, quickly zooming out and then back in sometimes left
only overzoomed tiles for the lower zoom level visible. The
problem was a race condition with deferred pruning:
1. Start at z15. Zoom in. This triggers loading of z14 tiles. As each
tile loads, _pruneTiles (throttled) is called. This results in deferred
removal of z15 tiles (250ms setTimeout). The deferral is done to avoid
flicker while the z14 tiles are faded in.
2. During the 250ms, zoom in. This triggers `_addTiles`, but since the
deferred pruning of the z15 tiles hasn't happened yet, the tiles are
still present in `this._tiles`. Therefore no tiles are queued for
loading, triggering an early return in `_addTiles`, before `_pruneTiles`
is called.
3. Deferred pruning of the z15 tiles happens. Since `_pruneTiles` was
short-circuited at z15, these tiles were never retained, nor were the
z14 tiles scheduled for pruning. End result is that the z15 tiles are
removed from the DOM while the z14 tiles remain, scaled 2x.
