- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 16 May 2014 17:37:47 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 16 May 2014 Present: Doug, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.11295 Agenda: 1. Next WD 2. Prioritization 3. Renaming contd. 4. Scheduling things for the next sample 5. Switching from NavigationStart to align with RAF times, or better 1. NEXT WD ========== (Brian) All done except: * startTime / timeLag changes -- I've made the changes locally but I'm not sure it's what we want--see next item, "2. Prioritization" * If we decide to rename things (see "3. Renaming contd.") then we should do that before we publish 2. PRIORITIZATION ================= (Brian) In reworking the time lag / start time changes I started wondering if we really want to use start time after all. The situation is basically this: * It would be nice to schedule things to play in advance--i.e. be able to create a player and set its start time. - You *could* achieve that by setting the delay on the source content but that seems odd. You should be able to do this without touching the source content - You *could* achieve that by setting the currentTime but that's quite complex for something simple * Now we could just have start time as a parameter to the player ctor/factory methods but that would be quite odd to be able to set it once and not be able to change it. That implies having a startTime member that is mutable. * I think for both reading and writing, the startTime member should probably represent the "effective start time" * Then does setting startTime effect prioritization? Presumably it does since otherwise you'd get different behaviour between the following: var player = new AnimationPlayer(..., 1000); and: var player = new AnimationPlayer(....); player.startTime = 1000; * And now you finally arrive at the situation where the following can have side effects: player.startTime = player.startTime My current thinking is, should we just sort by player sequence order? We can make this compatible with SVG/CSS by just making them careful about the order in which they generate animations and providing hooks as needed for them to shuffle the order. Eventually we'd open up these hooks to script. I'd like to avoid setting a numerical priority number. z-index shows why this is a bad idea, "z-index: 99999999" etc. Perhaps something like a "bring to front" / "push to back" / "bring before X" API could work. Shane: +, like, 10000000 Another option for hooks is to allow edges to be defined: z-index: before(#foo) Doug: +1 on splitting start time and priority, and exposing start time as the effective start time. > Brian to try and make prioritization independent on start time 3. RENAMING CONTD. ================== (Brian) Context: Item 2 from http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0082.html I'm leaning towards just renaming TimedItem to AnimationSource but mostly because trying to write spec text that differentiates between a "generic animation object" (=AbstractAnimation/AnimationBase/AnimationNode etc.) and a "concrete animation" (=Animation) seems hard. :) Shane: SGTM Doug: AnimationSource seems fine. > Brian to rename TimedItem to AnimationSource and Timing to AnimationTiming 4. SCHEDULING THINGS FOR THE NEXT SAMPLE ======================================== (Brian) My proposal: http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0085.html Doug: Sorry I didn't have a chance to reply yet, but I think this is great. We already have basically this (in blink) to deal with off-main-thread CSS Animations and Transitions. I'm not sure on the proposed "dummy times". I think that the player should act as if its current time is still 0 after calling play/animate. Any animations should still take effect immediately. Doug: Similar to CSS A&T, once an animation has started based on the style, it should have the effect of the first frame. Brian: Sounds good. Doug: Agree with having all players started in the same task agree on a single start time. We have no issue implementing this in Blink. Even with multiple threads there's still only a single time that changes can be displayed on the screen. Brian: Ok, we can try implementing this too. One minor adjustment to my proposal, the Promise should be called 'started' not 'ready' to match CSS Font Load events > Discussed TAG feedback about rendering requirements (i.e. not rendering just style changes without animation changes or vice versa). Doug to look into how tasks are defined and see if we can spec this more clearly in terms of tasks. > In general the proposal above looks good but we will wait until after publishing the next WD before integrating into the spec. 5. SWITCHING FROM NAVIGATIONSTART TO ALIGN WITH RAF TIMES, OR BETTER ==================================================================== (Doug) BlinkOn presentation on "glass time": https://docs.google.com/a/google.com/presentation/d/1oKEunkaeiTwznGaIX_yIhe6HPfZBXhtv8r5J5hz52UI/edit#slide=id.g339b6021e_01956 The time passed to RAF callbacks might change in the future. If it does the same change would likely apply to the web animations timeline. > We'll wait and see. It's best to just continue to align with RAF for the time being. Time origin: https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview.html#sec-time-origin Next meeting, Thurs 29 May 2014 07:00 UTC 07:00 Local time: http://arewemeetingyet.com/UTC/2014-05-29/07:00/Web%20Animations Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 16 May 2014 08:38:24 UTC