- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 11 Jan 2013 13:34:17 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
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