Re: [web-animations] Simplifying timing groups

Hi Brian,

this sounds reasonable.
I assume that this means that the timing function of a group will always be
linear?

FYI Flash Pro doesn't support custom timing function on a group either.

On Wed, Aug 7, 2013 at 8:25 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi public-fx,
>
> I have a proposal to simplify Web Animations by not allowing timing
> functions on groups (at least not yet, see the last part).
>
>
> MOTIVATION:
>
> Allowing arbitrary timing functions on groups complicates Web Animations
> in many ways:
>
> i. It means you can't convert from an animation's local time to the
> corresponding document time since timing functions are not always
> invertible. This introduces all sorts of complexity. For example, for event
> handling to report both a local time and document time for an event we have
> introduced uneased timing[1] which is not well-liked and as an alternative
> we have considered some fairly arbitrary approximations.
>
> It also introduces some as-yet unresolved questions such, "If a timing
> function on a group causes a child to oscillate between being in and out of
> the active phase repeatedly, perhaps even a dozen times in 100ms for a
> spring function, do we dispatch events for every one of those transitions?"
> (And if we have real spring functions the number of crossings would depend
> on how you evaluate the function and could be huge.)
>
> ii. It introduces complexity when timing functions on groups overshoot the
> [0, 1] range since then children won't stretch as they would if the timing
> function was applied directly to them, but rather will go into their fill
> behavior which will result in them being clipped. We discussed this
> previously[2] and considered adding special handling specifically for this
> situation which feels at least a little bit hacky (it involves passing
> extra state around and is only applied to children that touch the edge of
> their parent).
>
> iii. It complicates implementation since this feature makes it difficult
> to decompose timing hierarchies into simple animations that could be passed
> off to another process or even another API. Without this feature, any
> timing hierarchy could potentially be flattened down to a series of very
> simple sub-animations. (For example, an iteration count of a group would be
> represented by producing several sub-animations, one for each iteration. A
> direction setting on a group could be represented by flipping the playback
> rate on some of those sub-animations etc. On the other hand, splitting a
> timing function on a parent into pieces, then combining the appropriate
> piece with any timing functions already applied to the child's
> sub-animations, is far more complex.)
>
> I'm not sure if implementations will actually take this approach but I
> think the fact that arbitrary timing functions on groups greatly
> complicates this approach is indicative of the complexity introduced by
> this feature.
>
>
> OBSERVATIONS:
>
> No other animation API I can find allows arbitrary timing functions on
> groups.
>
> For example,
>
> * Core Animation talks about groups and timing functions but the groups in
> this case correspond to our keyframe animations. That is, a set of
> properties being animated together.
>
> * GSAP, which has an impressive feature set, has no 'ease' property on
> TimelineLite / TimelineMax.
>
> * WPF which has, by far, the most complicated animation API I have ever
> seen, only has easing functions on animations.
>
> * SMIL3, as discussed later, which is infamous for its complexity, does
> not allow arbitrary timing functions on groups.
>
> This begs the question, do we really need this?
>
> A further implication of the fact that other APIs don't provide this
> facility is that it is therefore probably quite difficult to implement the
> Web Animations model on top of an existing animation API.
>
>
> PROPOSAL:
>
> I propose making timing functions a property of animations only, at least
> initially. This would have the following benefits:
>
> * Events become a lot simpler. There is no need for uneased timing or
> approximations of timing functions and no questions about which events get
> dispatched.
>
> * In general, provided the 'current iteration' of each parent is known, it
> is possible to convert from an animation's local time to document time
> which may be useful in a number of contexts (it may, for example, be
> something we expose via the API in future).
>
> * There is no need for special overflow fill handling.
>
> * Implementations can easily flatten timing hierarchies into
> sub-animations and pass them off to a separate process and possibly another
> animation API.
>
> * Media references are not required to support timing functions initially.
> If timing functions are useful there, we can determine the sort of timing
> functions that are readily implementable and restrict the set of timing
> functions permitted accordingly. For example, overshoot doesn't make much
> sense for media. Likewise, some features of chained timing functions
> probably don't make much sense for anything other than animations (like the
> keyframe alignment feature).
>
> * For timing groups, we can likewise add a restricted set of timing
> functions later as needed. Due to the complications noted above, such
> timing functions could be restricted so that they are invertible and can't
> go outside the [0, 1] range. Note that this is what SMIL3 does.[3] For time
> containers (groups) it defines time manipulations and these include only
> playback rate control, auto-reversing, and accelerate/decelerate (which can
> be combined to produce ease-in / ease-out effects where the result is
> invertible and in the range [0, 1]).
>
>
> There are a number of options for how we might represent this in the API
> but I'd like to start by deciding about the model.
>
> Best regards,
>
> Brian
>
> [1] http://www.w3.org/TR/web-**animations/#uneased-timing<http://www.w3.org/TR/web-animations/#uneased-timing>
> [2] http://lists.w3.org/Archives/**Public/public-fx/2013AprJun/**0184.html<http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0184.html>,
> item 15
> [3] http://www.w3.org/TR/SMIL/**smil-timemanip.html#TimeManip-**
> Overview-support<http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-Overview-support>
>
>