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

[Carl Worth]

On Sat, 02 Dec 2006 19:19:04 +0000, Damon Chaplin wrote:
>
> 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.

OK. If "write your own animation" is the way it's supposed to work,
I'll just do that if I want to do anything fancy.

> (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.)

Well, imagine something like pieces on a game-board where I'm
implementing "move piece <foo> to square (<x>, <y>)". I compute things
like "legal move" with a logical x,y pair, and then when I go to do
the animation I just want to map the logical x,y to an absolute
coordinate and animate. The fact that I have to do a relative
animation means I have to also map the old x,y (or query the object's
position) and subtract. It's not really a big deal, but it is a bit
awkward.

So take that for what it's worth.

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

OK. I'll give that a try.

> 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.

OK. So given that, it sounds like I should just use the matrix to
position my item rather than having an item-specific position. I see
goo_canvas_item_translate, (which brings up my relative-vs-absolute
issue again). Or I could just ignore the matrix and do all my own
positioning/animation.

> 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.

Oh, that's pretty funky. If the animation code only supports
translation and rotation, why not just interpolate the translation and
rotation values independently and always compute a translate+rotate
transformation transformation at each step?

That should prevent weird scaling like I saw here, anyway.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061203/35d237d3/attachment.pgp