WebGPURenderer: Introduce CanvasRenderTarget

[sunag]

Closes #27628

Description

@aardgoose did a great job on PR #27628; this PR is a reinterpretation with a focus on simplification given the renderer’s current times.

With CanvasRenderTarget it’s possible to use multiple canvases sharing existing resources—such as the cache—from the same Renderer. Since the previous process, like webgpu_multiple_elements, can bring other difficulties—because it is a whole canvas on the screen rendering only the scissor—or creating a new Renderer with a new canvas does not reuse the previous renderer’s caches, this feature becomes the most recommended for this application, given that the focus is only the WebGPU backend; at least in this PR it will be used exclusively for this backend.

Usage

// -- setup --
const canvas = document.querySelector( '#mycanvas'  );
const canvasRenderTarget  = new THREE.CanvasRenderTarget( canvas );

// -- loop --
renderer.setOutputRenderTarget( canvasRenderTarget );
renderer.render( scene, camera );

Note that renderer.setOutputRenderTarget() must respect the renderer.outputColorSpace.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	338.91 79.11	338.91 79.11	+0 B +0 B
WebGPU	578.16 159.25	579.42 159.58	+1.26 kB +327 B
WebGPU Nodes	576.76 159.01	578.03 159.34	+1.26 kB +324 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	470.78 113.9	470.78 113.9	+0 B +0 B
WebGPU	648.69 175.28	649.67 175.51	+975 B +224 B
WebGPU Nodes	602.79 164.41	603.76 164.63	+975 B +223 B

[Mugen87]

Do you mind explaining why you have added this line?

We should check if this addition does not break XR.

[sunag]

After setting setRenderTarget() as outputRenderTarget it does not restore the previous state, making the current getRenderTarget() the same as getOutputRenderTarget() after the render, thus being a bug.

[Mugen87]

I try to make a test with a Quest 2 tomorrorw. Just to be on the safe side since r180 is released next week.

[Mugen87]

Would it be possible to keep updating the options object as before?

options is not only used in createTexture() but also in subsequent code like updateTexture(). To avoid side effects, it would be beneficial if options does not loose any information with these changes.

[Mugen87]

Could you please also temporarily update the builds? I can then build a rawgit URL for WebXR testing.

[sunag]

I'm checking an issue with anti aliasing, I think it would be better to wait a bit for final testing.