We don't store post-transform overflow areas for frames within preserve-3d, but we do store pre-transform overflow areas.
Rather than just recomputing the changed overflow for the root, we should recompute overflows for all ancestors up to the 3d root.
Differential Revision: https://phabricator.services.mozilla.com/D31213
--HG--
extra : moz-landing-system : lando
On some low end GPUs, clip mask rendering can be a significant
GPU cost. One way to reduce this is to support segment rendering
on more primitive types, to reduce the size of clip masks.
This patch adds support for pictures that have clip masks
to take part in segment rendering. This can significantly
reduce the number of fragments that must be drawn into a clip
mask for off-screen picture surfaces.
In future, WR can take advantage of segment rendering to use
clip mask shaders that handle only a single corner at a time.
This will be a further significant performance win to clip mask
render time.
Differential Revision: https://phabricator.services.mozilla.com/D24852
--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
Now we no longer update the corresponding display items for the animations that
are prevented from running on the compositor if the animations themselves don't
generate any change hints, e.g the same value is specified in both 'from' and
'to' keyframes. So that we can enable the reftests that we had been suffering
from continuous MozAfterPaint events.
Depends on D12397
Differential Revision: https://phabricator.services.mozilla.com/D12369
--HG--
extra : moz-landing-system : lando
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
For example, if we set a transform to rotate3d(0, 0, 1e50, 45deg), the
expected normalized rotate axis is (0, 0, 1).
However, the length is larger than the maximum of float, so the actual value is
(0/inf, 0/inf, 1e50/inf) == (0, 0, 0). Therefore, we scale the vector before
doing normalization to avoid getting a zero vector.
MozReview-Commit-ID: 5LUDWD4RuNj
--HG--
extra : rebase_source : eb82f0b3979bf6ea3cd11b643ebb30a49edc24f8
These tests rely on an optimization within Gecko where it stops firing
MozAfterPaint events if there was no visible change to the generated
layers. This allows the reftest harness to exit the
waiting-for-MozAfterPaint loop and proceed with the test. However, with
webrender, this optimization does not exist and so the loop never exits.
In order to solve this problem, this patch adds an explicit mechanism to
exit the loop by means of a class attribute on the root element of the
test page.
MozReview-Commit-ID: 17ta5kLPDr9
--HG--
extra : rebase_source : 96ea462274724c6c65f1186f473bc1767253fd6b
Many of these could probably be fuzzed but in the interests of getting
the reftest suite turned on sooner I'm doing a blanket fails-if. This
covers all the reftests where there is more fuzz with webrender on
windows than any of existing annotations account for. In some cases the
fuzz is only a few pixels more than the equivalent Linux fuzz already
annotated, but I'll clean that up in a future bug.
MozReview-Commit-ID: IaKarbnL46d
--HG--
extra : rebase_source : 71889340305b0b12fa8eace722e42bb3faf14419
This matches the behaviour of ChooseScaleAndSetTransform()
MozReview-Commit-ID: LxtkQn2XdYT
--HG--
extra : rebase_source : 9d2a9b1af9bf039def408f86982da835b7120e36
