WebGLRenderer: Add "readRenderTargetPixelsAsync" function

[gkjohnson]

Fix #22779
Based on #24466

Description

Adds a readRenderTargetPixelsAsync to WebGLRenderer which supports asynchronously reading pixels from a render target by waiting until the read commands have finished before providing the array buffer. The webgl_interactive_cubes_gpu example has also been updated to demonstrate the functions use.

Here's a quick look at the stall times when reading data in the interactive cubes example:

Benchmarks

Reading 1*1 Pixel Texture

readRenderTargetPixels

~2.2 - 2.5 ms stall when calling readRenderTargetPixels( ... )

readRenderTargetPixelsAsync

~0.5 - 1.0 ms stall when initially calling readRenderTargetPixelsAsync( ... )
~8.8 - 10.0 ms until the data is ready (asynchronous) or 1 or 2 frames on my 120 fps display.

Reading 1024*1024 Pixel Texture

readRenderTargetPixels

~10.0 - 11.0 ms stall when calling readRenderTargetPixels( ... )

readRenderTargetPixelsAsync

~0.5 - 1.2 ms stall when initially calling readRenderTargetPixelsAsync( ... )
~12.0 - 13.0 ms until the data is ready (asynchronous) or 2 frames on my 120 fps display.

cc @sciecode I've updated and simplified some of the code from #24466 and removed some of the tangential functions and options. If they're needed perhaps we can add them in future PRs but the use wasn't immediately clear to me. Unfortunately I couldn't include your contributed commits in this PR because the branch had been deleted.

This contribution is funded by the Cesium GIS Ecosystem Grant

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
675.7 kB (167.5 kB)	677.1 kB (167.8 kB)	+1.47 kB

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
454.8 kB (109.8 kB)	456.3 kB (110.1 kB)	+1.47 kB

[sciecode]

LGTM - Removed functions were used to test alternative APIs, they aren't required.

nit: I found empirically that a fixed 8ms is bit too large of an interval for some use cases, I have used 4ms or even 2ms in some cases. Since the probe function isn't too expensive, having a higher refresh rate can decrease waiting time quite significantly. Ideally this would be a user defined parameter, but I think a 4ms default is a nice compromise for now.

Other than that, should be good to go.

[gkjohnson]

Thanks @sciecode I've adjusted the value to 4ms

Ideally this would be a user defined parameter

If we see issues or needs in the future maybe we can look at add some more options.