Adding some logging to the ImageBitmap implementation and making a few changes:
https://chromium-review.googlesource.com/1009322

turns up several issues. Some of these are related to this performance issue, and some are correctness issues.

1) GPU acceleration is not being used for the ImageBitmap; it's a CPU-side bitmap. That's fine for this purpose, as we're comparing against uploading a Uint8Array to a texture.

2) The ImageBitmap is being decoded into Skia's kN32_SkColorType, which still – even on macOS – resolves to kBGRA_8888_SkColorType. This forces a swizzle during the upload to the WebGL texture and is half of the upload cost. Switching GetSkImageInfo in src/third_party/blink/renderer/core/imagebitmap/image_bitmap.cc to force kRGBA_8888_SkColorType eliminates about half of the cost of the upload.

3) It looks like there are correctness issues in the handling of unmultiplied alpha in image_bitmap.cc. CropImageAndApplyColorSpaceConversion should create an ImageDecoder that doesn't premultiply alpha, but then later it calls GetImageWithAlphaDisposition with argument kUnpremultiplyAlpha, doing a double-unmultiply. I thought this might be related to  Issue 826878  but it isn't (different code paths). This doesn't affect this test case.

I haven't yet figured out which code path this call in WebGLRenderingContextBase::TexImageHelperImageBitmap is taking:
  sk_sp<SkImage> sk_image =
      bitmap->BitmapImage()->PaintImageForCurrentFrame().GetSkImage();

but suspect that's where the remainder of the time is going.

Justin, the Canvas team owns ImageBitmap; can someone from your team please take this bug?

Taking this back from Justin.

Added logging to the ImageBitmap upload path in this CL:
https://chromium-review.googlesource.com/1009322

It shows that the cost is coming from basically two places:

1) ImageBitmaps are created with Skia's N32 internal format by default, and on desktop platforms this is BGRA8888. Because of this, when uploading ImageBitmaps to WebGL textures, a full-image conversion still has to be done. This is half of the cost in the customer's test case. Changing ImageBitmaps to use an RGBA8888 internal format eliminates this and is being proposed in https://chromium-review.googlesource.com/1094559 , but I don't know whether that has other performance or correctness implications.

2) The underlying call to TexImage2D has highly variable cost and that's almost surely due to Chromium's transfer buffer sizing logic. jdarpinian@ is working on this in  Issue 850271  and this will help. Changing which of the TexImage2D calls (from ImageBitmap or raw data) is made first affects the timing of the test case. Swapping them makes the ImageBitmap case faster than the raw data case sometimes, with the fix from (1) in place.

I'm sorry for the lack of progress on this issue. jdarpinian@ did excellent work in  Issue 850271  and I need to re-measure things. The solution will unfortunately not be as simple as changing ImageBitmaps' internal format.

Prezi folks: are you using the resizing options available in createImageBitmap? Or do you do any necessary resizing another way?

Yes, on one of the path when an image tile is not available on the server, we have to crop and resize the images all asynchronously.