This code was copied from the png decoder but it is only applicable to the png decoder because it produces output in rgb order. Whereas the avif decoder produces data in BGR order.
Differential Revision: https://phabricator.services.mozilla.com/D220088
AspectRatio already has a way of representing a null / invalid ratio,
and there are some cases (broken sizes or invalid SVGOuterSVGFrame
ratio) where we might get Some(AspectRatio()).
It's not a meaningfully different state, and IMO we shouldn't treat it
differently.
Differential Revision: https://phabricator.services.mozilla.com/D224212
AspectRatio already has a way of representing a null / invalid ratio,
and there are some cases (broken sizes or invalid SVGOuterSVGFrame
ratio) where we might get Some(AspectRatio()).
It's not a meaningfully different state, and IMO we shouldn't treat it
differently.
Differential Revision: https://phabricator.services.mozilla.com/D224212
Color management is usually handled in the SurfacePipe, but SurfacePipe is RGB(A) only, and qcms can only operator on grayscale images in grayscale format, not RGB(A). So we must handle the qcms operation in the decoder. This is the same as how the png decoder handles this same situation. One additional wrinkle is that gfx::ConvertYCbCrToRGB32 only outputs RGB even for grayscale input data so we have to create an intermediate grayscale copy of the data for qcms to work on.
Recording command lines here that were used to create the test in case it needs to be modified or extended in the future.
Convert png to grayscale or grayscale + alpha
ffmpeg -i file.png -pix_fmt gray file-gray.png
ffmpeg -i file.png -pix_fmt ya8 file-gray.png
Extract icc profile from png
exiftool -icc_profile -b -w icc file.png
Add icc profile to png
exiftool "-icc_profile<=profile.icc" file.png
Encode avif using provided icc profile in file
avifenc --icc profile.icc input.png output.avif
Differential Revision: https://phabricator.services.mozilla.com/D220101
ConvertYCbCrToRGB32 was doing the premultiplied conversion, which happens before the surface pipe, which is where color management happens.
Differential Revision: https://phabricator.services.mozilla.com/D220517
The background image is associate to the table frame, but the table wrapper frame is the primary frame, thus IsPrimaryFrameOfRootOrBodyElement returns false and we don't propagate to the root when we should. So I changed IsPrimaryFrameOfRootOrBodyElement to handle this case and renamed it. I checked the other root element frame types, only table frames had this issue.
Differential Revision: https://phabricator.services.mozilla.com/D217923
This bypasses any caching used on the display pipeline and is
intended to be used by layers that want asynchronous decoding
that fits well into the MozPromise style.
This also fixes an issue with the frame count metadata decoder in the
GIF decoder. The code only began being used with this patch, and the WPT
exposed an overflow bug caused by not clearing nsGIFDecoder2::mColormap
and nsGIFDecoder2::mColormapSize.
Differential Revision: https://phabricator.services.mozilla.com/D212833
Two changes are introduced:
* LCP has a hashtable called `ContentIdentifiersForLCP` to store
(element, image) pairs to avoid processing the same pair multiple
times. Instead of using weak pointers for elements, this patch changes
it to use raw pointers for better performance. Also, makes the
hashtable to use element alone as the key, so that the entry
can be quickly removed when nsINode::LastRelease is called.
* Another change to make imgRequestProxy stores the
timestamps for LCP, so we can create LCP entries when the size
is available, instead of creating one temporarily and updating it
later. This allows us to eliminate a hashtable called
`mImageLCPEntryMap` for better performance.
Differential Revision: https://phabricator.services.mozilla.com/D214315
This bypasses any caching used on the display pipeline and is
intended to be used by layers that want asynchronous decoding
that fits well into the MozPromise style.
This also fixes an issue with the frame count metadata decoder in the
GIF decoder. The code only began being used with this patch, and the WPT
exposed an overflow bug caused by not clearing nsGIFDecoder2::mColormap
and nsGIFDecoder2::mColormapSize.
Differential Revision: https://phabricator.services.mozilla.com/D212833
This bypasses any caching used on the display pipeline and is
intended to be used by layers that want asynchronous decoding
that fits well into the MozPromise style.
This also fixes an issue with the frame count metadata decoder in the
GIF decoder. The code only began being used with this patch, and the WPT
exposed an overflow bug caused by not clearing nsGIFDecoder2::mColormap
and nsGIFDecoder2::mColormapSize.
Differential Revision: https://phabricator.services.mozilla.com/D212833
Initially, the YCbCrUtils and yuv_convert APIs asserted success
internally. With recent changes, those assertions were removed. This
patch reintroduces those assertions on the caller's side instead, except
the `ConvertToRGBA` in ImageConversion.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D216191
Originally we would yield a new frame when the next frame was available,
or the decoder finished. This is problematic for some WPTs used by
WebCodecs image decoding. There should be no functional difference
besides yielding a new frame slightly earlier.
Differential Revision: https://phabricator.services.mozilla.com/D212832
This patch simplifies the code path in `nsAVIFDecoder`. Previously,
`nsAVIFDecoder` relied on both `ConvertYCbCrToRGB` and
`ConvertYCbCrToRGB32` to convert YUV data to BGRX or BGRA, depending on
the presence of an alpha channel. With recent changes, `nsAVIFDecoder`
can now use `ConvertYCbCrToRGB32` exclusively to streamline the
conversion process.
Depends on D215985
Differential Revision: https://phabricator.services.mozilla.com/D216228
This patch replaces `ConvertYCbCrAToARGB` with `ConvertYCbCrToRGB32` in
`nsAVIFDecoder`, as image scaling is not required.
Differential Revision: https://phabricator.services.mozilla.com/D215985
This attribute is not used in Gecko, but exists for use by other
applications. Specifically, the APP_TYPE_EDITOR type is given permission
to load privileged images as tested by browser_docshell_type_editor.js.
Before these changes, that test passed because the docshell was loaded
in a different process, so the cache was empty when each load occurred,
but after my changes the process ends up being re-used, so the image
cache bypasses this check.
This changes the image cache key to also include the app type
information so that it will be compared before re-using the entry.
Differential Revision: https://phabricator.services.mozilla.com/D126557
It is useful/necessary for WebCodecs image decoding support to be able
to calculate a frame count for the encoded image without actually
decoding every frame. It needs to be able to provide results without the
complete buffer as well.
Differential Revision: https://phabricator.services.mozilla.com/D212831
