-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix race conditions in symbol querying #6461
Conversation
d518331
to
81dc00e
Compare
I added a hover effect to four bus icons in |
4e7aa0b
to
6b87ffa
Compare
Unfortunately the interesting logic is coupled with CrossTileSymbolIndex and Placement.
…bucket that's waiting to be used in the next placement. Even though the data will still be held by the tile, it won't be re-added to the retention list the next time the CrossTileSymbolIndex updates, which means it'll be invisible for querying purposes after the next placement completes.
6b87ffa
to
d96101d
Compare
I've been working on addressing issue #5475 (stop doing |
Looks like this will be superseded by PR #6497. |
Addresses hover flicker from issues #5887 and #5506.
Moves all data necessary for symbol querying into FeatureIndex.
Retains old FeatureIndexes if they're associated with a bucket that was used in the current placement.
The approach to fixing these bugs is unfortunately a bit complicated: because GL JS supports "incremental placement", it's possible that one
CollisionIndex
(which we use for querying rendered symbols) is built with data from multiple different versions of the same tile. Placement can't be interrupted for a single bucket of a single tile, so what we do here is hold on to all the data we need to query each bucket that gets included in a given placement. We piggy-back on the existingbucketInstanceId
mechanism inCrossTileSymbolIndex
that guarantees a unique ID number for each new version of a bucket.In the case where one tile has multiple
FeatureIndex
es (because tile updates have arrived in the middle of an incremental placement), we run our symbol query against each of those indices separately, filteringCollisionIndex
results against the set of bucket ids associated with eachFeatureIndex
.Although this is a pretty inefficient way to store/query what is for the most part a bunch of duplicate data, I'm not too worried about it because it's just a temporary added cost during the period of time between a tile update and the next placement. This PR does introduce a lot of shared pointers to data, though -- one way it could go wrong would be to start leaking that data.
I've manually tested this branch against the repro case in #5506, but I haven't come up with any automated tests yet. Although they'll be a bit contrived, I think I can at least add some cases to the
Tile
unit test that try to exercise the functionality.Launch Checklist
/cc @ansis @malwoodsantoro @ryanbaumann @lilykaiser