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

Best performance for many markers #48

Open
az-faro opened this issue Mar 14, 2024 · 6 comments
Open

Best performance for many markers #48

az-faro opened this issue Mar 14, 2024 · 6 comments

Comments

@az-faro
Copy link

az-faro commented Mar 14, 2024

Say that you have a map with thousands of markers, are there any best practices for how to handle that to still have good performance?

  • Just let the library handle it (does the library ignore markers that are out of view? other performance improvements?)
  • Manually remove markers that are out of view (will reduce rendering if the library is bad at culling markers, but adds costs in constantly adding/removing items from lists and creating/destroying views)
  • Set markers that are out of view to GONE or INVISIBLE (unknown if this has any effect, again depends on the library)
@p-lr
Copy link
Owner

p-lr commented Mar 15, 2024

This library supports markers lazy loading, which does what you describe. You can see an example in the demo app (see "Markers lazy loading").

EDIT: sorry I thought the issue was about MapCompose. MapView indeed does not support markers lazy loading, and is on maintenance mode. So you're right, you would have to manually set markers visibility.

@az-faro
Copy link
Author

az-faro commented Mar 15, 2024

Thanks for the info, I might look into MapCompose then.

As for MapView, would you say adding and removing the entire markers is better or worse from a performance perspective vs just hiding the markers that shouldn't be shown?

@p-lr
Copy link
Owner

p-lr commented Mar 15, 2024

I would only set the visibility of markers to GONE or VISIBLE because adding and removing the markers causes the parent layout to recalculate its size.

@devjta
Copy link

devjta commented Mar 27, 2024

I would also need performance and/or clustering in the old one.. We dont want to use compose, as we had really bad experience. Our customers are still using crappy devices and everything was just slow, so we needed to redo everything in XML again..

Just so you know, what I am talking about: We are talking about something like >10k points on a single screen. The map is not infinite (its a plan of a building).

The original https://github.com/moagrius/TileView could handle that better.. But it had issues with recycling bitmaps and crashing the app then -.-

@az-faro
Copy link
Author

az-faro commented Mar 27, 2024

@devjta What I do when there is a lot of markers on the screen at once is that I start randomly hide them. If you have > 10k markers as you say then no one could possibly see anything useful with all of them visible anyway, so it's better to start hiding stuff randomly to reduce the clutter (it will still just look like a mess of markers to the user, but from a performance perspective it should be a lot better). Then as the user zooms in, less items will be on the screen at once and you can let more markers be visible.

The other option obviously being to cluster several nearby items together in a single marker (but again as this isn't supported natively by the library you would have to roll your own solution).

@devjta
Copy link

devjta commented Mar 27, 2024

@az-faro yeah, we kinda need some z-index logic and hide the pins which are mostly behind.. sounds like a good idea.

And yeah, I would need to add the clustering in there. If I get it to run successfully, I would even upload it. We already customized many things in the library, so we basically forked it already.

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

3 participants