Skip to content

Wait for sprite to load before parsing tiles #10294

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

Merged
merged 5 commits into from
Jan 26, 2021

Conversation

ryanhamley
Copy link
Contributor

@ryanhamley ryanhamley commented Jan 14, 2021

Launch Checklist

  • briefly describe the changes in this PR
    • This addresses Inconsistent rendering of a coalesced image expression #10122 by waiting for the sprite to finish loading before parsing tiles. This will ensure that any image expressions embedded in a style will have their sprite images available to them and we can be confident that if an image isn't found, it's because it's not in the sprite, rather than the result of a race condition in which the tile loaded before the sprite.
  • write tests for all new functionality
    • in progress
  • post benchmark scores

Screen Shot 2021-01-13 at 4 28 47 PM

This does not seem to have a substantial impact on tile load performance
  • manually test the debug page
  • apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
  • add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Ensure sprite has loaded before parsing tiles to avoid race condition when evaluating image expressions</changelog>

cc @tristen

Sorry, something went wrong.

if (this.scheduler) {
this.scheduler.add(parseTile, metadata);
} else {
parseTile();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In what case is this.scheduler not defined?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied this from above in the DedupedRequest class. Both classes get scheduler from actor.scheduler and since DedupedRequest lists the type as ?Scheduler, I assumed that should apply to this class as well and I should guard against the possibility that actor won't exist or won't have a scheduler property. I think this could be an issue in testing?

@karimnaaji karimnaaji added this to the v2.1.0 milestone Jan 25, 2021
@ryanhamley ryanhamley force-pushed the avoid-image-expression-race-condition branch from 0ecc2fd to 1ad2dbc Compare January 25, 2021 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants