Mapbox Animating Camera

[d-prukop]

This is a ticket to track the discussion around implementing a new camera system for the various platforms.

The goal is to provide a camera system that allows independent animations to run on each of the map camera parameters. It should use a familiar API's for each of the platforms. This will give developers and designers the ability to have total control of the experience. It will also allow for the easy use of plug-in camera animation libraries and physics simulations for those who want to use certain styles of animation.

Further down the line, we should be able to introduce design tools for crafting animations and sharing those creations.

Some background and prior thinking:
“Fresh new camera”: mapbox/mapbox-gl-js#3583
“Concurrent Transition Animations”: #3625
“Reimplement camera transitions with Core Animation”: #8176

The new camera system will be able to animate each of the following parameters on independent timelines:

• center coordinate
• zoom level
• bearing
• pitch
• anchor
• roll ?? (yes!!??)

Animations will be handled on the various platforms and committed to the core with the frequency (or frame rate) controlled by the platform.

cc @mapbox/gl @pveugen

[d-prukop]

@jfirebaugh Can we figure out a way to prefetch tiles using the platform based animations?

[1ec5]

mbgl currently treats anchor as a frame of reference for zoom and angle, but not as a degree of freedom in its own right. (Similarly, padding affects the frame of reference for center.) Would you suggest turning it into an animatable degree of freedom? What are the tradeoffs?

[d-prukop]

I'm thinking of anchor as an animatable parameter. Setting this explicitly has been the easiest way to control the effect. I haven't given much thought to the tradeoffs of setting this implicitly.

[1ec5]

Currently, to change the camera’s padding (as the user perceives it), you’d need to reapply the current center coordinate with the new padding. The anchor is often provided by gesture recognizers (to be under the mouse cursor) when specifying a camera to animate to, but if you ask the map for its current anchor, you’ll always get an unset value. In this sense, anchor could just as well have been a member of AnimationOptions instead of CameraOptions.

If we were to keep the current anchor implementation but allow for concurrent animations, the developer would for instance ease to a camera with a new anchor value, and any subsequent animation frames would have to account for that anchor when computing the center coordinate. On the other hand, if we turn anchor into its own degree of freedom, then there could be conflicting anchors when (say) the user makes a rotation gesture in the middle of a programmatic rotation.

[d-prukop]

That's a good point about the anchor moving to the point between touches on rotate. I'm very much thinking about this in the specific context of navigation where any touch/move on the map should cancel all animation. Any call to transition to the following mode (by tapping resume or re-center or using a timeout) should result in the anchor point moving to somewhere in the lower third of the screen. Calls for transition to the overhead view should move the anchor to the center of the defined viewport.

[kkaefer]

@d-prukop see #2006 for a discussion on tile prefetching.

[kkaefer]

See #9813 for cache eviction strategy when prefetching tiles.

[zugaldia]

Capturing chat today (cc: @tobrun). Looks like ObjectAnimator is a good starting point to achieve this on the Android side.

[d-prukop]

Had a chat with @1ec5 yesterday. The plan is to experiment with using CoreAnimation to do camera animations without changing anything on core.