[web-anim] Web animations minutes, 10 / 11 January 2013

Web animations minutes, 10 / 11 January 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.ZoTe0p0Zuo4/latest
Present: Dmitry Baranovskiy, Steve Block, Shane Stephens, Douglas 
Stockwell, Brian Birtles

Agenda:

1. Status update
2. Interface options: reworking time sources


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

Brian:
* Add section on interaction with script
* Add Element.animate
* Remove Animation.sample
* Work on WaveTimingFunc / SpringTimingFunc / SmoothTimingFunc
   - Setting up an appointment with a storyboard artist to get input here
   - 
https://docs.google.com/spreadsheet/pub?key=0AnaYHBKTKeZldGdTNnRGeUF6N1k1T2tfbkxqbEdfNGc&gid=2

Sydney team:
* Polyfill work
* Time sources design work and prototyping
* Working on test frame work (integrates with Shepherd and testharness.js)


2. INTERFACE OPTIONS: REWORKING TIME SOURCES
============================================

We are considering not allowing all timed items to be 
seekable/pausable/etc. but only at the root nodes.

Shane's proposal is:

1. Remove play, pause, reverse, defaultPlaybackRate from TimedItem 
(playbackRate now acts like defaultPlaybackRate)
2. Remove timeSource pointer from TimedItem and reintroduce parent
3. Create a PlaybackController class. Give it play, pause, reverse 
methods and a playbackRate value. This class is not directly constructible.
4. Allow documents (as TimeSources) to create PlaybackController classes 
- createPlaybackController()
5. Provide an attach() method on TimedItem that optionally takes a 
PlaybackController. If no parameter is provided, then 
document.newController() is called and the newly created controller is used.

There'll be a detach() method to match attach(), etc. etc.

Media integration:
6. MediaController provides a createPlaybackController() method.

Case A:
var anim = new Animation(...);
var controller = document.createPlaybackController(); // this step is 
optional
anim.attach(controller);
controller.play();

Case B:
var anim = new Animation(...);
controller = anim.attach();
controller.play();

Case C:
(sub-proposal, introduce TimedItem.start as an alias of attach, play)
var anim = new Animation(...).start();

(getActiveAnimations returns PlaybackControllers)
getActivePlaybackControllers()[0].playbackRate = 7; // RIGHT
getActivePlaybackControllers()[0].animation.playbackRate = 7; // SLOWER

(getActiveAnimations returns Animations)
getActiveAnimations()[0].playbackRate = 7; // SLOWER
getActiveAnimations()[0].controller.playbackRate = 7; // RIGHT

Brian's main concern: Intermediate object is confusing and 
MediaController already provides a precedent to deal with this situation.

How media controllers work:
  -- children can be paused independently
  -- unpausing a child makes it catch up to the group time
  -- seeking a child throws an InvalidStateException
  -- setting playbackRate on child (closest thing to reversing) is 
ignored and parent playbackRate is used instead
  -- the controller itself can't be repeated or reversed
  -- its playback rate can be set and governs all children
  -- media controllers can block either by being paused or because a 
child is blocked (e.g. buffering)
     -- then the time won't advance so effectively the children are blocked

How this might look like if we followed this pattern:
  -- still have play(), pause() on all items but their behavior differs 
when they are not at the root (i.e. have a parent group or not)
  -- setting currentTime on a slaved child throws InvalidStateException
  -- setting playbackRate on a slaved child is ignored
  -- reverse() == set playback rate so it's ignored
  -- pause() -- defer to the ancestor
        TimingGroups are different to MediaControllers in that they 
maintain strict synchronisation
        It's more like the blocking behaviour of media elements
        Eliminate the need for locallyPaused (which is somewhat confusing)

Comparing:
(A is the PlaybackController proposal, B is the one without--i.e. 
pause/play on the TimedItem itself)

   A: anim.controller.pause()
   B: anim.pause()

   A: anim.currentTime // read-only
   anim.controller.currentTime = 5; // seek
   B: anim.currentTime // mutable but throws when not attached to 
documentTimeSource

   A: var anim = new Animation();
   anim.attach().play(); // anim.start() might do this (above)
   B: var anim = new Animation();
   anim.play();

Extended discussion about which is simpler. Some feel that adding a 
controller clarifies an existing concept and that having, e.g. seeking, 
behave differently when a TimedItem has a parent group vs when it 
doesn't is confusing. Others feel introducing the concept of a 
controller adds complexity since the concept doesn't already exist, and 
that aligning with MediaController provides intuitive behavior.

Further discussion about the following case:

   var cont = anim.getController(); // Looks up the hierarchy to get the 
playback controller
   group.append(anim);
   // cont.pause() no longer has any effect

Discussed that the controller might still be re-used, e.g. to substitute 
in an alternative animation that picks up where the previous one left off.

Also, there was the suggestion that authors should be encouraged to 
interact primarily with controllers, and not the animations themselves.

Concern about this lead to the following action...

➙ Shane to write up yet another approach which uses the terms 
"Animation", "TimingGroup" and "TimedEffect".


Next meeting: Mon Jan 14, 17:30 PST / Tues 15 Jan 12:30 AEDST / Tues 15 
Jan 10:30 JST @ https://etherpad.mozilla.org/WMI4F0NGQV

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

Received on Friday, 11 January 2013 04:34:49 UTC