fix(google-maps): wait for shared context in interleaved mode

[geoff-ux]

Closes #10704
Closes #10059
Closes #10056

Background

Positioning onAdd creates Deck without Google's gl; _onContextRestored reuses it, so interleaved layers never draw. Prop changes can also make drawing use a different mode from context creation.

Change List

• Create interleaved Deck only when Google's context arrives
• Bind creation and drawing callbacks to the same mode
• Unit tests for callback orders and prop-change timing; tests release the WebGL contexts their standalone Decks create, so the shared test device is not evicted

Verified corepack yarn lint and corepack yarn test-headless --reporter=verbose test/modules/google-maps (21 passed). Eight drawing regressions fail before the draw-mode correction; the positioning-first regression fails on master. Twelve additional real-WebGL probes pass.

Please backport to 9.3-release and 9.4-release; we pin 9.3.11.

---

Note

Medium Risk
Touches vector-map WebGL lifecycle and render path (shared vs standalone context); behavior change is targeted but affects default interleaved rendering on Google Maps.

Overview
Fixes interleaved vector Google Maps overlays where Deck could be created on the positioning overlay before Google’s shared WebGL context arrived, so layers never rendered into the map’s GL context. Interleaved mode now skips createDeckInstance in _onAddVectorOverlay and only builds Deck in _onContextRestored with the supplied gl.

Creation-time interleaved is bound into _onAddVectorOverlay and _onDrawVector when vector overlays are set up, so draw behavior (shared-context _drawLayers vs standalone redraw and canvas sizing) stays aligned with how Deck was created even if interleaved props change later.

Adds Vitest coverage for positioning vs context callback order, interleaved/non-interleaved GL ownership, vector draw paths, and a finalizeOverlay helper that tears down standalone Deck WebGL devices so headless tests don’t evict the shared device.

^{Reviewed by Cursor Bugbot for commit 69571f2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new findings or outstanding previous findings remain.

Summary

The PR defers interleaved Deck creation until Google supplies its WebGL context and binds creation and drawing to the same mode. Tests cover callback ordering, mode changes, and WebGL resource cleanup. The changes since the previous review do not alter the Google Maps PR diff.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Vector overlay attached] --> B{Selected mode}
  B -->|Interleaved| C[Wait for Google's WebGL context]
  C --> D[Create Deck with shared context]
  B -->|Non-interleaved| E[Positioning onAdd creates standalone Deck]
  D --> F[Draw using bound mode]
  E --> F

Loading

_{Reviews (7) · Last reviewed commit: "Merge branch 'master' into fix/google-ma..." · Reviewed by Greptile}

[chrisgervang]

Thanks, I was able to reproduce this issue in the basemap-browser example and confirmed this PR fixed it.

[chrisgervang]

Please fix CI and then we can merge

[chrisgervang]

This also fixes #10059 and #10056. Could you add Closes #10059 and Closes #10056 to the description?

---

From Claude
Verified #10059 in the basemap browser: re-adding an interleaved overlay to an already-vector map draws nothing on master and renders correctly with this PR.

#10056's screenshots show the same thing on 9.2.10, where layers are drawn into a default 300×150 own canvas.

[coveralls]

coverage: 83.707% (+0.09%) from 83.619% — geoff-ux:fix/google-maps-interleaved-context into visgl:master