This is only used if the OffscreenCanvas has a webgl context, in which
case it forwards the tex type to WebGLContext::PresentFrontBuffer(). A
later patch in this series will make TexTypeForWebgl() return a
different value depending on whether the webgl context is in-process
or remote, which is something that cannot be known when the
OffscreenCanvas is initialized. This patch therefore removes the field
from OffscreenCanvas and makes WebGLContext::PresentFrontBuffer() call
TexTypeForWebgl() itself.
Differential Revision: https://phabricator.services.mozilla.com/D211289
This is only used if the OffscreenCanvas has a webgl context, in which
case it forwards the tex type to WebGLContext::PresentFrontBuffer(). A
later patch in this series will make TexTypeForWebgl() return a
different value depending on whether the webgl context is in-process
or remote, which is something that cannot be known when the
OffscreenCanvas is initialized. This patch therefore removes the field
from OffscreenCanvas and makes WebGLContext::PresentFrontBuffer() call
TexTypeForWebgl() itself.
Differential Revision: https://phabricator.services.mozilla.com/D211289
Adds ImageUsageType to ImageClient and ImageContainer to identify user of Image at WebRenderImageHost.
Some ImageContainers are used only for allocating Image. Only following types calls ImageContainer::SetCurrentImages().
- ImageUsageType::Canvas
- ImageUsageType::OffscreenCanvas
- ImageUsageType::VideoFrameContainer
Differential Revision: https://phabricator.services.mozilla.com/D211147
WorkerRunnable no longer keeps a raw pointer(mWorkerPrivate) for the associated WorkerPrivate in this patch.
Removing the WorkerRunnable::mWorkerPrivate needs to fix the following problems.
1. Thread assertions in WorkerRunnable::Dispatch()
To fix this problem, the associated WorkerPrivate is as a parameter and passed to WorkerRunnable::Dispatch() for the dispatching thread assertions. This associated WorkerPrivate is also propagated to PreDispatch() and PostDispatch() for the children classes of WorkerRunnable()
2. Get the associated WorkerPrivate in WorkerRunnable::Run() for environment setup(GlobabObject, JSContext setting for the runnable)
- For WorkerThreadRunnable
Since WorkerThreadRunnable is supposed to run on the worker thread, it does not need to keep a raw pointer to WorkerPrivate as its class member. GetCurrentThreadWorkerPrivate() should always get the correct WorkerPrivate for WorkerThreadRunnable.
- For WorkerParentThreadRunnable
WorkerParentRef is introduced to keep a RefPtr<WorkerPrivate> for WorkerParentThreadRunnable instead of using a raw pointer.
Checking the associated WorkerPrivate existence by WorkerParentRef at the beginning of WorkerParentThreadRunnable::Run(). If the Worker has already shut down, WorkerParentThreadRunnable cannot do anything with the associated WorkerPrivate, so WorkerParentThreadRunnable::Run() will return NS_OK directly but with a warning.
The associated WorkerPrivate is also passed into WorkerRun(), PreRun(), and PostRun(), so the majority of implementations of child classes of WorkerRunnable do not need to be changed.
If there are any cases in which the child classes of WorkerThreadRunnable/WorkerParentThreadRunnable want to keep the associated WorkerPrivate, they should use WorkerRefs instead of raw pointers.
Depends on D205679
Differential Revision: https://phabricator.services.mozilla.com/D207039
This is the first step in splitting the parent thread runnable out of WorkerRunnable.
To reuse the runnable dispatching codes in Worker, we still need a base class for runnable on the worker thread and the parent thread.
In this patch, we rename the original WorkerRunnable to WorkerThreadRunnable and make WorkerRunnable to be WorkerThreadRunnable's parent class.
In the second patch, we will create WorkerParentThreadRunnable and its sub-classes, split from WorkerThreadRunnable for runnable on the Worker's parent thread.
And in the third patch, we will re-structure the content of WorkerParentThreadRunnable to remove unnecessary members.
Differential Revision: https://phabricator.services.mozilla.com/D205178
It is disabled in this patch via the gfx.canvas.remote.allow-offscreen
pref. A follow up patch will enable this by default.
Differential Revision: https://phabricator.services.mozilla.com/D189532
This patch makes us block on the DOM worker thread in order to
synchronize properly with canvas 2D recordings when toDataURL and toBlob
are called on an HTMLCanvasElement object which also called
transferControlToOffscreen and transferred it to a DOM worker.
Differential Revision: https://phabricator.services.mozilla.com/D202286
It is disabled in this patch via the gfx.canvas.remote.allow-offscreen
pref. A follow up patch will enable this by default.
Differential Revision: https://phabricator.services.mozilla.com/D189532
When we recreate the display list, e.g. after tabbing away, we need to
ensure we flush the OffscreenCanvas because our resource handles will be
invalidated. This requires the OffscreenCanvasDisplayHelper to know
which OffscreenCanvas it belongs to, and a worker reference if necessary
to do the dispatching for the flush. Otherwise we would require the
canvas to be updated manually by the web application to repaint.
Differential Revision: https://phabricator.services.mozilla.com/D184324
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
When creating an ImageContainer for OffscreenCanvas, we were holding a
lock for the OffscreenCanvas. The constructor for an ImageContainer may
do a sync call back to the ImageBridgeChild thread in the content
process, unlike its typical async notifications for other operations
once it has been created.
There is no need to hold the OffscreenCanvas lock while we create the
ImageContainer itself, so it is best to not to avoid any potential
deadlocks.
Similarly, we should avoid holding the lock when performing the
readback, if any, for the canvas during the display commit.
Differential Revision: https://phabricator.services.mozilla.com/D154556
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
When we want to present with an OffscreenCanvas using a Canvas2D context
that is backed by a WebGL context via DrawTargetWebgl, we need to ensure
that any readbacks are done on the owning thread. As such, we need to
map in the surfaces before passing them to ImageBridge.
There are likely optimizations we can do here that don't involve
readback if the canvas doesn't fallback to software but for now this
patch focuses on making it work.
Differential Revision: https://phabricator.services.mozilla.com/D147297
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
On the path that we need to read the pixels from the canvas for display
purposes, instead of using a platform buffer handle, we need to take
into account the need to y-flip for WebGL. This patch ensures that we do
so.
Differential Revision: https://phabricator.services.mozilla.com/D136504
On the path that we need to read the pixels from the canvas for display
purposes, instead of using a platform buffer handle, we need to take
into account the need to y-flip for WebGL. This patch ensures that we do
so.
Differential Revision: https://phabricator.services.mozilla.com/D136504
On the path that we need to read the pixels from the canvas for display
purposes, instead of using a platform buffer handle, we need to take
into account the need to y-flip for WebGL. This patch ensures that we do
so.
Differential Revision: https://phabricator.services.mozilla.com/D136504
This patch ensures that our invalidation is more consistent and less
frequent. It no longer queues an invalidation for each draw call. It now
combines the parameter update (e.g. width, height, opacity) with an
invalidation to ensure the contents of the canvas are consistent with
the advertised properties. It also ensures that if an explicit commit
occurs, any pending commits are cancelled.
Differential Revision: https://phabricator.services.mozilla.com/D134655
This patch ensures that when we call TransferFromImageBitmap, it
actually gets the correct result and resets the context to all black,
instead of just crashing. We now also clear the ImageContainer properly
instead of adding a null image if none is provided.
Differential Revision: https://phabricator.services.mozilla.com/D133806
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
This helper class manages the necessary state to facilitate the display
pipeline for an OffscreenCanvas created through HTMLCanvasElement's
transferControlToOffscreen.
Differential Revision: https://phabricator.services.mozilla.com/D130786
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
