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
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204