[web-animations] Web Animations minutes, 23 Jan 2014

Web Animations minutes, 23 Jan 2014

Present: Doug, Shane, Brian
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.0-mAgddgQoP/latest

Agenda:

1. Status update
2. Animation model rework
3. Next WD
4. Events


1. STATUS UPDATES
=================

Brian: See item 2.
Doug: Some clarifications around NaN.


2. ANIMATION MODEL REWORK
=========================
(Brian)

I've been working on a branch since there are a lot of changes involved 
and I want to make sure the spec is internally consistent before I merge:

 
https://dvcs.w3.org/hg/FXTF/raw-file/rework-animation-model/web-animations/index.html

The basic changes are:
* Re-add keyframe specific timing functions
* Remove timing function chains
* Make CSS properties interpolable etc. by default and make all those 
definitions consistent
* Make paced timing no longer a timing function but a part of general 
spacing behavior
* Allow targetting attributes
* Returning computed values of keyframe offsets

It's mostly done. Just motion path effects left to go. Currently trying 
to work out how to spec some of the spacing behavior.

A few edge cases that might be of interest:

Edge case 1:

   0% {
     left: 0;
     top: 0;
   }
   * { // 20%
     top: -20px;
   }
   * { // 40%
     top: 0px;
   }
   * { // 60%
     top: 20px;
   }
   * { // 80%
     left: 100px;
     top: 0px;
   }
   100% {
     left: 75px;
     top: -20px
   }
   spacing: paced(left)

This should give a nice zig-zag pattern. But what if you want to make 
'top' use a different timing function or composition mode but still line 
up with the pacing applied to left? Basically, you can't unless we later 
introduce a special 'same time as last keyframe' sentinel value.

We could change the default spacing so that when it evenly distributes 
keyframes without the paced property it lines up the first keyframe at 
the start of the interval specifically so you can do this but that 
doesn't scale. If you wanted to then animate margin-bottom with yet 
another timing function it wouldn't work.

Perhaps this is a bit contrived. For this use case, a motion path effect 
is likely much more suitable.

 > We agree that it's OK for this to be slightly clumsy in V1.

Edge case 2:

If I set up a long path and say:

   timing points: 0; 0.75; 1
   spacing: distribute

Do you expect it takes half the time to get to the 75% mark and then 
half the time to get to the end? But what about the spacing of points 
between, say 0 and the 75% mark. Do we used paced timing there? My 
suggestion: yes. I just don't think even spacing of points on the path 
is generally very useful except for simple cases and for those you can 
calculate the point offsets if you need something other than paced timing.

Basically you end up with a notion of a "natural spacing mode" which is 
used to "fill in the gaps".
  - With keyframe effects it's distribute spacing. So with spacing: 
paced, we use even distribution to space out keyframes without the paced 
property.
  - For motion path effects it's paced spacing. So when we have some 
positioned points we used paced distribution to space out the remaining 
points.

 > This seems to be pretty good.


3. NEXT WD
==========
(Brian)

Proposal: Leave out events and do them properly. There's no problem 
publishing an updated WD a month or two later if we solve it soon.

That leaves:
- Animation model changes (finished soon, needs review)
- Alan's suggested changes to player
- Naming of timing groups (straw poll at FXTF meeting?)
- Timeline start changes (mostly decided, but should be use 
navigationStart instead? Would that make it easy to line up with other 
navigation times?)

 > Summary: using navigationStart seems to make a lot of sense as now 
our numbers match those generated by performance.now(). Yay!

 > WRT WD: Yes, lets definitely get this out soon :)


4. EVENTS
=========
(Shane)

Shane's summary:

Two kinds of event system we've been considering:
(1) "exact", non-sample-based events
(2) sample-alignment of events

Overall, it seems like the drawbacks of (2) are sufficient to rule it 
out as an approach.

(1) has problems too, mainly that as it gets more sophisticated (i.e. 
more likely to have good performance characteristics) it gets more complex.

Currently we have (1) specced, except during long delays, in which case 
we switch to (2). This is also problematic - what is a long delay?

BTW: CSS (at least in Blink, WebKit, and it seems in Firefox too) does 
(2). SVG does (1).

--

Observation: the overwhelming majority of use cases are player start / 
player end.

Probably, most of the rest of the use cases involve very simple 
instrumentation of a unique event in the timeline.

Suggestion: move the cost of event registration to registration, rather 
than generation. Only allow events on players, of 4 types:

(1) start events
(2) end events
(3) n-seconds-after-start events
(4) every-n-seconds in range (start, end) events
(maybe also allow pause/play)

In the strong version of this proposal, you manually generate the times 
for these events using something like:
player.getTimes([{item: item, timeFraction: 0, iteration: *}]) -> []

This is the function that will be expensive in pathological corner cases.

In the weak version, hide getTimes behind TimedItem 
addition/removal/timing adjustments, so that these actions become 
expensive in pathological cases, i.e. still generate times upfront.

Here is a pathological case:

ParGroup
([
         ParGroup
         ([
                 Animation(..., {..}, {duration: 2, iterations: 100}),
                 Animation(..., ..., 3);
         ], { iterations: 50}),
         Animation(..., {..}, 5)
], { iterations: 20});

Brian's feedback:
- The idea of associating events with the player seems to have merit. 
The syntax is probably somewhat less convenient but has some parallels 
to, e.g. event registration in backbone.
- Regarding the strong version, I'm not sure generating 100,000 numbers 
for a call to getTimes is a good idea for what may be a legitimate use.
- For a mild case where we generate 1,000 numbers, that might work fine 
on a developer's machine but not on a mobile device so I don't think 
this solves the issue of predictable performance, just ameliorates it.
- We're already visiting each node on a sample (or at least each node 
that could generate an event) so if we do (2) from above then we could 
just record which of a very limited no. of events needs to be generated. 
That seems cheaper.
- I don't quite understand how this works if the outer duration is Infinity.
- I prefer the weak version but it seems to boil down to an 
implementation requirement that event times be calculated up-front and 
I'm not yet convinced we need to spec that.

Need to consider: timing functions on groups (although note that 
getTimes can still generate periodic events here).

 > We'll come back to events next time


Next meeting: Thurs 13 Feb 22:30 UTC @ 
https://etherpad.mozilla.org/Tsq7DD9wKy
   Local time: 
http://arewemeetingyet.com/UTC/2014-02-13/22:30/Web%20Animations

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

Received on Friday, 24 January 2014 02:22:08 UTC