Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--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
So that we can use for KeyframeEffect::GetPropertiesForCompositor().
Depends on D12396
Differential Revision: https://phabricator.services.mozilla.com/D12397
--HG--
extra : moz-landing-system : lando
I.e., continue the loop if the CSS property is not what we want and set the
result value only if the CSS property is effective.
This change makes the function match
what KeyframeEffect::GetEffectiveAnimationProperties does in the similar loop
so that we can unify the iteration into a single function in the next commit.
Depends on D11597
Differential Revision: https://phabricator.services.mozilla.com/D11598
--HG--
extra : moz-landing-system : lando
This change gets all effective CSS properties on an nsIFrame just once.
Note that LayerAnimationInfo::GetCSSPropertiesFor intentionally returns
nsCSSPropertyIDSet instead of nsCSSPropertyID since when we support individual
transform properties for the compositor the mapping between display item types
and nsCSSProperty has to be 1:N. E.g. all scale/translate/rotate properties are
mapped to transform display item.
Depends on D11424
Differential Revision: https://phabricator.services.mozilla.com/D11425
--HG--
extra : moz-landing-system : lando
If mIsRunningOnCompositor is true, the property is effective state because
CanThrottle() is called in advance of a restyle for the effect so that we can
drop the check and drop skipping in the case of non-effective properties.
Depends on D10694
Differential Revision: https://phabricator.services.mozilla.com/D10695
--HG--
extra : moz-landing-system : lando
The comment there was wrong. We just bail out from there only if
mIsRunningCompositor is false, so it doesn't matter whatever the layer
generation check results. (i.e., we don't bail out in the case where
mIsRunningCompositor is true).
Also, we iterate over mProperties in the LayerAnimationInfo::sRecords loop
through HasEffectiveAnimationOfProperty, so it doesn't matter that we iterate
mProperties before the loop either. We will avoid the iteration in the sRecords
loop in a subsequent patch in this series.
Depends on D10692
Differential Revision: https://phabricator.services.mozilla.com/D10693
--HG--
extra : moz-landing-system : lando
In the case of WebRender there is no layers, but actually we'd been using it for
WebRender too, that's confusing.
Depends on D10689
Differential Revision: https://phabricator.services.mozilla.com/D10690
--HG--
extra : moz-landing-system : lando
If mIsRunningOnCompositor is true, the property is effective state because
CanThrottle() is called in advance of a restyle for the effect so that we can
drop the check and drop skipping in the case of non-effective properties.
Depends on D10694
Differential Revision: https://phabricator.services.mozilla.com/D10695
--HG--
extra : moz-landing-system : lando
The comment there was wrong. We just bail out from there only if
mIsRunningCompositor is false, so it doesn't matter whatever the layer
generation check results. (i.e., we don't bail out in the case where
mIsRunningCompositor is true).
Also, we iterate over mProperties in the LayerAnimationInfo::sRecords loop
through HasEffectiveAnimationOfProperty, so it doesn't matter that we iterate
mProperties before the loop either. We will avoid the iteration in the sRecords
loop in a subsequent patch in this series.
Depends on D10692
Differential Revision: https://phabricator.services.mozilla.com/D10693
--HG--
extra : moz-landing-system : lando
In the case of WebRender there is no layers, but actually we'd been using it for
WebRender too, that's confusing.
Depends on D10689
Differential Revision: https://phabricator.services.mozilla.com/D10690
--HG--
extra : moz-landing-system : lando
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
There doesn't appear to be any need to separate these anymore.
MozReview-Commit-ID: GHR259JJHJV
--HG--
extra : rebase_source : e9b15c820df97570c3f6e978a7f0c224e33f0468
This is no longer needed since in bug 1456394 we merged the two types of
KeyframeEffects into one.
MozReview-Commit-ID: 8IuTD9ivAGK
--HG--
extra : rebase_source : b14593b33bfa9a0233b524010b3bde3cfc078950
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
In the next patch, we are going to unthrottle UpdateOverflow change hint which
is also produced by non-transform properties.
MozReview-Commit-ID: BrJxo32uBJO
--HG--
extra : rebase_source : daeb91bc4ce44a120ce4092f9f113c78f0553326
In the next patch, we are going to unthrottle UpdateOverflow change hint which
is also produced by non-transform properties.
MozReview-Commit-ID: BrJxo32uBJO
--HG--
extra : rebase_source : daeb91bc4ce44a120ce4092f9f113c78f0553326
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Without this fix layout/reftests/css-animations/ib-split-sibling-opacity.html
would have failed if the next change in this patch series is applied.
MozReview-Commit-ID: CFNXePkXuOs
--HG--
extra : rebase_source : 48df6bf107e1a14dd2b2ae7c23d38d29581aabcb
Brian Birtles
Sylvestre Ledru
Hiroyuki Ikezoe
Andreea Pavel
Margareta Eliza Balazs
Diego Pino Garcia
Xidorn Quan
Emilio Cobos Álvarez
Jeff Gilbert
Chris Peterson