Web Animations minutes, 13 / 14 May 2013

Web Animations minutes, 13 / 14 May 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.J2MLqh336pT/latest
Present: Doug, Shane, Steve, Brian

Agenda:
1. Status update
2. Fill modes
3. Timing function chaining
4. Effect composition rework
5. Event model


1. STATUS UPDATE
================

Brian
- Made composition operation per-keyframe (not per-value)
- Updated KeyframeShortcut to allow specifying offset and composition 
operation
- Minor tweaks and corrections

Doug
- Implementing timing calculations.

Steve
- Wrote up media integration

Shane
- Sick :(


2. FILL MODES: The refillening
==============================

End-point exlusivity has an impact here.

What should be result be here?

   new ParGroup([new Animation(..., {fillMode: 'none', duration: 2})], 
{fillMode: 'forward', duration: 1});

Currently, the normative part of the spec says the child animation will 
continue to apply its mid-point value indefinitely after the parent 
reaches the 1s mark.

Shane's suggestion is that the active interval is clipped by parent 
groups, and that fill mode applies outside the active interval. So in 
the case above the animation wouldn't apply after 1 second.

ACTION: Shane, Brian to make use cases and ensure that this is a better 
approach.


3. TIMING FUNCTION CHAINING
============================
(Sydney team)

We had another think about how best to represent chained timing 
functions and stil prefer the idea of splitting the input time fraction 
into ranges, and specifying a timing function to cover that range.

"ease-in 0.4 0.4, cubic-bezier(1, 0, 1, 0) 0.7 0.7, ease-out"

This has several nice properties ...

- It allows chaining of arbitrary types of timing function
- It allows specification of discontinuous timing functions
- Each timing function can be parameterised independently of the range 
it spans. For example, in the above, the arguments to cubic-bezier() 
specify the shape of the curve, which is unchanged if the size or 
position of its range is changed.
- It matches the keySplines / keyTimes feature of SVG exactly

To simplify the common-case of chained beziers where c1 continuity is 
required, we propose adding a 'smooth' option. Specifying this option 
means that the direction of the vector representing the starting control 
point of the bezier is ignored, and only its magnitude is used. Instead 
its direction is set to be equal to that of the tangent at the end of 
the previous segment (ie the negative of the vector representing the end 
control point in the case of a bezier). If the smooth option is 
specified on the first segement, a direction of (1, 0) (i.e. horizontal) 
is used. For example ...

"ease-in 0.4 0.4, smooth cubic-bezier(1, 0, 1, 0) 0.7 0.7, smooth 
cubic-bezier(0, 1, 0, 1)"

Here the direction of the start control point of the first bezier is 
ignored, and set to match the end of the ease-in segment. Similarly, the 
direction of the start control point of the second bezier is ignored, 
and set to match the end control point of the first bezier.

As a further simplification, we propose that if the coordinates 
specifying the end of the range are ommitted for some segment, the 
ranges of any underspecified segments are set so as to evenly distribute 
the available space (both in x and y). For example ...

"ease-in 0.2 0.2, ease-in, ease-in"

is equivalent to ...

"ease-in 0.2 0.2, ease-in 0.6 0.6, ease-in"

Furthermore, if only one such coordinate is omitted, it is used for both 
the x and y compoenents. For example ...

"ease-in 0.2, ease-in, ease-in"

is equivalent to ...

"ease-in 0.2 0.2, ease-in 0.6 0.6, ease-in"


Discussion:

Discussion about when the positions of timing functions are unspecified, 
whether they are evenly distributed or distributed such that they line 
up with keyframes.

In general, we try to maintain a distinction between timing and 
animation. However, we note that it can be convenient to have timing 
functions line up with keyframes (cf. SVG).

For now, we think it is less surprising to have timing functions be 
independent of animation. This also makes more sense when the timing 
function is applied to a timing group or an animation with an animation 
effect other than a keyframe animation effect.

If we want to add the convenience later of lining up with keyframes we 
can introduce explicit notation to indicate the dependence on keyframes.

(Until then, this is pretty easy to polyfill.)

Also raised the question of whether the list of timing functions and 
their positions (x and y) should be separated into parallel lists. We 
note that this may make it impossible to have 'holes' in the list of 
positions--not sure how critical this is.

Shane thinks keeping them together is slightly easier to deal with, and 
that there aren't strong reasons to separate them (e.g. we're not going 
to animate them).

ACTION: Brian to review with Mozilla workgroup next week.


4. EFFECT COMPOSITION REWORK
============================
(Sydney team)

While writing section 21 we realized that we would need to define how 
the simple animation value of the path animation effect is composited 
with the underlying value. It seems like it would be cleaner and we 
would have less redundant text in the spec if we described composition 
separately. Compositing could be a separate step in the model that 
combined animation values (perhaps with separate "add" and "set" 
components) in the stack. This seems simpler and is more likely to match 
the way the model is implemented.

ACTION: Sydney team to draft the rework.

Doug: I'd also prefer we didn't call this "compositing", but rather 
something like "combining values in animation stacks".

 > Discussed that this is really only a concern for implementors and we 
expect 'composite' is clear for authors. On the other hand, 'combine: 
replace' seems odd.

RESOLUTION: Leave the name as compositing. The property shall be 
'composite'.


5. EVENT MODEL
==============
(Sydney team)

Our primary concern is that the event model shouldn't prevent animations 
from playing smoothly. The spec currently uses synchronous events, which 
means that from the prespective of JavaScript, we must halt the 
animation while invoking the event listener. Given the timing gurantees 
of the model, this means that the animation may have to jump forwards 
when the listener completes and we resume playing the animation. (Note 
that the is independent of whether or not animations are displayed on a 
separate thread. In this case, while the animation could continue to 
update while the model is halted on the JavaScript thread, this risks 
the animation 'overshooting' if the event handler modifies the animation.)

The use of async events would avoid this. In this case, the event is 
triggered as usual, but is delivered to the target as some future point, 
while the animation is allowed to continue. Obviosuly this means that 
there's no way to gurantee that an event listener runs before any given 
point in the animation.

In addition, we think that the timingpause and timingseek events should 
be moved from TimedItem to Player.

Given the two above points, perhaps it's best to drop all events from 
TimedItem for v1? An async event on a TimedItem can be synthesised using 
a custom effect (Though you'd need to manually implement event 
propagation if desired, and we should guarantee that zero-width custom 
effects are sampled at least once, even when seeking past).

 > Further discussion about these points. Firstly, the reference to 
synchronous dispatch was confusing and wrong. This has been fixed. 
Events are put on the queue in a defined order and dispatched 
asynchronously.

Discussed concern about events being heavyweight due to the propagation 
involved. It also makes handling events more cumbersome because if you 
register on a parent you have to detect if the event was for you or your 
child.

Decided that the use cases we are aware of really don't require propagation.

ACTION: Brian to make events not propagate.
ACTION: Sydney peeps to review rest of events section

Also discussed the idea of a Trigger which is like a zero-duration 
TimedItem with a CustomEffect but which is guaranteed to be called only 
once when the time it is registered against is passed (in either direction).

Decided this can be easily realised using events if they don't 
propagate. So for now we will just do events.


Next meeting: Thurs May 16 18:00 PDT / Fri 17 May 11:00 AEST / Fri 17 
May 10:00 JST @ https://etherpad.mozilla.org/bFKmqxgfow

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Tuesday, 14 May 2013 04:33:34 UTC