On Jun 28, 3:45 am, mark mcclure <[email protected]> wrote:
> I've seen several discussions on this list asking whether encoded
> polylines/polygons will ever be included in the V3 API. While I
> certainly think that the auto-encoding on the fly that is now built
> into the new API is a great addition, I still think that the option to
> pre-encode delivers the greatest performance. Here's a natural
> example.
> V2
> pre-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/BritishCo...
> V3
> auto-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/gmap3.html
>
> It should be no surprise that the first loads faster, since it much
> smaller. Even after the page loads, however, there is a delay in the
> second where, presumably, the encoding occurs.
>
> FWIW,
> Mark McClure
Other factors contribute to the performance difference. V2 builds a
single rectangular DIV. V3 builds tiles. A single rectangular DIV is
quick to initialize but panning & zooming are slow. Tiles require
extra effort to construct but panning & zooming are fast. V2 accepts
an array of {x:,y:} objects which is directly executable in
JavaScript. V3 requires every vertex to be executed in a new LatLng
object constructor which adds a ridiculous amount of overhead. Except
for reduced file size & reduced transmission time, encoding does not
offer very much. Zoom strings are an abomination.
http://www.polyarc.us
contains several demos of like complexity. I will try to duplicate
your British coast line demo in the next several days.
--
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 [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-js-api-v3?hl=en.
