Re: [web-anim] automatically discarding animations

(2012/08/08 16:43), François REMY wrote:
> |  I re-read your previous mail about (non-)seekable groups. I think the
> |  hasSeekableParent property actually needs to look right up the tree.
>
> Yes, true. If a child animation is seekable, you can't drop the parent
> animation once if finishes since the child can still be seeked. However,
> you can drop the other (non-seekable) children.

Oh, I was thinking the other way around. If an ancestor is seekable you 
can't drop any of the children since they could become re-activated if 
you seek the ancestor.

Unless you're suggesting that non-seekable items keep playing 
independently of their parents once started?

> |  One alternative is to prevent all seeking of the effects timeline and
> |  its descendants and re-work reverse to spawn a new animation. That would
> |  let implementations optimise fill: forwards by replacing such animations
> |  with a single value.
>
> This is basicly what I propose, indeed. This model is the most
> optimizable model and should therefore be the default one.

I had a bit more of a think about this optimisation and I think more is 
needed for forwards filling. The difficulty is that if an animation is 
filling it will still be in the animation tree. As a result an 
implementation can't just replace it will a single value since it will 
still be possible to access the full object by walking the tree.

I'm not sure what yet to do about this. In part, I wonder how important 
it is to optimise this since there are many strategies for efficiently 
storing common properties of similar animations like you mentioned later 
on regarding templates. I have to think about this a bit more.

> However, you can reach this without using an "effect" timeline at all.
> If animations and animations groups are non-seekable by default and you
> need to specify a parameter (or change a property value, or call a
> method or...) to mark them as seekable, you can achieve the exact same
> behavior using one root timeline only. A single timeline could contain
> both optimizable and non-optimizable animations, that's it. I don't see
> the point of creating two timelines and creating special rules for each
> one of them while we could merge that in a single concept.

Ok, I understand a bit better what you're saying. I think we felt that 
the uses of animations is so different to warrant separation. For 
example, if you have an app with both cartoons (seekable) and UI effects 
(not-seekable). You probably want to be able to pause all the cartoons 
but not the UI effects. Of course, you can do that by adding top-level 
groups, but it seems like such a common paradigm that it should be 
available by default.

(Of course, if you were suggesting that "non-seekable" means "continues 
to play independent on the parent time once started" then you can do 
that. But I'm not sure if that's what you had in mind and if it is it's 
a completely different discussion.)

Bear in mind that CSS Transitions would default to a non-seekable 
timeline, but SVG Animations would default to a seekable timeline (for 
backwards compatibility). In a model where objects are only optimisable 
if all ancestors are non-seekable then we probably need some means for 
getting SVG animations out of their default group to benefit from 
optimisation. That was also part of the thinking behind the effects 
timeline.

That said, there are still lots of areas I'm not sure about.

> BTW, I found an important reason to keep templating: if we can use
> templates, we can save memory by storing the property values once.
> However, we can get rid of the AnimInstance entirely if we use a model
> where animations can have a sequence<Element> instead of an Element as
> target.
>
>     let anim = new Anim(...);
>     anim.targets.push(document.getElementById("a"));
>     anim.targets.push(document.querySelectorAll("a"));
>
>     let anim2 = anim.makeIndependent(
>         document.querySelectorAll("a.external")
>     );
>
>     anim.targets == #a, a:not(.external)
>     anim2.targets == a.external

I'm not sure templates are necessary for efficient storage (even if we 
were to go with a cloning model, the clone can just point to its source 
for its values and use copy-on-write for changes), but I think I'm still 
in favour of keeping them.

The difficulty with making Anim objects refer to multiple targets is you 
often want the targets to have different timing, particularly different 
start times and pause states. For example, the animations generated by a 
CSS Animation declaration have different start times. CSS Transitions 
reverse independently of one another.

Once you include the ability for different targets in the sequence to 
have different timing, you basically end up with per-elem Anim instances 
(especially if you assume the storage for shared properties is optimised 
in ways like you mentioned).

> |  Yes, I agree. Shane has a proposal for this which we want to incorporate
> |  in the future.[1]
>
> I like his proposal! Using CSS Custom Properties to specify the state
> changes is very clever! Syntax could be reworked but globally I feel the
> idea is right. I didn't really understand the @node(...) proposal but I
> guess it's a bit like my "when(...)" concept.
>
> Since transitions are an important use case of animations, I think
> incorporating this proposal is important as well. At least, we need to
> make sure its incorporation will not require additionnal concepts.

Yes, we've added a few concepts to make supporting this proposal easier 
in the future. I think Shane also had some reservations about the 
@node(...) part. As soon as we can settle on a good base model, we can 
work on layering this on top.

Thanks,

Brian

Received on Thursday, 9 August 2012 04:51:41 UTC