We are about to make an update to the Google Maps API. This update
contains changes to speed up addition of overlay markers to the map.
The change will be transparent to applications that use the published
Maps API. However, if your application or extension makes use of
undocumented features, you may want to test it against the latest
version of the API:
Prior to this version, calling map.addOverlay(overlay) was slow for
large numbers of overlays. As some of you discovered, the reason was
the repeated internal calls to reOrderOverlays method. Several people
found a work-around by creating the 'addOverlays' method which added
an array of overlay markers and called reOrderOverlays just once.
the reOrderOverlays method was responsible for determining the
stacking order of overlay markers based on their latitude so that the
marker icons and their shadows would appear on the correct zIndex.
In the new version of the API, there is no longer a need for calling
reOrderOverlays since the stacking order of each overlay is computed
directly based on its latitude. This change should remove the need
for 'addOverlays' method because the regular addOverlay is be about as
fast.
The other change is the way different overlay elements (marker icons,
marker shadows, etc...) are placed on the map. Prior to this version,
all elements were appended to the map.div html element. Different
conceptual layers (eg: shadows vs. icons) was achieved by allocating
different zIndex ranges to each layer (eg: 5000 -> 10000 for the
shadows). In the new version of the API, each conceptual layer has a
dedicated div element (eg: map.markerPane).
If you are constructing a custom overlay (beyond customizing a GIcon),
you should try to use these dedicated Panes. Also, the
overlay.setZIndex() method has been modifed to accept a single zindex
value which should be applied to all elements that make up an overlay.
We are still in the process of finalizing an API for developing
Overlays and Controls. We will post more complete documentation once
it is ready.
will addOverlays continue to work after the release of 17 or is reORderOverlays going to go away completely? thats will all the addOverlays maps suddenly break when the change over happens?
>will addOverlays continue to work after the release of 17 or is
>reORderOverlays going to go away completely? thats will all the
>addOverlays maps suddenly break when the change over happens?
Perhaps we could persuade someone who currently uses addOverlays to do
the test recommended at the top of this thread and let us know.
add the line
<script src="http://maps.google.com/mapfiles/maps.17.js"
type="text/javascript"></script>
just after you call the main API code, so that maps.17 overwrites the
maps.16 that just got loaded.
I took a peek at the code, and from the looks of it, it looks like addOverlays will still work as reOrderOverlays is still defined, but does nothing. Haven't tested though. I would be interested if it still works as well.
I used the latitude to zIndex approach as well for my gallery marker effects.
With the map I'm working on, the addoverlays extension appears to work with version 17 of the Google Map javascript. So, no immediate need to change it, but addoverlays is apparently redundant and should be removed at some point - after 17 is out!
Now to take care of the glacial InfoWindow! While some developers avoid using them, myself included, the default behaviour should be a little less painful. It's like having a Ferrari dragging an iron girder behind it as a bumper. It works, but...
Of course the biggest bang for the buck (from a developer point of view) would be to give the marker's ids. A hundred character or so of code in the map js, and a million possibilities for developers. But if you're soon going to give us mouseover mouseout and the ability to change the icon on-the-fly, then ids are no big deal. ;)
> We are still in the process of finalizing an API for developing
> Overlays and Controls. We will post more complete documentation once
> it is ready.
Thanks for posting information about your API changes. I'd like to try
to document the innovation that you and Google are undertaking for the
mozilla project. The mozilla project wiki covers javascript, but lacks
good examples of what is possible.
It would be a great step forward for the development of javascript if
Google could provide more information about the maps javascript code. I
think there are components of the maps.js file that could be pulled out
and made into general purpose API's under licenses like the GPL that
would accelerate further web development using open standards.
Sweet grandmother's spatula! Those marker-rendering changes you made have sped things up by an enormous margin. 400+ markers' render time has been improved from 30-60 seconds (or just plain crashing a browser) to just around 10 seconds. Bravo!
