Since AnimationState::UpdateState now depends on a specific frame of the animation being in the surface cache we need to call UpdateState whenever we add a new frame.
Depends on D73583
Differential Revision: https://phabricator.services.mozilla.com/D73584
It takes a frame count argument but probably never gets a value we haven't already seen in a NotifyProgress call, so this doesn't fix anything as far as I know.
Depends on D73564
Differential Revision: https://phabricator.services.mozilla.com/D73583
The img.decode promise for animated images that aren't in the document might not resolve in common cases. Specifically for animated images that have been decoded and then discarded, so that mCompositedFrameInvalid is true.
mCompositedFrameInvalid is cleared by either:
1) the image is fully decoded and NotifyDecodeComplete is called.
2) RequestRefresh is able to advance to the current frame.
We don't call RequestRefresh on animated images that aren't in the document and we only decode a certain number of frames ahead of the current frame (even for fully retained animation buffers), so neither of these will happen with long enough animated images.
So we need to make sure that mCompositedFrameInvalid eventually gets cleared any time a decode is requested (which the FrameAnimator gets notified about via GetCompositedFrame). We do that be calling UpdateState in GetCompositedFrame whenever mCompositedFrameInvalid is true and the image is in the surface cache.
This runs into a second problem: UpdateState uses |mIsCurrentlyDecoded = aResult.Surface().IsFullyDecoded()| to determine when to clear mCompositedFrameInvalid. As mentioned above, we don't fully decode animated images. Further, for animated images that are large enough we use a discarding animation buffer that never keeps around all the frames and so IsFullyDecoded always returns false. So we replace that with a check that we can seek to the current animated frame index.
Differential Revision: https://phabricator.services.mozilla.com/D73564
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
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
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- No support for ICC profiles (bug 1634741)
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
Since we don't support downscaling animated images we'll need something like this even we were to try to request a smaller sized decode.
Differential Revision: https://phabricator.services.mozilla.com/D71523
We invalidate for more things than just frames advancing (if we are redecoding and still showing the same frame as before discarding for example). So there is no reason that the dirty rect and a frame being advanced should be linked.
Differential Revision: https://phabricator.services.mozilla.com/D71483
This is actually a one line change. The rest is just removing unneeded parameters.
The composited frame used to be valid for animations that had finished because we saved a separate composited frame, and since the animation had finished it was the final frame, so it had to be valid to display.
Now we don't have a separate composited frame so we only have a valid frame to display if we've decoded up to the current frame. For non-finished animations RequestRefresh will clear mCompositedFrameInvalid, but for finished animations we have to clear it, the easiest place is when we know we are fully decoded.
This problem caused img.decode to never fulfill or reject because we never sent out any frame update notifications because mCompositedFrameInvalid was always false because mAnimationFinished was always true. So we didn't get the invalidation that flipping mCompositedFrameInvalid to false when a full decode finished would cause.
Differential Revision: https://phabricator.services.mozilla.com/D70838
We invalidate for more things than just frames advancing (if we are redecoding and still showing the same frame as before discarding for example). So there is no reason that the dirty rect and a frame being advanced should be linked.
Differential Revision: https://phabricator.services.mozilla.com/D71483
This is actually a one line change. The rest is just removing unneeded parameters.
The composited frame used to be valid for animations that had finished because we saved a separate composited frame, and since the animation had finished it was the final frame, so it had to be valid to display.
Now we don't have a separate composited frame so we only have a valid frame to display if we've decoded up to the current frame. For non-finished animations RequestRefresh will clear mCompositedFrameInvalid, but for finished animations we have to clear it, the easiest place is when we know we are fully decoded.
This problem caused img.decode to never fulfill or reject because we never sent out any frame update notifications because mCompositedFrameInvalid was always false because mAnimationFinished was always true. So we didn't get the invalidation that flipping mCompositedFrameInvalid to false when a full decode finished would cause.
Differential Revision: https://phabricator.services.mozilla.com/D70838
We need this since nsLayoutUtils::SurfaceFromElement expects the
returned frame size to be correct, and we are now wrapping a source
element's image with an OrientedImage.
Differential Revision: https://phabricator.services.mozilla.com/D71243
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
RasterImage will make use of them.
Note that there is one bug fix in this patch, which is that
OrientedImage::OrientSurface now creates a surface of the correct size.
(Previously this code was creating a surface with the underlying
image's size, rather than the correctly oriented size. But we must
not have been calling into that code with our current uses of
OrientedImage.)
Differential Revision: https://phabricator.services.mozilla.com/D70271
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
--HG--
extra : moz-landing-system : lando
RasterImage will make use of them.
Note that there is one bug fix in this patch, which is that
OrientedImage::OrientSurface now creates a surface of the correct size.
(Previously this code was creating a surface with the underlying
image's size, rather than the correctly oriented size. But we must
not have been calling into that code with our current uses of
OrientedImage.)
Differential Revision: https://phabricator.services.mozilla.com/D70271
--HG--
extra : moz-landing-system : lando
This fixes the web-observable bits, but still not the context menu. Patch
incoming for that.
Differential Revision: https://phabricator.services.mozilla.com/D70936
--HG--
extra : moz-landing-system : lando
Currently, `NotificationObserverWrapper` would leak because no one delete it. When clearing the weak pointer in `ImageDecoderListener`, that won't destroy `NotificationObserverWrapper` itself, but only destroy the `WeakReference<NotificationObserverWrapper>`.
Therefore, we should remove `NotificationObserverWrapper` and use a strong reference to hold `imgINotificationObserver` directly.
Differential Revision: https://phabricator.services.mozilla.com/D70569
--HG--
extra : moz-landing-system : lando
We use FRAME_UPDATE and FRAME_COMPLETE notifications to check if we should resolve/reject img.decode promises. But all of the FRAME_UPDATE/FRAME_COMPLETE notifications for image/test/crashtests/1443232-1.gif come before we change the surface cache entry from a placeholder to available. So RequestDecodeForSize returns false and we don't resolve and we don't get anymore notifications.
In this case the DECODE_COMPLETE notifications comes after we mark the surface cache entry as available so checking if we should resolve for DECODE_COMPLETEs would also work, but it seems reasonable for consumers to expect that they can get a frame after getting a FRAME_COMPLETE notification for it.
Differential Revision: https://phabricator.services.mozilla.com/D70312
--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
WillDrawOpaqueNow tries to answer the question "if Draw is called on this image 'pretty soon' from now will it draw something opaque (so I know if I can cull stuff behind it for painting)".
But OrientedImage wants "is the frame I have right now opaque (so I can choose the right format for a surface I'm trying to draw the flipped image into)".
Bug 1260324 replaces imgIContainer::IsOpaque with WillDrawOpaquaNow, but it should have considered this case a bit more.
RasterImage::GetFrame already checks if the surface is finished before returning, and we have the format on the returned frame, so we don't need anything complicated here.
Differential Revision: https://phabricator.services.mozilla.com/D70303
--HG--
extra : moz-landing-system : lando
Just waiting for the load event of the image doesn't even mean the image has been painted at all yet, but by the time MozReftestInvalidate fires the first frame should be guaranteed to have been painted.
Also, switch to using new img.decode api. img.decode will decode an animated version of the img, whereas drawing to a canvas will kick off a first frame only decode which the page can't use.
Differential Revision: https://phabricator.services.mozilla.com/D70104
--HG--
extra : moz-landing-system : lando
Loading just the image results in "theatre mode" display of the image (centered, dark background). But the test needs to be in an html document. We either changed how top level images were displayed or stopped using a style sheet in reftests that displayed images like this since the tests were last enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70103
--HG--
extra : moz-landing-system : lando
Just waiting for the load event of the image doesn't even mean the image has been painted at all yet, but by the time MozReftestInvalidate fires the first frame should be guaranteed to have been painted.
Also, switch to using new img.decode api. img.decode will decode an animated version of the img, whereas drawing to a canvas will kick off a first frame only decode which the page can't use.
Differential Revision: https://phabricator.services.mozilla.com/D70104
--HG--
extra : moz-landing-system : lando
Loading just the image results in "theatre mode" display of the image (centered, dark background). But the test needs to be in an html document. We either changed how top level images were displayed or stopped using a style sheet in reftests that displayed images like this since the tests were last enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70103
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--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
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--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
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
This patch adds support for color management in BMPs added in
BITMAPV4HEADER and BITMAPV5HEADER. While display of BMPs is relatively
rare this comes in handy when interacting with the Windows clipboard.
Differential Revision: https://phabricator.services.mozilla.com/D64880
--HG--
extra : moz-landing-system : lando
This patch adds support for color management in BMPs added in
BITMAPV4HEADER and BITMAPV5HEADER. While display of BMPs is relatively
rare this comes in handy when interacting with the Windows clipboard.
Differential Revision: https://phabricator.services.mozilla.com/D64880
--HG--
extra : moz-landing-system : lando
On some RDL situations we may create the new item, then destroy the old one
afterwards.
When this is the order of operations, the image would end up unregistered, and
thus not invalidating the canvas frame.
Differential Revision: https://phabricator.services.mozilla.com/D64995
--HG--
extra : moz-landing-system : lando
This patch converts the BMP decoder to use SurfacePipe instead of using
AllocateFrame and Downscaler directly. As a result, it now uses the
accelerated premultiplication path, honours the
SurfaceFlags::NO_PREMULTIPLY_ALPHA flag, and allows for a path forward
to support color management and clipboard better.
Differential Revision: https://phabricator.services.mozilla.com/D64866
--HG--
extra : moz-landing-system : lando
We are seeing some crash reports with RecyclingSourceSurface containing
null pointers in the signature. The proto signature doesn't make any
sense however. Let's use NotNull to reassure ourselves that there isn't
something going wrong when we create RecyclingSourceSurface.
Differential Revision: https://phabricator.services.mozilla.com/D64066
--HG--
extra : moz-landing-system : lando
Currently, the GetCMSOutputProfile() and related methods pass their output
using the old C-style "ptr, len" parameters. This makes them more difficult
to deal with later in this change when they need to be safely passed over IPC.
This refactors them to return nsTArray<uint8_t> results instead. I also
removed some old cruft and refactored the existing code.
Differential Revision: https://phabricator.services.mozilla.com/D63583
--HG--
extra : moz-landing-system : lando
With the new 'defaults' key being added, 'default-preferences' is now
redundant. This commit converts all existing uses of 'default-preferences' to
use 'defaults' instead.
Differential Revision: https://phabricator.services.mozilla.com/D63247
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : source : 541b98270c9985c5bd3569ff3ff8bc6c3d3c650a
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : moz-landing-system : lando
The trickier part is that we represent -moz-image-rect as a Rect() type instead
of image with non-null clip-rect. So we need to add a bit of code to
distinguish "image request types" from other types of images.
But it's not too annoying, and we need to do the same for fancier images like
image-set and such whenever we implement it, so seems nice to get rid of
most explicit usages of nsStyleImage::GetType().
Differential Revision: https://phabricator.services.mozilla.com/D62164
--HG--
extra : moz-landing-system : lando
We include it everywhere because it's included from gfxTypes.h.
This should avoid including all the generated bindings _everywhere_.
Differential Revision: https://phabricator.services.mozilla.com/D62174
--HG--
extra : moz-landing-system : lando
This patch adds reporting the surface types used by the image frame in a
bit mask (such if it is a CAPTURE including a DATA_SHARED, the mask will
be 1 << CAPTURE | 1 << DATA_SHARED), as well as an estimated size
included in the report as decoded-unknown for when we do not know if the
surface is on the heap or the non-heap specifically. This is the default
implementation for a SourceSurface as well, so we should no longer have
the case where surfaces appear empty despite being in the cache. It also
makes requests being validated as always notable for reporting purposes.
Differential Revision: https://phabricator.services.mozilla.com/D61458
--HG--
extra : moz-landing-system : lando
On Windows, optimized surfaces can become invalid due to a device reset
or GPU process crash when D2D draw targets were being used. This is
because SourceSurfaceD2D1 checks if the D2D context has changed from the
one it was optimized for.
We assumed when creating a DrawableFrameRef that if we don't have
imgFrame::mRawSurface, then we must have an imgFrame::mOptSurface. This
is incorrect and causes SurfaceCache to believe it has a valid
DrawableSurface, even if the underlying optimized surface cannot be used
for drawing (or has already been freed).
If we can't draw the image, it goes missing from the screen. But since
the cache thinks it has a valid surface, we never actually redecode it.
With this patch, we now check if the imgFrame::mOptSurface has been
freed already, and if not, that it remains valid for drawing purposes.
If either condition is true, the SurfaceCache entry will be removed,
thus permitting a redecode attempt.
Differential Revision: https://phabricator.services.mozilla.com/D60834
--HG--
extra : moz-landing-system : lando
Andrea Marchesini
Coroiu Cristina
Kershaw Chang
Mihai Alexandru Michis
wesj
Cameron McCormack
Christian Holler (:decoder)
Honza Bambas
Edgar Chen
Sylvestre Ledru
Matt Woodrow
Timothy Nikkel
Simon Giesecke
Ian Moody
Andrew Osmond
Nathan Froyd
Jon Bauman
Razvan Maries
Bogdan Tara
Olivier Tilloy
Narcis Beleuzu
Andreea Pavel
Christoph Kerschbaumer
Daniel Varga
Csoregi Natalia
Emilio Cobos Álvarez
alwu
Noemi Erli
Stefan Hindli
Andreas Farre
Cosmin Sabou
Anders S
Chris Peterson
Oana Pop Rus
sonakshi
Chris Fronk
Boris Zbarsky
Arthur Iakab
Ehsan Akhgari
Mark Banner
Tim Huang
Dorel Luca
Andrew McCreight
Ciure Andrei
Chris Martin
Andrew Halberstadt
Sebastian Streich
Kristen Wright
Gijs Kruitbosch