Server Notice:


Public Pad Latest text of pad IFCnsPoRSr Saved Aug 22, 2012

Meeting 28
21 Aug 18:20 PDT / 22 Aug 11:20 AEST / 22 Aug 10:20 JST
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
7. Graphical Web presentation
Brian: Reworking all the timing stuff
Shane: Lots of implementation stuff - timing model is close to complete
   Showed demo -- nice work!
We have two different intervals that are confusing:
   Interval Zero Point: startTime
   End: max(startTime, End of 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
duration  // currently, this is iterationDuration
itemDuration // this is problematic because it could be negative if we allow the endTime to come before the start
(what I've currently got)
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: // readonly?
time.anim.dur // writeable -- for the above use case // writeable -- this is the time space you seek in
time.item.dur // readonly -- for the reasons outline above
  currentTime // = itemTime .. who cares that it doesn't match HTMLMediaElement
> 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.iteration.index - timing.iterationStart) * effectiveIterationDuration
time.iteration.index // = + startDelay
animationDuration // = (timing.iterationCount - timing.iterationStart) * effectiveIterationDuration
currentTime // =
effectiveIterationDuration // READ ONLY
We can probably get away with just the following four:
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)
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.
<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);
> Will continue this discussion next time
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.
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"
<animate begin="; 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
> Deferred until next time
Next meeting: 28 Aug 18:20 PDT / 29 Aug 11:20 AEST / 29 Aug 10:20 JST @