Use willReadFrequently optimization hint on 2D canvases.

[kircher1]

When setting willReadFrequently to true, it is a hint to the browser that it can decelerate the canvas. This can be beneficial to perf if the canvas is only used for decoding and getting image data in raw pixels. If the canvas was accelerated (i.e. hosting data on the GPU) there could be a lot of latency to get the image data back to the main thread.

Perf-wise, I was able to isolate this function into a benchmark to show the improvement:

From chromium on a relatively fast machine (~8ms vs ~2ms):

In practice, I'm seeing this improvement is better for slower machines and less noticeable on faster machines.

On Firefox I saw no difference.

Using the hint also removes the source of a warning when using hillshade layer:

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Post benchmark scores.
• Manually test the debug page.

[github-actions]

Bundle size report:

Size Change: +36 B
Total Size Before: 206 kB
Total Size After: 206 kB

Output file	Before	After	Change
maplibre-gl.js	196 kB	196 kB	+36 B
maplibre-gl.css	9.09 kB	9.09 kB	0 B

ℹ️ View Details

No major changes

[HarelM]

Should this be configurable like preserveDrawingBuffer? I'm not sure I know what the impact of this change unfortunately...

[kircher1]

Based on A/B testing the change, enabling this willReadFrequently hint provides a slight reduction in startup time for our usage of MapLibre. It also reduces the potential for dropped frames: if getImageData() is called during map moving, the current, slower version could easily add a few millis of overhead which could be the difference between hitting a frame target or dropping a frame.

Local benchmarking has corroborated the speed improvement (eg previously attached image); it's either faster or neutral.

Plus, given that the existing usage pattern of the canvas in raster_dem_tile_worker_source is now triggering a warning in Chrome, getting rid of this warning spam is a benefit in and of itself.

Since it appears to be an improvement that should benefit everyone, I don't think a config option is necessary. If there were negative tradeoffs, then I agree with the config idea, but that hasn't been the case.

FYI, here's the original proposal for 'willReadFrequently' operation, with more explanation: https://github.com/fserb/canvas2D/blob/master/spec/will-read-frequently.md

[HarelM]

What about the following: will it affect 3D in any way?

When the user sets willReadFrequently to true, the UA can optimize for read access, usually by not using the GPU for rendering.

[kircher1]

No, that would be very surprising, but I see your point given the ambiguity of that sentence :)

My understanding is that this hint only affects the 2D canvases. and when I apply it locally, I am still seeing GPU usage spike up in heavier MapLibre scenes, implying WebGL is still accelerated even if the 2D canvases are not.

Here's the documentation from Firefox, worded more clearly: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext

willReadFrequently
A boolean value that indicates whether or not a lot of read-back operations are planned. This will force the use of a software (instead of hardware accelerated) 2D canvas and can save memory when calling getImageData() frequently.

[kircher1]

In terms of exactly how the browsers implements this though, I can't speak with authority. My stance is based on what I've read and benchmarking/perf results.

[HarelM]

Sorry, forget to ask for a changelog entry, can you create a new PR to add that please?