Worker support and non-extension usage

[rconde01]

First off, amazing tool! I had some things to resolve to use it:

1. I need it to work in a worker
2. I want it it worker programmatically instead of interactively.

I was able to get both to work but i'm not sure if/how you want to integrate it.

I changed to:

function __WebGPUReconstruct_requestAnimationFrame_callback(timestamp) {
    __WebGPUReconstruct_file.writeUint32(2);
    __WebGPUReconstruct_file.writeUint32(1);

    const globalScope =
        typeof window !== "undefined" ? window :
        typeof self !== "undefined" ? self :
        undefined;

    __webGPUReconstruct.animationFrameID = __webGPUReconstruct.requestAnimationFrame_original.call(globalScope, __WebGPUReconstruct_requestAnimationFrame_callback);
}

I have a maxFrames and numFrames. Because our requestAnimationFrame may run before our webgpu component is rendering, I count submits in __WebGPUReconstruct_GPUQueue_submit and only consider it a frame if it is non-zero for a call of requestAnimationFrame. Then when maxFrames is reached requestAnimationFrame calls finishCapture.

I removed document.addEventListener('__WebGPUReconstruct_saveCapture' add added this into finishCapture

        const blob = new Blob(__WebGPUReconstruct_file.arrays);
        postMessage({ type: 'wgpuCaptureData', data: blob });

Which is then hooked when the worker is created.

Ideally I'd like to see:

• The build script/package containing a "manual" file which can be imported (could be useful as an npm package too)
• Detect if it's in a worker or not and directly download or postmessage
• Export the WebgpuReconstruct class so it can be created programmatically, and with configuration parameters (e.g. maxFrames)

If I know your thoughts I can also try to make a PR.

[Chainsawkitten]

A target that can be invoked programmatically does sound useful, as does a mode where a pre-configured amount of frames are captured.

As for what should count as a frame, I think there are some edge cases that "a frame counts if there has been at least one submit" doesn't cover.

You may submit without actually doing any rendering/presenting, which would make the frame count when it shouldn't. Eg. during initialization, you write texture data to scratch buffers and submit a bunch of copyBufferToTexture, etc. to upload your assets. I would argue that should not count as a frame.

You could also present without submitting, which would make the frame not count when it should. But then we're getting into very non-sensible territory, which probably doesn't matter. (You could update the canvas texture directly with writeTexture or copyExternalImageToTexture and not submit.)

Counting a frame if it contained a getCurrentTexture might be enough to cover all those edge cases? You could call getCurrentTexture and then not actually render anything to that texture, but arguably that should still count as a frame?

[rconde01]

That wouldn’t handle compute passes I think? You could keep it simple and just record a frame if any webgpu calls at all are made.

[Chainsawkitten]

If the compute pass writes to the canvas texture, you'd have to call getCurrentTexture. If you're using compute (or render passes) to do offscreen work, it won't count as a frame (and shouldn't).

[rconde01]

I guess then you want frame-based and non-frame based capture options - for a compute only task you might not use requestAnimationFrame at all...although could be true for rendering too. For a frame-based capture I think your idea of getCurrentTexture is good.

[Chainsawkitten]

I've added a module version. When called on the main thread, it will initiate a download of the capture file when finishing. When called in a worker, it'll postMessage({ type: "WebGPUCapture", data: blob }), which the user will need to handle.