[web-animations] Web Animations minutes, 16 May 2014

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