Thanks for your post -- I had seen your tiling class before though without any context.
For what it's worth I had initially started some time ago by implementing my own tile loader by subclassing MapType directly but quickly found that I was running into having to write a lot of browser specific code, problems with optimizing dom manipulation performance, needing to write my own algorithms for determining the tile request order (center out spiral) and a lot of other stuff. So I ultimately decided the perceived advantages of being able to do "deferred rendering" (I was calling it zoom/pan debounce) and managing my own request queue (I had an array of 50 tiles "holders" that I would dump into the dom and then manipulate my tileset within), etc. All this stuff was not really worth the hassle of trying to duplicate the efforts of the entire team of Maps developers who I imagine spend all day every day thinking about how to make tiles serve up faster... So I've spent enough time going down that I'd rather find an alternative. Knowing more about how ImageMapType operates internally and being able to experiment and change some things about the way our backend handles requests has been very helpful. Tiles are now coming in much faster after rapid zooming although the problem of interim tiles not being cancelled aggressively enough is still present. I disagree that cancelling in-flight requests is a bad performance move -- as Ben said the pending downloads are the whole crux of the problem in this case! After learning that request cancellation is supposed to happen and is currently not working in Chrome (and perhaps isnt aggressive enough in other browsers either,) all of my mitigation strategy today has been attempting to give the browser the best chance to keep making new non-blocking requests upon a zoom or pan by manipulating the hostname used to make the request (the number of hostnames and the mapping of tile/zoom->hostname). Cancelling requests is probably only a bad move if your tile generation is really expensive, your tiles are ridiculously huge in filesize, you don't or can't cache your tiles, and you have a reasonable expectation that your users will return to tiles they just abandoned. Plus, if you only have a few "slots" to download tiles you don't want these slots filled with slow multi-second tile downloads -- in that case it doesn't really matter what the next tile to download is. In our case though more aggressively cancellation of requests by the API would be quite welcome. If a tile has not yet been generated, our backend will generate it as fast as possible and immediately return it to the client; however before saving the tile to the cache it will continue to perform additional (read: slow) optimization and compression. Thus if the client aborts the initial request and then returns after a couple of seconds/minutes/hours/days to re-request the tile, they'll not only be fetching the tile from cache (no generation latency!) but it will probably be much smaller than it would have been originally. -- 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.
