Fluster2 0.1.1 with significant performance improvements
It’s five days since Fluster2 was released and I had the chance to use it in production the first time. When working on this I realized that it was quite slow, the map didn’t work properly when using >1000 markers (changing zoom mode or dragging the map was very slow, even in Google Chrome). So I tried out some things and found a solution. This is Fluster2 0.1.1 now.
Two things changed:
- Markers must not be added to the map, only to Fluster. Then Fluster only assigns markers to the map which have to be displayed. This speeds up the whole map (when changing zoom mode or dragging the map) and makes it about 15 times faster (measured with the 200 markers example included in the download package).
- Fluster only calculates markers and clusters which are in the viewport of the map. When increasing zoom mode, fewer markers/clusters have to be processed. When dragging the map, calculation of the needed markers is triggered.
Download
From now you can download Fluster2 from SourceForge.
Tags: Clustering, Fluster, Google Maps
I think it’s still slower than markerclusterer by Xiaoxi Wu, but anyway thank for sharing this, it’s a lot great feature :)
Thanks for the script.
is there any way to remove markers added to Fluster2 ?
Like the way we add fluster.addMarker(marker), I can’t find any fluster.removeMarker().
Many Thanks
This is great and exactly what I was after. Better still it worked first time.
Could fluster be expanded to:-
a) include a click event on a single marker so that an infoWindow could be displayed.
b) that a parameter could be passed so that clusters are only formed when there are say more than x markers. i.e. you would never see a cluster with x or less markers ‘in’ it.
Very nice, but I noticed a conflict with polygon overlays (I’ve only tried this with a polygon). The clusters are no longer clickable. I tried to see if I could change the z-index of the div/marker cluster but no effect.
Thanks.
Follow-up: I notice this seems to be an issue in markerclusterer, too.
http://code.google.com/p/gmaps-utility-library-dev/issues/detail?id=152
This fix worked for me:
In Fluster2.packed.js/Fluster2ClusterMarker.prototype.draw :
Changed
this.getPanes().overlayLayer.appendChild(this.div);
To
this.getPanes().overlayMouseTarget.appendChild(this.div);
thanks for the script! it works very good with my map. i have only one question: where do i have to put a limit on zoom level so that clusters did not show on every zoom level until zoom 19? i would like clusters to show up until apprx. zoom 16, and then i\’d allow for all the markers to show. could you please help me with that small piece of code? thank you!
First, thanks for this great tool. Works great already with xml-loader. However i’m trying to add an extra infoWindow with a mousover event to a cluster by adding an extra addDomListener.
google.maps.event.addDomListener(this.div, ‘click’, function() {
me.map.fitBounds(me.cluster.getMarkerBounds());
});
google.maps.event.addDomListener(this.div, ‘mouseover’, function() {
console.log(‘Show infowindow with 3 randoms from cluster’);
});
I tried some options already but without succes.
Will appreciate any help.
Nevermind previous post. Made a workaround that works fine now. Thx anyway.
Great work! I’ve been able to set this up, along with the community-contributed clearAll() function mentioned in an earlier thread on this site, to set up a nice cluster map, complete with filtering by different datasets. Brilliant!
I thought I’d mention another slight tweak I’ve made. I noticed that whenever I dragged the map, any individual markers would “flicker” off and on. The cluster icons stay put, this only affects single markers.
I managed to avoid the flicker by amending line 81 of Fluster2Cluster.js from this:
this.markers[0].setMap(me.map);
To this:
if(! this.markers[0].getVisible()) this.markers[0].setMap(me.map);
Which simply does a check first to see if the marker is already visible.
Cheers!
Nevermind that last post! Something is not right with my amend, the markers do not come back after zooming in and out (it appears as though once they’re consolidated into a cluster, they still claim to be “visible”, and my logic check is foiled). Anyway, if I fix it I’ll post a solution, otherwise ignore everything I’ve said!
OK, I *think* I’ve solved the flicker, but I don’t know if this hurts performance. It also seems like a shortcoming in the maps API. From what I can tell, when you remove a marker from a map (via .setMap(null)), the marker’s “visibility” is not toggled. So the marker’s getVisibility() method returns a false positive.
What I’ve done therefore is to explicitly set the visibility status when showing and hiding a marker, via the marker’s setVisibility() method.
So line 81 becomes:
if(! this.markers[0].getVisible()) {
this.markers[0].setMap(me.map);
this.markers[0].setVisible(true);
}
And then what was line 88 becomes:
this.markers[i].setMap(null);
this.markers[i].setVisible(false);
Hope that all made sense…
Hi, first of all, thanks for sharing, but I got a big problem, the sums of the markers are never the same according to the zoom level !
And sometimes the markers just disappear !
Here my test URL:
http://stage.ebuildy.eu/laurent/demo_fluster/commercial1.php
Hi, thanks for this library!
I’m having a problem using this on mobile devices. It seems that _fluster.getProjection() is undefined when it is first called. Increasing the delay before calling createClusters() seems to solve the problem, but I’m not sure why. Do you have any ideas as to what might be causing this?
@Brian, thank you – I was having that exact same problem!
It seems like I solved my problem. Here is my solution in case anyone runs into similar issues.
The call to createClusters should be moved to the draw method of Fluster2ProjectionOverlay instead of being called after an arbitrary delay. Draw is called automatically when the projection is ready. This also makes the explicit zoom handler (and its delay) unnecessary, as overlay.draw() is called whenever the view changes.
Without the arbitrary delays the clusters work correctly on slow hardware.