I have confirmed that by adding this, we end up calling SwapElements() on the
mPropertyValues member when we build up the nsTArray<Keyframe> result in
GetKeyframeListFromPropertyIndexedKeyframe. Without this explicit move
constructor (i.e. with only the default move constructor) the copy-constructor
for mPropertyValues is called.
MozReview-Commit-ID: 6IWkP97RFUr
--HG--
extra : rebase_source : 4ac4b6545337810a3047f2cfb1dac86074116cfb
StyleAnimationValue::ComputeValue(s) will automatically look up the style
context of the supplied element. This is mostly fine, but when we start using
this method in scenarios where we are building the initial style context
(as happens later in this patch series) it can easily land us in a situation
where we iterate indefinitely.
It would be better, instead, to just explicitly pass in the style context we
want to use, as we already do for StyleAnimationValue::ExtractComputedValue.
MozReview-Commit-ID: ZoVBlBRRBI
--HG--
extra : rebase_source : 9012cc2e405fc887f070fbfaa2f9853289882862
Once we tweak moz.build in the next patch, the grouping in the unified build
will change and expose these missing includes so we fix them here, first.
MozReview-Commit-ID: GebEEociwTo
--HG--
extra : rebase_source : 18158fdf8a3c1a1dcf446118371cad1a15fd4daf
Specifically, for the 'composite' member on keyframes, we now indicate "use the
composite value specified on the effect" using a missing/undefined 'composite'
member as opposed to a null value.
MozReview-Commit-ID: ZH45GvCTlP
--HG--
extra : rebase_source : 5acf081fb844f81280765a87ec019b7847ca1885
Before we begin re-arranging KeyframeEffect.h we move ComputedTiming aside
since putting it in a separate file should make navigating the source
easier.
MozReview-Commit-ID: L5GTFAo00sh
--HG--
extra : rebase_source : e88b6ea092c459afa90831de8469697454e00c5a
Add tests in test_animation_observers.html, so we can test elements and pseudo
elements together by setting subtree.
--HG--
extra : rebase_source : 1841d5db93657a07772bc73ce99cb6ab2a43a737
We use the parent element of a pseudo element as the subject to be notified.
Usage:
We record animations targeting to pseudo elements by setting subtree attribute
to true.
MutationObserver(Node, { subtree: ture });
So all the animations targeting to the pseudo elements whose parentElement is
the first argument will be recorded.
--HG--
extra : rebase_source : 3dc87802b65c74c3e5f2ed4504652ba14465fc02
Use NonOwningAnimationTarget as the returned type of
1. KeyframeEffectReadOnly::GetTarget()
2. nsNodeUtils::GetTargetForAnimation(...)
--HG--
extra : rebase_source : 3b0e117528035329fdf4bdbee127f095b710805a
NonOwningAnimationTarget is a struct made of two members:
1. mozilla::dom::Element*
2. mozilla::CSSPseudoElementType
--HG--
extra : rebase_source : df7ecf192c14f1973b064ffe8a31618df2e6955d
At the same time we also make the 'warning' member of AnimationPropertyDetails
no longer nullable and simply use the absence of the member to indicate "no
warning" (which is what we were already doing -- we were never actually setting
it to null).
MozReview-Commit-ID: HdRDbqhCdmw
--HG--
extra : rebase_source : 0282bd9f0e213aa0e1ed1f5b25d58b10fb3dbc0b
extra : histedit_source : 7d1f81dc57e2a55ab0ed6c4919a25b87819d9d58
I think the reason we originally didn't do this is that the
"isRunningOnCompositor" status might be misleading for animations that are
being overridden. That is, there are some animations we don't send to the
compositor because they are being overridden by another animation (e.g. a
CSS animation touching the 'transform' animation will cause a CSS transition
on the same property not to run, despite the fact that transitions apply
higher in the cascade). This is not merely a performance optimization but means
we don't have to do the cascade on the compositor.
In the future, once we introduce additive animation, we won't be able to handle
this so simply since it an animation will be able to be partially overridden.
Instead, consumers of this API will need to look at the 'composite' member of
the various animation values to see if an animation is being fully or partially
overridden.
As a result, this API really should return all running animations, even if they
are currently being overridden.
MozReview-Commit-ID: DwmbXdCqF32
--HG--
extra : rebase_source : 14e5412015b6c2c7ec6b7e105d414a89fc746c77
We are now extending this API to include more than just metadata about each
animated property but also the property values themselves.
Note that we can't use the name AnimationProperty for the dictionary since
we already use that name internally and [BinaryName] doesn't seem to apply to
dictionaries.
MozReview-Commit-ID: AcXeN4fsgTz
--HG--
extra : rebase_source : 714fdf85484775244daad6aaa288b1ec73ad6793
This better matches the order in the WebIDL and, once we rename
GetPropertyState to GetProperties it will make sense for GetFrames and
GetProperties to be side-by-side.
MozReview-Commit-ID: 67s9WGksPFv
--HG--
extra : rebase_source : f38ea60c0fec2f063126a0aa73422230189afbf5
Later in this patch series when we convert tests from web-platform tests to
mochitest-chrome tests, some of the test cases that use zero-length segments
(overlapping keyframes at certain offsets) would trigger failed assertions
in KeyframeEffectReadOnly::ComposeStyle. This is because this method was
originally written with CSS animations in mind where segments cannot be
zero-length. Furthermore, when these same tests cases are run as
web-platform-tests, the failed assertions are not visible.
This patch adjusts the handling of segments to allow zero-length segments and
adds a test to check that the handling matches that defined in Web Animations
which is summarized in the following informative note,
"this procedure permits overlapping keyframes. The behavior is that at the
point of overlap the output value jumps to the value of the last defined
keyframe at that offset. For overlapping frames at 0 or 1, the output value
for iteration progress values less than 0 or greater than or equal to 1 is the
value of the first keyframe or the last keyframe in keyframes
respectively."[1]
[1] https://w3c.github.io/web-animations/#the-effect-value-of-a-keyframe-animation-effect
MozReview-Commit-ID: JdyYbGZtbot
--HG--
extra : rebase_source : 00502ec8aec423196376e29bf4b70ef0ff178e29
The type name has been changed and re-ordered.
MozReview-Commit-ID: 78jrJ6a9Pro
--HG--
extra : rebase_source : f47e6bf27d8e48d10b3af123308c2ab89e71d8e1
As well as generally simplifying the different KeyframeEffect(ReadOnly)
constructor methods, this patch also means we will use the realm document for
parsing timing functions in all cases. Although this currently doesn't have
any impact (the current set of timing functions are expected to be parsed
identically regardless of the document used) it may become significant if, in
future, it becomes possible to register hooks with certain documents for
parsing CSS properties as part of the houdini efforts.
MozReview-Commit-ID: 4gAZi1G1uAD
--HG--
extra : rebase_source : f619592a02ddcbe56835344ec1fb3023219cd2d3
Once we update TimingParams to take a document, we will need to get an
appropriate document within the various constructor methods. This complicates
these methods and suggests they should be pushed into the .cpp file where
we can hide the complexity more easily and templatize the type of the options
argument so that we can share the document-fetching code.
By moving all uses of the declared template methods to the .cpp file we
can drop the explicit instantiations.
(We still need to declare the templated methods in the header file since
these methods need to be protected methods of KeyframeEffectReadOnly in
order to construct a KeyframeEffectReadOnly since its constructor is
protected.)
MozReview-Commit-ID: 8KrCWrWIb7X
--HG--
extra : rebase_source : c5b550b271cc68ceeb60a25243268a17b3ab7f65
Adds a utility function for getting the document on the global associated with
a JSContext. We will need this in various situations where we want to use
the CSS parser (which requires various bits of state we pull off a document)
to parse a timing function but might not have a target element.
Strictly speaking we currently always have a target element but in future we
expect to support creating KeyframeEffects without an associated target
element. Also, we will need this for some situations in bug 1245748 where we
need to parse CSS properties on keyframe objects when we may not have a
target element.
MozReview-Commit-ID: Klku1LFoRGp
--HG--
extra : rebase_source : f2aa06aafb8fa9b212791a3e602a168f5170fcd9
Each warning message is generated only when getPropertyState() is called.
MozReview-Commit-ID: C03ZSvPv9ff
--HG--
extra : rebase_source : 5932957f8f0b171c7b100b1c22e70513959c819e
Those message will be modified in part 4 (localization).
MozReview-Commit-ID: 6TMUxemVLcu
--HG--
extra : rebase_source : 65ef1879b3e606ae6dc279981b1e995c7b2cd40b
In order to convert CSSPseudoElementType into its underlying type easier,
we define CSSPseudoElementTypeBase. However, keep using uint8_t directly for
forward declarations.
Now we produce computed timing progress outside [0,1] range.
We use the last segment to calculate animation values if the value is greater than 1.
We use the first segment to calculate animation values if the value is lesser than 0.
Currently endTime is calculated when getComputedTiming() is called. As a
result, the value returned there doesn't necessarily reflect what we are using
in the model. It would be more simple, consistent and useful if we simply
calculate this as part of GetComputedTimingAt and use it both internally and in
the result to getComputedTiming().
With the added tests in part 4 we crash without this change because we end up
trying to multiply an infinite iteration duration by a zero iteration count
which trips an assertion in StickyTimeDuration. Hence we fix this behavior
before adding the tests.
Implement GetTarget() and functions of CSSPseudoElement.
We use a strong reference from CSSPseudoElement to Element and a non-owning
reference from Element to CSSPseudoElement.
This means that we won't associate animations with additional frames.
In this case, this fixes associating off-main-thread animations with a
table outer frame, when they should have been associated only with the
table frame.
Locally, the test fails without the patch (with opacity in the test
being 0.36 instead of the expected 0.6), and passes with the patch.
(Opacity 0.36 gives a color of rgb(163,163,255), whereas 0.6 gives
rgb(102,102,255).)
--HG--
extra : commitid : 7wtkIDLDHBF
We don't need observe restylings other than animations. If those restylings
happen, it's just noise for this test. We should drop them.
--HG--
extra : transplant_source : 9%0B%0B%B7O%E5R%86%D4%7F%29%90q%DDQ0%0B%FAuJ
Before this fix, sometimes an element which was removed in a prior test
would still visible when subsequent test starts.
We should wait for paints to complete after the element has been removed.
--HG--
extra : transplant_source : %C7%7F%03%0F%DA%05A%C1%CE%F0m%DA1%C5%1D%FA%06%FA%FE%CA
Nothing() represents linear function, i.e. skip calculation.
ParseEasing is changed to return a Maybe<ComputedTimingFunction>,
if timing function is linear function, ParseEasing returns Nothing().
This is also for compositor side.
we need a new class to share the function which converts TimingFunction
to ComputedTimingFunction for either keyframe's timing function or keyframe
effect's timing function.
This will allow us to re-use the constructor from Animatable.animate() since the
existing type, UnrestrictedDoubleOrKeyframeEffectOptions, is not compatible with
UnrestrictedDoubleOrKeyframeAnimationOptions (introduced in the next patch in
this series), as used by Animatable.animate()
In current our implemantation, animations which can run on compositor
in invisible element can not run on compositor on all desktop platforms.
*BUT* both on Android and B2G the animations still run on compositor somehow.
And one more thing. Animations can run on compositor in elements which are
scrolled out in the parent element *RUN* on compositor as well.
mochitest does not allow us to disable each test on specific platforms respectively.
One we have mozinfo in mochitest (bug 1150818), we can skip the tests on specific platforms.
In some circumstances when composing style, we tweak the time of the animation
before telling the effect to compose style. This is to avoid visual flicker in
certain situations where the main thread progress is being synchronized with an
animation running on the compositor.
In the past, effects would store their latest sample time locally so when
tweaking the animation time, we would need to call UpdateEffect() after tweaking
the time, and then again after restoring it as otherwise the style composed by
the effect would not reflect the adjusted time.
Now, however, effect's always query their animation for the time so this is no
longer necessary. Furthermore, the actions triggered by UpdateEffect are not
desirable in this case because they can, amongst other things, cause the
associated EffectSet to be destroyed and recreated.
Specifically, Animation::UpdateEffect() calls
KeyframeEffectReadOnly::NotifyAnimationTimingUpdated() which:
* Calls UpdateTargetRegistration which can trigger EffectSet
destruction/creation which is undesirable in this case because we intend to
restore whatever changes we make to the Animation's state and deleting and
recreating the EffectSet will cause any pointers to it to dangle.
* Cause us to possibly reset the "is running on compositor" status.
This too is undesirable since we intend to restore the state of the
Animation immediately after tweaking the hold time so we don't want to
act as if any state has changed.
* Similarly for marking the cascade as possibly needing an update or
requesting a restyle.
In summary, all the actions performed by NotifyAnimationTimingUpdated are
unnecessary and undesirable in this situation where we are temporarily tweaking
an Animation's current time only to restore it immediately afterwards since the
actions are all involved with recognizing actual changes in state.
Overload TimingParams::operator=() for AnimationEffectTimingProperties objects,
so we can assign an AnimationEffectTimingProperties/KeyframeEffectOption object
to a TimingParams object.
We also keep the uninitialized state of KeyframeEffectOptions::mDuration while
converting a KeyframeEffectOptions object into a TimingParams object.
We store the original value of duration in AnimationTiming, and add
computed duration in ComputedTiming, so both the Timing model and
AnimationEffectTimingReadOnly can get what they want.
By the way, replace mIterationDuration with mDuration.
--HG--
extra : rebase_source : f8e1fd648572e6d7b1cbecc2ac1888a2f74bbc7e
FillMode could be 'auto', and we should treat it as 'none' in the timing model.
However, AnimationEffectTimingReadOnly should get its original value.
By the way, replace mFillMode with mFill.
--HG--
extra : rebase_source : 5a397dd7fbb22ac76fe96003d82d097e398852c7
We want to store the original value from KeyframeEffectOptions whose
iterations is unrestricted double. Therefore, we can get the original value
of iterations by AnimationEffectTimingReadOnly.
By the way, replace mIterationCount with mIterations.
--HG--
extra : rebase_source : da2953056031079c41273ed977545dc926e1b83c
