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

[Damon Chaplin]

On Sun, 2006-12-03 at 21:49 -0800, Carl Worth wrote:
> On Sat, 02 Dec 2006 19:19:04 +0000, Damon Chaplin wrote:

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

If you were using pieces on a chess board, you'd use each piece's
transform to position it within the board, then
goo_canvas_item_animate() would do what you want.

(The current documentation is slightly wrong, though, so I'll fix that -
the arguments passed in are used for the final transformation matrix,
not as offsets from the current one.)


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

Yes, using the transform to position the item would be better (if you
want to use the builtin animation code).

Also, if you want the item to rotate in the animation you should
probably make the item's origin its center.


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

Yes, that does sound better.

Damon