Concurrent transition animations

[1ec5]

mbgl::Transform only supports one transition animation at a time, and starting an animation ends any existing animation (see #3624). mbgl::Transform should be refactored to manage multiple concurrent animations, potentially with staggered start and end times. At a minimum, it should be possible for two animations that animate different properties to run without conflicting with one another.

/cc @ansis @lucaswoj

[jfirebaugh]

Can you say more about why it needs to support this?

[1ec5]

On iOS, in heading tracking mode, user location updates typically come in every second or so (less frequently when there’s poor GPS connectivity), while heading updates come in more or less in real time from the on-board magnetometer.

MGLMapView pans to the new location with animation and also independently rotates to the new heading with animation. However, if you’re in motion and aren’t keeping your device pointed in a constant direction, heading updates tend to interrupt animations to new locations. On master, this is perceived as the map jumping from location to location with smooth rotation. In #3589, this is perceived as a series of smooth rotations in one place, followed by rapid panning as the location updates catch up.

I considered less drastic approaches to addressing this issue, such as allowing callers to easeTo() to update the camera in the middle of the animation, but the resulting code was messier than what we would get by supporting multiple concurrent animations. To be clear, all the animations would continue to run on the Map thread, but we’d interleave their frame functions rather than canceling animations.

[ansis]

to update the camera in the middle of the animation

What does "update the camera" mean here? If I do map.getLatLng in the middle of an animation do I get the current location or the location of the beginning of the animation?

[1ec5]

What does "update the camera" mean here?

CameraOptions is passed in by reference, so I considered checking on each frame whether the CameraOptions fields had changed and adjust accordingly. But that would never yield a pleasing animation and introduces too much complexity into what are already complex easeTo() and flyTo() methods. I don’t see a whole lot of code in mbgl or the iOS or OS X SDKs that assumes only one animation can run at a time. The Android SDK does appear to rely on this assumption for its listeners (cc @tobrun), so there might need to be more significant changes there.

If I do map.getLatLng in the middle of an animation do I get the current location or the location of the beginning of the animation?

You get the current location. That won’t change.

[1ec5]

A completely different approach to this problem would be to have platform-specific SDK code drive the animation. iOS, macOS, and Qt (not sure about Android) all have rich animation APIs, with options for keyframe animation, spring animations, and physics modeling, all things we wouldn’t want to have to build in mbgl and expose as a somewhat foreign-looking API. Animation notifications also become more predictable because only one layer of the stack is involved.

However, perhaps mbgl::Transition is valuable in its own right as an analogue to GL JS’s animation options. In that case, we’ll want to implement the concurrent animations described above for parity with mapbox/mapbox-gl-js#2801.

/cc @tmpsantos