зеркало из https://github.com/mozilla/gecko-dev.git
77d318b7de
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 |
||
|---|---|---|
| .. | ||
| ffvpx | ||
| gmp-clearkey/0.1 | ||
| highway | ||
| kiss_fft | ||
| libaom | ||
| libcubeb | ||
| libdav1d | ||
| libjpeg | ||
| libjxl | ||
| libmkv | ||
| libnestegg | ||
| libogg | ||
| libopus | ||
| libpng | ||
| libsoundtouch | ||
| libspeex_resampler | ||
| libtheora | ||
| libtremor | ||
| libvorbis | ||
| libvpx | ||
| libwebp | ||
| libyuv | ||
| mp4parse-rust | ||
| openmax_dl | ||
| openmax_il/il112 | ||
| psshparser | ||
| webrtc | ||
| moz.build | ||
| update-libjpeg.sh | ||