Web Animations minutes, 21 / 22 August 2012

Web Animations minutes, 21 / 22 August 2012

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.LIrBvR$UJFL/latest
Present: Dmitry Baranovskiy, Alex Danilo, Shane Stephens, Brian Birtles

Agenda:

1. Status update
2. Headaches with intervals
3. Does playbackRate apply to the delay?
4. Multiple intervals, reversing etc.
5. Supporting syncbase timing
6. Anim ctors

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

Brian: Reworking all the timing stuff
Shane: Lots of implementation stuff - timing model is close to complete
    Showed demo -- nice work!

2. HEADACHES WITH INTERVALS
===========================

We have two different intervals that are confusing:

* ITEM INTERVAL
    Interval Zero Point: startTime
    End: max(startTime, End of animation interval)
* ANIMATION INTERVAL
    Start: startTime + startDelay
    End: Start + animationDuration

(All this comes about because of the delay, by the way...).

It's a bit confusing but I've been reworking the API to make the item 
interval the primary frame of reference since we decided seeking, 
pausing etc. happen in item time. So I've replaced animationTime and 
animationDuration with itemTime and itemDuration.

An animation can still play outside the item interval if you have a 
negative delay. That's important for overlapping items within a sequence 
container (i.e. right-align, since you can do overlapping left-align 
with a par container)
   -- maybe that's the problem? Maybe we're trying to be too clever by 
allowing that and we should just clip outside the item interval?
   -- the use case was to have an animation start 5 seconds before 
another ends (e.g. curtains closing over a movie when it finishes). It's 
a pretty important use case but maybe we should use some other mechanism 
to achieve it?

At any rate, it's possible to have an animationDuration of 3s, and a 
startDelay of -5s, i.e. an animation that runs entirely before the 
startTime. I've defined the item interval so that in that case it is 
just a zero interval. But that means you can't constrain length of the 
animation by setting the itemDuration like you could when we exposed the 
animationDuration.

I did have one other proposal for the Timing API,

instead of

iterationTime
duration  // currently, this is iterationDuration
itemTime
itemDuration // this is problematic because it could be negative if we 
allow the endTime to come before the start
(what I've currently got)

have:

   time.iteration.now
   time.iteration.dur
   time.iteration.index
   time.anim.now
   time.anim.dur
   time.item.now
   time.item.dur

Dmitry: How many mistypes will happen while typing “time.item”?
Brian: good point

That, at least, exposes the animation duration, but I don't like it a 
lot. It's kind of intimidating and it's weird if we have:

time.anim.now // readonly?
time.anim.dur // writeable -- for the above use case
time.item.now // writeable -- this is the time space you seek in
time.item.dur // readonly -- for the reasons outline above

Maybe:

   currentTime // = itemTime .. who cares that it doesn't match 
HTMLMediaElement
   itemDuration
   time.iteration.now
   time.iteration.dur
   time.iteration.index
   time.anim.now
   time.anim.dur

 > After discussion, what we want is:

• endTime can come before startTime
• don't want to expose item duration since it can be negative and that's 
just weird to some (Shane dissents)
• want to expose animation duration since that is never negative and 
that's the duration you want to clamp / adjust usually
• need to expose iteration duration and iteration time

Proposal:

time.anim.now // = time.iteration.now + (time.iteration.index - 
timing.iterationStart) * effectiveIterationDuration
time.iteration.now
time.iteration.index
time.item.now // = time.anim.now + startDelay
animationDuration // = (timing.iterationCount - timing.iterationStart) * 
effectiveIterationDuration
currentTime // = time.item.now
effectiveIterationDuration // READ ONLY

timing.iterationDuration

We can probably get away with just the following four:

currentTime
animationDuration
iterationTime
iterationDuration

All are writeable? (Not sure about iterationDuration yet...)

Other resolutions:
 > endTime can come before startTime and hence the item duration (if we 
even need such a concept) can be negative
 > Need to rework interval descriptions accordingly (i.e. drop the item 
interval concept since it no longer really works)

3. DOES playbackRate APPLY TO THE DELAY?
===================================

If you have an animation with a delay of 3s and the playbackRate is 2, 
does the delay become 1.5s or remain 3s?

Dmitry: My gut-feeling that delay should remain the same. As Shane said 
changing one attribute should affect as less other attributes as possible.

SO RESOLVED: Playback rate only applies to the animation interval (i.e. 
doesn't affect the delay)

4. MULTIPLE INTERVALS, REVERSING ETC.
=================================

A while ago we looked at the fact that we want to be able to support 
running multiple animations such that they add to their base value but 
not to each other.

e.g.

<animate begin="3s; 10s" fill="freeze" additive="sum">

Assume this gives
AnimTemplate x 1
Anim x 2 { startTime: 3s, 10s}

When the second Anim starts, it shouldn't add to the previous run (which 
is filling) but should add to any animations running further down the stack.

I think the main proposal we settled on last time was to make Anim 
objects that point to the same AnimTemplate override each other in this 
way. Is that still what we want to do? Anyone want to spec it?

What if we have:

a = new AnimTemplate(....)

b = a.animate(div);
c = new Anim(div, ...);
d = a.animate(div);

b
c
d

 > Will continue this discussion next time

5. SYNCBASE TIMING
================

As far as I (Brian) see, there are three issues that are problematic 
with syncbase timing:

* Detecting all and breaking all kinds of cyclic dependencies in a 
consistent, interoperable fashion
* Maintaining the network of links complicates backwards seeking since 
you have to recall which interval triggered which in a cyclic 
relationship since the animation sandwich relies on this information (if 
A and B have the same start time but B was triggered by A, B adds on top 
of A)
* Cyclic dependencies can be 'generative' in the sense that the network 
continues to produce intervals infinitely. This complicates seeking 
since you can't generate all the intervals upfront and just do a binary 
search to find the closest one. Instead you have to step through the 
intervals one by one.

However,
a) We need to support syncbase timing in the SVG integration spec for 
backwards compatibility
b) Something *like* syncbase timing is probably very useful to Web 
Animations core.

Regarding (b), one use case I have in mind is if you assume we have 
these two timelines, the content timeline and the animation timeline, 
and you want to sync something between the two.

For example, you have a children's animation story book. It lives in the 
content timeline since it's something you want to replay/rewind/speed up 
etc. However, it's interactive. "Choose your own adventure". At certain 
points in the cartoon it stops and certain UI controls get enabled. The 
animations on the UI controls (e.g. glowing) should probably be in the 
effects timeline since you never want to rewind / replay them. But they 
should be keyed off events in the content timeline.

I'm not sure if that's the best example, but I think there probably will 
be use cases where you want to synchronise things in different groups.

Also, we need to support synchronising with HTML5 media controllers 
which work out of band like this (but have the extra requirement of 
synchronising pausing / seeking as well).

I wonder we can do something like:
i) make a simplified version of syncbase timing that avoids the problems 
listed above
   -- one idea that came to mind is to have named "moments"
e.g.
<animate begin="a.click; startWave" ...>
<animate begin="startWave" ...>
<animate begin="10s; startWave" ...>
    In the example, if 'a' was clicked, 'startWave' would get resolved 
to that time (initially it acts as an infinite time, or technically an 
unresolved time in SMIL terms) and the others would start accordingly. 
Any animation can cause the time to be resolved.
    I'm not sure if this actually helps or even works. I think we really 
need to approach this firstly in terms of graph theory and see what 
actually makes sense.
    The above essentially removes directionality from the network.

   -- it would probably be quite acceptable to have restrictions on how 
it could be used with children of a sequence container. For example, 
sequence container children can only trigger animations, not be triggered.

ii) spec syncbase timing in SVG in terms of this underlying interface 
and in the process make cyclic dependencies predictable and useful
   -- NOTE: one of the complications with syncbase timing comes about 
from using the direction of syncbase relationships to establishing 
priority in the animation sandwich. BUT amongst browsers I'm pretty sure 
only Firefox actually implements this. As a result, there shouldn't be 
significant content depending on this. We should investigate changing 
this behaviour if it makes seeking simpler.

iii) spec syncing with media controllers in terms of this
    -- again it would probably be quite acceptable to have restrictions 
on this with regards to sequence containers. Perhaps sequence containers 
can even be treated as a kind of media controller???

Alex, do you want to look into this?

 > Didn't talk about this in any detail but Alex agreed to look into it

6. ANIM CTORS
=============

Issue from last time: https://etherpad.mozilla.org/IW8zT9yCin

 > Deferred until next time

Next meeting: 28 Aug 18:20 PDT / 29 Aug 11:20 AEST / 29 Aug 10:20 JST @ 
https://etherpad.mozilla.org/4en317zuGQ

Received on Wednesday, 22 August 2012 06:48:45 UTC