Re: [web-animations] Ordering animations based on when they transition from idle

On 2015/07/15 8:37, Shane Stephens wrote:
> > (3) It is idiomatic to create animation resources separately from their
> > scheduling. We've already seen a desire to do things like this with
> > declarative animation and triggers, or with time sheets.
>
> It seems equally true to say that its idiomatic to create animation
> resources separately from their priority.
>

I'm not sure that this is true. Do you have examples? SMIL doesn't let you
do this, nor would time sheets. Even CSS ties priority to (timing property)
creation.


> > Creation time ordering ties animation priority to animation creation,
> > which means that you think about the order in which animation resources
> > will layer at the point where you're creating the resources.
>
> That seems odd to me. It seems more natural to set up the animations
> with all their properties and then think about how to combine them.
> That's where I was going with the FTFI proposal.
>

Doug and just I discussed two conflicting examples:

(1) I have a set of animations that have a known stacking order, and I just
want to apply them in response to (independent) events. With creation
ordering, I create them in the required stacking order. With FTFI, I need
to
animations.map(function(animation) { animation.play(); animation.cancel();
});

(2) I have a set of animations with a stacking order that needs to follow
their triggering order. I can't do this with creation ordering, and I can
only do this with FTFI if the animations never repeat.

I guess that I find case (1) more likely than case (2) - but we can fall
back on explicit examples. Here are examples of (1):
* an articulated robot with movements triggered by events
* A planetary system with rockets that can take off and orbit their
respective planets in response to events.

I can't think of examples that fit into (2) off the top of my head. Do you
have any?

> In contrast, TFI ordering means you need to think about animation
> > resource ordering at each point that you start an animation.
>
> Again, having to think about priority when you create animations seems
> unfortunate. That's something you'll often want to delegate to a factory
> method of some kind, and then take care of the controlling logic elsewhere.
>

Which is fine, because then you're delegating order to factory method
invocation.


>  > This is
> > slightly better than start time ordering, but not much - for example, it
> > means that if you've started other animations in the wrong order with
> > respect to the animation you're about to start, you are out of luck
> > unless you want to apply potentially global updates (your only available
> > operation is to move an animation to the top of the priority stack). For
> > another example, how do you slot a newly played animation in between a
> > high-priority animation and a low-priority one? You can't without
> > restarting the high priority animation.
>
> This is where creation-time ordering seems weakest. With TFI you can
> shuffle animations by restarting them (saving their currentTime in
> between if needed). With creation-time ordering you have to create
> entirely new animations. The again, the same problem exists for FTFI. I
> guess clone()-ing is not that bad as an interim measure.
>

Right, we definitely need that ordering tweak at some point soon.


> > I hope these arguments give a good sense for why I'm opposing the idea
> > of moving away from creation-time ordering. Any questions /
> > counter-arguments?
>
> I guess I'm not thrilled with any of the options. I was hoping I was
> forgetting something amazing about creation-time ordering!
>
> As Kris says, and as we've often acknowledged, we'll need a mechanism
> for explicitly setting priority in the future.
>
> Until them maybe creation-time ordering is ok. I was hoping to see how
> its better than FTFI but they seem much of a muchness to me.
>

In the absence of compelling examples for case (2) above, FTFI is basically
creation ordering with a required extra manual step.

Cheers,
    -Shane


>
> Best regards,
>
> Brian
>