Reduce slowness when loading many raster tiles at once

[kkaefer]

We're bottlenecked on too many texture uploads occurring at the same time, and Webkit's timeline recorder confirms this:

It seems that uploading a single texture takes ~7.5ms per raster tile. On smaller screens, this is typically split up across multiple frames, but if you have a fast network and a big screen, many of the load events can happen within the same frame.

We should:

• Investigate why the calls to texImage2D and generateMipmap raster tile take a combined ~7.5ms. The tiles in the screenshot above @2x tiles (512×512), but even then ~7.5ms seems excessive.
• Distribute raster tile loads across multiple frames and upload at most 1-2 tiles per frame.
• Don't generate the mipmaps immediately after loading, but wait a frame to spread the load.

Further avenues for investigation:

• Check whether using texSubImage2D to upload the bitmap in batches, and spread the upload of large bitmaps across multiple frames improves the performance.

• A comment on the chromium mailing list claims:

  Image decompression happens after the onload handler fires. [...] The ImageBitmap API will fix this problem.

  The ImageBitmap API is supported in Chrome and Firefox at the time of this writing, but not Safari/Webkit, IE and Edge. It looks like we could use this to make image decoding asynchrous: The createImageBitmap constructor method returns a promise that will be resolve to a ImageBitmap object, so the call to texImage2D doesn't need to decode the image first. (See example in https://gist.github.com/ahem/d19ee198565e20c6f5e1bcd8f87b3408). Note that at least Chrome still decodes on the current, thread, so we need to do this in a webworker.

[ansis]

Is it faster later on when it can reuse old textures and upload with texSubImage2D?

[hyperknot]

I wrote a detailed comment here: #7008 (comment)

I don't know if it's the WebGL part or the image loading, but I found this example to be extremely broken, when testing with Chrome's Fast 3G + disable caching network condition.
It produces many second long frozen frames.
https://codepen.io/hyperknot/full/bmvzQx/