We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
The change perturbs the drawing of the scrollbar endcaps for a handful of
APZ-related reftests, mostly with WR enabled. This just updates the fuzz numbers
to match the new values.
Depends on D92677
Differential Revision: https://phabricator.services.mozilla.com/D92678
Instead of using overflow:hidden on the body to hide the scrollbar, this
patch sets scrollbar-width:none on the html element. In some cases
overflow:hidden is set on non-root scrollers (i.e. div elements); in those
cases it is replaced by overflow:scroll;scrollbar-width:none to get an
equivalent effect.
One test had a pre-existing visible scrollbar on a nested scrollframe, but
which started failing with a small fuzz difference. I left the scrollbar as-is
and added an annotation to the reftest.list file.
Note that this only updates the tests that use reftest-async-scroll as those
were the cases that were easily detectable, and causing problems with the
apz.allow_zooming=true pref.
Differential Revision: https://phabricator.services.mozilla.com/D82032
Instead of using overflow:hidden on the body to hide the scrollbar, this
patch sets scrollbar-width:none on the html element. In some cases
overflow:hidden is set on non-root scrollers (i.e. div elements); in those
cases it is replaced by overflow:scroll;scrollbar-width:none to get an
equivalent effect.
One test had a pre-existing visible scrollbar on a nested scrollframe, but
which started failing with a small fuzz difference. I left the scrollbar as-is
and added an annotation to the reftest.list file.
Note that this only updates the tests that use reftest-async-scroll as those
were the cases that were easily detectable, and causing problems with the
apz.allow_zooming=true pref.
Differential Revision: https://phabricator.services.mozilla.com/D82032
Bug 1635406 made it so that webrender snaps the offsets of animated
transforms before accumulating them in to the reference frame
transform. Unfortunately, however, this causes jittery animations. The
original intention was just to snap the visual viewport offset when
scrolling, to avoid excessive picture cache invalidation.
To avoid this, make it so that we only snap for reference frames of
kind ReferenceFrameKind::Zoom. This will mean that most animations are
unaffected. There may however still be some jitter when zooming, but
this is outweighed by the benefit of not invalidating picture cache
tiles every frame when scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D77679
Bug 1620014 attempted to fix an issue where an animated visual
viewport offset (eg due to scrolling while being zoomed in) was
causing the fractional offset of a descendant scroll frame's content
transform to change, causing too much picture cache invalidation.
It did so by snapping the coordinate-system-relative offset when using
it to calculate the content_transform. This value of course includes
the animated visual viewport offset (as the axis-aligned zoom
transform cannot reset the coordinate system). However, it also
includes non-animated offsets, which were now being incorrectly
snapped, causing blurry/clipped text.
This change reverts that original fix. And instead, it snaps the
source_transform of the reference frame itself when it is sampled,
rather than the accumulated coordinate-system-relative scale_offset of
the scroll frame. Additionally, it only snaps the offset if it is an
animation (including zoom), and static offsets are left unsnapped.
Differential Revision: https://phabricator.services.mozilla.com/D76298
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59597
--HG--
extra : moz-landing-system : lando
Changes:
As with other ubuntu1804 reftests, the difference counts need to be updated when run with `webrender`. Once migration is complete, tighten the values.
Differential Revision: https://phabricator.services.mozilla.com/D57604
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
In the next part, the patch generated by a script removes "-moz" prefix
to all multi-column properties.
However, some of the tests already have standard multi-column properties
specified. To avoid duplicating CSS multi-column rules in these
files (after applying the next part), I manually remove the prefixed
rules beforehand as many as possible.
Differential Revision: https://phabricator.services.mozilla.com/D44869
--HG--
extra : moz-landing-system : lando
These changes are needed for consistently green runs with the new emulator with
"-gpu on".
Most changes are simple removal of fuzzy-if(geckoview) but I also needed to add
at least one new fuzzy-if.
In this configuration we can run reftests in just 2 chunks (20 minutes each on
opt/30 minutes on debug).
Differential Revision: https://phabricator.services.mozilla.com/D36258
--HG--
extra : moz-landing-system : lando
There are a number of failures, for which I've filed separate bugs.
And then a lot of fuzziness. I manually inspected the reftest analyzer
results on try pushes to distinguish failures vs fuzziness.
Depends on D34537
Differential Revision: https://phabricator.services.mozilla.com/D34538
--HG--
extra : moz-landing-system : lando
After introducing column-span, the ColumnSetWrapperFrame can have more
than one ColumnSetFrame children if there's any column-span:all child.
Thus we cannot use "height:100%" to pass block size information down to
the -moz-column-content's children.
Skip column span wrapper in nsIFrame::IsBlockWrapper() so that the
percentage column-span:all works.
Before this patch, the height of column contents are set to 100% of the
multicol container, so if the previous in-flows of column content
anonymous boxes consume all the height, later in-flows's height are all
0. In this patch, we don't restrict column-content's height, so their
height are calculated based on their children's height.
column-contain-1a.html passes because it can now correctly calculate the
union of all the column content's rect to find the correct sticky
positioning.
Differential Revision: https://phabricator.services.mozilla.com/D27627
--HG--
extra : moz-landing-system : lando
The API to create a sticky spatial node doesn't allow us to set a clip
chain that will apply to all the contents of the sticky node. This means
that when the ClipManager sets up the clip state for the sticky node,
the clip chain for it is dropped. Everything still works currently
because the contents of the sticky node have their own clip chains whose
parent link will include the sticky node's clip chain. However, in the
next patch we're going to sever that parent link to fix other issues,
and so we will break this mechanism. This patch fixes it up by
explicitly applying the sticky node's clip chain to the stacking context
that contains all the sticky contents. This ensures all those items pick
up the clip chain.
Differential Revision: https://phabricator.services.mozilla.com/D18100
--HG--
extra : moz-landing-system : lando