Re: Thinking about animation in the Hippo Canvas

["Havoc Pennington" <hp pobox com>]

Hi,

On Fri, May 9, 2008 at 4:19 PM, Owen Taylor <otaylor redhat com> wrote:
>   - Stop the first animation
>   - Take all property values to their end values for the first animation
>   - start a category B) (interpolating) transition
>   - Start the second animation

What I've actually implemented for my convenience API is that if you
do a new animation in the same set, the current one is fast-forwarded
to its end state, and then the second one starts up. The stuff I
mentioned about merging and replacing in more complex ways was all
hypothetical.

The API is like:

void animation_move                      (ClutterActor              *actor,
                                              const char
 *animation_set,
                                              int                        end_x,
                                              int                        end_y,

BigAnimationCompletedFunc  completed_func,
                                              void
 *completed_data);

void animation_change_opacity            (ClutterActor              *actor,
                                              const char
 *animation_set,
                                              guint8
  end_opacity,

BigAnimationCompletedFunc  completed_func,
                                              void
 *completed_data);

Which is obviously convenience-function-ish and not very suitable for
a library (you have to add a new one of these for every kind of
animation).

But I was thinking ability to "merge" two animations might let you
e.g. combine move and opacity in the above, so then the convenience
API there is somewhat more flexible.

In general I think it would not be bad to attach animations to actors
(aka items, aka widgets) rather than having all those little
timeline/animation/alpha objects floating around in the simple case.
(That's another thing the above convenience API does.)

// actor conceptually has a list of timelines ; if we begin a new one,
// it can delete the current list, run after the current list, or
// extend the existing timeline on the list tail
actor.begin_animation_timeline(how_long, enum { REPLACE, APPEND, EXTEND } )
actor.add_opacity_animation(end_opacity)
actor.add_move_animation(end_x, end_y)
actor.add_timeline_completed_func(completed_func, completed_data)
actor.end_animation_timeline()

I don't know, just thinking out loud. I don't know if a "timeline
list" is 1 per actor or a named list as in my "animation set" thing.

This kind of API probably has a more low-level general API underneath.

It gets complicated quickly as you say, not a bad idea to just ignore
everything but the simple case.

A couple more very minor thoughts on the clutter API: 1) in most
programs the number of different animation lengths is probably quite
short; like "fast" and "slow" or something; don't know if the lib
should just have some defaults 2) doing the alpha functions as
functions instead of an enum is bad on the language binding front 3)
the alpha functions could probably have a default too, I've been using
RAMP_INC always.

Havoc