Rather than change every use of IntSize/Rect/Point in image/, this patch
attempts to draw the line at the relevant parts of the decoding pipeline
to prevent confusion about which size and orientation we are working
with.
Differential Revision: https://phabricator.services.mozilla.com/D126381
CLOSED TREE
Backed out changeset f6519420f910 (bug 1678487)
Backed out changeset 9beae015d19b (bug 1678487)
Backed out changeset 029cc10d2477 (bug 1678487)
We really should be color managing them. It was a mistake and
misunderstanding of how Chrome worked because of differences in how we
color manage canvas.
Differential Revision: https://phabricator.services.mozilla.com/D79295
It appears some websites assume we will not color manage untagged images
and encode metadata in the image's surface data. Chrome matches this
behaviour. We should probably do the same for webcompat.
Differential Revision: https://phabricator.services.mozilla.com/D73737
Currently we can only use the gfx.color_management.force_srgb pref to
force all images to sRGB, or just accept device space. It would be nice
to be able to test device space in our tests, as well as sRGB. This
patch adds a surface flag which allows us to selectively output sRGB.
This will also be useful for clipboard and re-encoding purposes, since
they want a neutral output. In an ideal world we would just output the
color profile and the pixel data in the original color space, but for
now this is a relatively simple approach that works on all platforms and
interops well with all applications.
Differential Revision: https://phabricator.services.mozilla.com/D65734
--HG--
extra : moz-landing-system : lando
Currently we can only use the gfx.color_management.force_srgb pref to
force all images to sRGB, or just accept device space. It would be nice
to be able to test device space in our tests, as well as sRGB. This
patch adds a surface flag which allows us to selectively output sRGB.
This will also be useful for clipboard and re-encoding purposes, since
they want a neutral output. In an ideal world we would just output the
color profile and the pixel data in the original color space, but for
now this is a relatively simple approach that works on all platforms and
interops well with all applications.
Differential Revision: https://phabricator.services.mozilla.com/D65734
--HG--
extra : moz-landing-system : lando
In the PNG decoder, when an image is tagged as sRGB, we create a new
sRGB profile, and a new transform to map that to device space. Creating
a transform is fairly expensive, and we already cache sRGB to device
space transforms in gfxPlatform. This patch ensures that we use the
cached transforms instead. It should be noted that we ignore the intent
from the sRGB tag; nominally we could transform differently as a result
of that, but qcms does not actually implement any of that.
Differential Revision: https://phabricator.services.mozilla.com/D65320
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
The PNG decoder lacks fast implementations for swizzling/unpacking
inside the library, and both PNG and WebP may need to perform
premultiplication due to the alpha channel. This patch adds a new filter
allowing us to take advantage of our accelerated implementations to
perform these transformations on their behalf.
Differential Revision: https://phabricator.services.mozilla.com/D46449
--HG--
extra : moz-landing-system : lando
The PNG decoder lacks fast implementations for swizzling/unpacking
inside the library, and both PNG and WebP may need to perform
premultiplication due to the alpha channel. This patch adds a new filter
allowing us to take advantage of our accelerated implementations to
perform these transformations on their behalf.
Differential Revision: https://phabricator.services.mozilla.com/D46449
--HG--
extra : moz-landing-system : lando
The PNG decoder lacks fast implementations for swizzling/unpacking
inside the library, and both PNG and WebP may need to perform
premultiplication due to the alpha channel. This patch adds a new filter
allowing us to take advantage of our accelerated implementations to
perform these transformations on their behalf.
Differential Revision: https://phabricator.services.mozilla.com/D46449
--HG--
extra : moz-landing-system : lando
The PNG decoder lacks fast implementations for swizzling/unpacking
inside the library, and both PNG and WebP may need to perform
premultiplication due to the alpha channel. This patch adds a new filter
allowing us to take advantage of our accelerated implementations to
perform these transformations on their behalf.
Differential Revision: https://phabricator.services.mozilla.com/D46449
--HG--
extra : moz-landing-system : lando
Call WriteRow from a different line number if we have an interlacing buffer. I think the compiler shouldn't be able to optimize these into the same code, and so we should be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D44061
--HG--
extra : moz-landing-system : lando
Creating QCMS profiles and transforms are fairly expensive operations
and not necessary for metadata decoding. We can reduce the time required
for PNG metadata decoding by skipping this. The JPEG and WebP decoders
already do this.
Differential Revision: https://phabricator.services.mozilla.com/D35500
libpng uses the first IDAT chunk it encounters as a signal that it has read all header chunks and to send the info callback.
The testcase png has an IDAT chunk, then a z chunk (not a known chunk type), and then another IDAT chunk.
libpng tracks if we are in an "after idat" state, and throws a benign error if it encounters another IDAT chunk in "after idat" mode, but it just continues normally, processing the idat chunk as if it were the first and therefore sends the info callback again. This seems silly.
https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/media/libpng/pngpread.c#307
DecoderFlags::BLEND_ANIMATION will cause the decoder to inject the
BlendAnimationFilter from the previous patch into the SurfacePipe filter
chain. All frames produced by this decoder will be complete, and
should be equivalent to the result outputted by FrameAnimator.
DecoderFlags::BLEND_ANIMATION will cause the decoder to inject the
BlendAnimationFilter from the previous patch into the SurfacePipe filter
chain. All frames produced by this decoder will be complete, and
should be equivalent to the result outputted by FrameAnimator.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
If we were doing a first frame only decode we wouldn't fill in this value. The spec says this chunk must come before any image data so it should always be available at the end of any full decode (whether it be truly full or first frame only).
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
