1909257 - WebGPU DOM atomicity: presentation is not in sync with the DOM transaction

Status: RESOLVED FIXED

(Core :: Graphics: WebGPU, defect)

Description

[Nicolas Silva [:nical]]

I think that another bug already exists for this but I can't find it at the moment, so filing this one.

Links

Terms to look for in the spec:

• updating the rendering of a WebGPU canvas
• Replace the drawing buffer

https://gpuweb.github.io/gpuweb/#canvas-hooks

What Gecko does

(Copied from some notes I took a year ago:)

• CommandBuffer::Commit loops over the canvas context that are affected and call MaybeQueueSwapChainPresent()
  • MaybeQueueSwapChainPresent dispatches to the current event loop a task to present
    • !! I think that this happens too late, it happens outside of the transaction.
• SwapChainPresent
  • WebGPUChild::SwapChainPresent sends the SwapChainPresent ipc message.
    • WebGPUParent::RecvSwapChainPresent

What I think should happen

• in some JS callback C, if canvas canvas.getCurrentTexture() is called enqueue a task to expire the texture at the end of C.
  • This is so that we cannot use the canvas's current texture outside of the scope of C
• if in C work is submitted affecting a canvas, add the canvas to C's transaction
• when the transaction is applied in the compositor process, flip the canvas's texture.

Comment 1

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #0)

What Gecko does

(Copied from some notes I took a year ago:)

• CommandBuffer::Commit loops over the canvas context that are affected and call MaybeQueueSwapChainPresent()
  • MaybeQueueSwapChainPresent dispatches to the current event loop a task to present
    • !! I think that this happens too late, it happens outside of the transaction.
• SwapChainPresent
  • WebGPUChild::SwapChainPresent sends the SwapChainPresent ipc message.
    • WebGPUParent::RecvSwapChainPresent

"What Gecko does" part is very different in current gecko. Then WebGPU of main thread canvas rendering is sync to dom.

• Queue::Submit() calls CommandBuffer::Commit().

  • CommandBuffer::Commit() loops over the canvas context that are affected and call MaybeQueueSwapChainPresent().
  • MaybeQueueSwapChainPresent does not dispatch to the current event loop a task to present. It notifies, presenting texture by calling WebGPUChild::NotifyWaitForSubmit() and calls CanvasContext::InvalidateCanvasContent() for triggering WebRenderBridge transaction.
  • Queue::Submit() finally calls WebGPUChild::QueueSubmit() to forward sumitted CommandBufferIds and TextureIds to WebGPUParent.
  • WebGPUParent::RecvQueueSubmit() submits the CommandBufferIds, The TextureIds are used to store SubmissionIndex for fence handling.

• During the WebRenderBridge transaction, ShareableCanvasRenderer::UpdateCompositableClient() is called. CanvasContext::GetFrontBuffer() calls CanvasContext::SwapChainPresent(). It requests WebGPUParent to present remote texture. And WebGPUParent::RecvSwapChainPresent() post remote texture to RemoteTextureMap.

• CanvasContext::SwapChainPresent() calls Texture::Destroy() if the Texture is used for swap chain

• ShareableCanvasRenderer::UpdateCompositableClient() also calls WebRenderBridgeChild::UseRemoteTexture() to forward remote texture id in WebRenderBridge transaction.

• In host side, WebRenderImageHost::UseRemoteTexture() handles remote texture.

Remote texture of main thread canvas is presented in WebRender in sync with WebRenderBridge transaction (DOM transaction).

Comment 2

[Nicolas Silva [:nical]]

Great! thanks for the details, Sotaro. Closing this, then.