Use the non-webGL google.maps.OverlayView when interleaved is false

[neil-morrison44]

Background

Using google.maps.WebGLOverlayView when interleaved is false results in the overlay appearing over all UI like

and

with this in place it uses google.maps.OverlayView instead resulting in it sitting on the right google maps overlay pane

Change List

• includes interleaved status when judging wether the google maps overlay should treat the map like a vector map or not

---

Using interleaved=false on a vector map is a workaround for this issue: #9452

[chrisgervang]

Thanks for looking into this. I traced the behavior back to the original interleaved support work (#5980), and I’m not convinced switching the overlay class addresses the root cause. From what I’m seeing, the issue is driven by DOM stacking order rather than the renderer.

Also, per the Vector/Raster note in the docs, moving to OverlayView would mean losing tilt and rotation support, which isn’t ideal for users.

Can you focus on a solution that fixes the DOM order/stacking, instead of changing the overlay class?

[neil-morrison44]

I don’t think you’re right there - Google maps itself should be solely handling the layering of the overlays.

if you’re not doing 3D interleaving google.maps.OverlayView is the correct one to use then the stacking is controlled via Google’s MapPane concept https://developers.google.com/maps/documentation/javascript/customoverlays?authuser=1#intitialize

The overlay won’t disable tilt / rotate I’ll just be a 2D plane, which is about as good as you can expect.

Can see tilt & rotate still work when using the google.maps.OverlayView, the heatmap itself is positioned incorrectly depending on rotation but I think that's unrelated to the overlay.

(I've been working for a Google Maps partner for 11 years now, for most of the time as the lead frontend)

[chrisgervang]

Ah thanks that helps, and I think you’re right to push back on my assumption.

I was conflating our Vector/Raster docs with a hard limitation of google.maps.OverlayView. Your screenshot makes it clear that tilt/rotate remain enabled.

Given that, I’m good with switching to OverlayView for the non-interleaved + vector path rather than trying to “fix” DOM order ourselves.

The one thing I’d still like to sanity-check is the behavior you called out with rotation (the heatmap positioning drifting). If that’s unrelated to the overlay mechanics, then great - but it’s worth confirming so we don't introduce a subtle alignment regression.

@felixpalmer, I’d appreciate your input on this proposed fix.

[chrisgervang]

Looks like some tests are failing

[felixpalmer]

@neil-morrison44 thanks for flagging this, clearly an annoying issue.

The overlay won’t disable tilt / rotate I’ll just be a 2D plane, which is about as good as you can expect.

I'm not sure what you mean by this, could you clarify?

I've had a look and it is possible to fix this issue by tweaking how the deck canvas is inserted into the DOM, specifically in google-maps/src/utils.ts:

if ('getPanes' in overlay) {
  overlay.getPanes()?.overlayLayer.appendChild(container);
} else {
  // overlay.getMap()?.getDiv().appendChild(container); OLD CODE
  const gmContainer = overlay.getMap()?.getDiv();
  const gmElement = gmContainer?.getElementsByClassName('gm-style')[0];
  gmElement?.appendChild(container);
}

This will place it between the google maps canvas and UI. Does this resolve your issue @neil-morrison44? The benefit of this approach is that tilt & rotate work as before

[neil-morrison44]

@felixpalmer that solves some issues, though it still appears over some UI like the scroll message

and map-based popups

Also I'd be wary of how future proof doing DOM manipulation within the google map is

---

As for the fix suggested here, it doesn't cover any UI elements but there is some sort of projection issue at the edges of the screen when tilted (which, for us at least, would be less of a blocker than covering the UI)

tilt_issue.mov

[felixpalmer]

@neil-morrison44, thanks for the feedback - indeed relying on the DOM is risky.

Your video shows that the tilt parameter is not being passed through to deck.gl - could you try and debug that? In general, I buy your argument that OverlayView may be the correct one to use here, but we can't use it if the tilt isn't syncing

[neil-morrison44]

Tilt is being passed through (can see the heatmap being more squished in the 2nd image here after it's been tilted), I'm not sure what's causing the projection issues which get worse away from the centre of the viewport though

[felixpalmer]

@neil-morrison44 I've tried many approached to get the projection to work with the OverlayView API and cannot get good results. Instead I've come up with an alternative: #9992

[neil-morrison44]

@felixpalmer 👍🏻 looks good, can't see anything in that PR that sticks out at me as being something risky that's liable to be broken in future Google Maps versions.

Thanks for having a look into it

I'll close this PR off now

---

The original impetus for using interleaved: false was that the interleaved mode (which I'd rather be using) was encountering this bug: #9452 for the same sample data (though, it was red rather than yellow). If you, or others, want to do triage on that bug I can help, if needed.

With Google Maps deprecating the inbuilt heatmap in May & with their docs recommending deck.gl as the replacement I'd assume there'll be more people going through the same flow I did in the run up to the deprecation.

Thanks again

[felixpalmer]

Thanks for the heads-up about Google deprecating their heatmap - I wasn't aware.

#9452 is indeed annoying, I had a quick look but couldn't figure it out. If you could do some digging to try and figure out the root cause that would be appreciated