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

Reply via email to