Open friedbunny opened 8 years ago
+1
Is there a workaround?
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.)
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.
Ok, do you know when this will be fixed?
Looking for this as well. Thanks
Closing due to ticket age. If this is still a problem, please re-open
@friedbunny I'm also having this issue and would appreciate an update. Are there any workarounds?
As a possible starting point, we should check whether -[GLKView drawableHeight]
is even animatable:
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.
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.
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.
+1 for this issue
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)
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.
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.
@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
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.
Hi, I am getting same issue in iOS. Is there any solution to fix it? Please advise. @1ec5
The proper way to animate MGLMapView is to modify its auto layout constraints (and not the frame), but this doesn’t behave correctly:
Preview of the test project:
/cc @1ec5 @boundsj