Re: [web-animations] Significant changes to Web Animations coming up

On Thu, Mar 12, 2015 at 12:38 PM Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2015/03/12 10:10, Shane Stephens wrote:
> >
> >     Unfortunately I was unable to make a shared keyframe list since as
> was
> >     discussed at one stage.[3] This is because keyframe lists return
> their
> >     computed offsets but for paced keyframe lists, the computed offset
> may
> >     depend on their target element in order to resolve percentage values,
> >     for example. This is problem exists with the API regardless of this
> >     change so we can address it subsequently (e.g. by making the computed
> >     keyframe list getter take a target element).
> >
> >
> > I am very concerned by this.
> >
> > Our implementation demonstrates that parsing of keyframe lists is a
> > major cost, possibly the largest cost involved in setting up animations.
> > Sharing keyframe lists where possible would be a major benefit.
>
> Out of curiousity, what part of this is expensive?
>

Parsing CSS property names and values.


> > Furthermore, keyframe lists should only deal with specified lists - the
> > problem you're describing doesn't need to exist as accessors on a
> > KeyframeList should return the unmodified inputs.
>
> I tend to agree, but that's not what's specced now (i.e. before the
> change I'm proposing). We already return the computed list so we already
> can't share KeyframeEffect objects.
>

True. Seems like we're both happy to make this change though?


> > It's fine to keep a getFrames method on the KeyframeEffect object for
> > accessing the computed result (in a place where the target is known) -
> > although I think this could be deferred to a later level as we don't
> > have currently have strong use cases for it.
>
> I thought you had a strong use case for it? That seems to be why we
> added it.[1]
>

That predates the normalization simplification that we introduced a few
months back. The rules for normalization are now much easier to duplicate -
basically, you're guaranteed that the offsets will be sorted and just need
to duplicate distribution.


> It sounds like we could have KeyframeEffect.frames return an iterable
> KeyframeList object .and take a union of (Keyframe or sequence<Keyframe>
> or KeyframeList) on setting.
>
> The we could add KeyframeEffect.getComputedKeyframes() if/when needed
> for getting the copy with offsets filled in.
>

That works for me. Would we also have a KeyframeList constructor?


> At first I thought the KeyframeList object would be something like:
>
> interface KeyframeList {
>    readonly attribute unsigned long length;
>    iterable<Keyframe>;
> };
>
> Then you could do:
>
>    effectA.frames = effectB.frames; // Share the list of frames
>
> Unfortunately, this approach seems to break down.
>
> Firstly, if we add indexed property getters (as we probably should),
> you'd get authors doing the following:
>
>    effectA.frames[2].offset = 0.5;
>
> and then being surprised that it doesn't work (since Keyframe is a
> dictionary object, not a live object).
>

Yep, that's a good point.


> Also, if you actually want to get a copy (so you can make some
> modifications that only apply to one keyframe effect), I'm not sure how
> you'd do that short of defining our own clone() method on the interface.
>

list.clone() seems reasonable.


> Maybe we'd need another interface member that returns a sequence?


> Any ideas?
>

We could optionally start with opaque and immutable KeyframeList objects -
i.e. not observable or modifiable after construction - and add affordances
to get at/change the list later if they seem necessary.

Cheers,
    -Shane

>
> Best regards,
>
> Brian
>
> [1] https://lists.w3.org/Archives/Public/public-fx/2014JanMar/0015.html,
> item 5
>