I see what you are saying. I think the OverlayView and GOverlay are designed for "full" overlays which are positioned once with "draw", whereas MarkerClusterer etc efficiently manage the display of "partial" overlays, and are best updated on "bounds_changed".
Based on my testing I think Luke was right to say that "bounds_changed" gives a better user experience than "idle". It's quite a pause before clustering begins. As described by the OP the only problem is with a cascade of bounds_changed events where the Manager must do too much work, which blocks the user interface and maxes the CPU. I think the fix to this problem is to ensure the main calculation method createClusters_() can be interrupted if it running for too long. I tried this by having createClusters_() check whether it had been running more than 300ms, and if so, to setTimeout() with a resumption of the method after 0 milliseconds. This pause gives the processing thread back to the browser and allows other events to occur like for the user continuing to drag the map. This worked but the display was confusing because partial cluster counts were shown, and these were updated as processing completed. To be interruptable the update process needs to return final results, not interim results, so I'll try a grid-based update instead. ... -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to google-maps-js-api...@googlegroups.com. To unsubscribe from this group, send email to google-maps-js-api-v3+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
