-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Description
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
andgenerateMipmap
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 aImageBitmap
object, so the call totexImage2D
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.