IE8 problem: polygons with 0<fillOpacity<1 shows grid of lines

[Ing. Stefano]

If I try http://code.google.com/intl/it-IT/apis/maps/documentation/javascript/examples/polygon-simple.html
with IE8, I see into the polygon strange lines.
Don't you?
I think these lines can be borders of map tiles.
Every other browser (included IE7 and IE6) do not show these lines.

[bratliff]

On Feb 5, 1:43 pm, "Ing. Stefano" <ing.stefano.magr...@gmail.com>
wrote:
> If I tryhttp://code.google.com/intl/it-IT/apis/maps/documentation/javascript/...

> with IE8, I see into the polygon strange lines.
> Don't you?
> I think these lines can be borders of map tiles.
> Every other browser (included IE7 and IE6) do not show these lines.

It is a bug in the IE8 implementation of VML. Microsoft has been
aware of it for at least a year. It has been fixed in IE9 according
to a friend working at Microsoft.

VML adds an extra horizontal pixel & an extra vertical pixel to each
tile. A 256 x 256 pixel tile is actually a 257 x 257 pixel tile. The
last pixel of one tile combines with the first pixel of the adjacent
tile to produce a pixel with their combined opacity.

It could be fixed by artificially changing the tile size to 255 x 255
pixels for IE8 which IE8 would switch back to 256 x 256 pixels.

[Ben Appleton]

I see the bug too. We'll look into it.

If you want to be notified of a fix, please file an issue here:

http://code.google.com/p/gmaps-api-issues/issues/list?can=2&q=apitype:Javascript3%20type:Defect&sort=-stars&colspec=ID%20Type%20Status%20Introduced%20Fixed%20Summary%20Internal%20Stars

Thanks

Ben

--
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-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[Ben Appleton]

We've fixed the bug. The change should go live next week.

Thanks to Berry for pointing out the off-by-one bug in IE8's VML implementation.

Ben

[bratliff]

On Feb 7, 3:33 am, Ben Appleton <apple...@google.com> wrote:
> We've fixed the bug. The change should go live next week.
>
> Thanks to Berry for pointing out the off-by-one bug in IE8's VML
> implementation.
>
> Ben

Hi Ben,

PolyCluster does the same thing. I am curious to know how you fixed
it. How do you identify just IE8 without over compensating for IE6,
IE7 & IE9 ?

I am using a DIV with style.width="256px" & style.height="256px" &
style.overflow="hidden" to contain the VML element. I am not using
style.clip="rect(0 256 256 0)". What have you done to fix it ? I
have to admit, I do not understand how "coordorigin" & "coordsize"
relate to the "style" parameters.

If you are interested, I have figured out how to add mouse event
support to CANVAS with very little overhead. It works with
overlapping polys where the combined color & alpha are different than
any of the contributing polys. Let me know.

Berry

[Ben Appleton]

Hi Berry,

We have a user agent parser that extracts the rendering engine and version from the browser useragent. I only apply the workaround (width=height=255px) to IE version 8. Watch out for non-IE browsers which claim to be IE, as historically some webservers only supported IE.

We set coordsize to 1 1 and coordorigin to 0 0 if I recall correctly. Apparently this works around some VML coordinate bugs. VML is happy to overflow.

We now implement all hit detection in javascript. This allows layers to "play nice", so we can click through an SVG or canvas element's bounding box. I haven't yet converted to use Canvas by default, but as you.indicate this may be mucb faster than SVG.

Cheers
Ben

[bratliff]

On Feb 7, 10:24 pm, Ben Appleton <apple...@google.com> wrote:
> Hi Berry,
>
> We have a user agent parser that extracts the rendering engine and version
> from the browser useragent. I only apply the workaround (width=height=255px)
> to IE version 8. Watch out for non-IE browsers which claim to be IE, as
> historically some webservers only supported IE.
>
> We set coordsize to 1 1 and coordorigin to 0 0 if I recall correctly.
> Apparently this works around some VML coordinate bugs. VML is happy to
> overflow.
>
> We now implement all hit detection in javascript. This allows layers to
> "play nice", so we can click through an SVG or canvas element's bounding
> box. I haven't yet converted to use Canvas by default, but as you.indicate
> this may be mucb faster than SVG.
>
> Cheers
> Ben

Thanks Ben,

I use:

if (document.all) if (window.XMLHttpRequest)

to isolate IE7+. Do you know of similar capabilities tests for IE8 &
IE9 ? IE9 supports CANVAS. IE8 does not.

I am using coordsize 1 1 & coordorigin 0 0 also because every other
attempt failed. Without a useable VML installation on my PC, I am
flying blind.

The only drawback to CANVAS I have encountered is the inability to
recolor polys on the fly. Painting over the poly does not preserve
its zIndex. It also blends differently with other overlapped polys.
Repainting whole tiles is too slow for rollovers.

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.

Berry

[Ben Appleton]

On Wed, Feb 9, 2011 at 2:50 AM, bratliff <brat...@umich.edu> wrote:

On Feb 7, 10:24 pm, Ben Appleton <apple...@google.com> wrote:
> Hi Berry,
>
> We have a user agent parser that extracts the rendering engine and version
> from the browser useragent. I only apply the workaround (width=height=255px)
> to IE version 8. Watch out for non-IE browsers which claim to be IE, as
> historically some webservers only supported IE.
>
> We set coordsize to 1 1 and coordorigin to 0 0 if I recall correctly.
> Apparently this works around some VML coordinate bugs. VML is happy to
> overflow.
>
> We now implement all hit detection in javascript. This allows layers to
> "play nice", so we can click through an SVG or canvas element's bounding
> box. I haven't yet converted to use Canvas by default, but as you.indicate
> this may be mucb faster than SVG.
>
> Cheers
> Ben

Thanks Ben,

I use:

   if (document.all) if (window.XMLHttpRequest)

to isolate IE7+.  Do you know of similar capabilities tests for IE8 &
IE9 ?  IE9 supports CANVAS.  IE8 does not.

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 am using coordsize 1 1 & coordorigin 0 0 also because every other
attempt failed.  Without a useable VML installation on my PC, I am
flying blind.

The only drawback to CANVAS I have encountered is the inability to
recolor polys on the fly.  Painting over the poly does not preserve
its zIndex.  It also blends differently with other overlapped polys.
Repainting whole tiles is too slow for rollovers.

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.

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.

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.

Cheers

Ben

[bratliff]

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

[Ing. Stefano]

Hi Ben,
when do you think the fix could be online?
I should plan my site's production.
Thank you very much.

Stefano

On 7 Feb, 04:33, Ben Appleton <apple...@google.com> wrote:
> We've fixed the bug. The change should go live next week.
>
> Thanks to Berry for pointing out the off-by-one bug in IE8's VML
> implementation.
>
> Ben
>
>
>
>
>
>
>
> On Mon, Feb 7, 2011 at 9:38 AM, Ben Appleton <apple...@google.com> wrote:
> > I see the bug too. We'll look into it.
>
> > If you want to be notified of a fix, please file an issue here:
>

> >http://code.google.com/p/gmaps-api-issues/issues/list?can=2&q=apitype...

>
> > Thanks
> > Ben
>
> > On Sat, Feb 5, 2011 at 2:43 PM, Ing. Stefano <
> > ing.stefano.magr...@gmail.com> wrote:
>
> >> If I try

> >>http://code.google.com/intl/it-IT/apis/maps/documentation/javascript/...

[Ing. Stefano]

Ok, fix is online.

On 11 Feb, 14:44, "Ing. Stefano" <ing.stefano.magr...@gmail.com>
wrote:

[Mallee]

Hi Ben and others,
I've just noticed some polygons drawing strangely in ie8 especially,
and think it might be related to this problem.

I have an app which draws a number of polygons (with default fill/
opacity - a dark shading). Some of the polygons are missing a side,
and instead have straight lines (same style as the polygon border)
drawn off at what seem to be random angles outside the polygon. There
is a mouseover running on the polygons, and when the mouseover causes
a change in border colour, the single pixel tile overlap discussed in
this thread is visible. The random lines seem to end at tile borders,
and are different at different zoom levels. There seems to be no
pattern to which polygons are affected, but they are always the same
ones.

The same problem is present in all other browsers, but with different
rendering.

In Firefox 3.6, the polygon doesn't draw at all (but the listeners are
still active and in the correct place).
In Safari and Chrome, the polygons render, but with the same side
missing as in ie8 and shading similar to ie8 (as if the random lines
were there), but without the random lines.
In these browsers, the single pixel tile overlap is not visible when
the mouseover event occurs.

What's frustrating is that I can't reproduce the problem on a demo
page! I've tried (one of the polgyons is here: http://www.pasource.com.au/new/ie8polytest.html
- the missing side is the rhs) with a couple of methods of drawing the
polygon and there is no obvious problem. So it must be something to do
with the way the polygons are used in the app, which makes heavy use
of the dojo toolkit. I've tried various diagnostics (switching off
other overlays, different ways of drawing the polygon) and will
continue when I can think of some more! Perhaps it's some strange css
interaction?

The way the demo polygon appears in the app in ie8 (with normal
polygon to the right) is : http://www.pasource.com.au/new/ie8polytest.png

Thank you
Ben


On Feb 21, 5:39 am, "Ing. Stefano" <ing.stefano.magr...@gmail.com>
wrote: