RE: [web-animations] Setting hold time in "pause a player" procedure

Thank you Brian!

I'm not quite sure but may be there's one more issue here. It seems for me
that step "8. Run the procedure to update a player's finished state for
player" is excessive. I can't imagine conditions when this procedure were
not run earlier. For example:

1) player.finish(); // Runs the procedure to update a player's finished
state
    player.pause();

2) player.currentTime = player.source.computedTiming.endTime + 100; // Runs
the procedure to update a player's finished state
    player.pause();

3) Wait until player reaches the end then call player.pause().
    
Etc...

How pausing may change finished state so that we need to run update finished
state procedure? Are there any case when this procedure may change anything?

-----Original Message-----
From: Brian Birtles [mailto:bbirtles@mozilla.com] 
Sent: Wednesday, November 05, 2014 2:26 PM
To: Sergey G. Grekhov; public-fx@w3.org
Subject: Re: [web-animations] Setting hold time in "pause a player"
procedure

On 2014/11/05 15:42, Sergey G. Grekhov wrote:
> Hi All,
>
> The procedure to pause a player
> (http://w3c.github.io/web-animations/#pause-a-player) contains the 
> following steps:
>
> .
>
> 4. Set player's hold time to current time.
>
> .
>
> 7.1. Set player's hold time to the time value corresponding to the 
> value of player's current time used at the moment when the pause 
> operation was completed, even if that value was unresolved.
>
> Note: since player's start time and hold time are set to unresolved 
> earlier in this procedure, user agents will be required to maintain 
> additional state in order to determine the appropriate value of the 
> current time.
>
> .
>
> First, if player's hold time is set to current time at step 7.1 why do 
> we need set it to current time at step 4 (at the time of step 4 
> current time may be unresolved yet )?

Yes, this is clearly wrong. It came about because we've changed the
behaviour regarding if/when start time becomes unresolved a few times.

When the pause completes we should set the hold time to the result of
calculating the current time using the original start time. As the issue
notes, it might actually make more sense to keep the start time until the
pause completes which would make calculating this easier.

I'll update the spec to do that.

> Second,  Note section reads ".since player's start time and hold time 
> are set to unresolved earlier in this procedure.". But hold time is 
> not set to unresolved, it set to current time which may be unresolved 
> but not necessarily.

Yes, that comment is wrong. It was written before we decided to only make
the current time unresolved at the API layer. I'll remove it.

Thanks Sergey!

Brian

Received on Wednesday, 5 November 2014 08:14:47 UTC