Polylines not working in Opera

20 views
Skip to first unread message

Vladimir Agafonkin

unread,
Jan 4, 2010, 7:31:34 AM1/4/10
to Google Maps JavaScript API v3
Hi,

The polyline example - http://code.google.com/apis/maps/documentation/v3/examples/polyline-simple.html
- doesn't work in Opera (I'm using 10.10) at all - why? This is
strange because the SVG support in Opera is well enough for it to work
out of the box (if not turned off manually) - I know that because I
implemented polylines in a similar library.

Thanks for the answer in advance.

Michał Biniek

unread,
Jan 4, 2010, 6:47:50 PM1/4/10
to Google Maps JavaScript API v3
Hi there,

when I tested animation on routes I have noticed, that Google is
drawing routes as images for Opera, not as svg or any format of vector
graphics (in v2 version).
But it is interesting, that simple example is not working in all
normal web browsers :)

Regards,
Michal Biniek

On 4 Sty, 13:31, Vladimir Agafonkin <agafon...@gmail.com> wrote:
> Hi,
>
> The polyline example -http://code.google.com/apis/maps/documentation/v3/examples/polyline-s...

reflexive

unread,
Jan 5, 2010, 1:28:48 PM1/5/10
to Google Maps JavaScript API v3
When will this issue be fixed? is this an opera bug?
Anyway, are there any known workaraounds for this problem?

Ben Appleton

unread,
Jan 5, 2010, 6:34:05 PM1/5/10
to google-map...@googlegroups.com
Opera is not a supported browser:
http://code.google.com/apis/maps/faq.html#browsersupport
However we believe we have fixed the issue locally, and the fix should go live in a week.

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




Vladimir Agafonkin

unread,
Jan 5, 2010, 8:49:39 PM1/5/10
to Google Maps JavaScript API v3
Awesome, can't wait to see it live! Thanks!

On Jan 6, 1:34 am, Ben Appleton <apple...@google.com> wrote:
> Opera is not a supported browser:http://code.google.com/apis/maps/faq.html#browsersupport
> However we believe we have fixed the issue locally, and the fix should go
> live in a week.
>

> > google-maps-js-a...@googlegroups.com<google-maps-js-api-v3%2Bunsu...@googlegroups.com>

bratliff

unread,
Jan 6, 2010, 7:41:12 AM1/6/10
to Google Maps JavaScript API v3
Opera supports both SVG and CANVAS except for the
"globalCompositeOperation" which behaves differently in Opera than in
other browsers. Opera cannot do "cut outs" easily like the other
browsers without analyzing the "winding" direction (clockwise /
counterclockwise) for every poly.

I have some examples working in Opera located at:

http://www.polyarc.us/polycluster

By default, CANVAS is used by browsers supporting both. CANVAS
requires fewer DOM elements which improves performance during
dragging, panning & zooming.

Internet Explorer support is in the works but waiting on an
incompatability with the API to be resolved. I suspect it is a naming
conflict which I am happy to change if I know what to change. It only
occurs in Internet Explorer. It always occurs at line 397 in the API
(v 3.24).

Vladimir Agafonkin

unread,
Jan 6, 2010, 8:12:11 AM1/6/10
to Google Maps JavaScript API v3
bratliff, awesome work!

Canvas is great for really big polylines and polygons with lots of
points, but mapping libraries usually use SVG because you can add
listeners on mouse events (click, mouseover/out/move) for the
elements, and in Canvas you can't do that so you can only use it for
visual purposes, without interaction. But it's true that SVG is
considerably slower, taking into account that the lib needs to perform
clip rect for polylines and polygons manually (with a separate
algorithm for each) on every drag/zoom.

bratliff

unread,
Jan 6, 2010, 9:00:12 AM1/6/10
to Google Maps JavaScript API v3
On Jan 6, 1:12 pm, Vladimir Agafonkin <agafon...@gmail.com> wrote:
> bratliff, awesome work!
>
> Canvas is great for really big polylines and polygons with lots of
> points, but mapping libraries usually use SVG because you can add
> listeners on mouse events (click, mouseover/out/move) for the
> elements, and in Canvas you can't do that so you can only use it for
> visual purposes, without interaction. But it's true that SVG is
> considerably slower, taking into account that the lib needs to perform
> clip rect for polylines and polygons manually (with a separate
> algorithm for each) on every drag/zoom.

Thanks Vladimir,

I am planning to add "click" / "rollover" support without requiring
individual event listeners for every poly. It will facilitate hits on
multiple polys (state / county / township / city / zip code). It will
also allow clicking on a naked map to load the corresponding poly.

I guess the choice of SVG or CANVAS ought to be optional. In a prior
version, it was. I will add it.

An unobfuscated copy of the source code lives at:

http://www.polyarc.us/cluster.js

You can change the rendering engine priority in lines 21-42. I did
not use "else ifs" because it is executed just once.

If you can provide any insight on why it it is failing in Internet
Explorer at line 397 in the API, it will be greatly appreciated. I
suspect it is a naming conflict.

Thanks again,

Berry

Vladimir Agafonkin

unread,
Jan 6, 2010, 9:07:34 AM1/6/10
to Google Maps JavaScript API v3
Thanks for the answer bratliff,

Sounds really interesting. How the click/rollover support is possible
technically? I thought that you can only do that by manually going
through all the points with a sophisticated algorithm on click/
mouseover/out which is very slow.

bratliff

unread,
Jan 6, 2010, 10:00:51 AM1/6/10
to Google Maps JavaScript API v3
On Jan 6, 2:07 pm, Vladimir Agafonkin <agafon...@gmail.com> wrote:
> Thanks for the answer bratliff,
>
> Sounds really interesting. How the click/rollover support is possible
> technically? I thought that you can only do that by manually going
> through all the points with a sophisticated algorithm on click/
> mouseover/out which is very slow.

Visible polys are already broken into tiles. A typical tile contains
fewer than one thousand points with one hundred points per tile being
much more typical.

The search can be confined to just one tile using a "fast winding
number" algorithm:

http://softsurfer.com/Archive/algorithm_0103/algorithm_0103.htm

Otherwise, a discrete event listener is required for every poly for
every tile for every monitored condition (click / mousemove /
mouseover / mouseout / etc.)

For polys not yet rendered, I plan to use an auxilliary grid structure
with intersecting X & Y slices several pixels wide. A hit occurs if
the same poly resides in both the corresponding X slice & the
corresponding Y slice.

Vladimir Agafonkin

unread,
Jan 6, 2010, 10:19:57 AM1/6/10
to Google Maps JavaScript API v3
Awesome, thanks, I see now. Really looking forward to the development
of your script. Do you plan on open sourcing?

bratliff

unread,
Jan 6, 2010, 10:44:42 AM1/6/10
to Google Maps JavaScript API v3
On Jan 6, 3:19 pm, Vladimir Agafonkin <agafon...@gmail.com> wrote:
> Awesome, thanks, I see now. Really looking forward to the development
> of your script. Do you plan on open sourcing?

To date, noone has shown much interest because Internet Explorer was
not supported. Internet Explorer support is almost implemented except
for a bug occuring in the API. It may be my fault but I cannot debug
it without access to Google's source code. Life is too short spend
time unobfuscating the code.

I have never participated in an "open source" effort. I am willing to
try it. I have a very unconventional coding style. It works for me
but I doubt it will work for other people.

I could use some help debugging Internet Explorer. VML is broken on
my machine.

Reply all
Reply to author
Forward
0 new messages