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
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
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
If the channel is not a nsIPrivateBrowsingChannel, and it also has no load context (eg inside svg images) then we will over write a non-zero mPrivateBrowsingId on the OriginAttributes of the channel with 0, making NS_UsePrivateBrowsing return false for the channel.
Differential Revision: https://phabricator.services.mozilla.com/D212083
This patch refactors how we check for text formats when deciding how to handle
resources, such that more text MIME types will be rendered in-browser, rather
than downloaded.
This change requires us to move more away from using the Gecko-Content-Viewers
category in the category manager for this decision, as we need to handle an
unlimited number of MIME types behind the scenes.
Support for Gecko-Content-Viewers was left in for both the in-tree use for
application/http-index-format and dynamically determining whether image/avif
and image/jxl are supported, as well as for the message/rfc822 type used by
Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D212078
This patch refactors how we check for text formats when deciding how to handle
resources, such that more text MIME types will be rendered in-browser, rather
than downloaded.
This change requires us to move more away from using the Gecko-Content-Viewers
category in the category manager for this decision, as we need to handle an
unlimited number of MIME types behind the scenes.
Support for Gecko-Content-Viewers was left in for both the in-tree use for
application/http-index-format and dynamically determining whether image/avif
and image/jxl are supported, as well as for the message/rfc822 type used by
Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D212078
The page has
<link rel="shortcut icon" type="image/x-icon" href="data:image/icon;base64,__png_data__">
When the Favicon service tries to decode that is passes "image/icon" as the mimetype to choose the decoder type and so we try to decode it as our internal icon format (not a format used in the wild, only used internal to get pass around icon data we retrieved from the OS). This passes in an invalid format type and hits the assert. In a non-debug build we fail to create the surface pipe later when we can't find a swizzle function. We only ever create these icon files with formats R8G8B8A8, OS_RGBA, or B8G8R8A8. The favicon still gets displayed so the favicon service must be trying something more complicated if that fails.
In the normal content image loading path we prefer to sniff the content type from the image data and if that fails fall back to the specified content type. So the test had be careful not to look like png (or any other) image format so that we actually tried to decode it as an icon.
Differential Revision: https://phabricator.services.mozilla.com/D204732
A number of public APIs in Skia have changed since the update to m125,
so various places in Gecko need to be updated to track it.
Differential Revision: https://phabricator.services.mozilla.com/D209821
A number of public APIs in Skia have changed since the update to m125,
so various places in Gecko need to be updated to track it.
Differential Revision: https://phabricator.services.mozilla.com/D209821
Timothy Nikkel
Alexandra Borovova
Tooru Fujisawa
Emilio Cobos Álvarez
Andrew Osmond
Noemi Erli
Sean Feng
Stanca Serban
Chun-Min Chang
Sylvestre Ledru
Ting-Yu Lin
Nika Layzell
Sandor Molnar
Tom Schuster
Aron Cseh
Ryan VanderMeulen
Joel Maher
Norisz Fay
Valentin Gosu
Iulian Moraru
Tamas Szentpeteri
Lee Salzman