Create unique MaskEffect per EffectManager

[felixpalmer]

For #6552

Background

When rendering into multiple WebGL contexts, the MaskEffect.maskMap texture created by the DEFAULT_MASK_EFFECT isn't valid in all contexts. This is an issue in Kepler when rendering in split screen mode. To repro in test/apps/mask.js add:

<div style={{position: 'relative', height: '450px'}}>
  <DeckGL
    layers={showLayers ? getLayers() : []}
    initialViewState={INITIAL_VIEW_STATE}
    controller={true}
  >
    <StaticMap reuseMaps mapStyle={mapStyle} preventStyleDiffing={true} />
  </DeckGL>
</div>
<div style={{position: 'relative', height: '450px'}}>
  <DeckGL
    layers={showLayers ? getLayers() : []}
    initialViewState={INITIAL_VIEW_STATE}
    controller={true}
  >
    <StaticMap reuseMaps mapStyle={mapStyle} preventStyleDiffing={true} />
  </DeckGL>
</div>

Change List

• Create a new MaskEffect for every EffectManager instance

[coveralls]

Coverage remained the same at 80.432% when pulling c8e5cb0 on felix/mask-multi-gl into 8291e86 on master.

[ibgreen]

When rendering into multiple WebGL contexts.... This is an issue in Kepler when rendering in split screen mode.

In a perfect world, kepler.gl would obviously not be using two contexts but rather adopt the deck.gl View system.

Nit: I see a couple of lint warnings, at least some of them clearly introduced by the mask work, would you care to make a pass and squash them?

[felixpalmer]

In a perfect world, kepler.gl would obviously not be using two contexts but rather adopt the deck.gl View system.

There are other cases where we have two contexts, like when using multiple 3rd party basemaps, so this will always be an issue. @ibgreen I will take a look at the lint warnings

[ibgreen]

There are other cases where we have two contexts, like when using multiple 3rd party basemaps, so this will always be an issue.

Yes... if the user does wants deck.gl to use the WebGL contexts of multiple basemaps (as opposed to the "default" case of simply rendering deck.gl's views "on top of" multiple base map canvases), then multiple contexts are indeed needed.

It is in a way the most advanced use case for deck.gl, and it is great that you are working through the corner cases.

And yes, of course, we should absolutely support multiple contexts if we can. Was just pointing out that for performance and memory pressure reasons we have been investigating moving away from the dual context approach in kepler.gl, but sounds like you may still need the option? Though that is probably a discussion for the kepler.gl repo.

[felixpalmer]

Our use case is with kepler, but also with 2 basemaps - so we need 2 context support either way