fix(google-maps): Robust DOM positioning when interleaved: false

[felixpalmer]

Replaces #9985 @neil-morrison44 @chrisgervang

Background

The Google maps library has a number of rendering modes, which can be decided at runtime. At a high level we have:

• RASTER old code path, uses PNG images as tiles
• VECTOR newer code, rendering using WebGL and vector data

In order to integrate the deck.gl canvas we need to synchronize with the view state of the Google Map. Two classes are provided for this: google.maps.OverlayView and google.maps.WebGLOverlayView.

For the RASTER case, we have no choice, we must use OverlayView as there is no WebGL context. Conceptually this integration path is simpler as we have a clear DOM element to attach to: overlay.getPanes()?.overlayLayer

For the VECTOR case there is no DOM element, as we instead receive a WebGLContext to draw into.

The complexity comes when we want to support VECTOR with interleaved=false as the WebGLOverlayView does not give use a DOM point to mount to. Currently we just attach to the root element, but this causes issues as the deck.gl canvas is drawn on top of the Google controls.

In the interleaved=false case it seems natural to use the google.maps.OverlayView instead of the google.maps.WebGLOverlayView as we don't need access to the WebGL canvas and instead we want to cleanly add a DOM element (the deck.gl app) to the Google Maps library.

The problem is that google.maps.OverlayView.draw() is limited compared to google.maps.WebGLOverlayView.onDraw(). Specifically google.maps.WebGLOverlayView.onDraw() provides a transformer object which lets deck.gl exactly reconstruct the view state, and it even works during animations/transitions. There is no such API with google.maps.OverlayView.draw, which leads to a glitchy integration (see the long list of commits in this PR for details)

As such for the non-interleaved case, this PR both:

• Creates an OverlayView in order to position the non-interleaved canvas
• Creates a WebGLOverlayView in order to obtain transformer object to give correct camera tracking

Change List

• Create both OverlayView & WebGLOverlayView in non-interleaved case
• Update callbacks used by overlays
• Refactor to split code into _createOverlayVector and _createOverlayRaster
• Fix useDevicePixels default behavior in non-interleaved mode

[coveralls]

coverage: 91.091%. remained the same
when pulling 57bdf2a on felix/gmaps-non-interleaved
into b830b0e on master.

[chrisgervang]

Nice

[chrisgervang]

I'm unfamiliar with this Google view API. Are there any noticeable performance or billing implications that come with adding two views?