Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce slowness when loading many raster tiles at once #7405

Open
1 of 5 tasks
kkaefer opened this issue Oct 11, 2018 · 2 comments
Open
1 of 5 tasks

Reduce slowness when loading many raster tiles at once #7405

kkaefer opened this issue Oct 11, 2018 · 2 comments
Labels
performance ⚡ Speed, stability, CPU usage, memory usage, or power usage

Comments

@kkaefer
Copy link
Contributor

kkaefer commented Oct 11, 2018

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

image

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.

@kkaefer kkaefer added the performance ⚡ Speed, stability, CPU usage, memory usage, or power usage label Oct 11, 2018
@ansis
Copy link
Contributor

ansis commented Oct 11, 2018

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

@hyperknot
Copy link

hyperknot commented Oct 18, 2018

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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance ⚡ Speed, stability, CPU usage, memory usage, or power usage
Projects
None yet
Development

No branches or pull requests

3 participants