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 <[email protected]
<mailto:[email protected]>> 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
