This bug became an unexpected PASS on tier-2 android platform after
landing the fixes for bug 1572197. The fixes in that bug were
specifically to fix this test on windows platforms, so it's not
surprising that it also fixes it on android.
Differential Revision: https://phabricator.services.mozilla.com/D41493
--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
This patch implements the majority of the planned picture caching
improvements. It supports most of the functionality required to
(as a follow up) support OS compositor integration. It also improves
on the robustness and functionality of the previous picture caching
implementation.
There are some expected temporary performance regressions in
some cases (such as content that is constantly invalidating) and
during initial page render when many render targets must be drawn
to. These performance regressions will be resolved in follow up
commits by supporting multi-resolution tiles.
The scene is split into a number of slices, determined by the scroll
root of each primitive, which can be found by the primitive's
spatial node indices. If a scene contains too many slices, then
picture caching is disabled on the page, to avoid excessive texture
memory usage, and rendering falls back to rasterizing each frame.
The specific changes in this patch are:
* Support tile caches for multiple scroll roots, allowing the
entire page (including fixed divs and the main UI bar) to be
cached in most cases, in addition to the main content.
* Remove requirement to read tiles back from the framebuffer.
Instead, they are drawn into the picture cache target tiles,
and blitted to the screen. This is slightly slower than the
existing picture caching when content is constantly changing,
however this cost will disappear / become irrelevant when
the OS compositor integration work is complete.
* Switch picture cache render targets to be nearest sampled (they
are always rendered 1:1) and support depth buffer targets.
* Make use of the external scroll offset support to allow removal
of the primitive correlation hacks in the previous picture
caching implementation. Also allows storing of primitive
dependencies in picture space rather than world space, which
reduces floating point inaccuracies.
* Determine if each tile and picture cache can be considered
opaque. This is used to determine whether subpixel AA text
rendering is available on a slice, and for rendering optimizations
related to disabling blending and/or tile clears.
* Use the clip chain instance results from the recent visibility pass
work to determine clip chain dependencies. This results in fewer
clip item dependencies in tiles, which is faster to check validity
and reduces redundant invalidations.
* Remove extra overhead during batching related to batch lists,
and region iteration, as they are no longer required.
* Support PrimitiveVisibilityMask during batching. This allows a
single traversal of a picture (surface) root during batching to
efficiently construct multiple alpha batcher objects (typically
one per invalida tile).
* Picture caching is now handled implicitly by WR, depending on
the content of the scene. There is no requirement for client
code to manually select which stacking context should be cached.
* Simplify how clip chain / transform dependencies are tracked by
picture cache tiles.
* Support pushing / popping enclosing clip chain roots without
the need for a stacking context / picture in some cases. This
simplifies the logic to split the scene into multiple slices.
The main remaining work in this area is (a) extend the code to
optionally provide each slice as an input to the OS compositor
rather than drawing the tiles in WR, and (b) support multi-resolution
tiles so that we reduce the draw call, batching and render target
overhead in cases where much of the page content is changing.
Differential Revision: https://phabricator.services.mozilla.com/D34319
--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
Relocated the `fuzzy-if` conditions for windows10-aarch64 in the files listed below, as the fuzzy condition was being overridden by conditions that came later.
Also tuned some of the values for pixel differences to reduce oranges.
Differential Revision: https://phabricator.services.mozilla.com/D25113
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
The text in the <th> element was causing intermittent fuzz due to
antialiasing. This patch removes the text to eliminate the problem.
Differential Revision: https://phabricator.services.mozilla.com/D18092
--HG--
extra : moz-landing-system : lando
The contain:paint clipping would be redundant and hence unnecessary in this
scenario, because:
- Scroll frames already clip their descendant frames.
- contain:paint has other (non-clipping-related) effects that prevent
descendant frames from escaping the scrollframe ancestor.
So, no further clipping is required.
This is a behavior change - it works around an issue that makes us fail to
repaint mousewheel-scrolled content inside of any scrollframe that returns true
from ShouldApplyOverflowClipping().
Differential Revision: https://phabricator.services.mozilla.com/D12056
--HG--
extra : moz-landing-system : lando
adjust fuzzy-if statements for win10 tests that are fialing on new windows 10 ami image
Differential Revision: https://phabricator.services.mozilla.com/D11914
--HG--
extra : moz-landing-system : lando
When async-zooming, the compositor applies an invalid offset transformation to
position:fixed elements, causing them to be positioned incorrectly until a
repaint occurs.
MozReview-Commit-ID: IZEN1gtpbIA
--HG--
extra : rebase_source : c74df0ccdb44b4ad54c366eefbac1e46bab9dc7b
The first set of tests test that fixed/sticky position elements are no longer
attached to the visual viewport (i.e., that they go "out of view" when the
visual viewport is scrolled) and the second set of tests test that
fixed/sticky position elements are attached to the layout viewport (i.e., that
they "follow" the layout viewport when it's scrolled).
MozReview-Commit-ID: 6H2f0oz9lW7
--HG--
extra : rebase_source : c6e1beebe58883c0e500c28d579eb187c2cc8ea1
This patch was written entirely by the following script:
#!/bin/bash
if [ ! -d "./.hg" ]
then
echo "Not in a source tree." 1>&2
exit 1
fi
find . -regex '.*\(ref\|crash\)test.*\.list' | while read FILENAME
do
echo "Processing ${FILENAME}."
# The following has four substitutions:
# * The first one replaces the *first* argument to fuzzy() when it doesn't
# have a - in it, by replacing it with an explicit 0-N range.
# * The second one does the same for the *second* argument to fuzzy().
# * The third does the same for the *second* argument to fuzzy-if().
# * The fourth does the same for the *third* argument to fuzzy-if().
#
# Note that this is using perl rather than sed because perl doesn't
# support non-greedy matching, which is needed for the first argument to
# fuzzy-if.
perl -pi -e 's/(fuzzy\()([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy\([^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,)([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,[^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g' "${FILENAME}"
done
Differential Revision: https://phabricator.services.mozilla.com/D2974
--HG--
extra : moz-landing-system : lando
The test case has a fixed item A inside a scrollframe B which is inside
a reference frame C which is inside the root scrollframe D. The
ClipManager code currently uses D's scrollid as the scrolling ancestor
for A, because the gecko display list's ASR is set up that way. However,
we really want to set C as the scrolling ancestor, because otherwise the
item A gets hoisted out of C and the transform from C doesn't get
applied to it. This patch ensures that when we enter C, we install an
override so that anything that would have used D's scrollid ends up
using C's, which results in the correct behaviour.
MozReview-Commit-ID: 31tscfT4xWW
--HG--
extra : rebase_source : 03df2fa5519b2592a2c9f598af0f3f1500773718
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
