X-BeenThere: google-maps-js-api-v3@googlegroups.com
Received: by 10.90.8.32 with SMTP id 32ls3145234agh.1.p; Tue, 01 Dec 2009 
	08:40:30 -0800 (PST)
Received: by 10.91.209.7 with SMTP id l7mr7428943agq.7.1259685630226;
        Tue, 01 Dec 2009 08:40:30 -0800 (PST)
Received: by 10.91.209.7 with SMTP id l7mr7428941agq.7.1259685630186;
        Tue, 01 Dec 2009 08:40:30 -0800 (PST)
Return-Path: <bratl...@umich.edu>
Received: from mail-gx0-f202.google.com (mail-gx0-f202.google.com [209.85.217.202])
        by gmr-mx.google.com with ESMTP id 18si18524gxk.11.2009.12.01.08.40.30;
        Tue, 01 Dec 2009 08:40:30 -0800 (PST)
Received-SPF: neutral (google.com: 209.85.217.202 is neither permitted nor denied by best guess record for domain of bratl...@umich.edu) client-ip=209.85.217.202;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 209.85.217.202 is neither permitted nor denied by best guess record for domain of bratl...@umich.edu) smtp.mail=bratl...@umich.edu
Received: by mail-gx0-f202.google.com with SMTP id 26so2398858gxk.1
        for <google-maps-js-api-v3@googlegroups.com>; Tue, 01 Dec 2009 08:40:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.151.32.38 with SMTP id k38mr623894ybj.8.1259685630122; Tue, 01 
	Dec 2009 08:40:30 -0800 (PST)
Date: Tue, 1 Dec 2009 08:40:30 -0800 (PST)
In-Reply-To: <f0109763-c945-4bd6-9cb7-de61129fe082@o13g2000vbl.googlegroups.com>
X-IP: 216.86.90.43
References: <c7c53ecc-bd7a-441f-a19a-3265d3cd7fd6@u7g2000yqm.googlegroups.com> 
	<5e3fda7f-1a85-47da-9276-d2ba600687b8@m3g2000yqf.googlegroups.com> 
	<ff69de2d0911291826q6824f50fu7742fa6b23aec232@mail.gmail.com> 
	<e5307479-55b3-48d7-a365-8ea7834fa18e@g1g2000vbr.googlegroups.com> 
	<70b41378-37c1-4a68-8efa-c050d2b68864@1g2000vbm.googlegroups.com> 
	<f0109763-c945-4bd6-9cb7-de61129fe082@o13g2000vbl.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.13) 
	Gecko/20060410 Firefox/1.0.8,gzip(gfe),gzip(gfe)
Message-ID: <d267baa8-5ca1-4e63-aeb2-e31f69c577a9@k19g2000yqc.googlegroups.com>
Subject: Re: Tile Layer Overlay
From: bratliff <bratl...@umich.edu>
To: Google Maps JavaScript API v3 <google-maps-js-api-v3@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1

On Nov 30, 8:39 pm, Chad Killingsworth
<chadkillingswo...@missouristate.edu> wrote:
> > The tile latency will mask the extra CPU usage, but, why compute
> > identical tile offsets in different OverlayViews ?
>
> I did consider this while developing, but the math for the tile bounds
> calculations isn't that intensive. I opted for ease of implementation
> on options such as visibility, zindex and event handling as well as
> trying to keep the code easy to understand. For each draw event on the
> overlay, calculating the tile coordinates and bounds was taking around
> 12ms for the first time the code executed, then 1ms for each
> subsequent draw event on an iPhone 3G (I used this because of the
> slower processor and lower memory).

For a handful of tile layer overlays, it may not matter.  I am using
the same code for polys where it matters a lot.  I cannot imagine the
overhead of separate OverlayViews with separate event listeners for
every state in the United States or even every province in Canada.  I
cannot imagine the overhead of individual CANVAS elements for every
poly.  A single common OverlayView enables polys to be combined in the
same CANVAS elements.

> > The tile sets may originate from different servers like:
>
> >    www.polyarc.us/sparse
>
> I was considering the option of having a server proxy requests and
> dynamically composite the tiles together into a single image.

Great idea, especially if you have a campus WiFi network.  You could
cache common combinations.  You could bypass the AT&T network for
students on campus.

> > A general solution ought to support Internet Explorer 6.  It ought to
> > compensate for getBounds errors at low numbered zoom levels.  It ought
> > to calculate tile offsets correctly for maps spanning the
> > International Date Line.
>
> All of these points are correct - and something I plan on looking
> into. Although I'm not really that thrilled with spending a lot of
> work on the IE6 support. It's less than 5% of my total traffic. But a
> complete solution should handle it.

I agree, IE6 is a PITA but a lot of people still use it.