This patch adds support for color management in BMPs added in
BITMAPV4HEADER and BITMAPV5HEADER. While display of BMPs is relatively
rare this comes in handy when interacting with the Windows clipboard.
Differential Revision: https://phabricator.services.mozilla.com/D64880
--HG--
extra : moz-landing-system : lando
This patch adds support for color management in BMPs added in
BITMAPV4HEADER and BITMAPV5HEADER. While display of BMPs is relatively
rare this comes in handy when interacting with the Windows clipboard.
Differential Revision: https://phabricator.services.mozilla.com/D64880
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
No functional change. This allows us to support both alpha and non-alpha
variants with the same implementation, in addition to laying the ground
work for QCMS to support BGRA as an input and output.
Differential Revision: https://phabricator.services.mozilla.com/D30820
No functional change. This allows us to support both alpha and non-alpha
variants with the same implementation, in addition to laying the ground
work for QCMS to support BGRA as an input and output.
Differential Revision: https://phabricator.services.mozilla.com/D30820
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
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.
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
This is basically just this: https://bugs.chromium.org/p/chromium/issues/detail?id=562951
The original profile that caused us to add this check has bigger problems than negative
colorant tristiumlus values. We should reject it using a better metric. In the mean time
let's not reject these things on macOS.
Currently, the build scripts enable AltiVec unconditionally on all ppc*
targets. However, there some ppc* targets which do not support AltiVec
instruction set extensions, these are often embedded systems like the
PowerPC e500 or similar which have their own type of instruction set
extensions like SPE. Trying to enable Altivec support on these targets
results in a compiler error, hence we need to add an autoconf test for
AltiVec support before trying to enable it on ppc* targets.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
--HG--
extra : rebase_source : 6c4df813d97d95046fd2269c876313ce7591c5cf
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
This patch fixes various warnings from MSVC.
- Several "truncation from 'double' to 'float'" warnings, easily fixed by
appending 'f' to literals.
- Some "signed/unsigned mismatch" warnings. In read_tag_lutType(), MSVC is
apparently promoting the multiplication of a uint8_t and a uint16_t to an
int32_t, oddly enough. A uint32_t cast fixes the warning.
- |offset| was unused in qcms_data_create_rbg_with_gamma().
- A couple of "overflow in floating-point constant arithmetic" warnings
involving INFINITY in transform_util.c. There is some type confusion here --
in C99 HUGE_VAL is a double and INFINITY is a float. So the HUGE_VAL here
should actualy be HUGE_VALF. But, strangely enough, that isn't enough to
avoid the warning, I don't know why. However, it turns out that any
non-positive value for |interval| will have the same effect, so I just
removed all the INFINITY/HUGE_VAL stuff and used -1 instead.
It also fixes an ARM-only GCC warning.
- "'__force_align_arg_pointer__' attribute directive ignored". This is an
x86-only attribute. Instead of disabling it on x86-64, instead enable it on
i386 (which avoids enabling it uselessly on ARM).
--HG--
extra : rebase_source : 61015b7e48aebd58035fc222abf076e79a99a972
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973