WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
Similar to PWebGL, we want PCanvasManager to manage the PWebGPU
protocol. This will allow us to reuse the machinery that works for both
the main thread, and arbitrary worker threads to create PWebGPU
protocols.
For now, the only owner is still the main thread, so it should work very
similarly as to how it does with PCompositorBridge.
This patch also introduces some quality of life changes, such as making
the protocol ref-counted, and avoiding respinning the wheel for
CanSend() for IPDL actors.
Differential Revision: https://phabricator.services.mozilla.com/D134097
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
Right now, if we wanted to get a snapshot of an OffscreenCanvas context
on a worker thread from the main thread, we would need to block the main
thread on the worker thread, and from the worker thread, issue a sync
IPC call get the front buffer snapshot.
This patch adds an alternative which allows the main thread to go
directly to the canvas owning thread in the compositor process to get
the snapshot, thereby bypassing the worker thread in content process
entirely. All it needs as the unique ID of the CanvasManagerChild
instance, and the protocol ID of the WebGLChild instance.
This will be used for Firefox screenshots, New Tab tiles, and printing.
Differential Revision: https://phabricator.services.mozilla.com/D130785
This patch adds the necessary IPDL plumbing to allow us to create WebGL
instances off the main thread in the content process, and to execute
them on the Renderer thread in the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D127839
sotaro
Andrew Osmond
Csoregi Natalia
Molnar Sandor