Ben, I am seeing the behavior in Chrome and using the Network tab to check the issue. If I load my map with a single tile overlay (ImageMapType) requests queue for all tiles at all zoom levels, and the requests wait to complete. In fairness *sometimes* i can zoom fast enough that requests for an entire (or partial) layer are skipped, but for sure I never see requests that begin and are aborted. The base tiles are also loaded from google for all layers, but since they never have to be generated and are smaller in file size, the problem is not visible.
If I zoom from the my map's default zoom 5 in to its max zoom of 17, the network pane will report the following times for the request for a tile at layer 5: Conversely a tile at layer 5 has the following profile: Proxy 0, Blocking 0, Sending 0, Waiting 76ms, Receiving 209ms But by the time a layer 17 file is requested so many pending requests have built up progressively to a much longer blocking time: Proxy 0, Blocking 6.08s, Sending 0, Waiting 276ms, Receiving 0 Currently, I am requesting all of my overlay tiles using the same hostname. I do understand that I could use one hostname per layer and this would allow more concurrent connections and the ability of the browser to immediately initiate tile requests in a new layer without blocking, but only so long as the browser will still be willing to open new requests. It also introduces some other problems -- the load to generate all the interim tiles still unnecessarily goes to the servers. I have actually tested the multiple hostnames per layer and it helps a bit but not enough, and doesn't really solve the core problem. In firefox I do occasionally see Aborted requests in firebug, but still most of the time I see hundreds of lines with spinners as the downloads for each interim layer complete. John On Jan 25, 4:42 pm, Ben Appleton <[email protected]> wrote: > Hi John, > > The API will initiate requests for tiles on screen, but cancels any > in-flight requests after you zoom in again. It should not wait until pending > requests are satisfied. Further, your browser will limit the number of > concurrent requests to your tile server, so your tile server should not have > to generate every tile during a scrollwheel zoom over multiple zoom levels. > Different browsers use different limits here. > > For example, if I > loadhttp://code.google.com/apis/maps/documentation/javascript/examples/ma... > Firefox with Firebug enabled, then scrollwheel zoom a few zoom levels, > Firebug's Net tab reports many canceled tile requests and the final tiles > appear reasonably fast. > > Which browser are you using? Can you confirm that tile requests are never > being cancelled? > > Thanks > Ben > > > > > > > > On Wed, Jan 26, 2011 at 2:38 AM, John Laur <[email protected]> wrote: > > Hello, > > > I'm new to the group here; hello everyone. > > > I'm trying to figure out a technique for speeding up tile loading > > performance for a custom image tile overlay. The trouble is that when doing > > a fast zoom with the mouse wheel or by rapidly clicking zoom in/out buttons > > the API will queue a bunch of requests for layers that have been "zoomed > > through" and loading the overlay for the current layer will not actually > > happen until these pending requests are satisfied. Initially I thought > > Google was doing some magic with its base tile set to influence the > > retrieval order of the base tiles during zooms, but upon closer inspection > > it appears they are simply servicing the tile requests with ridiculous > > speed. > > > Since we are dynamically generating tiles, we can't hope to achieve a > > similar result with ImageMapType by reducing latency alone; best we are > > doing is about 100ms/tile. However we are able to horizontally scale our > > tile generation, so are there alternative techniques we can try? My initial > > thought is to use a different http hostname per layer to allow the browser > > to initiate immediate requests upon zooming to a layer, but there are some > > drawbacks to this approach on the server end. Another possibility might be > > to create an entirely new version of ImageMapType that performs better with > > a high-latency and highly-parallel tile generation, but that seems like a > > lot of work to jump into without first examining alternatives. > > > Thanks, > > John Laur > > > -- > > 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]<google-maps-js-api-v3%2B > > [email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-maps-js-api-v3?hl=en. -- 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.
