Other than compiler a bit more code this should have no functional effect, we're setting the values to their default values we had before.
Differential Revision: https://phabricator.services.mozilla.com/D130021
We don't enable PNG_WRITE_FILTER_SUPPORTED that means that do_filter field on the png_struct will always be zero (it's initialized to 0, and any calls to png_set_filter will error out unless the result is setting it to 0 https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/media/libpng/pngwrite.c#1032 ).
Then this code in png_write_IHDR https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/media/libpng/pngwutil.c#829 will execute and set do_filter to PNG_ALL_FILTERS for non-paletted images with >=8 bit depth.
This this code https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/media/libpng/pngwutil.c#339 will execute and set our zlib strategy to PNG_Z_DEFAULT_STRATEGY (as opposed to PNG_Z_DEFAULT_NOFILTER_STRATEGY). PNG_Z_DEFAULT_STRATEGY is also known as Z_FILTERED inside of zlib.
From here https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/modules/zlib/src/zlib.h#589 that means: "Z_FILTERED for data produced by a filter (or predictor) ... Filtered data consists mostly of small values with a somewhat random distribution."
So that is not what we want to our non-filtered image data.
Switching this so that we use PNG_Z_DEFAULT_NOFILTER_STRATEGY improves both the compression and speed. The following is the avg time taken for toDataURL with a canvas containing 3 different images, and dataURL.length.
Z_FILTERED
very simple line art
49.7ms
17618
"very png compressable image from bug 1724331"
60.8ms
192214
a photo
241.3ms
4193966
Z_DEFAULT_STRATEGY
very simple line art
52.2ms
17590
"very png compressable image from bug 1724331"
61.2ms
186182
a photo
213ms
3555170
All images are smaller with Z_DEFAULT_STRATEGY, the photo being 15% smaller. The two compressable images are perhaps very slightly slower, but the large photo is 12% faster.
For bug 1724331 I want to turn on PNG_WRITE_FILTER_SUPPORTED, and this means we avoid this bug because do_filter gets set to PNG_FILTER_NONE which is not equal to PNG_NO_FILTERS (which is a bit confusing). Avoiding his bug means our png encoder produces different output and we have a couple of tests that check against the exact output of the pngencoder that need to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D130019
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
libpng has NEON support using intrinsics, not assembler, so we should use it
even if aarch64.
MSVC build still turns off NEON since libpng doesn't support it on stable
version although upstream has it.
Differential Revision: https://phabricator.services.mozilla.com/D15462
--HG--
extra : moz-landing-system : lando
The media/libpng/moz.build file overrides the C standard used via
-std=c89, per bug 1371266, which conflicts with the use of the
arm_neon.h header: compilation fails on the inline keyword, which didn't
exist in C89. We thus "bump" to the GNU89 standard, which is C89+GNU
extensions, including inline.
--HG--
extra : rebase_source : fe93a13e3bef8888e1874d2e94a6d8ef396aaf83
This refactor is for exposing necessary symbols of libpng for freetype2 in a
general way. Currently the necessary symbols of libpng for freetype2 are
exposed only on Android. And whether these symbols are exposed solely depends
on the target platform checking. A better way to decide whether or not to
expose these symbols would be checking the dependency of freetype2 directly.
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
In bug 922912, we folded back gkmedias.dll info xul.dll, so in practice, there
is no default configuration left that exercises GKMEDIAS_SHARED_LIBRARY. And
sure enough, it's been broken for months in many different ways.
The gkmedias intermediate library is however kept for webrtc signaling tests.
Timothy Nikkel
Mike Hommey
Andi-Bogdan Postelnicu
Ryan VanderMeulen
Makoto Kato
byron jones
Sylvestre Ledru
Chris Manchester
Glenn Randers-Pehrson
Nicholas Nethercote
Petr Sumbera
Bruce Sun
Joel Maher
Andrew Osmond
Tom Tromey
Eric Rahm
David Major
Carsten "Tomcat" Book