[web-animations] Web Animations minutes, 8 / 9 Aug 2013

Web Animations minutes, 8 / 9 Aug 2013

Present: Doug, Shane, Brian, Steve
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.chkOgid4IMo/latest

Agenda:

1. Status updates
2. Timing functions on groups
3. Naming
4. Auto fill mode representation in the API
5. Additive/seamless/perfect animations


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

Brian:
  - Start work on integrating chained timing functions
  - Fill mode defaults correspondance - yet to integrate
  - Tweaks to fill modes

Doug
  - CSS Animations on Web Animations Model in Blink
  - Model is still holding up well, will allow us to fix many bugs that 
exist in the current implementation

Shane:
  - Transforms demo
  - Polyfill bugfixing


2. TIMING FUNCTIONS ON GROUPS
=============================

See thread starting: 
http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0056.html

Talking points:
a) Most animations frameworks provide easing on grouped content. We 
should too.

Possible distinctions between different types of timing functions:
(1) simple timing functions
   - monotonically increasing from (0, 0) to (1, 1)
   - undefined for inputs outside of the range [0, 1]
   Q: should this include step functions? Probably not.
(2) characterizable timing functions
   - defined only on the range [0, 1]
   - pass through (0, 0) and (1, 1)
   - contain only a bounded number of inversions
(3) arbitrary timing functions

Brian thinks most frameworks only offers (1), if anything, on groups and 
that autoReverse in SMIL is a separate feature, whereas Shane tends to 
treat all of these similar features as basically the same thing.

Some discussion about what level is desirable for timing groups. But 
generally, no-one wants (3).

b) For the limited set of timing functions we currently have, finding 
the inversions is pretty simple, and only a bounded number of inversions 
can exist

This is referring to (2) from above. Shane is confident we can provide 
mathematically rigorous definitions for each of these that can be 
consistently and performantly implemented.

This basically means that we can continue to use our existing 
approximations for beziers while animating, and switch to the 
mathematical versions only when we need to determine turning points or 
inverses. Hence the details of events will match across platforms, but 
platforms don't need to change the way they handle beziers.

c) For the limited set of timing functions we currently have, iterations 
behave very similarly to timing functions. Supporting timing functions 
doesn't add extra requirements

Brian thinks category (2) timing functions do add some extra complexity 
over iterations, particularly with regards to overflow fill etc. but 
will wait to see concrete proposals regarding this.

Shane agrees that there is a limited amount of additional complexity. He 
wants to spend some time looking at how to mitigate this before 
completely throwing timing functions away.

d) Removing timing functions selectively from groups breaks the model 
quite badly as we don't have a unified view on animation content any more

Shane retracts this point. Brian's model of moving timing functions from 
TimedItem to Animation (and possibly Timing Group) mitigates this issue.

e) A number of use cases for timing functions on groups exist, including 
smooth acceleration along a path.

Brian agrees but wonders if they are high-priority use cases.

Shane's main concern is closing the door on ever being able to support 
them. Additionally, smooth movement along a path is a high-desirability 
item.

f) If timing functions aren't supported on groups for V1 of the 
specification, it will be very difficult to add support later because of 
the model changes we'd need to make (see (d)).

We discussed ways of possibly staging this. For example, by making 
timing functions a property of animations and groups, we could mark 
timing functions on groups as at risk or limit them to (1) simple timing 
functions, based on implementation feedback.

g) the main apparent problem (Brian, please confirm) is deriving 
document time from local time.
   - with a strict bound on inversions, this isn't very hard
   - it also isn't even necessary for most (all?) events use cases, as 
we discussed in Tokyo
   - maybe looking at alternatives here is a better place to solve this 
issue?

This is one problem. The other is fill modes. We need to address both to 
make category (2) timing functions viable on groups.

Brian's general concern is about introducing complexity step-by-step 
where possible.

With regards to fill modes, Brian has some concern about category (2) 
timing functions putting timed items in an 'in play' state outside their 
active interval and about fill modes affecting which events get 
dispatched. He will wait to see Shane's proposals regarding how to 
address this.

Next steps: Move timing functions off timed item and to animation and 
groups. This will allow us to possibly drop timing functions from groups 
or limit them to category (1) simple timing functions in version 1 of 
the specification.

Doug: How will we enable this in the API?

Brian: some options:
(1) leave it in the timing dictionary but map to different properties in 
Animation and Group
(2) leave it in the timing dictionary and timing, but interpret differently
(3) make it a separate property altogether (i.e. an additional parameter 
to Animation and Group?)

Doug: Either way it seems like content may change behavior if we first 
only allow category (1) and then later support category (2+), but it 
seems like this is OK, any original content that specified (2+) would be 
'invalid'.


3. NAMING
=========

i. iterationDuration -> duration - OK
ii. startDelay -> delay - OK
iii. fillMode -> fill - OK
iv. iterationCount -> repeat
   - iterationCount aligns with iterationStart
   - repeat sounds like it should be a boolean
   - iterations?
   - repeats (still sounds boolean?)
   How about 'iterations'? We can always fix it at CR :)
v. timingFunction -> easing
   'easing' for now, with an issue about possibly using timingFunction


4. HOW TO REPRESENT THE DEFAULT FILL MODE
=========================================

Background: 
http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0044.html

Option 1: TimingInput.fillMode defaults to null
Timing.fillMode cannot be null but will be filled in with the 
appropriate fill mode for the TimedItem it is attached to (note that 
this would prevent sharing Timing objects in the future or at least make 
sharing problematic)

Option 2: TimingInput.fillMode defaults to a new setting "auto"
There is no way to query the actual "used value" of fillMode with the 
current API. Something to possibly add in the future.

Option 2 seems to win.


5. ADDITIVE/SEAMLESS/PERFECT ANIMATIONS
=======================================

Responding to the remainder of Kevin's email that we began discussing 
last meeting:

(Original message: 
http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0034.html)

 > ...
 > Next is a fiddle which shows a bug with additive scale transforms. An
 > additive scale animation from 0 to 0 should result in an unchanged
 > scale of 1. Animations from 0 to 0.25 or -0.25 should result in a
 > scale of 1.25 or 0.75, and one combining both should result in a
 > scale of 1. It is only 2d as I didn't have enough time to come up
 > with good tests and figure out the result of a combined translateZ
 > and scaleZ.
 >
 > http://jsfiddle.net/zQ6n3/embedded/result/

Doug: I don't think this is a bug.

Perhaps this is an issue with the use of the term 'add' in 'composite: 
add', for transforms addition is defined as post multiplication.

This implies that 'zero' for scale addition is a scale of 1. So if you 
want to scale up a bit, then scale down a bit, you need to use 1.25 / 
0.75, not 0.25 / -0.25.

 > I also found problems with 3d rotation as well. Additive animation
 > destinations of 0 degrees fail for rotateX and rotateY. Of course,
 > both of these tests need review as I could be wrong.
 >
 > http://jsfiddle.net/ucEWr/embedded/result/

Might be a polyfill issue.
Yeah, 3D transforms aren't implemented in the polyfill yet (or are broken).

 > I played with web-animations.js and was able to fix the flickering
 > problem. In CompositedPropertyMap's applyAnimatedValues() I simply
 > provided a different baseValue, but also for clearValue() as well,
 > providing a destination value instead of null. Unfortunately it was a
 > conceptually dubious and ugly hack, a desperate attempt to be able to
 > use element.style and achieve syncing. I thought the API could use
 > the ability to pass a dictionary of destination values, somewhere.

Not being able to use element.style is an artifact of the polyfill 
implementation. Native implementations will not have this problem.
Shane thinks we can fix element.style in the polyfill.

 > Forgive me for not being fully aware of all the issues dealing with
 > the underlying value as it relates to css and wherever this is going
 > to be applied to in the future. For now I am going to focus on
 > syncing, and any alternative way would work. I have always been
 > partial to Core Animation's transactions. Would it be possible to
 > replicate them to temporarily prevent requestAnimationFrame and the
 > ticker from redrawing? This is probably what I will be attempting
 > next.

We discussed this last week and decided that we need to introduce 
implementation requirements so that if you change style and start an 
animation immediately you don't see the style change momentarily whilst 
the animation is waiting to start but the two things happen simultaneously.


Next meeting: Thurs Aug 15 18:00 PDT / Fri 16 Aug 11:00 AEST / Fri 16 
Aug 10:00 JST @ https://etherpad.mozilla.org/lT8AJhVNPd

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

Received on Friday, 9 August 2013 05:07:52 UTC