Re: [web-animations] Freeing up forwards-filling Animation objects

Of course the link doesn't work.
addAnimation:forKey:

On Sat, Nov 21, 2015 at 4:58 PM, Kevin Doughty <socallednonflipped@gmail.com
> wrote:

>
> https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/CALayer_class/index.html#//apple_ref/occ/instm/CALayer/addAnimation:forKey
> :
>
> On Thu, Nov 19, 2015 at 2:08 AM, Brian Birtles <bbirtles@mozilla.com>
> wrote:
>
>> Hi,
>>
>> We have a difficulty in Web Animations with regards to object lifetimes
>> for animations that fill forwards. The trouble is one can do the
>> following:
>>
>>   elem.addEventListener('click', evt => {
>>     evt.target.animate({ opacity: [ 0, 1 ] },
>>                        { duration: 500, fill: 'forwards' });
>>   });
>>
>> What this does, is create a new animation that fills forwards, on every
>> click.
>>
>> Now, if we call:
>>
>>   elem.getAnimations();
>>
>> It should return *all* the animations we've generated.
>>
>> There are few reasons for that:
>>
>>   a. You should be able to use getAnimations() to help answer the
>>      question, "Why does my element have this style value?"
>>
>>      i.e. This method needs to return any animation that is affecting
>>      the element in question.
>>
>>   b. Animations can add together so you need to keep track of all the
>>      past animations anyway so you get the right final result.
>>
>>      e.g. you can do the following
>>
>>        // Nudge right
>>        elem.addEventListener('click', evt => {
>>          evt.target.animate({ transform: 'translate(50px)',
>>                               composite: 'add' },
>>                             { duration: 500, fill: 'forwards' });
>>        });
>>
>>      The total distance the element is translated is the sum of the fill
>>      values of all animations that have run up to that point.
>>
>> All that means you really need to keep track of all the forwards-filling
>> animations. Forever.
>>
>> Why is this a new problem?
>>
>>   For CSS transitions and CSS animations, once animations are no longer
>>   referenced by specified style they are cancelled and no longer affect
>>   the element.
>>
>>   You just don't accidentally end up in a situation with millions of old
>>   animations lying around. To do that, you'd have to have a *lot* of
>>   elements or have an animation-name value that is very long. Either
>>   case tells you to expect things to go slowly and are somewhat bounded.
>>
>>   With the animation API, however, as shown in the examples above, it's
>>   quite easy to get into a situation where the UA has to keep a lot of
>>   Animations around without the author realizing it.
>>
>> Solutions we've discussed until now:
>>
>>    a. Automatically cancel any filling animation when other filling
>>       animations cover the same properties.
>>       => Doesn't work for addition.
>>
>>    b. Make getAnimations() only return the *last* animation that is
>>       filling per-property.
>>       => For the addition case, you'd still need to keep around some
>>          sort of summary of the result of previous animations. Now,
>>          supposing you don't expose that summary, the view you see from
>>          the API is inconsistent.
>>
>>    c. Expose the summary view of underlying filling animations as
>>       some sort of special animation or a special attribute.
>>       => This is awkward, but maybe worth revisiting?
>>          e.g. elem.getFillStyle().opacity?
>>
>>    d. "That's the author's problem" or "Just let UAs just do whatever
>>       they feel like"
>>       => This is our current position and it's not great.
>>
>> I really think we need to fix this. I don't have any brilliant ideas.
>> Revisiting (c) could work, or perhaps some sort of "animation collapsing"?
>>
>> The rough idea of "animation collapsing" is that when the UA has two or
>> more filling animations on the same properties on the same element, it
>> basically takes the fill values of the underlying animations and
>> squashes them into the property values specified on the top-most
>> filling animation. Then the underlying animation ends becoming empty
>> and can be discarded.
>>
>> (I'd really like to make it so that the underlying animation actually
>> gets cancelled and you get an event for it, but I think when it comes to
>> group effects, you want to be able to collapse individual effects
>> without having to have a complete match for all effects.)
>>
>> Adding a bit more details I think it could be something like:
>>
>> Assume:
>>   * all finished animations do NOT fill forwards have been discarded
>>   * Element.getAnimations() does not return Animations targetting
>>     Element if the set of keyframes is empty
>>
>> For any two effects, A and B, (with corresponding animations, 'Animation
>> A', and 'Animation B') where:
>>
>>   a. A and B have the same non-null target element
>>   b. Animation A and Animation B are both finished
>>   c. Animation A and Animation B each have a fill mode of either
>>      'forwards' or 'both'
>>   d. Animation A and Animation B have the same animation type
>>   e. The common animation type of Animation A and Animation B allows
>>      collapsing (disallow for CSS animations/transitions)
>>   f. For each animation property that is common to both A and B, there
>>      is no animation effect referring to that animation property whose
>>      corresponding animation has a composite order between that of A
>>      and B.
>>
>> Perform the following steps:
>>
>>   1. Assume that A refers to the effect whose corresponding animation
>>      has a *lower* composite order of the two.
>>   2. For each animation property, |property|, that is referenced by both
>>      A and B, update each specified value |property| on B as follows:
>>      i.   Let |b| be the specified value of |property| on a keyframe in
>>           B.
>>      ii.  Let |a| be the fill value of |property| on a keyframe in A.
>>      iii. If the composite mode associated with |b| is 'replace',
>>             let b' = |b| and composite' = 'replace'.
>>           Otherwise, if the composite mode associated with |b| is 'add',
>>             let b' = add(|a|, b) and composite' = the composite mode of
>>             |a|.
>>           Otherwise, (the composite mode associated with |b| is
>>           'acccumulate),
>>             let b' = accumulate(|a|, b) and composite' = the composite
>>             mode of |a|.
>>      iv.  Update |b| with b' and use composite' as the composite mode
>>           for the keyframe.
>>           (TODO: Add logic here to handle when we have multiple
>>           properties on the same keyframe and we are changing the
>>           composite mode. Basically, make a new keyframe in that case,
>>           but then combine such keyframes at the end of the process.)
>>   3. Remove all values of |property| on keyframes in A.
>>   4. Remove any empty keyframes on A.
>>
>> It's pretty complicated and I don't love it, but I think it's a little
>> closer to the pit of success we'd like to create? If nothing else, it
>> might spark a better idea from someone else.
>>
>> Best regards,
>>
>> Brian
>>
>>
>