PaintMaskSurface shouldn't be applying ImgDrawResult::NOT_READY when we don't have a frame and the mask image hasn't been resolved. ImgDrawResult is only about drawing images, not about waiting for external resources to resolve or frames to get constructed. The only purpose of tracking ImgDrawResult's in painting code is to know which frames we need to invalidate because their rendering might change if we sync decode images during a Draw call. Applying NOT_READY here means we invalidate for every paint with the sync decode images flag (ie reftest paints), and it never changes from NOT_READY. This bites the reftest for this bug 1624532.
To fix it, instead of "overloading" the ImgDrawResult we return a bool to indicate the mask is missing or incomplete.
Differential Revision: https://phabricator.services.mozilla.com/D70595
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
Clamping of the blur radius depends on transform scale factors. This info is not available until later in the WebRender pipeline, so we need to delegate blur radius clamping to WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D65804
--HG--
extra : moz-landing-system : lando
Clamping of the blur radius depends on transform scale factors. This info is not available until later in the WebRender pipeline, so we need to delegate blur radius clamping to WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D65804
--HG--
extra : moz-landing-system : lando
Clamping of the blur radius depends on transform scale factors. This info is not available until later in the WebRender pipeline, so we need to delegate blur radius clamping to WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D65804
--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 expects drop shadow dx/dy to be in user space, which is a floating point value.
Before this, a dx/dy such as (0.2, 0.2) was truncated to (0, 0) resulting in no offset of the shadow.
Differential Revision: https://phabricator.services.mozilla.com/D63442
--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
WebRender expects drop shadow dx/dy to be in user space, which is a floating point value.
Before this, a dx/dy such as (0.2, 0.2) was truncated to (0, 0) resulting in no offset of the shadow.
Differential Revision: https://phabricator.services.mozilla.com/D63442
--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
This is done using a similar approach to CreateWebRenderCommands
but slightly modified. In particular the active layer check needs
to be done before we're ready to CreateWebRenderCommands, but once
we decide to activate an item, we can't let CreateWebRenderCommands
fail. Unfortunately, the need to query ImageLib for support means
we need to do basically ~all of the work of CreateWebRenderCommands
to do this check.
As such, this introduces a modified version of CreateWebRenderCommands
that SVGGeometryFrames implement with a "dry run" flag. When true,
it runs the same code but stops short of mutating the WR DL/state.
ImageLib may be encouraged to do some extra work that could be thrown
away, but I'm not sure there's any way to avoid that.
For now, only SVGImageFrame actually provides an implementation. The
bulk of the implementation is handling the on-by-default
preserveAspectRatio feature of SVG images. It was cleaner to just
reimplement that logic than reuse the existing preserveAspectRatio
code, as it was too tangled up in the particulars of how the PaintSVG
path is designed.
Differential Revision: https://phabricator.services.mozilla.com/D59925
--HG--
extra : moz-landing-system : lando
This is done using a similar approach to CreateWebRenderCommands
but slightly modified. In particular the active layer check needs
to be done before we're ready to CreateWebRenderCommands, but once
we decide to activate an item, we can't let CreateWebRenderCommands
fail. Unfortunately, the need to query ImageLib for support means
we need to do basically ~all of the work of CreateWebRenderCommands
to do this check.
As such, this introduces a modified version of CreateWebRenderCommands
that SVGGeometryFrames implement with a "dry run" flag. When true,
it runs the same code but stops short of mutating the WR DL/state.
ImageLib may be encouraged to do some extra work that could be thrown
away, but I'm not sure there's any way to avoid that.
For now, only SVGImageFrame actually provides an implementation. The
bulk of the implementation is handling the on-by-default
preserveAspectRatio feature of SVG images. It was cleaner to just
reimplement that logic than reuse the existing preserveAspectRatio
code, as it was too tangled up in the particulars of how the PaintSVG
path is designed.
Differential Revision: https://phabricator.services.mozilla.com/D59925
--HG--
extra : moz-landing-system : lando
We don't actually share _that_ much code across them. This makes callers clearer
and code less confusing, IMHO.
This also has the benefit of not autocompleting path from devtools for
shape-outside.
Differential Revision: https://phabricator.services.mozilla.com/D62373
--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
This removes nsStyleImageRequest by moving the load state to LoadData instead
(where other lazy state like the resolved URL and load id lives).
That way we can use cbindgen for more stuff (there's no blocker for using it for
all images now), and we can undo the image tracking shenanigans that I had to do
in bug 1605803 in nsImageFrame.
This removes the mDocGroup member because well, there's no real upside of that
now that quantum DOM is not a thing.
It also removes the static clones of the image requests, and the need for each
computed value instance to have its own request. These were needed because we
needed the image loader for the particular document to observe the image
changes. But we were also tracking the request -> loader for other purposes.
Instead, Now all the images get loaded with GlobalImageObserver as a listener,
which looks in the image map and forwards the notification to all the interested
loaders instead dynamically.
The style value is only responsible to load the image, and no longer tracks /
locks it. Instead, the loader does so, via the image tracker.
Differential Revision: https://phabricator.services.mozilla.com/D58519
--HG--
extra : moz-landing-system : lando
To avoid computing transform bounds over and over. It is generally just better.
Replace the various "overridebounds" thingies by using the "fallback" of the
transform-reference-box code which we need anyway.
Differential Revision: https://phabricator.services.mozilla.com/D61890
--HG--
extra : moz-landing-system : lando
This removes nsStyleImageRequest by moving the load state to LoadData instead
(where other lazy state like the resolved URL and load id lives).
That way we can use cbindgen for more stuff (there's no blocker for using it for
all images now), and we can undo the image tracking shenanigans that I had to do
in bug 1605803 in nsImageFrame.
This removes the mDocGroup member because well, there's no real upside of that
now that quantum DOM is not a thing.
It also removes the static clones of the image requests, and the need for each
computed value instance to have its own request. These were needed because we
needed the image loader for the particular document to observe the image
changes. But we were also tracking the request -> loader for other purposes.
Instead, Now all the images get loaded with GlobalImageObserver as a listener,
which looks in the image map and forwards the notification to all the interested
loaders instead dynamically.
The style value is only responsible to load the image, and no longer tracks /
locks it. Instead, the loader does so, via the image tracker.
Differential Revision: https://phabricator.services.mozilla.com/D58519
--HG--
extra : moz-landing-system : lando
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.
The related spec issue: https://github.com/w3c/fxtf-drafts/issues/392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.
Differential Revision: https://phabricator.services.mozilla.com/D60771
--HG--
extra : moz-landing-system : lando