[web-animations] Web Animations minutes, 17 July 2014

Web Animations minutes, 17 July 2014

Present: Dirk, Doug, Shane, Brian
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.22243

Agenda:

1. Promises, promises, promises
2. Player API implementation progress report
3. startTime/currentTime NaN/null/???


1. PROMISES, PROMISES, PROMISES
===============================
(Shane)

We got some feedback about the promises API we came up with last week.

We had proposed a single Promise instance that updates only when any 
pending state gets resolved. i.e.

     var player = document.timeline.play(...);
     var a = player.ready;
     var b = player.pause();
     var c = player.play();
     // a == b == c

The problem here is that you really want registered callbacks on a and b 
to be ignored, at least in some scenarios.

We could fix that by having different Promise instances each time:

     var player = document.timeline.play(...);
     var a = player.ready;
     var b = player.pause();
     var c = player.play();
     // a != b != c

but now there's a lot of object churn and the whole thing's quite 
complicated.

This is probably actually better modeled by events (onStarted, onPaused, 
etc.).

Some use cases to consider:
* testing - know when it was OK to read the start time without setting 
up a polling loop.
* pausing - want to align with the pausing currentTime.

Pausing:
Consider a sprite animation from A to Z.
Scenario: compositor is able to make frames faster than main thread.
Main thread calls pause when it sees frame D.
But compositor thread has already progressed to frame E.
If we report that the player was paused at time D:
1. rendering could glitch back from E to D.
2. OR, the current time of the paused player could jump from D to E.
3. OR, the paused player could have an incorrect (= doesn't match state 
on compositor) current time.

Aligning times while paused:

     var player =
       element.animate([{transform: 'translate(0px)'},
                        {transform: 'translate(1000px)'}], 5000);
     // some time later
     player.pause();

     // now we try to align
     var start = player.currentTime / 5000 * 1000; // (5000ms, 1000px)
     element2.animate([{transform: 'translate(' + start + 'px)'},
                       {transform: 'translate(1000px)'}],
                       5000 - player.currentTime);
     player.play();

 > We need to specify that players triggered (without a start time) in 
the same task will 'line up'
 > We agree that we can't think of a good reason (yet) for a promise on 
pausing.
 > We'll seek more feedback concerning limiting the only promise as that 
on the 'ready' attribute.

We note that having play() return a Promise is probably confusing anyway 
since some people will assumed it is the 'finished' promise.

Regarding promises vs events:

     var player = ....;
     player.ready.then(function() {
         assert_equal(player.startTime, 42);
     });

vs.

     var player = ....;
     player.onready = function() {
         assert_equal(player.startTime, 42);
         player.onready = null;
     });

It seems promises are a better fit for this kind of one-shot usage.


2. PLAYER API IMPLEMENTATION PROGRESS REPORT
============================================
(Shane)

After discussion, an interesting proposal for simplifying the pending 
state issue:
- if you execute an action that puts you into a pending state, then you 
will remain in that state until at least the end of the current task, 
_unless_ you force the animation out of that state by providing the 
unresolved start time and/or current time.

That is, even though we *could* detect a sequence of pause() followed by 
play() and skip going into the pending state, for consistency's sake we 
won't.


3. STARTTIME/CURRENTTIME NAN/NULL/???
=====================================
(Shane)

Thread: http://lists.w3.org/Archives/Public/public-fx/2014JulSep/0008.html

Feedback from Tab suggested that NaN isn't great for this either, as 
it's against precedent and hard to test for (need to use isNaN).

Doug: Another issue is that wile player.startTime += 1000 won't set the 
startTime to 1000 if NaN, it still silently fails.

Here's another alternative, use an enum with a single value 'unknown'.
Then:

     var player = document.timeline.play(...);
     player.startTime += 1000;

will attempt to set startTime to 'unknown1000' which we can have throw 
an exception.

Brian is concerned that this is no more idiomatic. Unless other spec 
editors etc. agree, prefer to do the idiomatic thing.

 > Shane to send this to the list and cc domenic and 
public-script-coord. The question comes down to whether we should be 
attempting to work around JavaScript's warts or not. We are happy enough 
to settle on 'null' if the answer comes back that we shouldn't be.


Next meeting, Thurs 24 July 2014 07:00 UTC
   Local time: 
http://arewemeetingyet.com/UTC/2014-07-24/07:00/Web%20Animations

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Friday, 18 July 2014 00:41:18 UTC