Stretchable UIImage support seems to be broken

[avi-c]

Environment

• Maps SDK Version: v10 beta

Observed behavior and steps to reproduce

The Nav SDK started seeing some issues with the route duration annotations being implemented here: mapbox/mapbox-navigation-ios#2996. These issues are also seen in the simpler PR for adding a new example to the Maps SDK sample app: #190.

The issues are around the icon-anchor and text-anchor properties seeming to regress somewhere between when I first put up the sample PR and now. @nishant-karajgikar and I spent a lot of time debugging this. Our shared assumption was that the issue lay either in my use of the runtime styling expressions or in the SDK expression logic itself.

After looking at it for a while and even eliminating the use of data-driven styling, the main issues remained. We came to the conclusion that the issues are likely to be in how the SDK handles generating the GL stretchable images from the UIImage interface provided in the iOS Maps SDK.

#190 contains an animated GIF of how this should look, mainly that the annotations are clearly visually anchored properly with the tip of the annotation staying attached to the map at the same spot. If you build and try the same sample in this branch: ac-AnnotationStylingRedux you will see that the visual behavior is now incorrect and the anchors are not maintained properly.

[avi-c]

Also, the icon-offset and text-offset properties seem to be broken. it could be that only one or the other is the issue or both could have an issue.

[ZiZasaurus]

I wanted to provide an image depicting the behavior @avi-c mentioned above:

[avi-c]

On the latest versions of the Maps SDK beta we are actually seeing different issues than that one, but both point to errors in the image stretching. Right now we see incorrect anchoring of the annotations. If you look at the image below you will see that the pin should be anchored on the route line but instead it is anchored further up the base/stem of the annotation. This used to work as expected in earlier betas.

[avi-c]

The image that @ZiZasaurus posted above shows the weird shaped annotations because the image is being stretched at the wrong pixel offset into the original asset, so the stem portion is being stretched when only the middle should be.

[cmilack]

The primary issue is that when using iconTextFit, the textAnchor takes precedence and overrides the iconAnchor. On top of that, some of the expressions didn't seem to be working as expected. I think mapView.mapboxMap.style.addLayer(shapeLayer) was probably throwing but it was an optional try so it was being swallowed.

[zugaldia]

This is also impacting mapbox/mapbox-navigation-ios#3177.

/cc: @knov

[ShanMa1991]

I find that the problem is related with the sequence of addLayer and the expression. When the expression is used to style the iconAnchor and iconOffset after we add the layer, they're not working as following:

But when we do it before adding the layer, it's working as expected.

So it seems that right now the SymbolLayer doesn't support the expression styling to a layer already added.

[evil159]

As per #548

This turned out to be expected behavior when using both icon-anchor and icon-text-fit.

[evil159]

Reopening as there seems to be more to it

[evil159]

Closing as stale anyway.

[avi-c]

But does it still occur?

[1ec5]

This turned out to be expected behavior when using both icon-anchor and icon-text-fit.

@cmilack @evil159 I think it’s a bit more nuanced than that. As #381 (comment) shows, the developer basically has a choice between anchoring the symbol on the correct location (resulting in a misshapen icon) or stretching the correct portion of the icon (resulting in a misplaced icon), but not both. I think this is suboptimal for the use case of displaying a 💬-like symbol. If that is no longer one of the intended use cases for icon-text-fit, text-anchor, and stretchable images, then we’d need to go back to the drawing board.

[1ec5]

Confirmed that the issue still reproduces: mapbox/mapbox-navigation-ios#2928 (comment).