Re: [web-anim] automatically discarding animations

|  How so? You can drop a sequenced or parallel group as soon as it becomes
|  inactive.

The whole concept of becoming inactive is broken in the case of seekable 
items. Because a script could seek back the animation at any time (even when 
it finished) it could still return to an active state.



|  I guess you're saying we couldn't drop any of the children of the group
|  until the group itself finishes since you might want to seek the group?
|  That's a fair point but I think it's ok since I don't imagine there will
|  be additional long-running top-level groups created in the effects
|  timeline.

What if one of the animations of the group has "fill: forwards"? This seems 
a pretty frequent case to me that authors would use a special transition to 
an effect and, in the same group, a long-running animation. I don't like to 
make guess about how API are going to be used by developers.



|  However, it's quite likely I might interactively want to reverse a UI
|  effect in progress.

If you are using a fill mode and want to be able to reverse the animation at 
any point, the animation can't be optimized anyway. Also, if you're keeping 
a reference to the animation for your script to be able to reverse() the 
animation, it can't be removed from memory, either. You would still need to 
manage the memory on the JavaScript side with an AnimationEnd event.

I think that you're merging the concept of "effect" and the concept of 
"state transition". An effect is optimizable because (1) it can't be 
modified (2) it leaves the element in the same state at the begining and at 
the end of the animation. Samples of effects includes "zoom-in zoom-out" or 
"blink/flash". A state transition doesn't leave the element in the same sate 
at the begining and at the end, and can be reversed if the state change is 
undone. A state transition can't be optimized for as long as it applies; 
however if final state is maintained elsewhere, the transition itself can be 
automatically discarded.

The only memory-optimizable animations are animations which can't be 
manipulated by script at all. This is the model we should push by default; 
if developers need more control they'll need to take care of more 
implementation details.

We should probably provide a better way to handle state transitions than 
just leave the developers alone on that matter. Something (roughly) like:

/* define states (CSS, JS...) */
ul.select-box > li {
    transition-states: itemSelected(false), ...;
}
ul.select-box > li {
    transition-states: itemSelected(true), ...;
}

/* define transitions between states */
@transition-state itemSelected {
    when(false) {
        ...
    }
    when(true) {
        ...
    }
    from (false) to (true) {
        /*
            - 0% and 100% are from the 'when' states;
            - properties can be interpolated just using a timing (like 
transition: xxx)
            - when state changes from true to false, these keyframes are 
reversed
            - when state changes occurs during a transition:
                the transition is reversed in place if revelant
                if not revelant, the from state is the animated one
            - state transitions animations are discarded when 100% is 
reached
        */
    }
}

In such case, developers only have to matter about "changing the state" and 
the magic happens elsewhere, with all optimizations still possible.

François

Received on Tuesday, 7 August 2012 09:11:00 UTC