Style layer animations in iOS

[olkiz]

I see that in maplibre on Android for user puck is used layer (and it is updated by Animator), but for iOS user puck is used as uiview (and in maplibreNavIosSdk). When I'm trying to animate the layer (MLNSymbolStyleLayer or MLNLineStyleLayer or both) by using CADisplayLink, CPU usage is 40%, and high energy impact. Same is 5.13 Maplibre and in pre-6.

I found on the Internet, that Mapbox has (or had) the same type of issue because changing one layer cause rendering all of the layers. Can it be improved? Because animating passed route or polyline is used in many apps today. Also using the user puck as uiview has bugs like "moving" from its place during map pan/rotate.

[olkiz]

During the investigation, found that camera animation causes the same CPU usage (including test animation of polyline and the symbol of user puck on the symbol layer). Also, maplibreNavIosSdk has less CPU usage because of dropping framerate to 5 fps. Dropping to 5 fps on test project (camera animation + polyline animation + symbol animation) decreases CPU usage.

But I have question, why UserPuck is UIView, not the symbol?

[louwers]

But I have question, why UserPuck is UIView, not the symbol?

I took a look, and there is quite a lot of (Objective-C) code relating to the location indicator in the iOS platform indeed! Even drawing it with Core Animation. I think the core C++ APIs were too awkward for this use case, but @1ec5 can can maybe give a better answer on that.

@stefankarschti has been working on a new type of custom layer that emits Drawables like all the internal layers now. The first (internal) use case of this new custom layer is planned to be a location indicator layer.

[olkiz]

Just reread my post and whant to clarify I have mostly same cpu usage as just camera animation (without layer animations) and same for layer animations (without camera) and when all is animating.

[1ec5]

View-backed annotations, such as the location indicator, predate custom layers and indeed even runtime styling. The location indicator also needed a lot of visual functionality that wasn’t available in style layers but users had come to expect on the platform due to Apple Maps and MapKit. There are too many nuances for me to dig up at the moment, but here are some key ones:

• A pulsing dot to indicate that the location is being actively updated, automatically colored according to the view controller’s tint color.
• A circular halo with a radius corresponding to physical units rather than screen units. Geodesic circles weren’t available as part of either GeoJSON or mbgl’s internal models. Add MGLCircle (with radius expressed in physical units)  mapbox/mapbox-gl-native#14534 was an attempt to generalize this functionality for data visualization, but it was never accepted.
• The location indicator needs to animate smoothly from one geographic coordinate to another. Because an interpolated location inherently trails the raw location updates from Core Location, the position on screen needs to be decoupled from the map’s model of where the user is located. The lag is usually 1 second but can vary arbitrarily based on whenever the updates come in. With a UIView, the presentation layer accomplishes this decoupling.
• With location tracking enabled, the camera needs to stay synchronized with the presentation layer; otherwise, the location indicator appears to hop around on screen. It ends up being more straightforward to just pin the view at a particular screen coordinate and animate the camera instead of the location indicator.
• We wanted to enable developers to customize the location indicator extensively but without having to reinvent UIKit for defining views. Ultimately mbgl ended up with some enhanced symbol placement functionality for faking view composition, but it’s very unpowered compared to what UIKit lets developers create. The hope was that developers would even figure out how to replace the view with a SceneKit view, but that turned out to need custom layers (MGLOpenGLStyleLayer) anyhow.
• Additionally, view-backed annotations support drag-and-drop out of the box, but obviously this doesn’t apply to the user location indicator.

As much as I valued the system integration that came with the view-backed annotation approach, it was not without downsides. It was way too painful to synchronize the view with an independently rendering base map. CADisplayLink was a crutch for the severe performance regressions that crept into mbgl in 2006 that we were never able to pin down, but it had a performance overhead of its own.

After years of haplessly trying to fix an endless stream of edge cases, I’m convinced that:

• View-backed annotations need to be better integrated into the drawing pipeline. You can only fake the visual effect so much by billboarding a view atop the map view. Custom layers are probably the way forward, but I think it’s important to preserve the developer’s ability to integrate their own UIView somehow. Otherwise you get into the business of rolling your own UI toolkit.
• The map SDK should only provide very limited functionality for indicating the user’s location, maybe not even location tracking. A lot of the complexity was for supporting turn-by-turn navigation use cases, which grew into the navigation SDK. The navigation SDK has much more context for reliably positioning the user. It can even do dead-reckoning instead of interpolation, to eliminate that 1-second lag. It should be responsible for vending a more advanced location indicator for location tracking.