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
This patch adds an annotation to an image cache entry if it is in the
process of being validated. This is very useful to know when debugging
missing images because state notifications are suppressed when we are
validating and may prevent the image from being displayed.
Differential Revision: https://phabricator.services.mozilla.com/D60526
--HG--
extra : moz-landing-system : lando
This patch adds error and progress tracker states to the memory dump. It
also now will include requests that have yet to create an image, and
fills in what information it is able to without it (such as URI, error
and progress tracker states).
Additionally the notability of an image has changed. If there are any
errors, missing progress trackers, or incomplete surfaces, they will
also now be notable. This is a departure from just the memory footprint.
Differential Revision: https://phabricator.services.mozilla.com/D60495
--HG--
extra : moz-landing-system : lando
This dumps more information about the surface cache. Each surface has a
flag indicating whether or not it has finished decoding; incomplete
surfaces are now marked as such in the cache reports. We now also have
counters for various insertion errors, as well as the composition of the
cache (total vs locked images, total vs locked surfaces).
Differential Revision: https://phabricator.services.mozilla.com/D60450
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
Now mfbt/Move.h is empty except for that excellent comment about move
semantics... Should we put it somewhere else and delete the header as a
follow-up? Or just delete the header and carry on?
Differential Revision: https://phabricator.services.mozilla.com/D60297
--HG--
extra : moz-landing-system : lando
I was poking at the missing images bug by dropping cache sizes and such and
found that we always ended up repainting some SVGs over and over. This seems to
be the cause. When we fail to insert into the cache we still end up notifying
over and over (because we forget to say aWillCache=false), so we'd end up
repainting, and failing again, etc.
This is easy to see adding some logging to
nsDisplayBackgroundImage::PaintInternal.
Any ideas as to how to add a test for it?
Differential Revision: https://phabricator.services.mozilla.com/D60372
--HG--
extra : moz-landing-system : lando
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59598
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
We should not attempt to shut down threads which we did not explicitly
remove from the image decode thread pool, when we want to shut down an
idle thread or otherwise. This behaviour would put us at risk of
shutting down a thread twice, which may trip assertions and/or cause
other issues. Now we assuming that any thread that is already removed
from the pool array has already been gracefully shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D58827
--HG--
extra : moz-landing-system : lando
When one uses SourceSurfaceRawData to wrap a data pointer, it will
perform a copy of said data if GuaranteePersistence is called. This is
done for DrawTargetCapture, which is used with OMTP. Prior to this
patch, image surfaces would be wrapped by a SourceSurfaceRawData when
using the basic compositor on any non-Linux platform (since Linux does
not support volatile memory). This means every time imgFrame::Draw is
called with OMTP, a copy of the image will be made. Images don't need
this property since the data is already going to persist, so this patch
adds a new class SourceSurfaceMappedData, which takes a ScopedMap
keeping the underlying surface open and readable.
Differential Revision: https://phabricator.services.mozilla.com/D58199
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando