We have to remove one of the radialGradient-basic-03-ref.svg tests (id=gradient5)
because it's testing clamping i.e. an fr just inside the radius is the same as
just outside and that's no longer true. Two of the other references are now different
due to the lack of clamping. In order to get the test and reference the same, the reference is created
using canvas since canvas has never had clamping.
Clamping was required by SVG 1.1 but that requirement was explicitly removed in SVG 2
mostly to match canvas, which has never clamped. Any rendering artifacts would likely
have been uncovered by canvas over the years since it has the same code that SVG uses
absent any clamping.
Differential Revision: https://phabricator.services.mozilla.com/D75706
In nsSVGOuterSVGFrame::IsContainingWindowElementOfType, we now inspect
the embedder by asking the window for its browsing context, instead of
asking it directly for its frame element.
Differential Revision: https://phabricator.services.mozilla.com/D77518
The brightness, contrast, and invert css filters are represented as component transfer filters when they required to be represented as an svg filter (ie when an element has a combination of CSS and SVG filters specified).
https://hg.mozilla.org/mozilla-central/rev/4f3360c4f104 (bug 1417699) used the value SVG_FECOMPONENTTRANSFER_TYPE_UNKNOWN for the function type in the G and B channels to specify that the R channel function should be used. As we know from https://hg.mozilla.org/mozilla-central/rev/a1ff0af83ad2 (bug 1605223) SVG_FECOMPONENTTRANSFER_TYPE_UNKNOWN is the value we get if the function is not specified, and by spec that is to be interpreted as the identity function.
To fix this use a special function type that is not exposed to content, SVG_FECOMPONENTTRANSFER_SAME_AS_R, when we want to do this optimization. And then teach the webrender filter code to understand it.
Differential Revision: https://phabricator.services.mozilla.com/D74189
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
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