I linked to the wrong test https://jsperf.com/webgl-teximage2d/6

On Chrome stable, texImage2D by UintArray32 is about 7 times faster.
On Canary canvas seems to have been booster (to the point where its faster than the Uint8Array), but uploading an Image is still as slow.

Calling toDataURL on a large canvas forces a GPU-to-CPU readback of the contents, defeating all of the optimizations the browser performs behind the scenes. This is why WebGL's texImage2D and texSubImage2D (and now the 3D variants) accept HTMLCanvasElements, HTMLImageElements, ImageBitmaps, etc. These utilize GPU-to-GPU copies behind the scenes.

This is expected behavior. Please switch your code to pass the canvases, images, etc. in directly. ImageBitmap rather than HTMLImageElement is now the recommended way to asynchronously prepare large images for upload to WebGL textures.

toDataURL is indeed slow, but it wasn't the problem here since it was not part of the actual performance test (only initialization, to create an image from the canvas rather than download an image from the web).


After more investigation following your informations I can add that :
- ImageBitmap a nice to use with fetch, but passing an ImageBitmap to texImage2D is not much faster than passing directly a Uint8Array.
- Passing a HTMLCanvasElement was slowing down texImage2D if drawn a HTMLImageElement in said canvas
- If the canvas is drawn an ImageBitmap and then the canvas is passed to texImage2D, it gets faster than passing the ImageBitmap directly.
It's kind of unexpected that ImageBitmap=>texImage2D is slow while ImageBitmap=>Canvas=>texImage2D is fast, but adding a canvas is not much so I'll consider WontFix acceptable.

Thanks !

wiz@ - sorry if I misinterpreted your test.

It's unexpected that uploading an ImageBitmap via texImage2D is slower than taking the same ImageBitmap, drawing it to a canvas, and uploading it via texImage2D.

If you have some test case demonstrating this, please file a new bug. Please be careful to avoid issues like accidentally caching the results of previous runs, or re-using the same ImageBitmap over and over again, thereby causing it to be cached in a texture internally and making the ImageBitmap -> Canvas -> Texture path accidentally faster.