Re: [web-animations] Simplifying timing groups

For anyone following this thread, we discussed this issue at our telcon 
a few hours ago. The latest discussion is here:

   http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0076.html

If you have comments to add, please reply to that message and change the 
subject. Thanks!

Brian

(2013/08/08 12:25), Brian Birtles 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
> [2] 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
>

Received on Friday, 9 August 2013 05:09:38 UTC