[web-anim] Web Animations minutes, 15 February 2013

Web Animations minutes, 15 February 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.g4AmirOCYzH/latest
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 HTMLMediaElement’s 
play() (e.g. if the start time is in the future, calling this method 
should NOT make the thing start, it simply unpauses if you’ve 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(); can’t 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 it’s 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 don’t 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 we’ve 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 doesn’t matter.

➙ Shane will look into other curves too.


Discussed meeting times. Good-looking options are:

a) Fri 10am AEDST / 8am JST
b) Wed 10am AEDST / 8am JST

We'll try Fri for now and if it's difficult (due to closeness with SVG 
telcon) then we will try Wed.

Next meeting: 22 Feb 2013 10am AEDST / 8am JST / 3pm PST

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

Received on Friday, 15 February 2013 05:00:19 UTC