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
We manually implement ComputeSquaredDistance for Translate, Rotate, and
Scale because we have to handle mismatch cases, and actually we don't
need to implement it for specified types.
Depends on D11934
Differential Revision: https://phabricator.services.mozilla.com/D11935
--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
It's worth to serialize the timing function from web animation api with
servo, too. However, we need an FFI to do that, so this patch also add a
new FFI.
Depends on D10443
Differential Revision: https://phabricator.services.mozilla.com/D10444
--HG--
extra : moz-landing-system : lando
For now, we keep supporting the prefixed version, since there are examples/instructions
on the Web that don't include an unprefixed value.
Differential Revision: https://phabricator.services.mozilla.com/D10451
--HG--
extra : moz-landing-system : lando
For some content both transitions and animations are triggered simultaneously.
As a result of bug 1301305, if the set of animations includes animations that
affect geometry, then we ensure that any transform animations are run on the
main thread, rather than on the compositor.
However, we have observed some content where this synchronizing is not necessary
and produces unnecessary jank. In the particular cases we have observed,
the transitions and animations do not need to be synchronized so this patch
refines the approach from bug 1301305 to only synchronize within the set of CSS
transitions or the set of non-transition animations.
Differential Revision: https://phabricator.services.mozilla.com/D10328
--HG--
extra : moz-landing-system : lando
1. Add a new preference, layout.css.step-position-jump.enabled, for
step(_, jump-*) timing functions.
2. We still keep JumpEnd and End tags, even though there is no difference
between them. Therefore, we could disable the preference if needed.
3. Update the calculation of StepTiming to match the algorithm in the spec.
4. For servo, we implement the correct step function algorithm except
for the handling of before_flag. This could be fixed later.
Depends on D9313
Differential Revision: https://phabricator.services.mozilla.com/D9314
--HG--
extra : moz-landing-system : lando
First, we generate StyleComputedTimingFunction by cbindgen from Rust, and use
it in nsTimingFunction, so we could copy it directly without handling
the different memory layout. However, we have to rewrite the
nsTimingFunction and mozilla::ComputedTimingFunction for this.
Second, the rust-bindgen seems cannot generate the correct generic members
from complex C++ templates, especially for the nested template struct,
(https://github.com/rust-lang-nursery/rust-bindgen/issues/1429)
So we have to hide StyleTimingFunction to avoid the compilation errors.
Depends on D9312
Differential Revision: https://phabricator.services.mozilla.com/D9313
--HG--
extra : moz-landing-system : lando
frames() timing function was removed from the spec, so we drop it.
Besides, some devtool tests are removed because they use frame(). I will
add them back by using new step function later.
Differential Revision: https://phabricator.services.mozilla.com/D9309
--HG--
extra : moz-landing-system : lando
This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
--HG--
extra : moz-landing-system : lando
When a compositor animation finishes that doesn't apply a fill, rather than
jumping back to the underlying value immediately we should apply a fill mode
until the main thread has a chance to remove the animation from the compositor.
This ensures that any main thread effects that are intended to synchronize with
the end of the animation have a chance to run before we show the underlying
style and helps to avoid flicker in such cases.
Currently we apply this synthesized fill mode to animations when they run
forwards (i.e. positive playback rate), but not backwards. This patch makes us
apply the same handling when running in reverse.
Differential Revision: https://phabricator.services.mozilla.com/D7259
--HG--
extra : moz-landing-system : lando
According to the new svg 2 spec update (#543), we flip the flag half way for
path interpolation.
Differential Revision: https://phabricator.services.mozilla.com/D6192
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Add tests for ComputeSquaredDistance on |offset-path:path()|.
Depends on D4791
Differential Revision: https://phabricator.services.mozilla.com/D4788
--HG--
extra : moz-landing-system : lando
flushComputedStyle is as follows:
var cs = getComputedStyle(elem);
cs.marginLeft;
That _probably_ flushes style in most engines, but it's possible some engine in
the future will optimize things in a way that it can flush marginLeft without
flushing, say, backgroundColor. Before moving these tests to wpt, it would be
better to explicitly flush the property (or at least one of the properties) we
are transitioning.
This patch also updates the "Setting zero combined duration" test from
test_animation-cancel.html since, in making this change, I realized the test was
wrong.
Specifically, it was testing that when we set a combined duration of zero that
a transition is canceled. However, nothing in the spec requires this. The spec
only requires a non-zero combined duration to _start_ a transition and only
cancels an existing transition if the combined duration becomes _zero_ if the
"the end value of the running transition is not equal to the value of the
property in the after-change style".
This test passed, however, because it changed the transition property to
margin-top, hence it was actually testing the same condition as the previous
test.
--HG--
extra : rebase_source : ab1890c3125cb0a136869cd665efd2aa358304f0
