Passing FlingHandoffState around as an in-out parameter was making
the next change (respecting overscroll-behavior) messy.
MozReview-Commit-ID: 4wuoll20Jt7
We're wasting a bunch of work unneedlessly.
Source-Repo: https://github.com/servo/servo
Source-Revision: 990058475797e5832467616d77e7fed651c8a357
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6c23fb88cb24150cf43be099c6a626926fac072a
A repaint is sufficient to pick up the new property value.
MozReview-Commit-ID: oKFgGfquyl
--HG--
extra : rebase_source : 4f145fb29eddcc5f83506cc6f512b123c29676ef
Factory::DoesBackendSupportDataDrawtarget already fulfills the same
purpose and we should use that instead, as imgFrame is the only user of
the former API. It has the added bonus of allowing us to use shared
surfaces on Linux with WebRender, and using volatile surfaces on Windows
when D2D is disabled.
Hopefully most of these changes are self-explanatory however a few notes follow.
* In timing-model/animations/play-states.html, as well as making the tests match
the updated spec, one or two tests have also been moved to better reflect the
order in the spec (to make it obvious which branch of the algorithm is being
tested).
* In timing-model/animations/set-the-timeline-of-an-animation.html we previously
had two tests that check:
a) That the playState was 'pending' before and after setting the timeline.
b) That the playState was 'pending' before setting the timeline and then,
after setting the timeline and waiting on the ready promise, would become
'running'.
Likewise we had the same test for pausing.
Since these are basically the same test--(b) just adds the wait on the ready
promise--we combine them here into one test that covers both (a) and (b).
MozReview-Commit-ID: CLoDJvsdwmF
--HG--
extra : rebase_source : c2f34fa6614795f2d3ba9ca3e572f11306f96463
Currently we have a test in interfaces/Animation/playState.html that somewhat
randomly tests the result of the `playState` member.
However, there's no complex logic associated with the `playState` member in the
IDL. It simply returns "The play state of this animation". The logic we need to
test is in the definition of 'play state' which is in the timing model.
As a result we move this test to timing-model/animations/play-states.html
However, this test as it stands does not test the calculation of the play state
in a particularly thorough manner. For example, it does not contain a single
test for the 'finished' state.
Given that this patch series will change the definition of the 'play state' we
first fix this test to cover each of the different cases in the definition of
the 'play state' prior to these changes. That is, we update the tests based on
the definition of 'play state' here:
https://www.w3.org/TR/2016/WD-web-animations-1-20160913/#play-states
(Note that at this point in the patch series the pref to turn on the changed
definition behavior has not been enabled even for tests so this patch is
actually testing the behavior when that pref is false. We'll replace much of
this test in the next patch but by updating the test first, we should be able to
more clearly see the changes in the next patch.)
MozReview-Commit-ID: 1xkOmuY1SxD
--HG--
rename : testing/web-platform/tests/web-animations/interfaces/Animation/playState.html => testing/web-platform/tests/web-animations/timing-model/animations/play-states.html
extra : rebase_source : 1890e1b4db007452df393e8a9e4b3ccf42bca237
This reflects the change made to the Web Animations specification in:
9e2053f5531c3415f4cc
(I got it wrong the first time. The second commit fixes the first.)
And discussed in:
https://github.com/w3c/web-animations/issues/196
In summary, we are splitting the "pending" play state out into a separate
boolean member so that it is possible to distinguish between "play-pending" and
"pause-pending" and because most of the time when you check for
animation.playState === 'running' you also really want to include play-pending
animations.
MozReview-Commit-ID: IJSNoZTKW2I
--HG--
extra : rebase_source : 5d17239fd087cfe3cce1c9697eff97d062b6dd4b