Image Artifacts Remain After Adding/Removing Symbol Layer

[otmanskim]

We're trying to add and remove "image" layers (they are actually MGLSymbolStyleLayer's), using the workaround detailed here. We have added a UIButton that will add and remove the image layer as appropriate when tapped. We are removing the images by removing the source, layer, and imageName from the map's style:

style.removeSource(source)
style.removeLayer(layer)
style.removeImage(forName: overlay.identifier)

The issue we are seeing is after removal, if we zoom in or out, when we re-add the layer, this time the image appears distorted, as though artifacts of the old image are still present on the map. Screenshots attached.

Original Image:

Image after removing, zooming, and re-adding:

Platform: iOS (10)
Mapbox SDK version: 3.5.4

Steps to trigger behavior

1. Implement the workaround to add an image layer to the map, as described here: Support "image" source type #1350 (comment)
2. Also implement removal / re-adding of the image layer
3. Run the app to add the image the first time
4. Remove the image layer from the map's style (via button or other added interface)
5. Zoom the map in or out
6. Re-add the image layer (via button or other added interface)
7. Notice extra border around the edges of the image looks like part of the original image

Expected behavior

The image should appear the same the second time it's added as it did the first time.

Actual behavior

The image appears distorted and artifacts from the original one remain.

[otmanskim]

@Guardiola31337 @fabian-guerra Is there any timeline for when someone will be able to take a look at this? It's blocking a release we have scheduled for next week, so we would greatly appreciate an expedited investigation. Thanks!

[friedbunny]

You might try this with the latest pre-release of v3.6.0, the stable release of which we’re currently finalizing. I don’t recall there being any relevant fixes included, but it would be good to confirm.

There’s also already been work done/planned for the release after that to improve the rendering of textures and images, such as #9213 and #9110. Our release cadence is typically once every few months, with pre-releases coming sooner.

[otmanskim]

@friedbunny thanks for your response! I tried this with v3.6.0 and unfortunately saw the same issue. I notice that both the PR's you linked are now merged. When would you estimate these changes will make their way into a release, even if it's just a beta?

[friedbunny]

It’s still too early to say what the timeline will be for the release after v3.6.0 (tentatively titled v3.7.0).

Though not production quality, we do publish nightly builds of the master branch. Today’s already includes #9213, and tomorrow’s will have #9110.

[otmanskim]

@friedbunny thanks for the help, I will definitely be taking a look at the nightly build soon to start playing around with this update. However we are scheduled to go to production in the next week, so do you think it would be at all possible to get the code merged in #9213 and #9110 into the next upcoming version, even if it's still a little rough around the edges?

[friedbunny]

do you think it would be at all possible to get the code merged in #9213 and #9110 into the next upcoming version

Unfortunately, no. Those changes are substantial and bugs/performance issues are still being ironed out, while v3.6.0 is more-or-less frozen and readying for final release.

[1ec5]

Does the issue reproduce if you give the image a new name every time you add it to the style? (I know this sounds kludgy, but it might help us narrow down where the problem lies.)

[jfirebaugh]

3.7.0 added MGLImageSource and likely fixed this bug as well.