Google certainly don't add any objects to the DOM to catch the mouse movements. So the only thing that they could be doing is continually listening for mouse movements and comparing the mouse position to the list of hotspot boxes that come back from the layer server.
The Google code is somewhat opaque, but I reckon that they use quadtree to make the processing efficient. If you were to continually compare the mouseover position to a list of thousands of hotspots by scanning a list one by one, then that would be unreasonably slow. Using a quadtree strategy dramatically reduces the number of comparisons that need to be performed on each scan. See: http://en.wikipedia.org/wiki/Quadtree The Google quadtree code is not accessible, so if you want to do the same, you'd need to write your own. The code at http://www.usnaviguide.com/ws-2008-02/demotilecookies.htm effectively performs a two-pass comparison. It has a list of hotspots for each tile, and scans that list linearly. I guess that's fine if you only have a modest number of hotspots per tile, but I guess it would become sluggish if there were hundreds of hotspots on a tile. -- Mike Williams http://econym.org.uk/gmap --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Maps-API?hl=en -~----------~----~----~----~------~----~------~--~---
