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

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?

> 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.

> 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]

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.

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).

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. 
Maybe we'd need another interface member that returns a sequence?

Any ideas?

Best regards,

Brian

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

Received on Thursday, 12 March 2015 01:38:53 UTC