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%[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%[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.

Reply via email to