https://kotlinlang.org
Join Slack
google maps compose is unusable with large amount of markers when using custom clustering when `clus...
# compose-android
m
google maps compose is unusable with large amount of markers when using custom clustering when 
clusterContent
and/or 
clusterItemContent
are not null, meaning when I pass custom composable to it. the more I zoom in, the more it lags until app completely freezes when I zoom in enough. having 
clusterContent
and and 
clusterItemContent
both set to 
null
solves the issue, everything works fine. but I want to customise those.
z
please file a bug
👍 1
m
I will
c
Interesting. I use google maps with AndroidView (in a project before compose maps was a thing) and I have a large amount of cluster items (over 10 thousand). and everything is pretty darn performant. We did put a few things in place to make it performant though because we just followed the general guidelines for the cluster manager algorithm, etc. Have you looked at the readme for google maps because it had a few items worth taking a look at when you have a lot of items.
m
View version if performant, works great. I've rewritten the View version in Compose, so it uses the same data sets, icons etc. I did everything that I should've done, I'm pretty sure.
c
I'll try to lookup what I did in the view version. I did we did two things specifically according to the docs.
If you file a bug though, I'll star. It's on my todo list to migrate.
m
I'll file a bug and we'll see. I'll scan through docs first but I think I've done everything right.
But again, it works with default markers and clusters, that's what's weird to me
@Colton Idle can you point me to what did you mean, maybe I really missed something
c
Yep. Once I'm out of work I will try to get back to you!
m
thank you very, very much
c
Looks like the fix for issue 380 was merged
FWIW. it looks like the two tricks to speed up rendering for me were: 1. clusterManager!!.setAlgorithm((NonHierarchicalViewBasedAlgorithm(screenHeight, screenWidth))) 2. val collection: Collection<Things> = VisibleMarkerHelper.filterVisibleMarkers(thingsOnMap, markerOnMapPosition)
m
nice, nice. thank you for the information
I’ll try this as soon as I can
c
Looks like there was good comments from a gmaps team member also after I commented: https://github.com/googlemaps/android-maps-utils/issues/1199
m
interesting. I’ll keep eye on this one. same as you @Colton Idle I want to get rid of 
AndroidView
. whole app is in compose and just map is using 
AndroidView
with a lot of ugly code that was a nightmare to write and cleanup
☝️ 1
s
Note that Compose wrapper for maps uses 
AndroidView
as well, so technically it is no different
m
I’ve noticed it while digging through the code to try to solve this problem. technically it’s not different but it makes difference in my code 😄 and how I’m writing/using it.
c
Yeah. I completely understand that it's still AndroidView underneath. But me doing my own crazy thing to try to get my own MapView to recompose because of different clusters and stuff is such a headache. I'd love to be able to have a nice performant example of how to do this stuff.
💯 1
@Marko Novaković if you have some time maybe you can chime in on https://github.com/googlemaps/android-maps-utils/issues/1199 I have not had the time to look at it yet
m
@Colton Idle I saw new replies but didn’t have time to try 
NonHierarchicalViewBasedAlgorithm
. I’ll try it soon and share in the issue
K 1
92 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by