Reimplement camera transitions with Core Animation

[1ec5]

The iOS and macOS SDKs should use indirect property animation in Core Animation to drive camera transitions in response to gestures and calls to methods like -setCamera:animated: and -flyToCamera:…. We should move off mbgl::AnimationOptions and use the mbgl::Transform methods only for incremental transform changes on each frame of the animation.

A key benefit is that the Android SDK will be able to implement concurrent animations (#3625) without us having to design an API around tweening, spring solving, or the like. There are already mature APIs for these effects in UIKit Dynamics.

#8175 is the equivalent issue on Android. Perhaps there’s also prior art in the Qt SDK, where we’ve always relied on Qt animation APIs instead of mbgl’s.

/cc @incanus @bsudekum @frederoni @boundsj

[1ec5]

The only nontrivial animation type mbgl supports is flight animation. We could factor out a utility that calculates the trajectory given a few inputs that we can use on both iOS/macOS and Android.

[brunoabinader]

@1ec5 are you thinking towards a core utility API for this? This way even e.g. Qt could take advantage of.

[1ec5]

Yes, I was envisioning a core utility API, perhaps a standalone API like Projection, that calculates flight trajectories. That would make it easily usable by the iOS, macOS, and Qt SDKs. Unfortunately, it occurs to me that it probably wouldn’t be usable by the Android SDK. That code would have to run on every frame of the animation, and my understanding is that we want to minimize the amount of JNI-crossing that occurs during animation. Fortunately, the algorithm behind flight animation is well documented, so the Android SDK would rely on a port of that code to Java.

[1ec5]

See “Property-Based Animations” for some APIs that would be used with this feature, especially UIViewPropertyAnimator and UISpringTimingParameters (for spring-solving animations).

[1ec5]

#9808 (comment) has a basic demo of UIView animations on MGLMapView. That issue is a bit more tightly scoped that this issue, with more caveats, but it offers a concrete look at how the more general feature would look.

/cc @d-prukop

[jfirebaugh]

A disadvantage of SDK-driven animations that incrementally update the mbgl core camera is that the core tile loading algorithm then lacks knowledge about the overall animation that would allow it to optimize decisions about what tiles to load or not load, as suggested in issues such as mapbox/mapbox-gl-js#2470 and mapbox/mapbox-gl-js#5482.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.