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
Building with ac_add_options --disable-unified-build on macOS hits the following warnings-as-errors:
gfx/2d/FilterNodeSoftware.cpp:1022:10 [-Wunreachable-code-return] 'return' will never be executed
gfx/2d/DrawTargetCairo.cpp:1957:20 [-Wunused-function] unused function 'GfxMatrixToPixmanTransform'
gfx/thebes/gfxHarfBuzzShaper.cpp:1008:23: warning: unused variable 'sDageshForms' [-Wunused-const-variable]
gfx/thebes/gfxMacPlatformFontList.mm:818:31 [-Wunused-const-variable] unused variable 'kLangFontsDirs'
gfx/tests/gtest/TestSwizzle.cpp:221:21 [-Wunreachable-code] code will never be executed
gfx/tests/gtest/TestTreeTraversal.cpp:16:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_TREE_DEPTH'
gfx/tests/gtest/TestTreeTraversal.cpp:17:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_TREE_CHILD_COUNT'
gfx/tests/gtest/TestTreeTraversal.cpp:18:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_TREE_LEAF_COUNT'
gfx/tests/gtest/TestTreeTraversal.cpp:19:11 [-Wunused-const-variable] unused variable 'PERFORMANCE_REGION_XWRAP'
gfx/vr/VRDisplayPresentation.cpp:151:3 [-Wunreachable-code-loop-increment] loop will run at most once (loop increment never executed)
gfx/ycbcr/scale_yuv_argb.cpp:61:21 [-Wunused-function] unused function 'Abs'
Differential Revision: https://phabricator.services.mozilla.com/D126592
Fix for ConvertYCbCrToRGB32 to use full range convert functions for full range data.
Some changes of libyuv are backported from newer version, to get support of full range BT.709 and BT.2020 colorspace.
Differential Revision: https://phabricator.services.mozilla.com/D105937
This patch implements the transparency support for AVIF image files.
To convert the decoded YCbCr and Alpha data to RGBA, a function named
`ConvertYCbCrAToARGB` is created to do this job in the following
procedure:
ConvertYCbCrAToARGB:
If the layout of the YCbCr is I420
Calling libyuv::I420AlphaToARGB
Else
Fill RGB data converted by ConvertYCbCrToRGB in ARGB buffer first
Insert the alpha data to ARGB buffer
On the other hand, this patch refactors the nsAVIFDecoder a bit to make
the lifetime of the parsed data and decoded image data clearer. They
won't live longer than Parser object and {Dav1d, AOM}Decoder object.
This should improve the code readability.
This patch also adds a transparent image test (TransparentAVIFTestCase)
to check the FLAG_HAS_TRANSPARENCY is posted or not. The test image file
`transparent.avif` is from Bug 1654462.
Differential Revision: https://phabricator.services.mozilla.com/D98951
Also, add `clang-format off` directives to files which are ignored by
.clang-format-ignore so that the editor isn't trying to reformat them
Differential Revision: https://phabricator.services.mozilla.com/D76217
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
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
This is used by the basic compositor.
Re-using existing logic, however as with other conversion it only handles limited 8 bits ranges (16-235) and to make things worse is rounded aggressively as the focus is on speed.
Differential Revision: https://phabricator.services.mozilla.com/D25345
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
While the current code compiles fine with the file as it is, with LTO
enabled, some functions end up inlined into their callers and their
callers, recursively, and the compiler doesn't know some of the
registers have been modified by the assembly, leading to bad decisions,
and bad behavior at runtime. The same problem would likely happen if we
were using UNIFIED_SOURCES in the directory.
Differential Revision: https://phabricator.services.mozilla.com/D4200
ycbcr is dead upstream, and has been for almost as long as the code in
the gecko tree hasn't been updated. Let's not pretend that we can
actually run the update script and that having the patches separated
matters, because there's no upstream to apply those patches to anymore.
Update README accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D4198
While the current code compiles fine with the file as it is, with LTO
enabled, some functions end up inlined into their callers and their
callers, recursively, and the compiler doesn't know some of the
registers have been modified by the assembly, leading to bad decisions,
and bad behavior at runtime. The same problem would likely happen if we
were using UNIFIED_SOURCES in the directory.
Differential Revision: https://phabricator.services.mozilla.com/D4200
ycbcr is dead upstream, and has been for almost as long as the code in
the gecko tree hasn't been updated. Let's not pretend that we can
actually run the update script and that having the patches separated
matters, because there's no upstream to apply those patches to anymore.
Update README accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D4198
The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.