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.
In order to support arbitrary timelines which may provide a "null" current time,
we need a suitable value to return from GetComputedTimingAt for the animation's
phase when the timeline time is null.
This patch introduces a null animation phase for this purpose.
This patch adds the WebIDL definitions and implementation of
getAnimationPlayers on Element.
It does not include the full definition of AnimationPlayer but only readonly
versions of the currentTime and startTime attributes since these are easy
to implement and enable identifying the different animations that are returned
for the sake of testing.
Web Animations defines getAnimationPlayers as only returning the animations that
are either running or will run in the future (known as "current" animations).
This will likely change since it seems desirable to be able query animations
that have finished but are applying a forwards fill. For now, however, this
patch makes us only return animations that have not finished.
This patch also removes an assertion in ElementAnimation::GetLocalTime that
would fail if called on a finished transition. This assertion is no longer
necessary since an earlier patch in this series removed the overloading of
the animation start time that meant calling this on a finished transition
was unsafe. Furthermore, this assertion, if it were not removed, would fail
if script holds onto a transition and queries its start time after it
completed.
When we expose ElementAnimation objects to script they need to have a parent
object so they can be associated with a Window.
This patch adds a pointer from an ElementAnimation to its AnimationTimeline.
When transitions finish, we keep them around for one additional throttle-able
tick to provide correct behavior for subsequent transitions that may be
triggered. Prior to this patch we did this by overloading the start time of the
animation and setting it to null in this case.
However, if we begin returning ElementAnimation objects to script, script can
hold on to those objects and query their start time even after they are
finished. Therefore we need another means of marking finished transitions that
doesn't clobber the start time field.
This patch introduces a new boolean member for marking such transitions.
While we're touching IsFinishedTransition we also take the chance to tidy up one
of the call sites, namely IsCurrentAt, to make the logic a little easier to
follow.
* Replace png images with svg images for touch caret and selection
carets.
* Fix touch caret is enlarged on high resolution device due to
background-size was not set.
When animation-name does not match a keyframes rule, we should not dispatch
animation events as per:
"Any animation for which both a valid keyframe rule and a non-zero duration
are defined will run and generate events; this includes animations with empty
keyframe rules."
http://dev.w3.org/csswg/css-animations/#events
Since bug 1004377, however, we started dispatching events in this case because
we no longer ignore animations whose set of keyframes is empty.
This patch checks for a matching keyframes rule in BuildAnimations and if one is
not found, no corresponding animation is generated.
This patch causes animations whose corresponding animation-name is "none" to be
dropped from the list of generated ElementAnimation objects. This means we avoid
generating events for these animations.
The -*- file variable lines -*- establish per-file settings that Emacs will
pick up. This patch makes the following changes to those lines (and touches
nothing else):
- Never set the buffer's mode.
Years ago, Emacs did not have a good JavaScript mode, so it made sense
to use Java or C++ mode in .js files. However, Emacs has had js-mode for
years now; it's perfectly serviceable, and is available and enabled by
default in all major Emacs packagings.
Selecting a mode in the -*- file variable line -*- is almost always the
wrong thing to do anyway. It overrides Emacs's default choice, which is
(now) reasonable; and even worse, it overrides settings the user might
have made in their '.emacs' file for that file extension. It's only
useful when there's something specific about that particular file that
makes a particular mode appropriate.
- Correctly propagate settings that establish the correct indentation
level for this file: c-basic-offset and js2-basic-offset should be
js-indent-level. Whatever value they're given should be preserved;
different parts of our tree use different indentation styles.
- We don't use tabs in Mozilla JS code. Always set indent-tabs-mode: nil.
Remove tab-width: settings, at least in files that don't contain tab
characters.
- Remove js2-mode settings that belong in the user's .emacs file, like
js2-skip-preprocessor-directives.
This patch makes the active duration a property of the ComputedTiming struct and
returns this as part of calculating GetComputedTimingAt. GetComputedTimingAt was
already calling the method to calculate the ActiveDuration and the only other
callers of ActiveDuration() were also calling GetComputedTimingAt so this
doesn't make us do any unnecessary calculation.
I've left ActiveDuration as a public method on ElementAnimation for now since
it's a struct and just about everything there is public. At some point in the
future we'll probably make this more class-like to hide some details but that
can happen as a separate step. This patch does, however, move the definition of
ActiveDuration inside the .cpp file.
In tidying up GetComputedTimingAt we also replace all the references to
TimeDuration() and TimeDuration(0) with a single local variable representing
zero duration. This should be easier to read and possibly a little faster.
We don't use a function static variable since this method is called from
different threads and the initialization of function statics is not guaranteed
to be thread-safe until C++0x.
In TimeStamp_windows.cpp and TimeStamp_darwin.cpp, in
TimeStamp::FromMilliseconds we cast the floating-point number of ticks to
a 64-bit integer before passing to TimeStamp::FromTicks(int64_t).
This means that we skip the check for integer overflow performed by
TimeStamp::FromTicks(double).
This patch simply removes that cast so that we perform overflow checking.
It also adds an assertion to ElementAnimation since this is one place where
the lack of overflow checking was producing a negative value where it should
not.
This patch also moves the static methods defined on nsStyleAnimation so that
they are part of StyleAnimationValue class.
Renaming nsStyleAnimation.h to StyleAnimationValue.h is performed in a separate
patch to simplify the diff (since some tools may not handle file renames
elegantly).
This patch takes the two static methods ElementAnimationsPropertyDtor and
ElementTransitionsPropertyDtor and replaces them with a class static on
CommonElementAnimationData.
This patch removes ElementAnimations and replaces all references to
ElementAnimations with references to CommonElementAnimationData.
We don't bother to rename variables like 'ea' or methods like
GetElementAnimations to correspond with the data type
(CommonElementAnimationData) since CommonElementAnimationData will soon be
renamed in bug 1010067 and we'll rename these things then.
The ElementAnimationsPropertyDtor function is renamed and merged in a subsequent
patch in this series.
In order to unify ElementAnimations with CommonElementAnimationData we need to
find another home for GetEventsAt which is specific to queueing CSS Animation
events. For now nsAnimationManager seems an appropriate place and corresponds
more closely to the arrangement for transitions (where nsTransitionManager is
responsible for queueing the events by iterating over the list of animations).
In future we may reintroduce a subclass of animation specific to CSS Animations
that does this event queueing but for now nsAnimationManager seems to be a
suitable place.
This patch simply moves the code and replaces references to "mAnimation" with
"eEA->mAnimation". There are no functional changes.
This patch adds a test for transitions with a delay that run on the compositor.
Currently animations (including transitions) are not sent to the compositor
until they reach the end of their delay phase introducing the possibility that
the behavior might differ for animations with or without delays.
This patch adds a simple test for a transition with a delay. It also fixes an
existing bug in the opacity test. Also, it moves the step where the "transition"
property is removed to the end of the test sequence rather than the end of the
opacity test (which previously happened to occur at the end of the test
sequence).
This patch moves PostRestyleForAnimation from ElementAnimations to the base
class CommonElementAnimationData and makes use of it within nsTransitionManager.
IsForElement and PseudoElement are currently only defined on ElementAnimations
but could be used for transitions. This patch moves these methods to the common
base class CommonElementAnimationData and also makes use of PseudoElement within
nsTransitionManager.
This patch moves PostRestyleForAnimation from ElementAnimations to the base
class CommonElementAnimationData and makes use of it within nsTransitionManager.
IsForElement and PseudoElement are currently only defined on ElementAnimations
but could be used for transitions. This patch moves these methods to the common
base class CommonElementAnimationData and also makes use of PseudoElement within
nsTransitionManager.
This patch replaces all references to ElementTransitions (now that it is empty)
with references to the base class, CommonElementAnimationData. It also takes the
opportunity to tidy up some of the call sites in nsLayoutUtils since they no
longer need to differentiate between animations and transitions.
In order to remove redundant code and generally make transitions less special,
this patch reworks ValuePortionFor to reuse the existing code for calculation
the fractional distance of within the animation interval.
A previous patch moved CanPerformOnCompositorThread to
CommonElementAnimationData including a FIXME saying that active layer
notification should happen at call sites. Now that the code for
GetAnimationsForCompositor is common, we can do the active layer notification
there.
This patch still leaves ElementAnimations|
ElementTransitions::GetAnimationsForCompositor as shortcuts
for the method now defined on CommonElementAnimationData.
This patch moves HasAnimationOfProperty to CommonElementAnimationData. It also
takes the chance to start removing some redundancy from nsLayoutUtils
/ ActiveLayerTracker. Some of this should never have been added in the first
place and some could have been removed earlier on but while we're fixing up
HasAnimationOfProperty it seems like an appropriate time to fix up its call
sites too.
Also, since HasAnimationOrTransition actually returns an object, not a bool, we
this patch renames it to GetAnimationsOrTransitions.
In a number of places in nsAnimationManager we have the following sequence of
calls:
CommonElementAnimationData::EnsureStyleRuleFor
ElementAnimations::GetEventsAt
nsAnimationManager::CheckNeedsRefresh
nsAnimationManager::EnsureStyleRuleFor already does exactly that so we should
just reuse it.
At the same time we rename EnsureStyleRuleFor to UpdateStyleAndEvents since
that's a bit more accurate. It's also confusing to have two methods of the same
name (but on different objects) that don't exactly correspond in terms of
the scope of what they do.
Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method.
The ElementAnimations version is a more general of the ElementTransitions one
with the exception that the ElementTransitions version checks for finished
transitions. This patch moves the code from ElementAnimations to
CommonElementAnimationData with one minor change: adding the checks for finished
transitions. The ElementTransitions version is removed.
Since the ElementAnimations version contains a second parameter, aIsThrottled,
callers of ElementTransitions must include this extra parameter. In
a subsequent patch we add an enum for this parameter to make call sites easier
to read.
The ElementAnimations version also sets the mNeedsRefreshes member so at the
same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore,
since the ElementAnimations version which we have adopted returns early if
mNeedsRefreshes is false, this patch ensures that when we call
EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set
mNeedsRefreshes to true first.
Another difference to account for is that the ElementTransitions version of
EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to
it) where as the ElementAnimations version only creates the rule when necessary
so we need to add a check to ElementTransitions::WalkTransitionRule that
mStyleRule is actually set before using it.
Now that an animation's delay is part of AnimationTiming--the struct we pass to
GetComputedTimingAt--it makes sense to act on it in GetComputedTimingAt.
This also happens to bring the procedures here closer to the algorithm
definitions in Web Animations.
As part of this refactoring, this patch converts ElementAnimation::IsRunningAt
to use GetComputedTiming since the previous approach no longer works now that
GetLocalTimeAt (nee ElapsedDurationAt) no longer handles delays. This also
removes duplicated logic.
Also, previously ElapsedDurationAt would assert if called on a finished
transition since TimeDuration's - operator wouldn't like the null mStartTime.
This patch adds an assertion for this case to GetLocalTimeAt to ease debugging.
One of the main differences in handling a list of transitions vs a list of
regular animations is that when we are dealing with a list of transitions we
need to check for transitions that have finished and are about to be discarded
but need to be retained temporarily to provide correct triggering of subsequent
transitions. Such transitions are marked as "removed sentinels" and are ignored
for most operations.
This patch moves the methods for setting and checking such transitions to the
base class ElementAnimation so that we can treat animations and transitions
alike without having to downcast or do obscure checks for mStartTime.IsNull()
(which equates to checking if the animation is a "removed sentinel" but is not
particularly clear).
In the process, this patch renames said methods to Is/SetFinishedTransition
since hopefully that is a little easier to understand at a glance.
This patch is the first part in preparing the way to merge ElementTransitions
with CommonElementAnimationData (which we'll eventually rename to something
nicer).
Here we move mTiming from CommonElementAnimationData to the AnimationTiming
struct. While this is not strictly necessary in order to do the later
refactoring it makes it simpler since it:
- Divides time calculation into calculation based on dynamic play state (the
responsibility of animation players in Web Animations terms) and static
author-specified timing parameters (a property of animations in Web Animations
terms).
- In future we will probably put animations on the compositor during their
delay phase so we will want the delay to be present in the AnimationTiming
struct then.
- Makes AnimationTiming line up with the dictionary of the same name in Web
Animations.
This is in preparation for nsStyleCoords becoming non-POD types. The
use of memcpy is a bit of a trap when modifying the style structs, and
it likely has marginal value now that anything with an nsStyleCoord
can't be memcpy-initialized.
In addition to moving the code, this patch also:
* changes the square character from U+25AA to U+25FE to match the spec
* changes all the generating functions from using append to using assign
* removes negative handling from CJKIdeographicToText since it is no longer used there
* fixes indentation and naming conventions
* changes buffer size in DecimalToText
This patch removes the check that skipped queueing events for animations
without keyframes since the spec indicates such animations should dispatch
events.
There is a further correctness fix here for the case where a keyframes rule
is modified using the CSSOM so that it becomes empty. Previously when we
came to create the new animation rules we would end up setting
ElementAnimations::mNeedRefreshes to false since we check if the keyframes
rule is empty and if it is we would skip all further processing (including
setting mNeedsRefreshes).
That means that:
(a) We may end up unregistering from the refresh observer so we would never
dispatch the end event for such an animation.
(b) If the animation was running on the compositor we may never remove it from
the compositor or may not do it in a timely fashion.
To fix both these problems, this patch removes the check for an empty keyframes
rule so that mNeedsRefreshes is set in this case.
This patch adjusts the tests for transform transitions that run on the
compositor to handle transitions that begin with a non-invertible transform.
In this case the first sample at the start of the animation won't create
a layer because in nsDisplayTransform::BuildLayer
/ FrameLayerBuilder::BuildContainerLayerFor we'll skip creating the layer once
we notice the equivalent matrix is singular.
In this patch we detect that case and force an extra sample betwee 0 and 200s at
100s. This means the layer will be created at t=100s and be available for
querying at the next sample.
Similar issues could occur, for example, if the transforms at both t=0s
and t=100s are not invertible but currently that doesn't occur. We can add
handling for that if and when it becomes necessary.
This patch takes the existing tests for transitions running on the compositor
and makes them re-use the same test utility methods as used for testing CSS
Animations that run on the compositor. This means these tests now also check
that the transition is in fact running on the compositor when it is expected to.
It seems the big_omta_round_error is no longer needed so I've removed that.
The test that begins with "skew(45deg, 45deg)" currently fails so it is skipped
here. This is addressed in the next patch in the series.
This patch simply re-arranges the order of arguments to omta_is_approx so that
the delta sits along side the values being compared.
This, I think, makes more sense and also is more consistent when converting
tests from test_animations.html to test_animations_omta.html since the
"RunningOn" parameter is consistently inserted in the second-to-last position
just before the description for both omta_is and omta_is_approx.
This patch removes the line from new_div that forced a style flush. This was
very confusing because:
* It behaved differently to new_div in test_animations.html so copying tests
over was more complex (particularly when registering for events is involved).
* It meant after setting up initial style using new_div you could just call
waitForPaints but if you updated style using elem.style you'd need to call
waitForPaintsFlushed.
In adjusting test_animations_omta.html we are able to simplify the tests
somewhat. This patch also adds a few additional checks that waiting to update
the compositor does not produce different results.
This patch moves some test utility methods from test_animations_omta.html to
animation_utils.js. It also renames addAsyncTest to addAsyncAnimTest and
likewise for a few other methods.
This patch adjusts GetComputedTimingAt to set the time fraction and current
iteration fields of the output computed timing correctly for animations with
zero iteration duration. Care must be taken to handle cases such as animations
that have zero duration but repeat infinitely.
The code is significantly re-arranged to more closely align with the naming and
algorithms defined in Web Animations.
A couple of tests in test_animations.html have been tweaked to account for
floating-point error. This is not because the new code is less precise but
actually the opposite. These tests fall on the transition point of step-timing
functions. The new code uses the closest possible floating-point representation
of these times which happens to cause them to fall on the opposite side of the
transition point.
For example, in evaluating a point 3s into a reversed interval the old code
would give us an intermediate time fraction of:
0.29999999999999982
When we reverse that by subtracting from 1.0 we get: 0.70000000000000018
With the code in this patch we get an intermediate time fraction of:
0.29999999999999999
When we reverse that by subtracting from 1.0 we get: 0.69999999999999996
Hence we fall on the opposite side of the transition boundary.
This patch also makes ElementAnimation::ActiveDuration a static method that
takes timing parameters as an argument. This is so that this method can be
used within ElementAnimations::GetComputedTimingAt (a static method) in a
future patch.
We could also make ActiveDuration() a method of AnimationTiming. I suspect
this logic belongs together in ElementAnimation however.
In a future patch we could also add the active duration to the ComputedTiming
struct which would simplify the only other place this is currently used
which is ElementAnimations::GetEventsAt.
viewport-units-rounding-1.html fails without the patch and passes with
the patch.
viewport-units-rounding-2.html fails with an early version of the patch
but not without the patch or with the final version.
Also shuffle the initialization of members in
nsAnimationManager::BuildAnimations to roughly match the order in which they
are declared (with the exception that mPlayState needs to be set before calling
IsPaused() which is used to set mPauseStart).
This was only needed when we were inspecting the returned time fraction but now
that we inspect the phase it's not necessary to force the fill mode to "both".
This patch simply moves the code from ElementAnimations to ElementAnimation so
that it can later be used in transitions code and so we can later move
EnsureStyleRuleFor to ElementAnimation.
This patch shuffles the code in ElementAnimations::GetEventsAt to make it easier
to follow.
It also removes a check for whether or not the animation is paused.
Previously we would not dispatch events if the animation was paused and in its
active phase (but we would if the animation had finished). There doesn't seem to
be any reason for this. If the animation was paused between the last sample and
the current sample and the boundary of an iteration also occurred in that time
then I expect we should dispatch that event. Removing this check for the pause
state does not cause any tests fail.
Separating out the event logic here makes it clear that we do not dispatch start
events in the situation where one sample falls before the active interval and
one sample falls after it (filed as bug 1004361). This patch adds a comment to
this effect.
This patch simply shifts the event-related code from GetPositionInIteration to
GetEventsAt. Although there are simplifications that could be done to
GetEventsAt, they are deferred to a subsequent patch so as not to obscure the
translation of code from one function to another.
As a result of moving event-related handling from GetPositionInIteration it no
longer needs to support different main-thread vs compositor modes.
This patch makes ElementAnimations::GetPositionInIteration return
a ComputedTiming object instead of just a time portion (time fraction).
Since the ComputedTiming object includes phase information, we can fix those
parts of EnsureStyleRule and GetEventsAt that were temporarily using the time
portion to guess if the animation might have finished or not.
This patch moves the FillsForwards/FillsBackwards methods previously defined on
ElementAnimations to the structure contain the fill mode: AnimationTiming. It
also changes GetPositionInIteration to use these methods.
Introduces a struct to store timing parameters for passing to
GetPositionInIteration. In future this struct is expected to be expanded to
include other timing parameters as well (based roughly on Web Animations'
"Timing" interface, hence the name AnimationTiming).
This patch moves event queuing out of EnsureStyleRuleFor into a separate method.
This is a preparatory step towards making GetPositionInIteration into a more
generic method for calculating the current time fraction.
In order to achieve this, GetPositionInIteration needs to be able to calculate
the correct time portion for times outside the range [0, 1] even when it is not
passed a ElementAnimation object. Specifically, it needs the fill mode of the
animation to be passed in.
(Rather than using FillForwards/FillBackwards this patch just compares the
NS_STYLE_ANIMATION_FILL_MODE_* values directly but FillForwards/FillBackwards
are restored in a subsequent patch when they are added to the struct used to
lump the timing parameters together.)
There are a number of places where positionInIteration is used to determine if
the current sample occurs in the active phase or after. This is sub-optimal but
is fixed in a subsequent patch in this series.
The actual work of removing event queuing from GetPositionInIteration is
deferred to a subsequent patch in order to keep the changes as small as
possible. This patch simply makes separate calls to GetPositionInIteration for
interpolating and for event queuing.
This patch adds tests for triggering animations based on the length of the
animation-name property as well as tests for dynamic changes to style rules.
These tests are based on tests in test_animations.html but for directed at
animations that run on the compositor thread.
This patch adds tests for the cascanding of keyframes rules based on those in
test_animations.html but for animations that run on the compositor thread.
This patch adds tests for the interaction of animation and restyling (Bug
686656) based on those in test_animations.html but for animations that run on
the compositor thread.
The implementation here current expects BOTH the following to fail:
- The comparison between the OMTA value and the expected value
- The comparison between the OMTA value and the computed value
This generally tends to be the case since the computed value and expected value
normally match unless we have a bug that affects all CSS animations. If we need
to mark tests where the computed value is also wrong we'll need to modify the
behavior here at that time.
This patch also applies this new function to the author !important test that was
previously commented-out because it currently fails.
This patch also ensures that when we have an animation running on the compositor
when it should not that we still compare the values produced on the compositor
and on the main thread so that the visual result is correct even if the
performance characteristics are not.
This patch adds tests for the handling of author !important rules and animations
based on similar tests in test_animations.html but for animations that run on
the compositor thread.
Due to bug 847287, these tests don't pass and are partly disabled. Subsequent
patches add todo_is tests for this.
This patch adds a version of tests in test_animations.html for bug 651456 which
covers multiple samples with the same timestamp. The version here, however,
tests animations that run on the compositor thread.
This patch adds a version of tests in test_animations.html for keyframe
animations with multiple properties where some properties are present in only
some keyframes. The version here, however, tests animations that run on the
compositor thread.
This patch adds a version of tests in test_animations.html under the heading,
"css3-animation: 3.8 The 'animation-delay' Property", for animations
that run on the compositor thread.
This patch adds a version of tests in test_animations.html under the heading,
"css3-animation: 3.7 The 'animation-play-state' Property", for animations
that run on the compositor thread.
This patch adds a version of tests in test_animations.html under the heading,
"css3-animation: 3.6 The 'animation-direction' Property, for animations
that run on the compositor thread.
This patch addresses and issue where the OMTA style and computed style were not
comparing equal in one particular case.
In this case AddTransformTranslate in nsStyleAnimation would give us
a translate-y value of 94.331673 in both cases (i.e. when calculating the
animated value on the compositor thread or when fetching computed style).
For the OMTA case, however, after we apply additional layer transformations and
then reverse them (so we can query the CSS value) we'd end up with 94.331642,
a difference of 0.000031. The reversing procedure is only used for testing so
the actual error introduced here by the additional layer transformations is
probably less.
Unfortunately, when we pass 94.331642 this along to MatrixToCSSValue we get back
matrix(1, 0, 0, 1, 94.3316) since it only outputs 6 digits of precision.
On the other hand, on the computed style end we'd pass 94.331673 to
MatrixToCSSValue which gives us matrix(1, 0, 0, 1, 94.3317), so the error swells
from 0.000031 to 0.0001.
Then when we subtract 94.3316 from 94.3317 in Javascript we get
0.00010000000000331966 due to floating-point precision issues which compares
greater than the default tolerance of 0.0001.
This patch simply adjusts the default tolerance to 0.00011 to accommodate
these floating-point differences.
This patch adds a version of tests in test_animations.html under the heading,
"css3-animation: 3.5 The 'animation-iteration-count' Property" for animations
that run on the compositor thread.
These tests surface an issue where in some cases precision errors lead to
discrepencies between the OMTA style and computed style. This is fixed in
a subsequent patch in this series.
This patch adds a version of the tests in test_animations.html under the
heading, "css3-animations: 3.2. The 'animation-name' Property" that tests the
same features when animations are running on the compositor thread.
The test harness code for normalizing transform inputs to a standard form for
comparison fails to detect the case where the input is a string such as
{ tx: "20px" }
instead of:
{ tx: 20 }
When we go to compare matrix components we fail if:
Math.abs(a.comp - b.comp) > tolerance
But if a.comp or b.comp is a string, we'll get NaN on the LHS and
"NaN > tolerance" will return false so we'll skip the failure handling and
continue onto the next component. That means if we have input { tx: "30px" } and
we get "20" as the x-translation component we'll pass the test.
This patch fixes this condition to check for isNaN.
We *could* also just drop a few .map(parseFloat) calls into
convertObjectTo3dMatrix and convertArrayTo3dMatrix to ensure "20px" becomes 20
but there may be situations where that masks bugs (since "20px" and "20em" turn
into the same thing) so for now this minimal fix should be enough.
This patch converts the tests in test_animations.html under the heading,
"css3-animations: 3.1. Timing functions for keyframes" to an equivalent version
for testing animations that run on the compositor thread.
These functions get invoked as event listeners, so we'll automatically get the
proper |this|. The reason for the existing shenanigans was to work around
bug 872772, which has now been fixed.
As a result, transitions are now stored using a pointer to the base class,
mozilla::ElementAnimation. We downcast to a transition only when necessary. No
error-checking of the result of AsTransition is performed since we only ever
call it on the mAnimations member of ElementTransitions.
Add a method for downcasting from an ElementAnimation to an
ElementPropertyTransition (when the underlying object is an
ElementPropertyTransition).
This, unfortunately, adds a vtable to ElementAnimation but in the long term
I hope we will be able to isolate transition-specific code to a specific kind of
TransitionEffect that hangs off ElementAnimation and put the vtable on
AnimationEffect instead. (The AnimationEffect concept is part of the Web
Animations API.)
We currently have mozilla::StyleAnimation as well as nsStyleAnimation. This
patch renames StyleAnimation back to ElementAnimation.
Although ElementAnimation is very similar to ElementAnimations, in the near
future we expect to retire ElementAnimations and replace it with a common
AnimationSet-like structure that is covers the features of ElementAnimations and
ElementTransitions.
This patch takes StyleAnimation and makes it ref-counted heap object. This
should allow us to store StyleAnimation and its subclasses (transitions only
currently) in a consistent fashion (an array of base-class pointers).
Furthermore, this will be helpful if we want these things to be pointed to
from Javascript objects that may, for example, preserve their lifetime beyond
that of the element that currently owns them.
This patch also introduces a typedef for an array of refptrs to StyleAnimation
objects (and similarly for the subclass ElementPropertyTransition) to simplify
the code somewhat.