This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
This patch adds plumbing to allow sharing ExternalImageId via
SurfaceDescriptor. This will be used in a future patch by WebGL and
WebGPU to avoid extra copies. It also refactors how CanvasTranslator
gets a SourceSurfaceSharedDataWrapper pointer by ensuring the surfaces
are kept alive long enough even if the CompositorManagerParent actor is
destroyed before CanvasManagerParent and its children. Now we keep the
surfaces around until all of these dependent objects have been freed.
Differential Revision: https://phabricator.services.mozilla.com/D196067
This patch adds plumbing to allow sharing ExternalImageId via
SurfaceDescriptor. This will be used in a future patch by WebGL and
WebGPU to avoid extra copies. It also refactors how CanvasTranslator
gets a SourceSurfaceSharedDataWrapper pointer by ensuring the surfaces
are kept alive long enough even if the CompositorManagerParent actor is
destroyed before CanvasManagerParent and its children. Now we keep the
surfaces around until all of these dependent objects have been freed.
Differential Revision: https://phabricator.services.mozilla.com/D196067
The process IDs can be recycled by the platform, but we guarantee that
each new content process gets a new namespace ID.
Differential Revision: https://phabricator.services.mozilla.com/D195994
This patch switches us from an arbitrary 50ms timeout to an IPDL based
method to force the event/IPDL queue to be flushed. We also no longer
block if we are already on the Compositor thread, because if there are
events pending to add the required surface, they will be stuck waiting
behind us.
Differential Revision: https://phabricator.services.mozilla.com/D195965
This patch reworks CompositorManagerParent to be able to:
1) Get the owning IPDL actor for a given namespace
2) Rework shutdown to be more consistent
3) Block until either the relevant shared surface is added or the actor
is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D195964
The change is a preparation for Bug 1865984, Bug 1863474 and Bug 1861605.
FenceD3D11 is going to be used by Bug 1865984 and Bug 1863474. And FileHandleWrapper is going to be added for wrapping shared handle of ID3D11Fence and ID3D11Texture2D(Bug 1861605).
For now, FenceInfo is expected to be delivered just during creating TextureHost. It works for WebGL and WebGPU.
Differential Revision: https://phabricator.services.mozilla.com/D194612
This replaces the use of a single large ring buffer.
The buffers are still processed in parallel and are recycled to reduce
allocation. Events that do not fit in the default sized buffer have a separate
buffer created to fit them. These large buffers are not recycled.
Separate shared memory is used for readback, with a single shmem cached for this
purpose. Generally only one cached shmem should be required, because the
operations that usually readback the data do it straight away.
Differential Revision: https://phabricator.services.mozilla.com/D193207
The change is a preparation for Bug 1865984, Bug 1863474 and Bug 1861605.
FenceD3D11 is going to be used by Bug 1865984 and Bug 1863474. And FileHandleWrapper is going to be added for wrapping shared handle of ID3D11Fence and ID3D11Texture2D(Bug 1861605).
For now, FenceInfo is expected to be delivered just during creating TextureHost. It works for WebGL and WebGPU.
Differential Revision: https://phabricator.services.mozilla.com/D194612
This replaces the use of a single large ring buffer.
The buffers are still processed in parallel and are recycled to reduce
allocation. Events that do not fit in the default sized buffer have a separate
buffer created to fit them. These large buffers are not recycled.
Separate shared memory is used for readback, with a single shmem cached for this
purpose. Generally only one cached shmem should be required, because the
operations that usually readback the data do it straight away.
Differential Revision: https://phabricator.services.mozilla.com/D193207
This patch makes it so that WebGL that runs in the compositor process
can take advantage of the fact that GPUVideoImage should have an already
created TextureHost between the compositor process and the producing
utility process. For software decoders, this will allow us to avoid a
copy into a shmem from the utility process, and another copy into a
shmem to the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D195559
This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
This adds some separation between MediaInfo.h and WebRender, avoiding the
include of MediaInfo.h in WebRenderMessages.h.
Depends on D193161
Differential Revision: https://phabricator.services.mozilla.com/D193162
This replaces the use of a single large ring buffer.
The buffers are still processed in parallel and are recycled to reduce
allocation. Events that do not fit in the default sized buffer have a separate
buffer created to fit them. These large buffers are not recycled.
Separate shared memory is used for readback, with a single shmem cached for this
purpose. Generally only one cached shmem should be required, because the
operations that usually readback the data do it straight away.
Differential Revision: https://phabricator.services.mozilla.com/D193207
With the change, yuv BufferTexture is uploaded to D3D11 NV12 texture also if webrender supports D3D11 and NV12.
Calling GpuProcessD3D11TextureMap::GetTexture() is changed from RenderDXGITextureHost::EnsureD3D11Texture2DWithGL() to RenderDXGITextureHost::EnsureD3D11Texture2D(), since the EnsureD3D11Texture2DWithGL() is not called with WebRender(Software D3D11).
Differential Revision: https://phabricator.services.mozilla.com/D194171
The task queue makes NS_DECL_OWNINGEVENTTARGET confusing for single
threaded uses, when the canvas expects it can just dispatch to the
CanvasRenderThread directly.
Differential Revision: https://phabricator.services.mozilla.com/D191697
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
In the case where the LayerTreeState for the input content LayersID
was found, but its mParent was null for some reason, the function
was incorrectly returning the content LayerTreeState.
Instead, in such a case, where the root LayerTreeState cannot be
looked up, the function should return null.
Differential Revision: https://phabricator.services.mozilla.com/D190143
TextureHostWrapperD3D11 is created in WebRenderImageHost::GetAsTextureHostForComposite() if possible. TextureHostWrapperD3D11 usage could reduce ID3D11Texture2D usage compared to Bug 1753373. And its usage adds video overlay support of DRM protected video.
The TextureHostWrapperD3D11 wraps YUV BufferTextureHost and instead exposes DXGITextureHostD3D11 to WebRender. The DXGITextureHostD3D11 holds GpuProcessTextureId of ID3D11Texture2D. The ID3D11Texture2D is allocated and data updated in TextureUpdate thread.
If the ID3D11Texture2D is not ready, a wait happened by calling GpuProcessD3D11TextureMap::WaitTextureReady() in Render thread.
Differential Revision: https://phabricator.services.mozilla.com/D189882
TextureHostWrapperD3D11 is created in WebRenderImageHost::GetAsTextureHostForComposite() if possible. TextureHostWrapperD3D11 usage could reduce ID3D11Texture2D usage compared to Bug 1753373. And its usage adds video overlay support of DRM protected video.
The TextureHostWrapperD3D11 wraps YUV BufferTextureHost and instead exposes DXGITextureHostD3D11 to WebRender. The DXGITextureHostD3D11 holds GpuProcessTextureId of ID3D11Texture2D. The ID3D11Texture2D is allocated and data updated in TextureUpdate thread.
If the ID3D11Texture2D is not ready, a wait happened by calling GpuProcessD3D11TextureMap::WaitTextureReady() in Render thread.
Differential Revision: https://phabricator.services.mozilla.com/D189882
This patch makes the PCanvasManager protocol manage the PCanvas
protocol. This allows us to share a top level protocol and message
channel, as well as use the same thread as we need for WebGL. This will
allow future patches to do record/replay for WebGL, particularly for
configurations that do not support threadsafe GL.
Differential Revision: https://phabricator.services.mozilla.com/D187721
Prior to this patch, CanvasRenderThread represents the concrete thread
we would spawn if gfxVars::UseCanvasRenderThread() returned true.
CanvasManagerParent was responsible for checking our state and deciding
between using the Compositor, Renderer and CanvasRender threads.
This patch makes the CanvasRenderThread class represent a virtual
thread. It will spawn a CanvasRender thread if necessary. Other classes
may use the abstraction to run on the correct thread without having to
duplicate the selection logic.
Differential Revision: https://phabricator.services.mozilla.com/D187719
This patch makes the remote canvas enabled state global. If we failed to
create a context, then it cannot recover, so we should never try again.
In the event of stream errors, it is likely due to virtual memory
shortages.
Differential Revision: https://phabricator.services.mozilla.com/D187718
We could avoid adding the snap area into ScrollSnapRange if we added two
additional flags representing whether the snap area size is larger than the
snapport into SnapTarget and drop ScrollSnapRange entirely. But it would
be inefficient in most cases since such larger snap area cases are uncommon, we
will not find any larger snap areas while iterating over
ScrollSnapInfo::mSnapTargets.
Differential Revision: https://phabricator.services.mozilla.com/D184340
This seems to work, and turns out I need to fix this before bug 1847584,
because the epoch handling breaks with those patches in the case
customize mode sets display: none on browser elements.
Instead of dealing with epochs, just always report the last "has layers"
state to BrowserParent. This is both simpler and more reliable (there
were a couple hacks in WebRenderBridgeParent to make sure we notified
even though a transaction failed).
AsyncTabSwitcher pretty much already deals with this correctly because
it already needs to deal with browsers that already have layers, we only
had to loosen some assertions for potentially previous messages which
are fine.
Differential Revision: https://phabricator.services.mozilla.com/D187203
SyncObjectD3D11Host::Synchronize() could spend time when GPU is busy.
The Synchronize() call is not necessary when all RenderDXGITextureHosts have GpuProcessTextureId or KeyedMutex.
Differential Revision: https://phabricator.services.mozilla.com/D185619
This patch sends the information of border-radius to the compositor as
well, so we can use it if offset-path uses coord-box only.
Note:
We repaint the frame if border-radius property gets changed, and rebuild
the display item. In this case, we resend the transaction of compositor
animation as well. Therefore, we don't have to block the compositor animations
if they depends on border-radius (i.e. use coord-box only).
We may need a better way to check what should we pass to the compositor,
for motion path, in Bug 1838977.
Differential Revision: https://phabricator.services.mozilla.com/D179631
I'd like to reuse the data in RayReferenceData for all basic shapes,
so unpack RayReferenceData and drop this struct.
Also, use `nsPoint` for the current position and use `nsRect` for coord-box
because we use these types (i.e. app units) in ShapeUtils.
Besides, remove the usage of Maybe from nsStyleTransformMatrix.h and
just accept the pointer of ResolvedMotionPathData to avoid including
the entire header.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181008
The patch for bug 1830753 stops these for CompositorBridgeChild's that are recorded as paused. That fixes the problem for animated images that are in the top level chrome document, but doesn't fix the problem for images in a content tab because the CompositorBridgeChild in the content process is not aware the compositor is paused. So instead we check the throttled state of the refresh driver. Since we only have access to the layer manager at this point it is a bit of a trip to get the refresh driver but very possible.
Differential Revision: https://phabricator.services.mozilla.com/D181353
We send offset-position to the compositor, just like other similar
properties, e.g. offset-rotate, offset-anchor. This includes extracting
this animation value, doing serialization and sending it via IPC.
So now we can run the animation of ray() on the compositor properly.
Differential Revision: https://phabricator.services.mozilla.com/D179862
DeviceManagerDx::Get()->CanUseNV12() needs D3D11Device in current process. The SupportsD3D11NV12() could be used without D3D11Device in current process.
It is preparation for Bug 1834039.
Differential Revision: https://phabricator.services.mozilla.com/D179532
This patch changes KillHard() such that the IPC channel is immediately
shut down with an error after a KillHard() is performed. This is done by
fixing the previously-broken CLOSE_CHANNEL_WITH_ERROR support in
ShutDownProcess, and calling that method after KillHard().
This ensures that after the process has been killed, no further messages
will be delivered and processed, even if they were sent before the
process was killed.
In addition, the assertions and KillHard calls which are disabled for
fuzzing were changed to also shut down the channel, making fuzzing IPC
errors cause the connection to be terminated like it is in production
for these actors.
This change does not impact actors which ignore processing errors.
Differential Revision: https://phabricator.services.mozilla.com/D178383
This patch changes KillHard() such that the IPC channel is immediately
shut down with an error after a KillHard() is performed. This is done by
fixing the previously-broken CLOSE_CHANNEL_WITH_ERROR support in
ShutDownProcess, and calling that method after KillHard().
This ensures that after the process has been killed, no further messages
will be delivered and processed, even if they were sent before the
process was killed.
In addition, the assertions and KillHard calls which are disabled for
fuzzing were changed to also shut down the channel, making fuzzing IPC
errors cause the connection to be terminated like it is in production
for these actors.
This change does not impact actors which ignore processing errors.
Differential Revision: https://phabricator.services.mozilla.com/D178383
We see a fair number of crashes caused by failing to create an EGL
surface when resuming the compositor on Android. We believe that in
the vast majority of these cases the Surface we have been provided by
the OS is in an invalid state, and therefore we will never succeed in
creating an EGL surface from it.
Currently when creating the EGL surface fails we raise a NEW_SURFACE
webrender error. This causes us to fall back through webrender
configurations, reinitialize the compositors, and eventually crash
when we are still unable to resume. None of this will help when the
Android Surface we have been provided is in this invalid state.
This patch therefore avoids raising the webrender error initially, and
instead gives the widget an opportunity to handle the failure. The
widget uses the new GeckoView API added in the previous patch in this
series to request a new Surface from the application. This will cause
another resume event immediately afterwards with a new - and hopefully
valid - surface, allowing the EGL surface to be created and the
compositor to be successfully resumed. If we are still unable to
create an EGL surface after this, then we will raise the webrender
error as before, likely eventually resulting in a crash.
Differential Revision: https://phabricator.services.mozilla.com/D176721
We see a fair number of crashes caused by failing to create an EGL
surface when resuming the compositor on Android. We believe that in
the vast majority of these cases the Surface we have been provided by
the OS is in an invalid state, and therefore we will never succeed in
creating an EGL surface from it.
Currently when creating the EGL surface fails we raise a NEW_SURFACE
webrender error. This causes us to fall back through webrender
configurations, reinitialize the compositors, and eventually crash
when we are still unable to resume. None of this will help when the
Android Surface we have been provided is in this invalid state.
This patch therefore avoids raising the webrender error initially, and
instead gives the widget an opportunity to handle the failure. The
widget uses the new GeckoView API added in the previous patch in this
series to request a new Surface from the application. This will cause
another resume event immediately afterwards with a new - and hopefully
valid - surface, allowing the EGL surface to be created and the
compositor to be successfully resumed. If we are still unable to
create an EGL surface after this, then we will raise the webrender
error as before, likely eventually resulting in a crash.
Differential Revision: https://phabricator.services.mozilla.com/D176721
Non-scrollable elements are immediately activated on touch-start, so it
is not necessary to delay firing the synthesized mouse and click events.
Differential Revision: https://phabricator.services.mozilla.com/D169727
In current m-c, async RemoteTexture wait at RenderThread stops window update when the wait is too long. If async RemoteTexture is handled by WebRenderAPI, window could be updated during long async RemoteTexture wait.
async RemoteTexture wait of root WebRenderBridgeParent are disabled to simplify WebRenderAPI's wait handling.
offscreen canvas case is handled by WebRenderImageHost by Bug 1827578.
Differential Revision: https://phabricator.services.mozilla.com/D175590
It should be OK to wait remote texture ready of offscreen canvas at WebRenderImageHost. Offscreen canvas uses ImageBridge. And ImageBridge works asynchronously.
WebRenderImageHost::UseRemoteTexture() is split to WebRenderImageHost::PushPendingRemoteTexture() and WebRenderImageHost::UseRemoteTexture(). It is for handling RemoteTexture ready callback in WebRenderImageHost.
Differential Revision: https://phabricator.services.mozilla.com/D175226
The in-process compositor assumes that no compositor window was present.
This is not guaranteed to be true if, for example, the preference
`gfx.webrender.flip-sequential` is set.
Make the in-process compositor more closely mirror the out-of-process
compositor. (At present this effectively just means calling ::SetParent
on the compositor window.)
Differential Revision: https://phabricator.services.mozilla.com/D172733
The in-process compositor assumes that no compositor window was present.
This is not guaranteed to be true if, for example, the preference
`gfx.webrender.flip-sequential` is set.
Make the in-process compositor more closely mirror the out-of-process
compositor. (At present this effectively just means calling ::SetParent
on the compositor window.)
Differential Revision: https://phabricator.services.mozilla.com/D172733
This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
