Skip to content
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

Symbol rendering issue at viewport edges during pan/pitch #6781

Closed
dagjomar opened this issue Jun 5, 2018 · 2 comments
Closed

Symbol rendering issue at viewport edges during pan/pitch #6781

dagjomar opened this issue Jun 5, 2018 · 2 comments

Comments

@dagjomar
Copy link
Contributor

dagjomar commented Jun 5, 2018

screen shot 2018-06-05 at 22 17 02

Video

https://www.youtube.com/watch?v=WUkhM0tRdUE

JSBIN

https://jsbin.com/tohelasila/edit?html,output

mapbox-gl-js version: 0.45.0, 0.44.2, 0.44.1, 0.44.0, 0.43.0, 0.42.2 (but maybe not as bad?), 0.42.1, 0.42.0 (better on pan, but still bad on pitch),

Not reproducible on 0.41.0

browser: Tested on OSX on Chrome, Safari, Firefox

Steps to Trigger Behavior

  1. Have some symbols on one or more layers that will cause symbol collisions such that only one of the symbols are visible after collision/clustering logic
  2. Move the viewport such that symbols are outside of the view. Then pan or trigger a camera action such that the symbols will are in view.
  3. You will observe that ALL the symbols are briefly visible initially while the ones that are affected by the collision logic are faded out, leaving only the ones that should be visible.

Expected Behavior

  • Expected clustering/collision logic to have run before symbols enter view and be pre-calculated as visible or hidden and not have the fade-out animation when this case occurs.

Actual Behavior

  • Fade-out animation occurs
@dagjomar dagjomar changed the title Symbol rendering issue at viewport edges Symbol rendering issue at viewport edges during pan/pitch Jun 5, 2018
@ChrisLoer
Copy link
Contributor

Thanks for the report @dagjomar! I believe this is a duplicate of #5654 (see also #6489 for a clearer example of the actual behavior).

@dagjomar
Copy link
Contributor Author

dagjomar commented Jun 6, 2018

@ChrisLoer Ah, thanks. Looking forward to seeing #5654 being fixed then ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants