By using the destination DT we will use the correct offset
during playback instead of the offset of the reference target.
Differential Revision: https://phabricator.services.mozilla.com/D68495
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68152
--HG--
extra : moz-landing-system : lando
So that accesses that use mSkipRect.XMost() - 4 or - 16 are aligned to a 4-byte
boundary. Not doing so would crash on some architectures due to a SIGBUS.
Differential Revision: https://phabricator.services.mozilla.com/D66748
--HG--
extra : moz-landing-system : lando
UnpremultiplyRow will be used in the image encoders to reverse
premultiplication. SwizzleRow needs to support copying (no swizzling)
and swapping RGB/BGR.
Differential Revision: https://phabricator.services.mozilla.com/D66743
--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
WebRender won't support GDI fonts so we need to figure out what to do
with the users that are currently using them. This should help give us
better diagnostics on what's going wrong.
gfxCriticalError only crashes on Nightly and Beta builds
Differential Revision: https://phabricator.services.mozilla.com/D65342
--HG--
extra : moz-landing-system : lando
In DrawTargetRecording::CreateSimilarDrawTarget, we would originally
create a new DrawTargetRecording. For resources that are shared, such as
SVG patterns, we would do the same work for each blob image tile. This
can get expensive if the pattern is large. Now we check a size
threshold, and if passed, we create a DrawTargetSkia backed by a
SourceSurfaceSharedData. When we want a snapshot, we now try to get the
shared surface instead if available. The recording infrastructure
already knows how to handle the lifetimes and use of external IDs for
shared surfaces, so now we rasterize the pattern once for all the blob
tiles. In an ideal world we would do this in the compositor process
once, but that requires more changes, and this is useful as a stopgap in
the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D63903
--HG--
extra : moz-landing-system : lando
This is generally around object creation failures and their subsequent lookup,
which can happen, for example, during device reset.
Differential Revision: https://phabricator.services.mozilla.com/D60888
--HG--
extra : moz-landing-system : lando
The crash reports all have allocation failures in their gfx critical log indicating that the best we can do is bail out without crashing and hope that enough memory will be freed before we run into an infallible allocation.
Differential Revision: https://phabricator.services.mozilla.com/D63085
--HG--
extra : moz-landing-system : lando
So as to avoid UB. It is somewhat unfortunate/dumb the fact that we need to do
this and we can't detect when we forget to do it :(
Give it uint8_t as it's type as that's enough and consistent with LogicalSide.
Differential Revision: https://phabricator.services.mozilla.com/D62390
--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
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
3. Add brackets for the for loop in nsCSSRendering.cpp.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_HALF_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalHalfCorners())"
rename "NS_FOR_CSS_HALF_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalHalfCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61252
--HG--
extra : moz-landing-system : lando
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_FULL_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalCorners())"
rename "NS_FOR_CSS_FULL_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61251
--HG--
extra : moz-landing-system : lando
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_SIDES\(side\)" "for (const auto side : mozilla::AllPhysicalSides())"
rename "NS_FOR_CSS_SIDES\(s\)" "for (const auto s : mozilla::AllPhysicalSides())"
rename "NS_FOR_CSS_SIDES\(i\)" "for (const auto i : mozilla::AllPhysicalSides())"
rename "NS_FOR_CSS_SIDES\(ix\)" "for (const auto ix : mozilla::AllPhysicalSides())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61250
--HG--
extra : moz-landing-system : lando
SourceSurfaceCapture can contain an underlying surface instead of a set
of drawing commands. The surface has its own valid state, and must be
checked by the parent in SourceSurfaceCapture::IsValid. If we don't,
then we may end up failing silently while drawing, and images will go
missing. The underlying surface can be invalidated by a device reset if
it is a SourceSurfaceD2D1, as an example.
Differential Revision: https://phabricator.services.mozilla.com/D61245
--HG--
extra : moz-landing-system : lando
This is done by using CreateDataSourceSurfaceWithStrideFromData to create a
DataSourceSurface and then OptimizeSourceSurface to record and optimize that.
This means that we now only have SourceSurfaceRecording using SurfaceType
RECORDING. We then rely on this to improve the test in OptimizeSourceSurface to
check that a SourceSurfaceRecording is for its recorder.
Differential Revision: https://phabricator.services.mozilla.com/D60736
--HG--
extra : moz-landing-system : lando
This patch makes us use the correct intrinsic for loading a uint8x16
register. It is not entirely clear why clang accepts this without
complaint but beyond the types, it should be equivalent.
Differential Revision: https://phabricator.services.mozilla.com/D60667
--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
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
