Upload one raster tile texture per render frame

[ryanhamley]

Launch Checklist

This closes #7451

It also completes some of the work in #7405

• briefly describe the changes in this PR
  • introduces a queue to limit raster tile texture upload to the GPU to one texture per render frame
• write tests for all new functionality
• post benchmark scores
• manually test the debug page

Benchmarks don't show any major performance improvement or degradation

[kkaefer]

Given that we're now deferring the action of uploading the tile, abortTile no longer cancels everything: There could be a situation where the request responds with a tile, we store in the queue, then the tile gets aborted/deleted. We now still hold on to the tile and upload it to the GPU, but it'll never be used and gets GCed once the callback/tile object is removed from the textureQueue. We should add a way to either remove requests from the textureQueue that reference this tile, or use another mechanism to prevent tiles from remaining alive longer than they need to.

[ryanhamley]

Is it enough to check that the tile pulled from textureQueue doesn't have the aborted property before uploading to the GPU? Or would that be unreliable and not cover all potential cases? It seems to work but I'm not 100% sure how to ensure that the aborted tiles aren't being uploaded.

[kkaefer]

That works; another option would be to remove the object from the queue when the tile is aborted.

[mourner]

There's similar logic here if that helps: https://github.com/mapbox/mapbox-gl-js/blob/master/src/util/ajax.js#L196-L197

[ryanhamley]

My manual testing seems to indicate that 2 is an optimum number of textures to upload at once. 1 and 2 textures both show a roughly 12% dropped frame rate while at 4 textures per frame, the dropped frame rate increases to roughly 20%. 1 texture per frame is too slow, especially on pitched maps while 2 textures per frame looks much snappier and uses half as many frames.

I've also implemented the queue on a per-source basis rather than per-style because having a single queue per style leads to the possibility of tiles for multiple raster(-dem) layers being jumbled together in the queue which can result in not being able to render all necessary tiles. It leads to some awkward type checking to make Flow happy but it's the simplest implementation I could think of.

[andycalder]

This looks like a great performance improvement to me! I tested this on a satellite map with 60 degree pitch and the frame rate difference is very noticeable on initial map load when the tiles have been cached by the browser. I'd love to see this PR move forward. Is it a work in progress?

Some things I noticed:

• This breaks the tile fade-in transition because the _tileLoaded() callback sets tile.timeAdded immediately, and this starts the opacity interpolation before the tile is even rendered. I quick-fixed this by moving the callback to textureCallback(). Visual comparison with master is more favourable when the fade works.
• For the raster-dem case, it looks like you're queueing the DEM decode operation, which happens in a web worker, instead of the actual texture upload. Texture upload happens in draw_hillshade.js.

[ryanhamley]

Thanks for the feedback @andycalder! It's a work in progress, yes. We've been investigating a few different ways of making performance better with raster image loading. #7405 is the master ticket for this work. A related improvement I've been working on is using the Image Bitmap API in browsers that support it which you can see in https://github.com/mapbox/mapbox-gl-js/tree/image-bitmap-prototype (very rough prototype).

I actually hadn't seen a huge improvement with this PR and in fact, when combined with #7497 the performance seemed worse since raster requests were essentially being rate limited twice. It definitely requires more investigation. Are you able to share a minimal example in which you saw a performance improvement?

[ryanhamley]

Also, I don't think the version of this branch on Github had been updated with #7497 previously so I'd recommend trying it now that I've rebased against master @andycalder

[andycalder]

@ryanhamley #7497 is trying to solve the same problem, right? So implementing this PR would mean reverting #7497 and you wouldn't be throttling rasters twice.

If I understand correctly, the underlying problem is texture uploads to the GPU (gl.texImage2D()) taking too long. I don't think #7497 solves this problem because it limits parallel image requests to 16 but the bottleneck for texture upload is far less than 16 per frame. The master ticket #7405 notes that a single texture upload takes ~7.5ms and you noted above that 4 textures per frame degrades the frame rate. Wouldn't it be better to leave the requests alone and limit the offending texture upload.

On my machine, when I refresh https://jsbin.com/xubonu (v0.52.0) the frame rate is terrible. Using my stagger-texture-uploads build, the frame rate is much better (I'm not sure how to host a repro of this). The tradeoff is that it takes slightly longer to populate the map with tiles.

The Image Bitmap API is interesting and it looks like it's probably the ideal solution but browser support is really unfortunate.

[vakila]

Closing this as stale/no longer WIP per chat with @ryanhamley