Instead of having `ScriptThread` handle rooting nodes, do this in
`Animations`. This makes it easier to know when it is appropriate to
root and unroot nodes instead of relying on a certain order of events.
This also allows reducing quite a bit the amount of unsafe code.
For legacy reasons, transitions were marked as finished after updating the
style. According to the spec, they should be marked as finished when
animations are updated and before restyle. This change does that as well
as preventing replacement of finished transitions.
Having finished transitions survive a full restyle cycle and allowing
the replacement of finished transition, could lead to issues were
removed from the global list of animating transitions too soon:
1. A transitions finishes
2. Restyle
3. Transitions is marked as finished and events are queued
4. Restyle cancels finished transition and replaces it instead of
clearing finished transition
5. Events are sent for the incorrectly canceled transition removing it
completely from the list of running transitions due to the extra
event.
This event is triggered when an animation iterates. This change also
moves iteration out of style calculation to an "update animations" which
is the next part of having animation event handling match the HTML spec.
This is described in the spec and allows interrupted transitions to
reverse in a more natural way. Unfortunately, most of the tests that
exercise this behavior use the WebAnimations API. This change adds a
test using our custom clock control API.
This removes an extra layer of abstraction and allows Servo to share
more code with Gecko. In addition, we will need to handle raw
`AnimationValue` structs soon in order to fully implement "faster
reversing of interrupted transitions."
This is preparation for sharing this code with layout_2020 and
implementing selective off-the-main-thread animations.
We still look for nodes not in the flow tree in the layout thread.
This change splits the list of animations and transitions, which are
almost always handled differently. It also renames
`ElementAnimationState` to `ElementAnimationSet` and establishes an
`AnimationState` for every transition and animation. This allows us to
stop continually reallocating lists every time a transition or animation
needs to be canceled.
Fixes#14419.
This change corrects synchronization issues with animations, by
reworking the animation processing model to do a quick restyle and
incremental layout when ticking animations.
While this change adds overhead to animation ticks, the idea is that
this will be the fallback when synchronous behavior is required to
fulfill specification requirements. In the optimistic case, many
animations could be updated and applied off-the-main-thread and then
resynchronized when style information is queried by script.
Fixes#13865.
This is triggered when an animation finishes. This is a high priority
because it allows us to start rooting nodes with animations in the
script thread.
This doesn't yet cause a lot of tests to pass because they rely on the
existence of `Document.getAnimations()` and the presence of
`animationstart` and animationiteration` events.
`update_style_for_animation` previously handled both canceling defunct
animations and also updating style to reflect current animation state.
This change splits those two concerns because we want to start handling
replaced or canceled animations and finished animations in two different
places.
This is a refactor, so ideally it shouldn't change any behavior.
When doing a restyle, we should apply animations and transitions to the
new style so that it is reflected in `getComputedStyle()` and the new
style information properly cascades. This is the first part of properly
ticking animations and transitions.
This causes a couple new animations tests failures (along with many new
passes), but we currently don't have support for properly handling
animations after they have completed, so this isn't totally unexpected.
This refactor is preparation for implementing a specification
compliant transitions and animations processing model.
These data structures hold all the animation information about a single
node. Since adding, updating, and modifying animations for a single node
are all interdependent, it makes sense to start encapsulating animation
data and functionality into a single data structure. This also opens up
the possibility for easier concurrency in the future by more easily
allowing per-node mutexes.
This change adds support for canceling CSS transitions when a property
is no longer transitionable or when an element becomes styled with
display:none. Support for canceling and replacing CSS transitions when
the end value changes is still pending. This change also takes advantage
of updating the constellation message to fix a bug where transition
events could be sent for closed pipelines.
Fixes#15079.
This change modifies the names of some methods to make it clearer what
they are doing. It also adds some clarifying comments to explain some
confusing behavior.
The micro-benchmark `style-attr-1.html` regressed slightly with my patch, after
the CascadeLevel size increase.
This benchmark is meant to test for the "changing the style attribute doesn't
cause selector-matching" optimization (which, mind you, keeps working).
But in the process it creates 10k rules which form a perfect path in the rule
tree and that we put into a SmallVec during the cascade, and the benchmark
spends most of the time pushing to that SmallVec and iterating the declarations
(as there's only one property to apply).
So we could argue that the regression is minor and is not what the benchark is
supposed to be testing, but given I did the digging... :)
My patch made CascadeLevel bigger, which means that we create a somewhat bigger
vector in this case. Thankfully it also removed the dependency in the
CascadeLevel, so we can stop using that and use just Origin which is one byte to
revert the perf regression.
Differential Revision: https://phabricator.services.mozilla.com/D53181
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
TimingFunction is defined in a separate spec (i.e. css-easing), instead
of transform, so we move it into a different file.
Depends on D9310
Differential Revision: https://phabricator.services.mozilla.com/D9311
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
This reverts commit d6092fae27.
This change actually makes transitions start, and our code for stopping
transitions is just bogus, so we just keep re-starting them over and over, which
is not good.
The last caller who used was #14418, which did fix a problem but introduced
multiple. In particular, now transitions don't get expired ever, until they
finish running of course.
That is not ok, given you can have something that the user can trigger to change
the style (hi, :hover, for example), and right now that triggers new
transitions, getting this into a really funny state.
I should give fixing this a shot, but it's non-trivial at all.
We were working around the lack of alias support during parsing in
TransitionProperty by doing a Gecko lookup. That's a hack and is now gone.
Bug: 1419695
Reviewed-by: xidorn
MozReview-Commit-ID: EptUvJNTrZr
The key here is that we only filter longhands if the shorthand is accessible to
content and vice-versa. This prevents the bug that prevented me to land this
patch before, which was us not expanding properly chrome-only shorthands.
Again, this is incomplete, and I need to teach LonghandsToSerialize to get a
potentially incomplete list of properties, and all that.
