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
Before Bug 1713276 fix, BufferTextureData of ffmpeg decoded video was recycled.
ShmemTextureData::CropYCbCrPlanes() changed BufferDescriptor. And it blocks the BufferTextureData to be recycled. The BufferDescriptor needs to be restored to original value before recycling.
Differential Revision: https://phabricator.services.mozilla.com/D137829
This is no longer necessary as the Quantum DOM project is no longer
happening, and removing support simplifies various components inside of
IPDL.
As some code used the support to get a `nsISerialEventTarget` for an
actor's worker thread, that method was replaced with a method which
instead pulls the nsISerialEventTarget from the MessageChannel and
should work on all actors.
Differential Revision: https://phabricator.services.mozilla.com/D135411
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This implements a customized buffer allocator for ffmpeg decoder to allow it to store decoded data on shmem, so decoded data can be shared with the compositor process without doing extra copy.
As ffmpeg decoder needs a special alignment which will be larger than the actual image, we would need to crop the planes by telling plane descriptor correct place size in order to display image correctly.
Otherwise, showing a larger image causes visible incorrect border on the right and bottom of the actual image.
This will help improve the performance of software decoding while using ffmpeg and ffvpx, which is about h264 and vpx on Linux, vpx on Windows and MacOS.
Inaddition, Here is a result [1] showing that how much improvement using shmem can help.
[1] https://bit.ly/3dy4rya
Differential Revision: https://phabricator.services.mozilla.com/D130220
This removes some of the changes that meant we started using
mPermanentBackBuffer straight away and we now wait until we actually try and
lock a read locked texture.
While this might still give a very small risk of contention, it gives
improvements in the following two circumstances.
* If a canvas texture is never forwarded and never read locked, it means we will
only use one texture with no copies.
* If a canvas is always fully overwritten at the start of the frame (and a
snapshot is not taken between frames), then we avoid a copy on each frame.
This also adds back in code so that on an OPEN_READ_WRITE lock we cache the data
surface if required, because that texture will be the new front buffer and we
won't be using mPermanentBackBuffer at that point.
Depends on D132601
Differential Revision: https://phabricator.services.mozilla.com/D132602
We accidently duplicate the file descriptor when serializing because we
hit a constructor for ipc::FileDescriptor which duplicates the handle
instead of just taking it. This means we are supposed to close it
explicitly but we've already forgotten about it. We should just do a
move instead to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D131569
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
Randell Jesup
Noemi Erli
Butkovits Atila
Lee Salzman
smolnar
sotaro
Nika Layzell
alwu
Cristian Tuns
Norisz Fay
Narcis Beleuzu
Bob Owen
Alexandru Michis
Andrew Osmond
Tetsuharu Ohzeki
Matt Woodrow
Iulian Moraru