marker.setZIndex seems to no longer work

[Raoul]

Until a few days I had no problem using marker.setZIndex to place a
marker in the forground. Today it seems that it doesn't work anymore.
Other functions called at the same time, like marker.setIcon, still
works. Am I the only one having this problem? Was something modified
in the API? If someone could help I would apreciate it alot

http://www.raoul-kieffer.net/Italy/Roma/Rome%20Google%20Maps.html

$( this ).hover(
function() {
if ( site.marker ) {
site.marker.setIcon( book.IconSelected );
site.marker.setShadow( book.ShadowSelected );
site.marker.oldZIndex = site.marker.getZIndex();
site.marker.setZIndex( 10000 );
}
},
function() {
if ( site.marker ) {
site.marker.setIcon( book.Icon );
site.marker.setShadow( book.Shadow );
site.marker.setZIndex( site.marker.oldZIndex );
}
}
);

[geoco...@gmail.com]

On Mar 1, 1:24 pm, Raoul <Raoul.Kief...@arcor.de> wrote:
> Until a few days I had no problem using marker.setZIndex to place a
> marker in the forground. Today it seems that it doesn't work anymore.
> Other functions called at the same time, like marker.setIcon, still
> works. Am I the only one having this problem? Was something modified
> in the API? If someone could help I would apreciate it alot

Perhaps this is the time to remind you of what the documentation says
about not specifying a version:
http://code.google.com/apis/maps/documentation/javascript/basics.html#Versioning

+ Choosing an API version
+ The following guidelines apply when choosing the appropriate API
version for your Maps API V3 application:
+ + Production applications should always specify a minor version (eg.
3.2, 3.3, etc.).

-- Larry

[Raoul]

Many Thanks Larry,

Specifying v3.1 solves the issue, I will also try the newest versions.

Kind regards,

Raoul

On 1 Mrz., 22:59, "geocode...@gmail.com" <geocode...@gmail.com> wrote:
> On Mar 1, 1:24 pm, Raoul <Raoul.Kief...@arcor.de> wrote:
>
> > Until a few days I had no problem using marker.setZIndex to place a
> > marker in the forground. Today it seems that it doesn't work anymore.
> > Other functions called at the same time, like marker.setIcon, still
> > works. Am I the only one having this problem? Was something modified
> > in the API? If someone could help I would apreciate it alot
>
> Perhaps this is the time to remind you of what the documentation says

> about not specifying a version:http://code.google.com/apis/maps/documentation/javascript/basics.html...

>
> + Choosing an API version
> + The following guidelines apply when choosing the appropriate API
> version for your Maps API V3 application:
> + + Production applications should always specify a minor version (eg.
> 3.2, 3.3, etc.).
>
>   -- Larry
>
>
>
>
>
> >http://www.raoul-kieffer.net/Italy/Roma/Rome%20Google%20Maps.html
>
> > $( this ).hover(
> >         function() {
> >                 if ( site.marker ) {
> >                         site.marker.setIcon( book.IconSelected );
> >                         site.marker.setShadow( book.ShadowSelected );
> >                         site.marker.oldZIndex = site.marker.getZIndex();
> >                         site.marker.setZIndex( 10000 );
> >                 }
> >         },
> >         function() {
> >                 if ( site.marker ) {
> >                         site.marker.setIcon( book.Icon );
> >                         site.marker.setShadow( book.Shadow );
> >                         site.marker.setZIndex( site.marker.oldZIndex );
> >                 }
> >         }

> > );- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Chad Killingsworth]

This may be an unintended side affect of a new rollout. See https://groups.google.com/d/topic/google-maps-js-api-v3/hlaFCakWshk/discussion

Chad Killingsworth

[Raoul]

Problem starts with v3.4.

Kind regards,

Raoul

> > - Zitierten Text anzeigen -- Zitierten Text ausblenden -

[Ben Appleton]

It looks like you're setting zIndex to 10000 in order to bring a marker to the front on hover. A recent change increased the range of default marker z-indices, so 10000 no longer puts the marker in front.

A quick fix would be to change 10000 to 1E9 (1000000000). A more robust fix would be to assign z-indices to each marker, so that you do not rely on the default marker z-indices being small.

Perhaps to support bring-to-front we need to publish a maximum zIndex or add an explicit API property like 'bringToFront'.

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

[bratliff]

On Mar 1, 10:46 pm, Chad Killingsworth
<chadkillingswo...@missouristate.edu> wrote:
> This may be an unintended side affect of a new rollout. Seehttps://groups.google.com/d/topic/google-maps-js-api-v3/hlaFCakWshk/d...
>
> Chad Killingsworth

Sorry about the last post. Apparently something I typed sent an
incomplete message.

Yes. CANVAS has no zIndex because all markers in the same tile are
rendered cumulatively. Event listeners have to examine candidates in
LIFO order. If just one target is recognized, it ought to be the last
one rendered. If multiple targets are recognized, the order ought to
be reversed.

[Raoul]

Hi Ben

The quick fix didn't work. The problem seems different.
alert( site.marker.getZIndex() ); returns undefined
Can it be that getZIndex is no longer available?

Kind regards

Raoul

> >http://groups.google.com/group/google-maps-js-api-v3?hl=en.- Zitierten Text ausblenden -

[Ben Appleton]

No, marker zIndex is supported. When rendering markers in canvas we first sort by zIndex.

[Ben Appleton]

Hi Raoul,

marker.getZIndex() returns the zIndex that you set on the marker. If you have not set a zIndex on the marker, .getZIndex() returns undefined. Inside the API, if you have not set a zIndex, we default to a zIndex based on the marker's height on screen. That default zIndex logic recently changed which may have broken your hover code.

I'll set up a demo page which brings markers to front on hover, to see if I can replicate the issue you report.

Thanks

Ben

[Esa]

getZIndex() does not return the value that API has set. It only
returns the value you set. It has always been that way.

IMHO getZIndex() should return relative value. That is zero if user
did not set zIndex. User zIndex should be added to the 'under the
hood' zIndex.

[Raoul]

Hi Esa,

You're right. I checked, also with v3.3 or v3.1,
alert( site.marker.getZIndex() ) returns undefined.

However the behaviour of my hover code is different in v3.4 compared
to v3.3

With v3.4
http://www.raoul-kieffer.net/Italy/Roma/Rome%20Google%20Maps.html

With v3.3
http://www.raoul-kieffer.net/Italy/Roma/Rome%20Google%20Maps%20(1).html

Kind regards,

Raoul

[Ben Appleton]

Hi Raoul,

The quick solution I proposed above works for me in Chrome, Firefox and IE:

http://geoapis.appspot.com/agdnZW9hcGlzchMLEgtFeGFtcGxlQ29kZRjZswEM
Are you sure you set the zIndex to 1E9?

Thanks

Ben

[Raoul]

Hi Ben,

Great! This works.

I have this hover code on different places (for the markers on the
map, for the names of the places on the sidebar, ...) and didn't
replace all 10000 by 1E9. Now it works!

Many thanks for your fast response and the time you spent writing this
quick solution (but efficient) demo.

Kind regards,

Raoul

On 2 Mrz., 01:49, Ben Appleton <apple...@google.com> wrote:
> Hi Raoul,
>
> The quick solution I proposed above works for me in Chrome, Firefox and IE:http://geoapis.appspot.com/agdnZW9hcGlzchMLEgtFeGFtcGxlQ29kZRjZswEM
> Are you sure you set the zIndex to 1E9?
>
> Thanks
> Ben
>
>
>
> On Wed, Mar 2, 2011 at 10:59 AM, Ben Appleton <apple...@google.com> wrote:
> > Hi Raoul,
>
> > marker.getZIndex() returns the zIndex that you set on the marker. If you
> > have not set a zIndex on the marker, .getZIndex() returns undefined. Inside
> > the API, if you have not set a zIndex, we default to a zIndex based on the
> > marker's height on screen. That default zIndex logic recently changed which
> > may have broken your hover code.
>
> > I'll set up a demo page which brings markers to front on hover, to see if I
> > can replicate the issue you report.
>
> > Thanks
> > Ben
>

[Esa]

So, it looks like

setZIndex(null);

recovers the original z-index? That is great news.

[Ben Appleton]

That's correct, it restores the original z-index.

--

[Berry Ratliff]

Ben Appleton wrote:

> No, marker zIndex is supported. When rendering markers in canvas we
> first sort by zIndex.

Sorry - my mistake. Unlike SVG & VML, style.zIndex applies to the whole
CANVAS tile. Sorting does change the rendering order. The event
listeners must resolve ambiguity.

[Esa]

>
> >  setZIndex(null);
>
> > recovers the original z-index? That is great news.
>

That is absolutely great, but why not setZindex(0);?

[Ben Appleton]

That would set the z index to 0. We need a way to let you specify z-index of 0 versus letting the API default to z-index by height. We use null/undefined to mean "please default to z-index by height".

--

[Esa]

Why not add user zIndex to your internal zIndex?

[Ben Appleton]

Some sites want to control the z-indices of their markers. If we were to add an API-computed z-index to their z-index, that could change the ordering of their markers. So if a site wants to control the z-indices of their markers, we should do exactly what they say.

The issue here is that some sites are happy with the default z-indexing (by height), but want to bring a marker to the front on hover. Whether we added their z-index to ours, or obey their z-index directly - they still need to use a sufficiently large value to ensure their marker appears in front of everything. So either the API must provide a "maximum z-index" promise, which would be the maximum z-index the API would assign to a marker, or the API must provide explicit support for hover.

On Thu, Mar 3, 2011 at 11:26 AM, Esa <esa.i...@gmail.com> wrote:

Why not add user zIndex to your internal zIndex?

--

[Esa]

Ben

I am not happy with the answer. We don't know anything about your
zIndex formula. It used to be 'top' but you never documented it and
now you even changed the zIndex scheme.

If you you would simply add user zIndex to your internal zIndex,
anyone would be happy. We would be happy without knowing the formula
you use by latitude. Defining zIndex would be "{z-index:20} will bring
20px high icon on top of others". getZIndex() would return 20 and we
would not be confused with any formulas.

I don't see any trouble with making user zIndex relative to API
internal zIndex.

[Esa]

By the way. Draggable marker doesn't behave well right now concerning
z-index.

[Ben Appleton]

Esa

Thanks for talking this through.

On Thu, Mar 3, 2011 at 12:15 PM, Esa <esa.i...@gmail.com> wrote:

Ben

I am not happy with the answer. We don't know anything about your
zIndex formula. It used to be 'top' but you never documented it and
now you even changed the zIndex scheme.

Sorry, what do you mean by 'top'?

We used to say "if you want to control the z-index of one of your markers, you must set the z-index of all of your markers". However that's tedious when you just want to bring a marker to the front. We will soon add a robust way to bring a marker to the front.

 

If you you would simply add user zIndex to your internal zIndex,
anyone would be happy.

No, as I described in my last email, users who want to control the z-indices of all their markers would be unhappy if we modified them. Adding is undesirable in this case.

 

We would be happy without knowing the formula
you use by latitude. Defining zIndex would be "{z-index:20} will bring
20px high icon on top of others". getZIndex() would return 20 and we
would not be confused with any formulas.

In your example you would still need to know the z-index of our markers. If you wanted to bring a marker to the front, by how much would you increase its z-index? Why should that be a function of the marker's height?

 

I don't see any trouble with making user zIndex relative to API

internal zIndex.

[Ben Appleton]

Draggable markers are not rendered in Canvas. This is only noticeable when there is a mix of non-draggable and draggable markers, in which case the draggable markers pop out in front of the other markers.

On Thu, Mar 3, 2011 at 12:30 PM, Esa <esa.i...@gmail.com> wrote:

By the way. Draggable marker doesn't behave well right now concerning
z-index.

[bratliff]

On Mar 3, 2:07 am, Ben Appleton <apple...@google.com> wrote:

> We will soon add a robust way to bring a marker to the front.

You could leave the main CANVAS tiles containing many markers alone.
You could float a separate CANVAS element containing just one marker
over it. It also works for temporary style (color / opacity) changes
to one marker without changing the main tiles.

[Ben Appleton]

When 1 marker changes we just repaint the "dirty rectangle" around it, so it's quite fast to pop a marker in or out of a tile.

There's a minor issue with leaving the tile alone and rendering another copy of the marker in front: translucent markers would suddenly appear to have higher opacity.

--

[bratliff]

On Mar 3, 4:46 am, Ben Appleton <apple...@google.com> wrote:
> When 1 marker changes we just repaint the "dirty rectangle" around it, so
> it's quite fast to pop a marker in or out of a tile.
>
> There's a minor issue with leaving the tile alone and rendering another copy
> of the marker in front: translucent markers would suddenly appear to have
> higher opacity.

I agree about additive opacities.

How do you repaint a dirty rectangle if your markers are not
rectangular without clobbering other markers in the same rectangle ?
Are you using "drawImage" to copy a prototype marker into the tile ?
Does it handle overlapping colors & opacities correctly ? What
"globalCompositeOperation" do you use ?

[bratliff]

On Mar 3, 1:10 pm, bratliff <bratl...@umich.edu> wrote:

> How do you repaint a dirty rectangle if your markers are not
> rectangular without clobbering other markers in the same rectangle ?
> Are you using "drawImage" to copy a prototype marker into the tile ?
> Does it handle overlapping colors & opacities correctly ? What
> "globalCompositeOperation" do you use ?

I guess you could use an irregular clipping path. I assumed
"drawImage" used an implicit "globalCompositeOperation" of "COPY". I
admit I have not really experimented with it. I know Opera's
"globalCompositeOperation" is inconsistent with other browsers.

[bratliff]

OK - I believe I have figured it out.

You use "drawImage" to extract the dirty rectangle into a detached
CANVAS element. You save it for later replacement. You also make
another detached copy of the same rectangle for temporary changes.
You paint your changes into one of the copies. You use "drawImage" to
exchange copies in response to "mouseover" / "mouseout". You use a
"globalCompositeOperation" of "COPY" to cover up any crap underneath
your marker.

I have a trick you might consider. I have not actually implemented it
but I believe it will work.

Suppose your tile size is 256 x 256 pixels. Suppose your marker with
all of its paraphernalia (shadow, etc.) is 40 x 40 pixels. Suppose
the center of your marker happens to coincide with pixel 0:0 of a
particular tile. You could break your marker into four pieces in four
different tiles. Alternatively, you could use larger overlapping
tiles.

For each tile:

style.left=(tileX*256-20)+"px";
style.top=(tileY*256-20)+"px";
style.width="296px";
style.height="296px";

The marker resides entirely in one tile. The overlapping area of
adjacent tiles is transparent.

[bratliff]

Sorry to clutter up the thread. The overlapping tile suggestion may
not work properly. Intra-tile zIndex priority will be preserved.
Inter-tile zIndex priority may not be. It will depend on the
childNode order of the CANVAS element which is arbitrary. Sorry.

Also, the repaint can occur in the CANVAS tile itself. Just one
detached CANVAS element is required to restore the original CANVAS
tile.

Both "getImageData" & "putImageData" are too inefficient to be
practical. Conversion between 32 bits & 128 bits is performed for
each pixel. It depends on transfer direction. CPU architecture (big
endian / little endian) determines whether bytes have to be reordered.

"drawImage" ought to be very quick if the rectangle dimensions are
identical. It is just one REP MOVSD per row of pixels. Perhaps the
DMA processor can assist. Because one of the CANVAS elements is in
memory but off screen, old graphics card may not be able help.

[Raoul]

Esa> We will soon add a robust way to bring a marker to the front.

Please, don't forget to add also a robust way to put it back to its
initial zIndex value.


Ben> The issue here is that some sites are happy with the default z-
indexing (by height), but want to bring a marker to the front on
hover.

Yes, it's my case.

[Esa]

On Mar 3, 4:08 am, Ben Appleton <apple...@google.com> wrote:
> Draggable markers are not rendered in Canvas. This is only noticeable when
> there is a mix of non-draggable and draggable markers, in which case the
> draggable markers pop out in front of the other markers.

Actually that is quite nice behavior.

[Esa]

On Mar 3, 4:07 am, Ben Appleton <apple...@google.com> wrote:

> Sorry, what do you mean by 'top'?

In some previous api version the z-index was equal to pixel value of
'top' position of the marker. That was clever. Actually my idea is
based on that. Relative z-index works only if the internal z-index
goes one step per pixel. However the z-index formula should be
published as it was with v2.

> Why should that be a function of the marker's height?

Right. Marker height is not a parameter in this issue. Forget it.