Re: Thinking about animation in the Hippo Canvas

["Havoc Pennington" <hp pobox com>]

Hi,

Some observations about the Clutter animation API and aspects you
might want to improve on -

* the name "alpha" for the ramp function I thought was pretty bad,
since alpha means something else... "ramp function" might be good in
fact.

* animation collision. To give a simple example, say you can expand
and collapse something. When the user clicks expand you start to
animate a "width" property. If the animation completes then great, now
they click "collapse" and you animate width again, down to what it was
before. However, say the user clicks collapse before your expand
animation completes. Now you may have two animations at once fighting
each other. Or if your animation depends on the starting value of a
property, it may do the wrong thing. Anyway, in general animations
tend to fight each other (and the rest of the code, for that matter).
It's just a pain to have your item's state changing around in a
timeout. It seems like almost all animations have an "inverse" or "go
back to how it was before" so hand-rolling every time a way to deal
with this is a pain.

* a solution I've been using to the collision problem is an idea of a
"named animation set", where when you start an animation you put it in
a named set. For example you could put your "expand" and "collapse"
animations in an "expand-collapse" set. The idea is that sets can have
some different behaviors; in the expand-collapse example, if you add a
collapse while expand is running, the expand might be sped up to
finish almost immediately, and then the collapse would be run after it
(starting from the known fully-expanded state). Or the expand could be
canceled immediately. There are also cases where you might want to do
two things at once (say move and zoom), and in that case the set might
have a "merge" or "combine" mode. enum { SET_MODE_REPLACE,
SET_MODE_COMBINE } or something. I have not fully worked this out.
It's possible sets should be recursive, or maybe animation sets are a
kind of animation, much like container items are a kind of item.

* interaction with layout. We just added layout to clutter, and we
chose to have an extra transform that is only used for painting, not
for layout. This lets you do something like grow an element slightly
on mouseover, without pushing everything else on the screen around. Or
you can have an element "fly" to its slot in a a layout box since the
layout can be done but the item temporarily painted elsewhere. The
idea of "transient" or "display-only" properties used to animate is
interesting in general I think, but of course it could get unwieldy to
start having this for every property. But it's nice if the animations
aren't affecting any properties the "normal" or "logical" code cares
about.

* clutter has some kind of animation convenience API (clutter effects
I think it's called?) that I don't really understand, though it's
possible I'm just missing someone explaining it to me.

Havoc