Use frame time for map animations

[ljbade]

I want to bring back something along the lines of #2410

Basically a way to pass into the Map the current "frame time" that it uses for all animations instead of Clock::now(). This will help ensure animations like map pans are smooth and not jerky.

I will explain why using now() is bad for animations:

To get a smooth animation between point A and point B you need to update it's position 60 times per second to match the screen vsync. Each time point should be accurately 1/60 second apart.

Using Clock::now() provides no guarantee that you will get an exact multiple of 1/60 second intervals (I say multiple in case we drop a frame). This is because the exact time it executes varies depending on the CPU workload and scheduling.

To solve this problem both Android and iOS provide access to a very accurate "frame time" that is captured from the screen vysnc hardware. As this is a hardware timer it will be as close to exactly 1/60 second intervals as you can get.

This is what the rest of the OS uses to run animations in their respective "native" views. Which also will allow users to easily sync map animations to any animations in their UIs.

/cc @1ec5

[ljbade]

From discussion with @1ec5 and @incanus it seems on iOS it is not as easy to get the "frame time" as on Android without requiring end developers to jump some extra hoops.

[ljbade]

On Android we can use the Choreographer class' FrameCallback:

On iOS it seems we can use the CADisplayLink callback: http://www.bigspaceship.com/ios-animation-intervals/

The idea is in the callback we just "capture" the frame time, and use it later on when we draw. We don't need to actually run any rendering or such in the call back.

[ljbade]

Quick note for myself: Choreographer callbacks can leak the MapView. Somehow need to ensure they get cancelled and any recursive post loop breaks when onPaused.

[1ec5]

Removing iOS label because we’re syncing drawing using CADisplayLink as of #2922 and I have ideas for moving away from that towards a more robust model in #2985.

[tobrun]

stale