Re: [web-animations] AnimationPlayer.ready confusion

Hi Aleksei,

Thanks for your mail.

Firstly, I think there may be a couple of points of confusion in the 
second part.

On 2015/01/23 22:02, Aleksei Semenov wrote:
> Another option:
>
> player.pause(); // => let's assume that player is immediately ready,
> // so pending pause task is not scheduled, all necessary actions are
> immediately executed

Why is the player immediately ready? Are you assuming the player is 
already paused?

If so, I think we should abort the procedure early in that case. As far 
as I can tell, the procedure doesn't currently do that but it probably 
should. I'll add an issue for that.


> // player.ready promise is fulfilled
>
> player.ready.then(function() { // => because player.ready promise is
> fulfilled,
> // the function is executed immediately, 'paused' is displayed.
>      alert(player.playState);
> });
>
> player.play();
> // executes 'play a player' procedure
> // http://w3c.github.io/web-animations/#playing-a-player-section
> // there is no pending task
> // player.ready promise is replaced with new one, which has no handler

In this case, the function associated with the ready promise is not run 
immediately. Rather, it queues a microtask:

   "A promise p is fulfilled if p.then(f, r) will immediately enqueue a 
Job to call the function f."[1]

As a result, the subsequent call to player.play() will happen *before* 
the callback is run.

If, in fact, the player was originally paused above then we'd end up 
running the promise callback before the player became ready to play so 
we'd end up alerting 'pending'.


> It seems that this is part of more general problem.
>
> 1. AnimationPlayer.ready serves for several methods play(), pause(),
> reverse(), cancel().
> So there is no way to predict in response to which method call the promise
> handler function is called.

Right. It's not quite that bad though. You can control what you call and 
test the state before you wait on 'ready' and, since implementations 
resolve the ready promise by queuing a microtask, it's completely 
predictable what the result will be.

We've considered the idea of having playReady, pauseReady etc. but it's 
not a very friendly API.

Alternatively, we've considered having play() and pause() return a 
Promise object (which could be different objects) but we were concerned 
that authors would think that play().then( ... ) would execute after the 
animation had finished. Perhaps we could rename play() to resume()?


> 2. Methods play(), pause(), reverse() can replace AnimationPlayer.ready
> with a new Promise object. There is no way to predict whether
> AnimationPlayer.ready will be replaced or not, because it depends on
> whether the player has pending tasks or not.

You can tell if it will be replaced by checking if playState is 
'pending'. If playState is pending we will re-use the same Promise object.


> For example, how to get some function called in response to some method
> call (pause() or play() or reverse())? I.e. I call, for example, method
> pause() and would like to get my handlePause() function called exactly
> when player pause operation is complete.

What if that pause never completes because there is a call to play() in 
the meantime?


> Is it possible to change the specification, that each method
> (play, pause, reverse, finish) return unique Promise object related
> to the method. So the following promise-like code could be possible:
>
> player.pause().then(handlePause, rejected);
> player.play().then(handlePlay, rejected);
> player.finish().then(handleFinish, rejected);

I prefer this but the main problem is just the naming of play(). What do 
you think of using resume()?

Best regards,

Brian


[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects

Received on Tuesday, 10 February 2015 00:56:04 UTC