Re: [web-animations] Updating the finished promise in a separate task

Hi Kris,

On 2015/06/30 17:05, Kristopher Giesing wrote:
> If I understand this correctly, there are really two questions here:
>
> 1) Whether certain operations on animation objects should have
> synchronous or asynchronous semantics;
> 2) Whether executing two asynchronous operations that cancel each other
> out should behave as if neither ever happened
>
> I think 2) is not necessarily a foregone conclusion.  The alternative
> would be to behave as if both really did happen, in the order
> specified.  I don't know whether this is complicated to implement, or
> even desirable, but I wanted to bring it up for consideration.

(2) is probably more accurately, "Whether executing two operations that 
have asynchronous effects and that cancel each other out, should cancel 
those asynchronous effects".

My most recent pondering was that (2) need *not* always the case but 
that certain operations triggered by cancel() and finish() are performed 
in a synchronous manner but that the same operations, when triggered by 
simply seeking the current time etc., trigger them in an asynchronous 
manner.

(Note that in all cases the event dispatch itself is still asynchronous; 
it's the part where we decide whether or not to queue a task to dispatch 
the event that may or may not be synchronous.)

I'm not really sure what's best:

a) Be consistently synchronous and force authors to be careful about the 
order in which they perform operations;

b) Be consistently asynchronous and possibly produce some surprising 
results where calling cancel() and finish() produce no effect at all; or

c) Try to make cancel() and finish() act more intuitively at the cost of 
introducing inconsistency.

I started to spec (b) but then I brought up (c). Now I'm wondering if we 
should just go back to (a).

Best regards,

Brian

> On Mon, Jun 29, 2015 at 10:58 PM, Brian Birtles <bbirtles@mozilla.com
> <mailto:bbirtles@mozilla.com>> wrote:
>
>     On 2015/06/30 13:21, Brian Birtles wrote:
>
>         Hi,
>
>         I'm currently speccing finish/cancel events for animations and I
>         think
>         it makes sense to dispatch finish events and also update the
>         finished
>         promise in a separate task.
>
>
>     I was thinking of applying similar handling to the cancel event
>     including the part where we cancel a pending finished promise.
>
>     However, a consequence of this handling is it means that in the
>     following case:
>
>        anim.finish();
>        anim.currentTime = 0;
>
>     the finished promise won't resolve. Nor will any finish event fire.
>
>     Likewise, if you say:
>
>        anim.finish();
>        anim.cancel();
>        anim.currentTime = 0;
>
>     The finished promise won't fulfill or reject. Nor will the finish or
>     cancel event fire.
>
>     Is that weird?
>
>     I wonder if we the following behavior is more intuitive:
>
>     1. cancel() queues event dispatch / promise rejection synchronously
>         such that calling cancel() always triggers a cancel event unless
>         the animation is already idle.
>
>     2. finish() likewise queues event dispatch / promise resolution
>         synchronously unlike simply setting the currentTime.
>
>     (3. A timeline going inactive should cause us to update the hold time
>          of any animation watching it. This is consistent with what happens
>          when we set animation.timeline = null and means the only time we
>          ever transition to the idle state is from a call to cancel().)
>
>     Best regards,
>
>     Brian
>
>

Received on Tuesday, 30 June 2015 23:41:57 UTC