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