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.
For now, convert 10/12 bits YUV image to 8 bits. Native support will be tracked in bug 1379948
MozReview-Commit-ID: LOr9X5xxKY7
--HG--
extra : rebase_source : 279e00832543501616af0a4a5958917b72533a4c
For now, convert 10/12 bits YUV image to 8 bits. Native support will be tracked in bug 1379948
MozReview-Commit-ID: LOr9X5xxKY7
--HG--
extra : rebase_source : 90b39f46cbc9d5233965e3693c620466557eb8e7
ycvcr_to_rgb565 uses inline assember for arm neon. Since it is different for aarch64's assembler, we should define HAVE_YCBCR_TO_RGB565 on arm32 only.
MozReview-Commit-ID: 4c2n1luvVvC
--HG--
extra : rebase_source : 8ae3f9deb6d0f4e3ab6036b7ce7ec57e0c7e1b57
Jon Bauman
Sandor Molnar
Andi-Bogdan Postelnicu
Yuan Tong
Chun-Min Chang
Thomas Daede
Jeff Walden
A. Wilcox
Nicholas Nethercote
Jean-Yves Avenard
Gurzau Raul
Mike Hommey
David Major
Dorel Luca
Nathan Froyd
Sylvestre Ledru
Sebastian Hengst
Makoto Kato
Randell Jesup
sotaro