Ben, Egads no! One overlay only. I meant to say something like "zoom through 10 levels". Sorry for the confusion. I know we are hitting the browser's maximums in our one hostname per payer tests but it is still marginally better.
Your response does reinforce though how much work it would be to reimplement an ImageMapType equivalent -- we will hang tight and see what happens on the issue tracker. John On Jan 26, 2011, at 1:33 AM, Ben Appleton <[email protected]> wrote: > Hi John, > > On Wed, Jan 26, 2011 at 3:21 PM, John Laur <[email protected]> wrote: > Ben, > > Thank you for your assistance. I have filed Issue 3011 to track this > externally http://code.google.com/p/gmaps-api-issues/issues/detail?id=3011 > > You mention you have 10 layers. Do I understand correctly that you're making > 10 HTTP requests per zoom level per tile on screen? You must be loading > thousands of tiles for a quick scrollwheel zoom, ouch! > > Is there any chance you could composite your layers in a server? For example, > you could launch another EC2 service which loads the tiles from each > individual tile renderer, composites them into a single image, and returns > this to the browser. > > In my particular test case, I have several tile generators running on > EC2, so my latency to the tile servers is not 200ms but it's also not > particularly great (about 55ms). Knowing what to look for now, I would > expect a much larger number of requests to be aborted than actually > are aborted when performing the same tests (doing this in Firefox > now). Can you share additional specifics on how this is supposed to > work for the ImageMapType class? I would assume this is buried deep in > the internals of the class's releaseTile and whatever part of the map > code is responsible for calling it, so I would therefore conclude that > it's fairly fruitless for me to attempt to debug anything. > > ImageMapType cancels tile requests when .releaseTile() is called. In most > browsers it cancels an in-flight image request by setting image.src to a > transparent image. That does not work in WebKit browsers, in which case > ImageMapType loads images in iframes and calls iframe.window.stop() to cancel > in-flight image requests. > > Browsers will only allow a certain maximum number of concurrent HTTP > requests, ranging from 2 to 15. Even though ImageMapType requests all tiles > in view, browsers will send the first few requests then queue the rest, > trickling out more requests as responses arrive. So when you zoom twice in > quick succession, there will never be more than 2 to 15 in-flight requests to > abort. > > We are using ImageMapType rather than creating our own subclass of > MapType because it would seem to have the advantages of both saving > both work and complexity. I know it is not documented, but is there > any easy way to trap the getTile/releaseTile calls to ImageMapType to > better see whats going on there? > > Sorry, there aren't any hooks (not even undocumented) for tracing > ImageMapType's internals. You could step through the obfuscated code in a > debugger (starting from a breakpoint in your .getTileUrl() implementation), > but you would have to be keen. > > Cheers > Ben > > John > > On Jan 25, 7:35 pm, Ben Appleton <[email protected]> wrote: > > Regarding Firefox: interesting; I see at least 50% of tile requests aborted, > > so it's working for me. I'm in Australia with ~200ms round trip time; I'm > > guessing you have a low RTT to your tile server which might affect this. > > > > Regarding Chrome: I see the problem now, it looks like a bad interaction > > with continuous zoom. I'll file a bug internally. If you'd like to track > > progress on the issue, please file an issue in the issue > > tracker:http://code.google.com/p/gmaps-api-issues/. > > > > Thanks > > Ben > > > > > > > > > > > > > > > > On Wed, Jan 26, 2011 at 11:30 AM, John Laur <[email protected]> wrote: > > > 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]><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]<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. > > > -- > 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. -- 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.
