Increase maximum label width by factor of 2 #6375
Merged
Conversation
This file contains 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
|
Before: Thank you @ChrisLoer! I haven't found any labels that still overflow. The additional 2x width makes a big difference for us. |
|
@james-wagner11 that's great! Thanks for posting those pictures, and happy this turned out to be (knock on wood) an easy one. |
mollymerp
approved these changes
Mar 22, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a partial fix for #1531 -- wide labels can still overflow (at which point they stop rendering correctly), but they can now be twice as wide, which will hopefully cover a much wider variety of use cases. #5150 took care of the collision detection problem, so there's no added work necessary for doing collision detection on labels that are wider than the tile's symbol buffers. Also, we no longer use tile clipping for symbols, so there's no problem with labels bleeding far outside their origin tile (err, except for api-gl, wide labels will get rendered-correctly per-tile, but a very wide label in a neighboring tile may be clipped if it doesn't make it into the symbol buffers).
This decreases our glyph-placement precision from 1/64th pixel to 1/32nd pixel, which still seems plenty high. I can't notice any difference in rendering, and all of the render tests pass without change. Doing another halving to 1/16th pixel precision still looks fine to my eyes, but it causes two render tests to fail on (very slight) glyph position changes. For now, 1/32nd seems like a good conservative choice.
Test result before fix:
/cc @ansis @jfirebaugh @james-wagner11