WebGL CanvasSource performance drop in 0.40.0

[gpbmike]

mapbox-gl-js version: 0.40.0

Steps to Trigger Behavior

Add a webgl canvas source/layer.

Expected Behavior

Should be a buttery 60fps like 0.39.1.

Actual Behavior

Severe drop in framerate. In the example codepens below I'm using plotty to generate a colorful webgl canvas. The only difference between the codepens is the mapbox-gl-js version.

The performance is heavily dependent on the size of the canvas being used. In this case it's 2000x2000, which is not uncommon for me.

It's probably the overhead of creating a large image on every render. 😢
#5155

0.39.1

https://codepen.io/gpbmike/pen/oGXmRJ

0.40.0

https://codepen.io/gpbmike/pen/jGPvpo

[gpbmike]

I can't seem to create a reduced test case for this so I'm going to close it and do more digging.

[gpbmike]

I have updated the description with a reduced test case.

[lbud]

🙁 right, likely a side effect of having to copy all pixels into an intermediary buffer #5155 — we can mitigate this for non-animated canvases actually (added in #5303), but unfortunately since #5155 is a workaround for a hardware bug I don't have ideas for making animated, WebGL-based canvas sources much faster easily. (Eventually down the road when Mapbox GL adds support for "custom layers" — that is, layers that define their own layout and shaders, hooking into our existing rendering pipeline — that'll be the way forward for fast custom WebGL overlays.)

[gpbmike]

I've been doing some additional tinkering in mapbox-gl-js with my broadwell processor machine (#4262 (comment)).

• I reconfirmed the problem with 0.39.1 when adding a webgl canvas source.
• I confirmed that the problem is fixed in 0.40.1 when adding a webgl canvas source.
• I pointed to a local copy of 0.40.1 where readCanvas simply sets this.canvasData = this.canvas and it still works. 🤔

Now I suspect #4262 was fixed by something else in 0.40 and maybe there's no need for the intermediary imageData step?

[jfirebaugh]

Fixed in #5448/#5449; thanks @gpbmike!