Google Maps API Tutorial

© 2008, 2009 Mike Williams

Translate this page:


Google Chrome Considerations




Chrome is an awful lot faster at client side processing. In particular, it compiles Javascript code rather than interpreting it.

[But it's possible that you ain't seen nothing yet. TraceMonkey is rumoured to run Javascript faster.]

This doesn't mean that every map page will run faster. If the critical factor is the amount of time it takes to fetch resources from a server then there's not a lot that Chrome can do to improve the speed.

What's acceptable is very subjective, and depends on the hardware and Internet connection speed as well as the browser. On my computer, I reckon that the number of displayed markers and polylines that make the browser unacceptably sluggish are:
    MSIE: 100 markers or 10 polylines.
    Firefox: 300 markers or 100 polylines.
    Chrome: 2000 markers or 1000 polylines

Currently Unsupported

Google Chrome is not included in the current list of supported browsers.

Most of the Google Maps API functionality works under Google Chrome, and GBrowserIsCompatible() accepts it, but if you happen to stumble upon something that doesn't work under Chrome, then there may not be a fix for it.

3D Map Type

G_SATELLITE_3D_MAP currently doesn't work under Chrome. The Google Earth plugin is not recognised.

Async Behaviour

Chrome has more asynchronous behaviour than other browsers. In other browsers, the display only gets refreshed when Javascript pauses, but Chrome is designed to run Javascript and refresh the display at the same time. This might possibly be a problem if you depend on things happening in a predictable order.

One particular problem that you might encounter is that it's possible for the Javascript to start executing before CSS files have been read. If your map container has its size specified in an external CSS file, Chrome may well execute the "new GMAp2()" command before the map container size is known. A moment later, Chrome processes the CSS information and changes the size of the container, but the GMap2 object has been created with the wrong size.

Maps in new tabs

There's an occasional problem that results in a page that's launched into a new tab to be centred incorrectly.

It seems to occur intermittently with the API, but it occurs consistently with For example If you shift-click this link in Chrome and wait a few seconds for the page to be rendered in the closed tab, then the marker gets placed in the correct location but the map is centred on Moscow instead of Blackpool.

Poor developer tools

At present there are no useful extensions for Google Chrome equivalent to things like Firebug, Venkman, HTMLValidator and WebDeveloper in Firefox.

I recommend developing your code in Firefox and testing it in Chrome, MSIE, etc afterwards.

Polygon winding rule

When you create an encoded polygon with holes, the holes may not appear when your map is viewed with Chrome.

This is because the API uses the CANVAS graphics technology to render polylines and polygons, and CANVAS has a different winding rule.

In the other three graphics technologies, a region of a polygon is filled if its winding number is odd, and left empty if the winding number is even. You can consider the "winding number" to be the number of times that the path winds round the region in a clockwise direction. So, if you have a clockwise outer boundary and a clockwise inner boundary, the inner region has winding number 2, and is rendered as a hole.

In CANVAS, a region of a polygon is filled if its winding number is non-zero, and left empty only if the winding number is zero. So, if you have a clockwise outer boundary and a clockwise inner boundary, the inner region has winding number 2, and is not rendered as a hole. To create a hole you need to have one path be clockwise and the other path be anticlockwise for the centre to be renedered as a hole.

Here's an example

Similarly, if you have a polygon with a path that crosses itself, the interior will appear different in Chrome.

Here's an example

The different winding rule is a basic feature of the graphic technology, and there's nothing that the API can do about it.

Polygon fill order

The fill of a polygon appears to be performed above the polyline that forms its boundary, whereas with the other graphics technologies the boundary is placed on top of the fill. This can make the result look quite different.

Consider this example and this one


From time to time, Chrome will decide to update itself. Without asking.

During the update process, the computer becomes so sluggish that it's effectively useless for doing anything else until Chrome has finished its update.

Chrome also seems to occasionally perform extensive housekeeping tasks. At least I guess that's what it's doing. Every so often it will grab 100% of the CPU for about 10 minutes without any Internet I/O. The only way I've found to do any other work on the computer is to close Chrome, then, when I don't want to use the computer for a while, restart Chrome and let it do its thing.

Back to Mike's Homepage
Up to the start of this tutorial