We need them for SVG primitives.
This patch adds a bit of plumbing to disable snapping some of the primitives and forcing the antialiasing shader feature where needed, and uses it for SVG solid rectangles and images.
Differential Revision: https://phabricator.services.mozilla.com/D139024
This makes WR properly handle mPicSize when RenderBufferTextureHost is used.
The main change is that we need to take care to pass in display().Size() from
the descriptor, and then further use that to carefully limit the size of the
CbCr texture, as it doesn't necessarily maintain an appropriate half-sized
scale with respect to the Y texture if it is padded.
Given that mPicSize should now actually work, we should no longer need any
of the previous mCroppedSize mechanisms that were added to work around this,
and so they are removed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D139267
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
Removes async (windowless) NPAPI plugin rendering methods used to render a plugin to an offscreen surface in the GPU process. None of this code is used since we have removed all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107152
Removes async (windowless) NPAPI plugin rendering methods used to render a plugin to an offscreen surface in the GPU process. None of this code is used since we have removed all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107152
Whether or not we use a native texture or something else is affected by our
backend and the size of the texture. This patch adds a new function to
centralize that logic in TextureHost, and applies it in callsites that were
checking the backend to determine an image type.
Differential Revision: https://phabricator.services.mozilla.com/D106568
Whether or not we use a native texture or something else is affected by our
backend and the size of the texture. This patch adds a new function to
centralize that logic in TextureHost, and applies it in callsites that were
checking the backend to determine an image type.
Differential Revision: https://phabricator.services.mozilla.com/D106568
Whether or not we use a native texture or something else is affected by our
backend and the size of the texture. This patch adds a new function to
centralize that logic in TextureHost, and applies it in callsites that were
checking the backend to determine an image type.
Differential Revision: https://phabricator.services.mozilla.com/D106568
We shouldn't be trying to create the wrapping source surface here here GetBuffer
fails - in this case because of a shmem allocation failure. There are already ample
log notes about the failure so just bailing out and not spewing more warning spam
here seems like the right thing to do. Downwind code already deals with mFirstSource
not being set, so we should be safe.
Differential Revision: https://phabricator.services.mozilla.com/D100739
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
The patch ended up more complicated than I anticipated due to a lot of places in webrender assuming texture arrays unless specified otherwise.
The patch also merges TextureTarget into ImageBufferKind, and removes the realloc code path ing the texture cache (which is supposed to be dead code since because of performance issues on windows+intel).
Differential Revision: https://phabricator.services.mozilla.com/D95562
The code always assumed that the size of the image with the Y plane dimensions, which, while often the case, isn't correct.
We remove the assertions that the display offset was always (0,0) and properly carry the actual data over IPC.
Remoting the theora decoder and enabling fast video copy exposed several other related issues in the various D3D11 image types.
Various WPT uses theora YUV44 images (because we do not support YUV444 H264 ones). Those images are made of 32 pixels planes with a display size set to 20 pixels. Prior P1D the backend image was a ShareYCbCrPlanar image which correctly handled the size settings.
Like the image serializer, the various D3D11 images always assumed that the Y plane size was the image size.
This however expose existing issues where the offset position of the display is completely ignored for some image type. See bug 1669054
All those problems explain why sometimes we displayed more pixels than we should have.
Depends on D91914
Differential Revision: https://phabricator.services.mozilla.com/D92233
This creates a unique (per content process) ID for each TextureRecorded. This is
then used as a lookup in the GPU process for the real texture.
Previously the pointer for the TextureRecorded's DrawTarget was used, but as the
translated texture is used in multiple threads in the GPU process, pointer reuse
could mean that the handle for an old texture could be picked up by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D93501
When using the native RenderCompositor+SWGL on MacOS, we don't support passing buffer textures directly to the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D93179
It is possible that when the ImageBridge received a new image to composite, that image hasn't yet been registered via the VideoBridge.
This can happen if the decoding occurs in the different process than the content process. Even though the VideoBridge registration message was sent earlier by the RDD process, the ImageBridge message sent by the content process reached the compositor earlier.
So we only attempt to use the TextureHost if it is valid and the underlying image has been properly registered. Otherwise we will continue to use the previous image.
Some methods are modified to lazily perform their action only once the image has been registered from the PVideoBridge.
Differential Revision: https://phabricator.services.mozilla.com/D92234
