Conversation
… error image readyToDisplay documents itself as true when "loading errored but an error image is configured", but _display() set it on any error regardless. A tile that failed and has nothing to paint therefore counted as covering its area, so renderTiles discarded the coarser ancestor standing in for it and the area went blank instead of staying upscaled. Services whose coverage depth varies by location show this plainly: past the deepest level available at a given place the tiles 404, and zooming in lost detail that was already on screen. Set it from errorImage, as documented. Tiles that have an error image are unaffected, and must stay ready — opacity is gated on this, so the error image would otherwise never be painted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A TileProvider that cannot throw returns TileProvider.transparentImage instead, usually when a request is cancelled as its tile leaves the viewport. That arrives as an ordinary successful 1x1 decode, so the tile is marked loaded while painting nothing, and counts as covering its area. The cancelled tile itself is being disposed, so it is not the one that suffers. A tile created while that request is still in flight is: it resolves the same URL, attaches to the same pending image stream, and receives the placeholder. It is live, it claims to be loaded, and it paints nothing, so the layer drops the ancestor that was standing in for it. Report it as a load error so that ancestor is kept, and evict it for the benefit of providers that return the placeholder without evicting it themselves. It reaches errorTileCallback but is not printed: abandoning a load is routine while panning. Depends on the readyToDisplay fix in the previous commit; without it a load error still counts as covering and this changes a blank tile into a hole.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #2260 — the first commit here is that PR. This only makes sense with it: without that fix a load error still counts as covering, so on its own this would turn a blank tile into a hole.
A TileProvider that cannot throw returns
TileProvider.transparentImageinstead, usually when a request is cancelled as its tile leaves the viewport. That arrives as an ordinary successful 1x1 decode, so the tile is marked loaded while painting nothing, and counts as covering its area.The cancelled tile itself is being disposed, so it is not the one that suffers. A tile created while that request is still in flight is: it resolves the same URL, attaches to the same pending image stream, and receives the placeholder. It is live, it claims to be loaded, and it paints nothing, so the layer drops the ancestor that was standing in for it.
Report it as a load error so that ancestor is kept, and evict it for the benefit of providers that return the placeholder without evicting it themselves. It reaches
errorTileCallbackbut is not printed — abandoning a load is routine while panning.