[cairo] Re: Goocanvas: absolute-position animation and "update" confusion

[Damon Chaplin]

On Sat, 2006-12-02 at 08:44 -0800, Carl Worth wrote:

> 1. I'd like to be able to animate an item to an absolute position,
>    rather than a relative position. Would you be interested in having
>    two variants for that? [Separate, interesting things to do would
>    be to animate along a path, and to animate with something other
>    than linear timing along it.]

I wouldn't mind adding features that are useful to lots of people.
But I want to avoid cluttering up the API with rarely-used stuff.
It's fairly easy for people to write their own animation code anyway.

(Personally I'm not sure if the absolute position option is that useful,
though animating along a path sounds more useful. But its difficult to
judge.)


> 2. Since I have to compute a relative offset to use the current
>    animate functions I have to be able to query the item's current
>    position. Unfortunately, in demo-item.c there appear to be two
>    copies of the position and size, (an "x,y,width,height" in DemoItem
>    and a position/size that the canvas itself manipulates with things
>    like animate). Having two copies makes things harder since I have
>    to carefully keep them in synch. Is there a good reason to have
>    these two copies?

The current animation code is very simple - it just adjusts the item's
transformation matrix. This means it can be used with any item, without
any knowledge of the item's internals.

But it sounds like you need something more complicated, so maybe you
should use your own animation functions. Then you can adjust the item's
internal properties as you need.

Call "goo_canvas_item_simple_changed (simple, TRUE)" after updating the
item's state so its bounds are recalculated and it gets redrawn.



> 3. As far as keeping the two copies of position/size in synch, I
>    haven't succeeded at doing that yet. What are the correct semantics
>    of the "update" function? In demo-item I see it copying a position
>    from demo_item->x,y to its parent objects simple->bounds.x1,y1.
>    This seems to be necessary on the "update" to get the constructed
>    "x,y" value to replace a stale (0,0) in simple-bounds. However,
>    after doing any animation, subsequent calls to "update" still now
>    have stale data in demo_item->x,y and the correct position in
>    simple->bounds. Am I just confused? What's the best way out of this
>    mess?

The demo_item->x,y coords are in user space, which isn't affected by the
builtin animation code. It is the item's transformation matrix which
gets changed in the animation.

The simple->bounds gets converted to device space and so takes the
transformation matrix into account.




> Oh, and finally, I accidentally rotated an item during an animation
> one time and I think I saw it shrink and grow on the way, (at least
> the way I wrote the paint function). It looked like maybe the canvas
> was keeping the size of the bounds unchanged and the rotated drawing
> was shrinking to always fit within those bounds. Maybe this was my
> bug---I didn't look closely since I wasn't actually trying to rotate
> anything anyway.

The current animation code just calculates the current transform and the
final transform and divides each of the xx/yx/xy/yy/x0/y0 differences by
the number of steps in the animation - see goo_canvas_item_animate().

So it isn't very clever and may lead to weird transforms along the way.
I'm not sure what a better solution is.

Damon