This affects the correctness of transitions that take over from a
running animation. (In the current code this can happen on a single
element; once the cascading changes in bug 960465 are complete it can
only happen via inheritance.)
This version of the patch changes to do the test using opacity rather
than transform, since testing using transforms encountered issues
related to bug 1031688: the presence of phantom transitions due to the
interaction of the computed value rules for transforms distinguishing
between values that the interpolation rules consider identical. (These
problems only appear after patch 24 in this bug changes the coalescing
order between a parent with animations and a child with transitions so
that the parent is handled before the child, instead of transitions
being handled before animations.)
The final two added tests fail without the patch and pass with the patch.
(With the opacity version, the third to last test also fails without the
patch, probably due to the value not having yet been sent to the layer.
This was not an issue pre-patch with the original test using transform,
though. I haven't tested that this happened with patch 0, though, so it
might have been the issue patch 0 fixes.)
This removes each test element when we're done with it so that each
successive test element isn't 100px lower. This is required to keep the
third test element (added in the next patch) onscreen when running tests
on the B2G emulator (other than when running a single test at a time).
This, in turn, is required to get animations in that test properly
shipped to the compositor thread, which is required for the test to
pass.
I think this has become needed due to changes in the configuration of
the VMs on which we're running tests.
--HG--
extra : transplant_source : %83%CE%27M%CF2%0E%A9%0B%B4%9E%BC%AB%E45g%C9J%D4%17
A document that belongs to an iframe that is display:none as no associated pres
context from which to get a refresh driver. However, in this case
document.timeline.currentTime should still never go backwards (since document
timelines are supposed to be monotonically increasing).
This patch makes AnimationTimeline record the last value returned for the
current time so that if the document becomes display:none we can still return
the most recently used time.
This patch changes the order in which we look for matches when updating existing
animations. Previously we would iterate through new animations in a forwards
direction but match old animations by going through the list of animations
backwards.
This patch makes us iterate through both lists in a backwards direction. That
means that if we have:
animation: anim 100s
and later we make it
animation: anim 100s, anim 100s
Then the new animation will be added to the *start* of the list, i.e. prepended,
and the resulting animation will not restart.
Previously when updating animations we'd generate a new list of animation
objects then try to match up animations from the existing list and copy across
state such as start times and notification flags. However, this means that from
the API we end up returning different objects.
This patch makes us maintain the same object identity when updating an existing
animation. It does this by looking for matching animations in both lists. If it
finds a match it copies the necessary information from the *new* animation to
the *existing* animation (but preserving the start time, last notification
etc.). Then, finally, it puts the *existing* animation in the list of *new*
animations and removes the corresponding *new* animation. The existing
animation is also removed from the list of existing animations so that it only
matches once.
The method used for matching is probably not intuitive but this is addressed in
a subsequent patch in this series.
This is similar to bug 1038488, which did the same for style structs.
This means the entire path from frame to style struct should be
allocated using frame IDs or object IDs.
This also moves those 4 operator new methods to be inline to match the
style of all of the others.
I audited that all the members of these structs are initialized by all
their constructors (see patch 1).
The testcase is a slight simplification of dholbert's testcase 2
(attachment 8456312) in the bug. It fails in the reftest harness
without the patch, and passes in the reftest harness with the patch.
This patch introduces a method GetComputedTiming that calls GetComputedTimingAt
supplying the current time of the animation's timeline.
We still keep the GetComputedTimingAt static method since it is used for
off-main thread animation. Furthermore, we keep the second argument to
GetComputedTiming--the animation's timing properties--since on some occasions we
want to override those properties (ElementPropertyTransition::ValuePortionFor
does this). We could also add another overload that also supplies the
animation's timing properties but that can happen as a separate step.
This patch changes ElementAnimation::GetLocalTimeAt so that instead of taking
the current time as input, it uses the animation's mTimeline member to look up
the current time of the associated timeline. As a result of this, it is possible
to remove a few instances of querying the refresh driver for the current time.
Further instances are removed in subsequent patches.
Furthermore, in order to keep the use of time sources consistent, the mStartTime
of new transitions and animations is initialized with the current time from the
animation's timeline rather than with the latest refresh driver tick.
Since this time could, in future, be null, GetLocalTime(At) is updated to check
for a null start time.
GetLocalTimeAt is also renamed to GetLocalTime in the process.
Once we support arbitrary timelines which can return null current time values,
the local time of an animation can also become null so this patch updates
ElementAnimation::GetLocalTimeAt to return a Nullable<TimeDuration>.
Doing this also allows us to pass the result of GetLocalTimeAt directly to
GetComputedTimingAt.
As part of supporting arbitrary timelines, we'd like to pass null times to the
function that calculates computed timing. Incidentally, this also provides
a means for evaluating calculating timing parameters that are independent of the
current time (currently only the active duration) without requiring a valid
time.
This patch updates the signature of ElementAnimation::GetComputedTimingAt to
take a nullable time duration.
We use the Nullable wrapper to represent null TimeDurations since, unlike,
TimeStamp, TimeDuration does not include a null state.
