- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Dec 2017 04:40:17 +0000
- To: public-css-archive@w3.org
What about setting the start time, current time, iteration count etc.? Those also will take time to be reflected by off main thread animations. I guess the difference here is that when we update the playbackRate we want to use the currentTime as seen on the compositor as the currentTime to maintain? The reason play and pause set the ready promise is that we don't know in advance what startTime / currentTime we'll end up using for those. So the idea here would be that the currentTime will shift in between calling `playbackRate = 2` and the ready promise resolving in a way that is not necessarily equivalent to what would happen if we just used the currentTime on the main thread when the playbackRate was set. This could be quite tricky to spec since we need to define all the interactions with other things that affect ready promises etc. (e.g. if you set the playbackRate, then call pause() do we re-use the ready promise etc. etc.). Also, we'll need to work out what happens with reverse(). -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2059#issuecomment-349193519 using your GitHub account
Received on Tuesday, 5 December 2017 04:40:35 UTC