In the new composite order arrangement CSSAnimations and CSSTransition have the
following life-cycle:
1. Animation created by markup
=> composite order determined by markup
(e.g. CSS animations use tree order and animation-name order;
CSS transitions use transition trigger order)
2. Animation cancelled by changing markup
=> composite order is undefined
3. Animation is played again using the API
=> composite order is defined by when the animation is first played.
Another way of saying this is that, at the point when the animation is
played, it is appended to the "global animation list".
4. Animation is subsequently cancelled / played => no change
We need a way to know when we are going from 2 to 3. It would seem like we
could do that by setting mAnimationIndex to some sentinel value while it is
in 2. However, even when in 2, although the spec doesn't define the composite
order animations at this point (from an API point of view you can't access these
objects and they don't contribute to style so it doesn't need to be defined), we
sometimes will need to establish an order.
This can happen, for example, when an animation queues events and then is later
cancelled before the events are dispatched. Because we sort events based on
their associated animation at the time of dispatch (for performance reasons) we
need a deterministic order for these idle animations.
We do that (in a subsequent patch in this series) by setting mAnimationIndex
when we transition from 1 to 2. That is, these idle animations are effectively
ordered by when they became idle (which always happens in a deterministic
fashion).
The Web Animations specification has replaced the term "sequence number" with
references to a global animation list. This patch applies similar naming
to our animation structures.
This also tests that regions of a fixed background layer that may be revealed by async scrolling are painted.
--HG--
extra : rebase_source : b79de765277d9ea4f23a88f923b06cbeee9712d6
extra : source : 49e72ce8143af66579c8d6c0b6a0f215e9883d5a
This ensures that regions beyond the clip are painted, and async scrolling can reveal them by moving the layer-level clip.
This patch also ensures that we continue creating mask layers for fixed background layers correctly, where appropriate.
--HG--
extra : rebase_source : e0759006463e7d69cd1d916c8e759b35d300a7c7
extra : source : 09922c7c550760f9b61d8ef523281234805af218
In this case the test image is painted using -moz-element which layerizes
differently than not using -moz-element when APZ is enabled. This slight
layerization difference causes a few pixels to be different and the reftest
to fail. Fuzzing it seems reasonable as the fundamental nature of the test
is unchanged.
--HG--
extra : commitid : 1faZ7pEEkxj
This makes reftest command line arguments behave more like other test suites,
so we can use a simple unified syntax for e.g. |mach try|. The patch also
reworks the command line argument parsing to use argparse rather than optparse,
and causes mach to reuse the same parser as the suite.
This unifies how reftests are invoked across desktop and
mobile, and paves the way for introducing more complex
datatypes that are unreasonable to express on the
command line.
