Server Notice:

hide

Public Pad Latest text of pad WoyQinDYyA Saved Jan 10, 2013

 
Meeting 39:
 
Web animations minutes, 10 / 11 January 2013
 
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
 
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. parent is not document time line)
 -- setting currentTime on a slaved child throw 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 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 (BRAND NEW AND NEVER EVER EVER SEEN BEFORE) 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