Transitions fail to complete when zooming

[brunoabinader]

When zooming with a scroll wheel or with pinch gestures, we sometimes fail to finish the fade transition (both fading in and fading out):

[jfirebaugh]

@brunoabinader, want to take a crack at this? Basically, we need to thread some more state through so that MapContext::renderSync can return true for needsRerender while label fading is happening.

[brunoabinader]

@jfirebaugh yes, I'll take a look at this.

[brunoabinader]

Review @kkaefer @jfirebaugh?

[kkaefer]

While this fixes the bug, it also means that the map is continuously rendering at 60fps, using system resources and battery. Instead, we need to figure out in what circumstances we need to rerender (= when fading in/out), and not render otherwise.

[brunoabinader]

I've cracked my head a bit these past days trying to figure out why this was not working. It turns out that we're missing checking if Painter::needsAnimation() along with Style::hasTransitions() in MapContext::renderSync(). I've learned a lot from the code while resolving this bug, and thus got the chance to do some other fixes and cleanups along the way:

Relevant changes:

• Unify default transition values in MapData:
  • Added defaultFadeDuration and defaultTransitionDelay to MapData;
  • Painter & StyleParser now receives a reference to MapData;
  • As previously seen on the code:
    • 300ms is the default fade duration;
    • 0ms is the default transition duration;
  • We no longer pass the current time point to Style, since it now uses MapData.animationTime, which gets updated in MapContext::update().
  • Updated StyleParser check to use a mock MapData;
• Pass {Duration,TimePoint} by const ref whenever possible;
• Unify time point for Mapcontext::update:
  • Let style classes cascade use the same time point as the one used to
    recalculate style.
  • Cleaned up MapContext::update() to return early whenever possible.
  • Cleaned up MapContext::loadStyleJSON() to avoid redundant calls to style
    classes cascade.

/cc @jfirebaugh @kkaefer @tmpsantos @tmcw

[brunoabinader]

What about moving these commits not exactly related to the fix to a separated PR?

👍 Moved related (but not necessary to fix the issue) changes to #1888. Thanks!

[brunoabinader]

Build failure cause is not related to these changes. See #1887 for details.

[brunoabinader]

This should fix #779 as well.