Skip to content

Conversation

@SamSamskies
Copy link

Consider this scenario... A user draws a long polyline on a map, say across the whole United States. They add a decorator to the line displaying a marker every 100 pixels. If the user zooms close into the line, thousands of symbols are drawn that are not even visible on the map. This was causing the browser to crash in the app that I'm working on. I noticed that the DOM had thousands of marker DOM nodes in it when zooming in.

With my changes, it seems to increase performance a lot. We keep the cache, but only add the symbols that are in bounds on the map to the DOM. Now instead of having close to 10,000 symbols in the DOM when zoomed in on a long line, I have 10 in my case.

Consider this scenario... A user draws a long polyline on a map, say across the whole United States. They add a decorator to the line displaying a marker every 100 pixels. If the user zooms close into the line, thousands of symbols are drawn that are not even visible on the map. This was causing the browser to crash in the app that I'm working on. I noticed that the DOM had thousands of marker DOM nodes in it when zooming in.

With my changes, it seems to increase performance a lot. We keep the cache, but only add the symbols that are in bounds on the map to the DOM. Now instead of having close to 10,000 symbols in the DOM when zoomed in on a long line, I have 10 in my case.
@bbecquet
Copy link
Owner

Hi!
Thanks a lot for contributing, and sorry for this very late reply. I haven't had time during the last months for my open-source projects :/

You raised a very good point, as indeed the plug-in may quickly create a lot of DOM objects and become very slow. Actually, a lot of people have complained about the overall poor performance, and I had to find some ways to improve it.
Your fix is a great to do it, but I can't merge it as-is. It assumes symbols are always Markers, with a _latlng properties, but they can be Paths or even LayerGroups too, so it crashes in these cases. When the symbol is not a Marker, the getBounds() method should be used.
You can send another pull request with the fix, or I will do it myself, because I waited so long to reply that you may have moved on.
Thanks again!

@Splaktar
Copy link

Hopefully this can get improved and merged in. It sounds like this will greatly help with some of the performance issues. But it certainly needs to handle Paths and LayerGroups (probably FeatureGroups too).

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

Successfully merging this pull request may close these issues.

3 participants