This will be necessary when we use the restyle tracker for the
animation-only style flush, because animation-only style flushes need to
update *only* the animation style data and no other style data. Thus
using the RestyleTracker for animation-only style flushes requires that
we do this.
This changes the coalescing behavior during the animation-only style
flush by doing tree-based coalescing between the style updates required
by animations and those required by transitions, rather than doing
animations and transitions separately.
Note that both the old and the new code update all
animating/transitioning styles rather than only the throttled styles,
though we should fix that eventually as noted in the FIXME comment in
the code (but only for the existing caller, and not for the new one to
be introduced in bug 960465).
Note that this depends for its correctness on the previous patches to
make the restyling process exact.
The test changes are because the effects of bug 1031688 are changed by
the change in coalescing. In the old code, we updated transition styles
before animation styles; in the new code we do a single pass over the
tree, which for the relevant test means updating animations on the
parent before transitions on the child, which changes the effects of the
bug.
This will be necessary when we use the restyle tracker for the
animation-only style flush, because animation-only style flushes need to
update *only* the animation style data and no other style data. Thus
using the RestyleTracker for animation-only style flushes requires that
we do this.
Note that we're not yet using this code for style contexts that have
pseudo-elements, since we don't run transitions or animations on
pseudo-elements on the compositor thread. But bug 960465 will (with
some more work) start doing so.
The added test passes locally on Linux with OMT compositing and OMT
animations enabled. However, it also passes without the patch because
the calls to FlushAnimations and FlushTransitions from
PresShell::FlushPendingNotifications cover up the damage done by bugs in
the animation-only style flush.
Unfortunately due to lack of global history on B2G and not running OMT
animations tests on any other platforms, the new test won't actually run
in automation right now.
ResolveStyleForRules had various problems: it failed to set importance
correctly and really only handled replacing a path in the rule tree
since it didn't handle creating important rules. (Possibly more.)
This means ResolveStyleWithReplacement will replace only the rules in
the nsRestyleHint rather than always replacing both the animations rule
and the transitions rule. (This will become even more useful later when
we add the ability to replace the style attribute rule.)
This is the start of a refactoring of the existing code in
CommonAnimationManager, nsTransitionManager, and nsAnimationManager,
which will be removed in later patches (after patches in between cause
this code to be used instead of the current code).
But it also handles interesting cases more correctly, such as cases
where style context parents are unusual.
FIXME: It would be nice to add tests for these cases, but they're mostly
pretty obscure (e.g., a transition of 'transform' that's affected by
inheriting 'transform' from ::first-line), so I'm not treating it as a
priority right now.
FIXME: Adjust for eRestyle_Force if bug 931668 lands first.
Later patches will add such types that are like eRestyle_Self but that
only replace the style attribute, animation rule, or transition rule.
I believe this will fix some cache misses in the FindChildWithRules
lookup when restyling. I don't think it will fix any correctness bugs
because the RelevantLinkVisited() bit will always end up set to true
anyway as the non-link descendant of a visited link style context, and
link descendants shouldn't be able to share styles with non-link
descendants due to matching rules in the UA style sheet.
- Verify that instant scroll-behavior is synchronous.
- Verify that smooth scroll-behavior is asynchronous.
- Verify that smooth scroll-behavior is triggered by CSSOM-View DOM methods.
- Verify that instant scroll-behavior interrupts smooth scroll-behavior
animation.
- Verify that smooth scroll-behavior is not framerate dependant.
- Verify that smooth scroll-behavior physics simulations used by animations
converge and allow the animation to reach completion.
- CSSOM-View scroll-behavior smooth scroll animations must produce the same
results indendently of frame-rate:
- Reference samples of scroll position for each frame are captured from a
smooth scroll at 120fps for variations in X-Distance, Y-Distance.
- Test samples are captured from an animation with the same parameters at
varying framerates.
- Variance in position at each sampled interval is compared to the 120fps
reference. To pass the test, the position of each test sample must match
the reference position with a tolerance of one test sample frame's range
of motion. This range of motion is calculated by the position delta of
the reference samples one test frame duration before and after.
- The duration of the reference sample animation and the test sample
animation must match within 1 frame to pass the test.
- The simulation driving the animation must converge and stop on the
destination position for the test to pass.
- Updated ScrollTo method in nsGlobalWindow to accept a
mozilla::dom::ScrollOptions parameter to select between the instant
and smooth MSD motion.
- Updated WebIDL binding boilerplate scrolling functions in nsGlobalWindow
to pass the correct value of mozilla::dom::ScrollBehavior to the
implementation and functions, activating smooth scrolling.
- These functions will need to be updated again to support the scroll-behavior
CSS property in Bug 1010538.
This could be a separate bug, but it's easiest to fix it here, since
removing this assignment enables removing the Makefile.in later.
Untested, but if everything else builds without a custom SHELL
assignment, this module should too.