-
Notifications
You must be signed in to change notification settings - Fork 26
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
Fluster - performance issues #7
Comments
My Widget:
|
Also, a little issue that I found it that I need to instantiate the Fluster instance with data already, with one possibility to update the instance later. This is quite a bit obstacle if you would like to manage the state properly and not rebuild the entire widget from scratch. |
I've been working with over 8000 items to be displayed on the map and I have to say I'm pretty envious of lesser lag you are facing. One way I managed to optimize loading of the clusters was here at this line:
I replaced the [-180, -85, 180, 85] with only the currently visible region on the map using So essentially, you would be fetching and processing only those clusters that are currently visible to the user on the map. When the user moves the maps camera, I'm calling fetchClusters() again with an updated visible region. |
Oo that is a good idea, but doesn't your phone get overheated? With these 700 items, the phone is quickly starting to burn (I'm using Pixel XL and iPhone xs). Also, I observe that when having items very need each other it would be nice to have the clustering stop working when reaching some zoom values, like above 18 clusterings would just leave it to google maps. |
I did not face an overheating issue but I did face terrible lag. I added an if condition too that checks the current zoom level and displays the clusters only if it is under a certain zoom level. Yet it was still slow. I'm not an expert but from what I understood, the K-D tree algorithm at the heart of the Fluster package essentially works on two things - searching and indexing. Indexing is what shows the clusters and searching is when you zoom down to a single marker. They are decided by 'extent' and 'nodeSize' parameters of fluster. The default values are like a sweet spot. These two parameters can be tweaked at the expense of each other i.e. increasing the indexing efficiency makes the searching bad and increasing the searching efficiency makes me the indexing bad. (I guess. Like I said I'm not an expert). I managed to reduce the lag by drastically increasing the 'extent' parameter value and decreasing 'nodeSize' value but that in turn resulted in me waiting for a couple of seconds for the marker to show up once I zoom down. You could probably look into this. At the end, I gave up on using Fluster because for 8000 items I just could not reduce the lag regardless of what hack I tried. Good luck! |
I had the same problem. Using onCameraIdle instead of onCameraMove() to update map and only update visible region solved the problem for me GoogleMap( |
I'm using something like this:
Not perfect. Still tinkering with the values. Will probably have more steps at various zoom levels. But the relationship between extent and nodeSize is definitely the right approach from my testing. |
First of all good work with the lib and providing an alternative for clustering.
I've followed your example with a bloc provider and tried to adapt it to my use case.
One major difference is that in my scenario I have over 700 items that need to be displayed on the map (a perfect case for clustering :)).
The data is passed from an http service and filtered based on some conditions that can change outside the map. That's why I use a provider to reload the map when data changes (the data can change based on the filtering).
My markers have different marker icons depending on the item type, the cluster icon has a number - children count that are under the parent. For this reason, I needed to make the function that creates markers an async function (because of the drawing of cluster icons to be exact).
I observed that with this amount of items my app has performance issues (it recalculates the cluster markers on each zoom or camera position change). Because I'm using async functions, this adds extra overlap to the overall process.
There is the demo:
https://drive.google.com/open?id=19USypvWS0KIRF7J1-42mSHVYV9BfoMkr
The text was updated successfully, but these errors were encountered: