Server Notice:

hide

Public Pad Latest text of pad d6CZxjKKAH Saved Feb 14, 2013

 
Meeting 47
 
Web Animations minutes, 15 February 2013
 
Present: Doug, Dmitry, Shane, Silvia, Steve, Brian
 
Agenda:
1. Review of media integration
2. Should it be getComputedTiming() or just computedTiming?
3. More complex timing functions
 
 
1. TOP-LEVEL OBJECT REVIEW
=========================
 
Presented summary of discussion regarding Players etc.
 
Whiteboard reference: http://cl.ly/image/1O0o2g0b2W20
 
Code sample:
  var anim = new Anim(...);
  var p = document.timeline.createPlayer(anim);
  p.startTime = 5;
  p.pause();
 
A few questions to nail down:
 
a) Is the parameter to Document.timeline.createPlayer optional?
 
Yes, since this allows you to set up the players (with their start times) and set (schedule) the timed items later.
 
i.e. Timeline.createPlayer(optional TimedItem item)
 
b) Is Player.play(TimedItem item) needed?
 
No, not if Player.timedItem is writeable. Making Player.timedItem writeable allows you to substitute in another animation whilst maintaining current time / playback rate etc.
 
If you want to reset then just set Player.startTime to Timeline.currentTime (or just cancel and createPlayer with the timedItem).
 
c) What does cancel() do?
 
Cancel sets timedItem to null.
 
 
Discussed whether unpause() should be called play() but agreed it should stay unpause() because the semantics are different to HTMLMediaElements play() (e.g. if the start time is in the future, calling this method should NOT make the thing start, it simply unpauses if youve paused). Also: unpause() has no effect without calling pause() first, so it's an appropriate name.
 
Also discussed whether Player can control multiple TimedItems but agreed that this is not necessary since you can just use a ParGroup for that.
 
Also discussed how audio/video is part of this and decided for a MediaRef object that is also a TimedItem. MediaController could also be referenced from a MediaRef object Shane is going to have a go at sorting through the details.
 
 
2. SHOULD IT BE getComputedTiming() OR JUST computedTiming?
=======================================================
 
getComputedTiming() parallel to getComputedStyle(); cant change
getComputedTiming() suggests a snapshot (i.e. not live)
 
Should it live on document.timeline? To better parallel window.getComputedStyle()?
 
getComputedTiming() suggests it is a property on the Window with a parameter of TimedItem.
computedTiming is more like a property on TimedItem.
 
We need a property on the TimedItem element and its supposed to be read-only.
 
TimedItem.getComputedTiming()
parallels getComputedStyle() better
better suggests it is read-only? but we have read-only attributes elsewhere
provides a snapshot. Is this really more useful though?
 
TimedItem.computedTiming
seems more natural since we dont normally use getters to get local values
 
Decided to revisit yesterday's decision about splitting off computed timing and consider a number of alternatives:
 
// Option 0
interface TimedItem {
 
  // Timing layout parameters
  double startDelay;
  double iterationStart;
  unrestricted double iterationCount;
  (unrestricted double or DOMString) iterationDuration;
  double playbackRate;
 
  // Timing style parameters
  FillMode fillMode;
  PlaybackDirection direction;
  TimingFunction? timingFunction;
  
  // Calculated timing params
  readonly double computedIterationDuration;
  readonly double startTime;
  readonly double endTime;
  readonly double activeDuration;
  
  // Playback state
  readonly double currentTime;
  readonly double outputTime;
  readonly double currentIteration;
 
  // Event callbacks
  EventHandler onstart;
  EventHandler oniteration;
  EventHandler onend;
  
  // Player
  Player getPlayer();
};
 
// Option 1:
interface TimedItem {
  readonly TimingDictionary specified;
  
  // Calculated timing params
  readonly double iterationDuration;
  readonly double startTime;
  readonly double endTime;
  readonly double activeDuration;
  // May need the *actual* TimingFunction here? (For when specified.timingFunction is a string)
  
  // Playback state
  readonly double currentTime;
  readonly double outputTime;
  readonly double currentIteration;
  
  // Event callbacks
  EventHandler onstart;
  EventHandler oniteration;
  EventHandler onend;
  
  // Player
  Player getPlayer();
};
 
dictionary TimingDictionary {
    double startDelay = 0;
    FillMode fillMode = "forwards";
    double iterationStart = 0.0;
    unrestricted double iterationCount = 1.0;
    unrestricted double? iterationDuration = null;
    double defaultPlaybackRate = 1.0;
    PlaybackDirection direction = "normal";
    (DOMString or TimingFunction)? timingFunction = null;
};
 
// Option 2:
interface TimedItem {
  // Timing layout parameters
  double startDelay;
  double iterationStart;
  unrestricted double iterationCount;
  (unrestricted double or DOMString) iterationDuration;
  double playbackRate;
  
  // Timing style parameters
  FillMode fillMode;
  PlaybackDirection direction;
  TimingFunction? timingFunction;
  
  readonly ComputedTiming computedTiming;
  // may be getComputedTiming() ?
  
  // Event callbacks
  EventHandler onstart;
  EventHandler oniteration;
  EventHandler onend;
  
  // Player
  Player getPlayer();
};
 
interface ComputedTiming {
  // Calculated timing params
  readonly double iterationDuration;
  readonly double startTime;
  readonly double endTime;
  readonly double activeDuration;
  
  // Playback state
  readonly double currentTime;
  readonly double outputTime;
  readonly double currentIteration;
}
 
// Option 3:
interface TimedItem {
  readonly TimingDictionary specified;
 
  ComputedTiming getComputedTiming();
  // Maybe readonly ComputedTiming computedTiming; ?
  
  // Playback state
  readonly double currentTime;
  readonly double outputTime;
  readonly double currentIteration;
  
  // Event callbacks
  EventHandler onstart;
  EventHandler oniteration;
  EventHandler onend;
  
  // Player
  Player getPlayer();
};
 
After some fairly intense deliberations weve decided to go with option 1 for now. We will clearly mark in the spec as an issue some of these alternatives and see what feedback we get.
 
There was also the suggestion of gathering metrics from the polyfill to see which functions are used most often so we can optimise the API accordingly.
 
 
3. MORE COMPLEX TimingFunctions
==============================
 
Some other APIs have many many timing functions. We don't want to define all of these in Web Animations, and certainly not in the first version. However, many authoring tools will want to export different effects (e.g. bounce effects etc.).
 
It would be useful if the baseline version of Web Animations had a means of representing such timing functions.
 
There is a proposal to extend SplineTimingFunction so that it can take more than one segment. This would allow most timing functions to be approximated. Also, all implementations will be required to implement the maths for SplineTimingFunction anyway so it should be minimal implementation overhead to support multiple segments.
 
However, we need to consider what constraints are necessary on the control points in order to ensure that the resulting curve produces a function (i.e. there is one and only one output value for each input time).
 
One strawman proposal was to take multiples of four numbers where the sequence is something like this:
 
<first point is 0,0>
[0,1]: first control point
[2,3]: second control point
[4,5]: end of first segment
<first control point of second segment is the reflection of [2,3]>
[6,7]: second control point of second segment
<end point is 1,1>
 
But this makes it hard to represent curves with sharp points (such as bouncing). We need to look into what limitations are needed on the input values.
 
Dmitry proposed an approach that takes 3 points for all segments except for the last, which takes 2. (0, 0) forms the first point for the first bezier, (1, 1) forms the last point for the last bezier. The final point of each bezier forms the first point of the next bezier.
 
The final points (i.e. the 3rd, 6th, 9th, etc.) (or maybe all the points?) must be monotonic increasing in x.
 
This approach allows for sharp corners at the cost of more difficulty in producing smooth curves; as the interface is primarily for tool designers this increase in difficulty doesnt matter.
 
Shane will look into other curves too.