Renderer: Return self in init().

[CodyJasonBennett]

Description

Resolves the renderer prototype instead of returning void for init().

This allows const renderer = await new WebGPURenderer().init() which is the cause of bugs otherwise.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	336.51 78.38	336.51 78.38	+0 B +0 B
WebGPU	519.2 144.16	519.21 144.16	+4 B +1 B
WebGPU Nodes	518.67 144.05	518.67 144.05	+4 B +0 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	465.51 112.23	465.51 112.23	+0 B +0 B
WebGPU	591.03 160.12	591.04 160.12	+4 B +1 B
WebGPU Nodes	546.34 149.59	546.35 149.59	+4 B +0 B

[WORMSS]

Hmm, just wondering the reason why init() is async in the first place? Legacy maybe?
I can see it returns a promise, but no actual awaiting happens inside init();

I could understand if it was

await this._initPromise;
return this;

but with it being (below) I fail to understand the reasoning behind it. Any insight would be grateful.

return this._initPromise;

[CodyJasonBennett]

Awaiting does happen. WebGPU API is asynchronous to request a device and adapter. The code you shared does the same except when an exception is encountered. In both cases, init() is deduplicated and can be awaited at all calling sites.

three.js/src/renderers/common/Renderer.js

Lines 730 to 747 in 008362f

	this._initPromise = new Promise( async ( resolve, reject ) => {
	let backend = this.backend;
	try {
	await backend.init( this );
	} catch ( error ) {
	if ( this._getFallback !== null ) {
	// try the fallback
	try {
	this.backend = backend = this._getFallback( error );
	await backend.init( this );

[WORMSS]

@CodyJasonBennett that awaits is within the promise resolver callback.
Different scope.