This test is skipped on Android, since on Android it takes too long to send
the transition to the compositor. On an Android emulator, it took 5s!
For this test case, 5s duration transition needs busyness on the main thread
more than 5s, it's undesirable.
MozReview-Commit-ID: DIqcwsnLttV
--HG--
extra : rebase_source : 256978c2a58fb483da4c0acac1db0e51fcf45ccd
tree_ordering test can not be moved because the test waits for animationend
event.
createPseudo() were picked from
testing/web-platform/tests/web-animations/testcommon.js .
MozReview-Commit-ID: EZ2sGEgdMFM
--HG--
extra : rebase_source : 1ebf46dd91f42ba75f5711e781d72e77948e6150
All of cleaning up code were dropped. Also some trivial comments were dropped.
Note that test cases can not be rewritten to synchronous test.
* Waiting for events, e.g. transitionend.
* single_transition
* single_animation
* Manipulated by style, e.g. style.animationDuraton = "0.5s".
* single_transition_cancelled_property
* single_transition_cancelled_value
* single_transition_cancelled_noninterpolable
* single_transition_reversed
* multiple_transitions
* single_animation_cancelled_name
* single_animation_cancelled_duration
* single_animation_cancelled_delay
* single_animation_cancelled_fill
* single_animation_cancelled_iteration_count
* single_animation_change_XXX
* coalesce_change_cancel
* Falling into a pending state, e.g. play() or pause().
* finish_from_pause
* finish_from_pause_pending
* play
* play_filling_forwards
* play_after_finish
* pause
* pause_while_pause_pending
* aborted_pause
MozReview-Commit-ID: 5bTzO7GtEHF
--HG--
extra : rebase_source : 905f5144706e20c743030b4bcff428ef124abfff
So that the new subclass of DeclarationBlock could just be
ServoDeclarationBlock.
MozReview-Commit-ID: 55KgfmWmmyU
--HG--
extra : source : 27c55355da341fce112b15d966eb9b2fa2c8834b
We needed this polyfill for <initializer_list> when some of our C++
standard libraries did not support said header. They all do now, so the
polyfill is redundant.
To send animations to compositor in the delay phase we need to
modify Animation::IsPlaying returning true in the delay phase.
Note about background-position-in-delay.html:
After this patch, background-position animation also creates an active layer
from its delay phase.
Also note about test cases in test_animations_omta.html:
After landing bug 1279071, getOMTAStyle() returns the style value only
specified by animations, also in this patch we don't apply any opacity or
transform values in the delay phase, as a result we can't tell animating
value during delay phase on the compositor.
MozReview-Commit-ID: ILYKig3c08d
--HG--
extra : rebase_source : 5715c1f9ec43da3c8374f08cdca82e2ca29fe474
We are going to pass animations to the compositor in before phase but not to
pass when active duration is zero. To distinguish this state we need a new
function to check that the active duration is zero.
MozReview-Commit-ID: 2Lckmt4LQcV
--HG--
extra : rebase_source : aa059b8c75bcea4ff4c5788aac98d1e17a4a5d7b
The check of negative elapsedDuration is basically no longer valid since
animation delay is not factored into start time any more. But still we have
somtimes met negative elapsedDuration sice we use a previous vsync time stamp
for async animations to make the animations more sync. This is not a problem
in most cases but makes two reftests intermitent failure because both of them
used steps(1, start), the steps(1, start) composed different results in the
before phase and in the active phase. To avoid this difference this patch
replace the steps(1, start) with steps(1, end).
Once we incorpolate playbackRate into GetCurrentOrPendingStartTime, we don't
need to call AnimationTimeToTimeStamp for deviding delay by playbackRate since
the time passed to AnimationTimeToTimeStamp does not contain delay any more.
MozReview-Commit-ID: IVE2IFfNgm0
--HG--
extra : rebase_source : 7cb42e57067c21451706bd89284016d996dc8b12
We should run basically tests with subtree true or false option.
MozReview-Commit-ID: 8HDAnKh7Xq
--HG--
extra : rebase_source : 13d1551240bf68b776df5111c512cd13e248a0ea
All of the split out test cases were re-written with synchronous API.
Also, cleanup codes in the end of each test cases, e.g. anim.cancel(), were
dropped because we now create a new MutationObserver and a new element for
each test respectively.
MozReview-Commit-ID: 9Bx0OUOU9On
--HG--
extra : rebase_source : c51b9e850bfdc692344012b9176a17083187ab89
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
Also we skip to update the cascade and compose style for orphaned elements if
the animation reqeusted restyle but the target element has been removed from
document before a subsequent tick.
MozReview-Commit-ID: 3I6uyvuSPO5
--HG--
extra : rebase_source : 817b123a4e1b64c89cfbe796073d88410792bf84
There are a few pieces missing before we can do this with Servo. Since this
only enables an optimization for off-screen animations we should skip this
for now so it doesn't block animations from running.
MozReview-Commit-ID: GecHWQZYxpK
--HG--
extra : rebase_source : c0330b104afb4b970569c0cb650315e633b7e796
extra : histedit_source : db91b37d3370c9b766976b42b0701f6e0ec56159
For animation values parsed using the Servo backend that are invalid,
we simply end up with an empty declaration block (and we fill in |mValue|
with the string so we can later serialize it).
MozReview-Commit-ID: 6ruwJGVzRla
--HG--
extra : rebase_source : 83e415febf10cf90631fd7a1b447921822a44bc0
Actually this test case does not pass for now, since we don't throttle
animation properties running on the main thread overridden by important
rules. But after part 6, we don't request restyle layer in the case
when the cascading result of the property which is not running on the
compositor is changed, so this test case is meaningful.
MozReview-Commit-ID: eraPs9WAe9
--HG--
extra : rebase_source : a0d6f6629299fbbad59bcabeae3b8c48b7c7ce1a
This patch also makes composite order lowest to highest, as a result we also
need to replace mWinsInCascade checks with the the properties.
The mWinsInCascade membed itself will be removed in a subsequent patch.
Now we call RequestRestyle(Layer) respectively for transition and animation,
so a test case in test_restyles.html works as expected.
And now lower-priority animations are also sent to the compositor so this patch
fixed some tests in test_running_on_compositor.html and
test_animation_performance_warning.html
MozReview-Commit-ID: BchUsJbmatg
--HG--
extra : rebase_source : ff295aecb08bb672ac5f02e26e37a4ea4f3eb7c0
The result animatons of FindAnimationsForCompositor() should be sorted
by composite order because SampleAnimations() on the compositor expects
the animations are sorted by the order.
MozReview-Commit-ID: 4eI4EldFVcu
--HG--
extra : rebase_source : eabbea6aa54d1637b8baba8b6ac4959a1e6025b6
