-
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
featuresAt callback delay after adding geoJSONSource at high zoom level #1507
Comments
@kristfal Can you post an executable test case on JSFiddle? Also, can you post the profiler |
@jfirebaugh Working duplication at https://jsfiddle.net/paoqrwec/7/ See inline comments for workarounds, let me know if it doesn't lock up for you. Isolated the case to requiring an empty geoJSON source + high zoom level to trigger this issue. |
Wow, that looks wild. So apparently it's only reproducible with an empty GeoJSON, right? Investigating. |
@mourner That is correct. It also requires a high zoom level when the GeoJSON is loaded. If you change it to 2 in the fiddle and re-run, it will work even with the empty GeoJSON. |
Confirmed to be an upstream geojson-vt bug, mapbox/geojson-vt#40 |
Released geojson-vt 2.1.6 with the fix. Should be included in the build of the next gl-js version. Also discovered a different bug that led to more tiles being generated than necessary, fixed as well. Thanks for the report! |
@mourner Thanks for the fast turnaround, I'll keep you posted if I find anything else after it has trickled downstream. |
Hey,
featuresAt
callback may at times be as slow as 70+ seconds after adding a geoJSONSource at high zoom levels. The source data I'm testing with is a line string of 12 kB, and it renders instantly.This issue only happens if the geoJSON is loaded at high zoom levels. At low zoom levels, there is no delay. During this delay, CPU activity is 100%.
Adding source data with (can't add through URL in this use case):
Tap event:
After the initial wait/delay,
featuresAt
triggers instantly again. If multiple tap events are triggered during the delay, they queue up and fire in sequence.unproject
and other methods trigger instantly at any time during this delay.I can only reproduce this issue if the source is loaded a high zoom level (12+). Loading the source at lower zoom levels and triggering a click event doesn't cause a delay, nor does zooming in and clicking after a load.
Profiling this issue leads me to believe geoJSONVT.splitTile is causing the slowdown. It seems to me like the issue only happens if the geoJSON crosses tile boundaries upon initialization, but I can't verify this 100%.
See attached screenshot for profiling results. Let me know if you need any other info.
The text was updated successfully, but these errors were encountered: