When rendering to SVG, if the weight is 0 the outline is not displayed.
However, when rendering to canvas it will still display the outline.
This change makes the behaviour consistent when rendering to either.
Continue to retain loaded-but-still-fading-in tiles,
but also continue to look for loaded-and-active tiles.
This reduces flicker on multiple rapid zoom actions.
Now that we are fading during the zoom animation, this
is no longer necessary. The zoom animation itself provides
enough of a transition, and resetting the opacity can lead
to more flickering than it solves.
Do not throttle _pruneTiles. Instead, when adding new tiles,
prune tiles that are no longer needed immediately, and when
a new tile finishes its fade animation, immediately prune
just its parents/children.
Avoids cached _tilesToLoad value getting out of sync with
actual loading tiles, e.g. if _removeOtherTiles or _abortLoading
removes tiles that are loading.
I've just bumped into this while browsing the source code. It's not tested in any way and I didn't look for similar issues in other files neither. But I hope it helps anyway.
[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
