This is just a renaming patch, motivated by a need for clarity before
addding more YUV formats. Comments and log messages are updated as well,
and one function in MacIOSurface is renamed.
There is one small change in TextureHost.cpp to satisfy clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D217883
Initially, the YCbCrUtils and yuv_convert APIs asserted success
internally. With recent changes, those assertions were removed. This
patch reintroduces those assertions on the caller's side instead, except
the `ConvertToRGBA` in ImageConversion.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D216191
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
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
YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
--HG--
extra : moz-landing-system : lando
In particular, it looks like this alignment is required by the Intel driver on
macOS if you want to avoid CPU copies.
It was already known that the efficiency gains from client storage only
materialize if you follow certain restrictions:
- The textures need to use the TEXTURE_RECTANGLE_ARB texture target.
- The textures' format, internalFormat and type need to be chosen from a small
list of supported configurations. Unsupported configurations will trigger
format conversions on the CPU.
- The GL_TEXTURE_STORAGE_HINT_APPLE may need to be set to shared or cached.
- glTextureRangeAPPLE may or may not make a difference.
It now appears that the stride alignment is another requirement:
When uploading textures which otherwise comply with the above requirements, the
Intel driver will still make copies using the CPU if the texture's stride is not
32-byte aligned. These CPU copies are reflected in a high CPU usage (as observed
in Activity Monitor) and they show up in profiles as time spent inside
_platform_memmove under glrUpdateTexture.
However, when uploading 32-byte stride aligned textures which comply with the
above requirements, this CPU usage goes away. There might still be hardware
copies behind the scenes, but they no longer take up CPU time.
Differential Revision: https://phabricator.services.mozilla.com/D25316
--HG--
extra : moz-landing-system : lando
In particular, it looks like this alignment is required by the Intel driver on
macOS if you want to avoid CPU copies.
It was already known that the efficiency gains from ClientStorage only
materialize if you follow certain restrictions:
- The textures need to use the TEXTURE_RECTANGLE_ARB texture target.
- The textures' format, internalFormat and type need to be chosen from a small
list of supported configurations. Unsupported configurations will trigger
format conversions on the CPU.
- The GL_TEXTURE_STORAGE_HINT_APPLE may need to be set to shared or cached.
- glTextureRangeAPPLE may or may not make a difference.
It now appears that the stride alignment is another requirement:
When uploading textures which otherwise comply with the above requirements, the
Intel driver will still make copies using the CPU if the texture's stride is not
32-byte aligned. These CPU copies are reflected in a high CPU usage (as observed
in Activity Monitor) and they show up in profiles as time spent inside
_platform_memmove under glrUpdateTexture.
However, when uploading 32-byte stride aligned textures which comply with the
above requirements, this CPU usage goes away. There might still be hardware
copies behind the scenes, but they no longer take up CPU time.
Differential Revision: https://phabricator.services.mozilla.com/D25316
--HG--
extra : moz-landing-system : lando
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch:
- Makes the following substitutions (plus necessary namespace qualifiers:
gfxImageFormat::ARGB32 --> SurfaceFormat::A8R8G8B8_UINT32
gfxImageFormat::RGB24 --> SurfaceFormat::X8R8G8B8_UINT32
gfxImageFormat::A8 --> SurfaceFormat::A8
gfxImageFormat::RGB16_565 --> SurfaceFormat::R5G6B5_UINT16
gfxImageFormat::Unknown --> SurfaceFormat::UNKNOWN
- Changes gfxImageFormat to be a typedef to gfx::SurfaceFormat. This will be
removed soon.
- Removes gfxCairoFormatToImageFormat() and gfxImageFormatToCairoFormat() and
replace calls to them with CairoFormatToGfxFormat() and
GfxFormatToCairoFormat().
- Removes ParamTraits<gfxImageFormat>.
- Add namespace qualifiers to SurfaceFormat instances where necessary.
--HG--
extra : rebase_source : f56e92b1593957a9e4e00171100bc7605816e696
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
This conversion was done with the script:
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl' | \
egrep -v 'cairo-win32-refptr.h|RefPtr.h|TestRefPtr.cpp' | \
xargs sed -i -e 's/mozilla::TemporaryRef</already_AddRefed</g' \
-e 's/TemporaryRef</already_AddRefed</g'
Manual fixups were performed in the following instances:
- We handled mfbt/RefPtr.h manually so as to not convert TemporaryRef itself
into already_AddRefed.
- The following files had explicit Move() calls added to make up for the lack
of a copy constructor on already_AddRefed:
dom/base/ImageEncoder.cpp
dom/media/MediaTaskQueue.{h,cpp}
dom/media/webaudio/PannerNode.cpp
- A redundant overload for MediaTaskQueue::Dispatch was deleted.
- A few manual fixups were required in mfbt/tests/TestRefPtr.cpp.
- Comments, using declarations, and forward declarations relating to
TemporaryRef in dom/canvas/ and gfx/layers/ were changed to refer to
already_AddRefed.
