Animating map view contraints is jerky; implicit animation via Core Animation properties not supported

[friedbunny]

The proper way to animate MGLMapView is to modify its auto layout constraints (and not the frame), but this doesn’t behave correctly:

• White gaps at top and bottom jump as the map frame instantly shrinks to fit, rather than animate to the new, smaller constraint. The logo and attribution subviews do animate correctly, which indicates this is an issue with the GLKView that provides the map itself.
• User location annotation does not move, it just sits around waiting to be in the correct spot again.

Preview of the test project:

import UIKit
import Mapbox

class ViewController: UIViewController {

    @IBOutlet weak var mapView: MGLMapView!
    @IBOutlet weak var heightConstraint: NSLayoutConstraint!

    override func viewDidLoad() {
        super.viewDidLoad()
        mapView.showsUserLocation = true
    }

    @IBAction func animate(sender: AnyObject) {
        UIView.animateWithDuration(1.5, delay: 0, options: .CurveEaseOut, animations: {
            self.mapView.userInteractionEnabled = false

            self.heightConstraint.constant = self.heightConstraint.constant > 200 ? 200 : self.view.frame.height/2

            self.view.layoutIfNeeded()
        }, completion: { finished in
            self.mapView.userInteractionEnabled = true
        })
    }

}

/cc @1ec5 @boundsj

[harri121]

+1

[harri121]

Is there a workaround?

[1ec5]

I’m not sure about a workaround, but I suspect the problem may be that -layoutSubviews only gets called at the beginning of the animation, so mbgl::Map::update() gets called only once with the final size. Meanwhile, the user dot appears to stay stationary because it’s actually animating in the opposite direction to compensate. (If the map view is flush with the bottom of the view controller, showing and hiding the bottom bar will cause the user dot to visibly slide into place.)

[1ec5]

The fix is probably to move the call to mbgl::Map::update() from -layoutSubviews to the -setFrame: or -setBounds: override and also have MBGLView::getSize() return GLKView’s presentation layer’s size instead of MGLMapView’s explicit size.

[harri121]

Ok, do you know when this will be fixed?

[afinlayson]

Looking for this as well.
Thanks

[lilykaiser]

Closing due to ticket age. If this is still a problem, please re-open

[katiesmillie]

@friedbunny I'm also having this issue and would appreciate an update. Are there any workarounds?

[1ec5]

As a possible starting point, we should check whether -[GLKView drawableHeight] is even animatable:

mapbox-gl-native/platform/ios/src/MGLMapView.mm

Lines 615 to 616 in d5f0e4b

	return { static_cast<uint32_t>(self.glView.drawableWidth),
	static_cast<uint32_t>(self.glView.drawableHeight) };

[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.

[katiesmillie]

This is still an issue that I've been following and hoping for a resolution. I hope you'll consider re-opening it.

The best workaround that I've come up with is to leave the size of the mapview unchanged, and change the content insets of the map (which adjusts the coordinates bounds and center of the map). The map animation happens after the second view has been finished animating so you lose the effect you see above where they both animate together. This significantly degrades the experience as it has become a very common mobile UI pattern with all the major map apps.

[julianrex]

This is still open @katiesmillie!

Your workaround of changing the content insets may actually be part of the solution that we're looking at (or similar) - since adjusting the frame buffers during an animation gives poor performance.

[pappalar]

+1 for this issue

[pappalar]

The same issue is also happening when the iOS tab bar or Navigation Bar are showing animated. as the container of the map will change constrains animated.

I also noticed that changing the content inset (animated if I remember correctly) also does not redraw the current location annotation position (as originally reported)

[1ec5]

The root cause of the original report is that MGLMapView.camera, centerCoordinate, etc. are not implicitly animatable. (Notice how the constraint is being modified inside an implicit animation block.) Supporting implicit animation for the camera properties would be one side effect of reimplementing camera animation atop Core Animation: #9808.

[1ec5]

Replacing GLKView with a built-in Core Animation layer (#14785) would make the effect somewhat less jarring, as it is on macOS. The layer’s frame would animate correctly, though the content could potentially stretch or compress to fit that frame during the animation. Supporting implicit animation is the correct fix no matter what.

[pappalar]

@1ec5 Would it be possible and is the idea to support animation for the camera and centerCoordinate etc?

We noticed that changing the inset/frame of the map while zooming the camera will:

trigger uiView SafeAreaInsetChanged

mapView.adjustContentInset

which calls MGLMapView.cancelTransitions that also destroy the camera anmations

[1ec5]

Would it be possible and is the idea to support animation for the camera and centerCoordinate etc?

Yes, I think implicit animation of these properties is essentially what this issue tracks. There is a separate effort to overhaul the camera APIs on both Android and iOS/macOS, which is sort of tracked in #9808, but I think we have to solve this issue regardless, especially considering the prominence of implicit animation in SwiftUI.

[robert-frankin]

Hi, I am getting same issue in iOS. Is there any solution to fix it? Please advise. @1ec5