> When testing vector graphics capabilities I test first for SVG, then canvas, > then VML. So I only need to distinguish IE6/7 vs IE8 in the VML code (not > IE9). Since we have a general browser detection library, I haven't gone > looking for short tests to distinguish IE6/7 vs IE8. I'm sure there must be > some though.
I emailed Giorgio Sardo at Microsoft: http://blogs.msdn.com/b/giorgio/archive/2009/04/14/how-to-detect-ie8-using-javascript-client-side.aspx Unfortunately, IE8 in IE7 mode or IE8 in IE6 mode will both fail but real IE7 & real IE6 are OK. The "userAgent" is unreliable. > In the past we preferred SVG over Canvas, but we may revisit that decision > now that we use JS hit detection. Specifically once we paint Canvas tiles, > panning seems to be much faster than with SVG tiles which seem to repaint on > each frame. So I'm interested to hear about Canvas repainting speed. I was > hoping that when a poly changed visual style we could repaint the affected > tiles, or "dirty" rectangles inside each tile. I haven't measured anything > yet though. I repaint entire tiles because everything is cumulative in CANVAS. Blending colors & dealing with irregular boundaries are too much to mess with. I save all tile relative paths - 16 bits for X & 16 bits for Y in the same 32-bit DWORD. It cuts the storage requirements by half. > Do you use "point-in-poly" analysis for hit detection ? I let CANVAS > > > do it for me in an off-screen CANVAS element. It involves just one > > tile. It is actually quite fast. > > I use point-in-polygon and point-near-polyline hit tests. I first detect > which tile the event applies to, then I run the hit tests over all polys in > that tile. I use the simplified, cropped tile vectors for hit detection, so > that even a pathological poly (a test fractal) only has 1000 vertices per > tile. Benchmarking shows that IE7 on my laptop can hit test about 1M > vertices per seconds, so JS hit detection seems to be fast enough even for > mousemove. > > I haven't tried rendering an off-screen canvas element. Does that slow down > rendering by 2x? Have you had any trouble with canvas anti-aliasing in your > offscreen element? I recommend JS hit detection - if it's fast enough, it > can save a lot of work upfront. First I test whether the pixel has non-zero opacity. If it does, I do a bounding box comparison to determine which polys might be contributers. If it is just one, I procede no further. If the pixel color/alpha is an exact match for just one poly in the tile, I could also quit. If it could be more than one poly, I render each candidate in an off-screen CANVAS element to see which ones light the pixel. I let CANVAS deal with doughnut holes. Since I already have the path, it is just a series of "moveTo" / "lineTo" calls without the overhead of displaying it on the screen. I return the whole set of polys in (LIFO) zIndex order. > By the way, if you don't already you might want to throttle mousemove > events. I've seen hundreds of mousemove events per second in some browsers, > particularly with a high DPI mouse. We start dropping mousemove events when > they exceed 50fps, which helps slow browsers a lot. I have a really old PC. It does not choke on mousemove. I am using my own mousemove event listener. It works entirely in tile relative pixel offsets rather than in Lat/Lon coordinates. I use one "click" event listener & one "mousemove"event listener for all polys rather than one per poly. -- 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-v3@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.