> 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).
> Try using an "idle" event listener without timer interrupts. That is an excellent suggestion. I just added the setTimeout interrupts as a quick fix. I'll take a look at this. > The primary delay is the limited iPhone bandwidth. This should only be true on initial load. Once the images are cached, I would expect processor and memory to be the constraints > > If I needed to display large numbers of tile layers simultaneously, I > > personally would pursue a server side solution rather than having the > > client render that many layers. Of course not everyone may have that > > option. > > 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. > 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. Thanks for the feedback, Chad Killingsworth On Nov 30, 10:14 am, bratliff <bratl...@umich.edu> wrote: > On Nov 30, 2:27 pm, Chad Killingsworth > > <chadkillingswo...@missouristate.edu> wrote: > > I put 3 tile layers on a map each as their own OverlayView. I also put > > the same 3 tile layers on a map in the same OverlayView. On an iPhone, > > there is a pretty significant performance difference between a single > > layer and 3 layers. However there was not a noticeable difference > > between 3 layers in a single OverlayView or in multiple OverlayViews. > > The tile latency will mask the extra CPU usage, but, why compute > identical tile offsets in different OverlayViews ? > > > This may be due to the fact that I throttle the bounds_changed event > > to only fire once a second. > > Try using an "idle" event listener without timer interrupts. > > > This leads me to believe that the vast > > majority of the performance degradation with multiple layers comes > > from the rendering and memory usage of that many DOMNodes and images > > rather than from the events. > > The primary delay is the limited iPhone bandwidth. > > > Of course at much higher numbers of > > layers there may indeed be a significant difference, however this > > seems to be a pretty specialized optimization. > > > If I needed to display large numbers of tile layers simultaneously, I > > personally would pursue a server side solution rather than having the > > client render that many layers. Of course not everyone may have that > > option. > > The tile sets may originate from different servers like: > > www.polyarc.us/sparse > > Even Google's own "HYBRID" tiles are split across hosts. > > > Using my class, the performance of the map with 3 layers is > > acceptable. Beyond that, your mileage may vary. > > 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. The use of a timer interrupt just adds extra > overhead. > > Peter, > > Please provide a link, either V2 or V3, to what you are trying to do. > You ought to be able to build a proper URL for your server from the > examples. -- 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 google-maps-js-api...@googlegroups.com. To unsubscribe from this group, send email to google-maps-js-api-v3+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
