MGLComputedShapeSource renders clipped features

[albintornqvist]

In our iOS-application we often see that features from a MGLComputedShapeSource does not get fully rendered. They appear to get clipped in tile boundaries. The error seems to correct itself when panning away from the tile and back again.

See the gif below illustrating the problem.
We can observe that the correct feature appears briefly when first rendered. Then the upper right part of the feature disappears (when the rendering has settled) and appears again when panning away and back again.

Configuration

Mapbox SDK versions: 4.4.1
iOS/macOS versions: 12
Device/simulator models: iPad Pro A1709
Xcode version: 10.0

[kkaefer]

Hm, this looks similar to the issue being fixed in #12982. Let's hold on investigating this until #12982 is merged and you have a chance to confirm that the issue goes away with it.

[albintornqvist]

I have tried to replicate the error with ccae9f9 at tag ios-v4.5.0-beta.1. Unfortunately the changes discussed in #12982 does not seem to fix my problem. I am still seeing the same behavior. We are investigating this further but are grateful for any ideas on what the cause for this might be.

[albintornqvist]

Just a guess we have is that this might be connected to mapbox’s tracking of active/visible tiles. It seems like the tile where the geometry is cut off is inactive. Even if new geometries are added, and the source reloaded/invalidated, they do not appear in the region of the inactive tile. When panning the tile out of view and back again all geometries appear as expected.

[mollymerp]

@albintornqvist can you provide a test case so we can try to reproduce this issue?

[albintornqvist]

I found a way to reproduce the bug in the iOS test app. The problem occurs when it takes some time to feed the data source with geometries and the map is navigated around with a bit of delay at the same time. I tried to replicate the events in our app leading up to the problem.
This commit peroper@68aff8b (on top of the ios-v4.5.0-beta.1 tag) reproduces the issue. It is enough to start the app and the example will run automatically. I successfully reproduced the bug on an iPad Pro A1709 and an iPad simulator. Since the bug seems to only occur with a certain timing, other devices might behave differently. I hope this will make it a bit clearer on what the cause might be.

[albintornqvist]

Any news on this issue? Our production is currently stalled because of this issue and we would appreciate all the help we can get!

[asheemmamoowala]

@albintornqvist sorry for not getting back on this sooner. I haven't been able to reproduce this issue as yet. Is there a specific iPad version that you use on the simulator to reproduce this consistently.

Also - if your geometry spans multiple tiles - you could try setting MGLShapeSourceOptionClipsCoordinates option to YES on your MGLComputedShapeSource. That should clip the geometry provided to the tile bounds.

[herrapa]

I can successfully reproduce the issue @albintornqvist provided (peroper@68aff8b) on both the iPad Pro simulator, and the iPad Air 2 (12.1) simulator. I also tried setting MGLShapeSourceOptionClipsCoordinates to YES, same results unfortunately.

Clipped:

Expected:

[asheemmamoowala]

I am able to reproduce this consistently with the changes from (peroper@68aff8b). Thank you for boiling it down to such a simple case.

My initial guess of what was causing this was way off. Given the asynchronous nature of tile requests and loads, I had to use printf debugging to understand what was going on:

**CustomTileLoader::fetchTile invoke fetch 4399, 2465, 13

CustomTileLoader::fetchTile invoke fetch 4399, 2464, 13
Setting Tile Data on raw Source: 4399, 2464, 13
CustomTileLoader::setTileData called on 4399, 2464, 13
CustomGeometryTile::setTileData called on 4399, 2464, 13

**CustomGeometryTile::setNecessity cancel tile 4399, 2465, 13

CustomGeometryTile::setNecessity cancel tile 4399, 2464, 13

**CustomTileLoader::fetchTile invoke fetch 4399, 2465, 13
**CustomTileLoader::fetchTile invoke cancel 4399, 2465, 13
CustomTileLoader::fetchTile invoke fetch 4398, 2465, 13

CustomTileLoader::fetchTile invoke fetch 4399, 2466, 13

CustomTileLoader::fetchTile invoke fetch 4398, 2466, 13
CustomTileLoader::fetchTile invoke cancel 4399, 2464, 13
Setting Tile Data on raw Source: 4398, 2465, 13
CustomTileLoader::setTileData called on 4398, 2465, 13
CustomGeometryTile::setTileData called on 4398, 2465, 13
CustomGeometryTile::setTileData geoJSONToTile called on 4398, 2465, 13
Setting Tile Data on raw Source: 4398, 2466, 13
Setting Tile Data on raw Source: 4399, 2466, 13
CustomTileLoader::setTileData called on 4398, 2466, 13
CustomTileLoader::setTileData called on 4399, 2466, 13
CustomGeometryTile::setTileData called on 4398, 2466, 13
CustomGeometryTile::setTileData geoJSONToTile called on 4398, 2466, 13
Features parsed: 1CustomGeometryTile::setTileData called on 4399, 2466, 13
CustomGeometryTile::setTileData geoJSONToTile called on 4399, 2466, 13

The problem displayed above is that contents of tile 4399/2465/13 are not being rendered. It turns out that the animation of the map is causing that specific tile to be tagged as optional necessity which cancels parsing the results returned by the implementation in PPComputedShapeSourceDataSource.

The bug goes away if the timing of this animation has subtle changes, or if I add breakpoints. This is likely caused by the timing of invokeTileCancel called from CustomTileLoader::cancelTile being delayed. Commenting out that line also fixes the issue.

A tile marked as optional doesn't get cancelled by other sources. It usually returns and is available for rendering if later required, without needing to be marked as required by the update_renderables algorithm.

I need to further investigate why the tile is not being required again as the animation settles. This would hopefully force the contents of that tile to be displayed.

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

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