Raster tile loading blocking UI, FPS < 2.0

[hyperknot]

mapbox-gl-js version: 0.45.0
browser: Chrome 66 / macOS

1. On an empty style, add a raster tile layer, especially with smaller tile sizes, like "fake-retina" 256 pixels as 128.
2. Zoom around the map or use flyTo animations
3. Things can get really choppy.

Link to Demonstration

(I tested using Chrome FPS meter)
example: https://zl761nnr3m.codesandbox.io/
code: https://codesandbox.io/s/zl761nnr3m

Expected Behavior

UI interactions should be smooth, independent of tile loadings in the background.

Actual Behavior

The UX is really bad with raster layers now. Chrome FPS meter regularly gets under 2.0 fps on my Macbook Pro.

I've almost finished porting a big codebase over to Mapbox GL viewer, but this one is puzzling me. Both Leaflet and OpenLayers can display raster maps at constant 58+ FPS. How is it possible that Mapbox GL can render the most complicated vector tile regions smoothly, but is breaking with simple raster tiles?

[mourner]

This seems to be some kind of regression with the source cache logic — most of the time is spend figuring out which tiles to show, not actual rendering or loading. Investigating now.

[mourner]

Looks like it's not a regression, just an algorithm that dramatically slows down quadratically when the tile size goes down — it was only optimized for vector tiles, where you typically only see 6-7 tiles on the screen. Thinking about a faster one now...

[mourner]

OK, I have a good lead on this. Will submit a PR tomorrow.

[mourner]

Turns out that the jank on raster layers is currently dominated by XHR requests, which we use to load images since #1472 because of an issue with browsers not fully respecting Cache-Control: no-cache (#1470). You can see how much snappier the raster test case becomes in 9b372d9, which uses the old image loading approach (git co bench-raster-tile-load, yarn run start-debug, then load http://localhost:9966/debug/). If you switch getImage back to XHR-based requests in ajax.js, it becomes unusably janky, as reported.

Since the original fix with XHR image loads was introduced specifically to fix sprite updates, and most image loads don't have short cache spans, I wonder if we can use some kind of a mixed approach. For example, a raster tile source would do its first request with XHR-based getImage, see if cacheControl is small (no-cache, small enough max-age or whatever), and then either continue using XHR or switch to simple new Image for snappier performance. @jfirebaugh what do you think?

[hyperknot]

Thanks, it's great to see this! Is there any use case for super frequently updating raster tiles? Like satellite images are the slowest changing data in a map platform, aren't they?

If it is seriously needed for any use case, I'd recommend adding a tileXHR or tileCache or something similar to rasterSource and letting the developers choose it manually.

[mourner]

@hyperknot I feel like letting the developers choose would expose too much internal detail for a thing that should just work well automatically. So let's try to exhaust automatic heuristics first and resort to an explicit option if it doesn't work.

[jfirebaugh]

I was going to say we could probably just have tile requests always use Image directly, and use XHR only for sprites, but I wouldn't be surprised if there are use cases (e.g. weather apps) that depend on frequently updating raster tiles.

For browsers that support it, we could try out an XHR with req.responseType = 'blob' combined with createImageBitmap.

[hyperknot]

@jfirebaugh do you think it's worth the added complexity? As I see neither does Safari nor Edge supports it, while a simple Image.src is probably super optimised in every browser.

[mourner]

For browsers that support it, we could try out an XHR with req.responseType = 'blob' combined with createImageBitmap.

@jfirebaugh this likely won't help — looks like it's not the blob construction that's the bottleneck, but the XHR itself. Here's a screenshot from a stuttered frame (notice that all time is spent in send + open):

I wouldn't be surprised if there are use cases (e.g. weather apps) that depend on frequently updating raster tiles.

I think we could come up with a heuristic that supports this use case. E.g. if Cache-Control on the first XHR indicates that you can cache for >1hr, switch to simple image loads, otherwise continue with XHR. Thoughts?

P.S. #6995 and #6998 are PRs that remove two other bottlenecks that I identified when researching this issue.