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

[Damon Chaplin]

On Tue, 2006-12-05 at 07:35 -0800, Carl Worth wrote:
> On Tue, 05 Dec 2006 12:37:31 +0000, Damon Chaplin wrote:
> > Yes, it is a bit confusing. Though I don't really think items should
> > change their own coordinate space. If you have the item itself and
> > higher-level/application code both changing the item's transformation
> > matrix it could get even more confusing.
> 
> I'd be interested in seeing that documentation describing how you
> envision this working. In my application, I do have higher-level code
> working to place the items, but it expects to allow the object to move
> itself with object-oriented-like functions such as:
> 
> 	object_move_to (object, x, y);
> 
> 	object_glide_to (object, x, y);
> 
> I've got that working really nicely now, (it definitely helps to know
> that animate takes absolute values---which is what I wanted
> anyway). I implemented this by getting rid of any private x,y values
> like the original demo-item had. Then I call canvas_item_set_transform
> in my move_to and canvas_item_animate in glide_to.
>
> That's working great for me now, but I can see it definitely being a
> problem if in the canvas hierarchy there were other things going on
> inside the matrix besides the translation for this object's position,
> (such as the translation of its parent as well).

The GooCanvas model is almost identical to the SVG model - a hierarchy
of items, each with various properties and an optional transform.

So by getting rid of your item's position properties your item doesn't
quite follow this model. Whether that matters I'm not sure.


> Maybe all that I'm missing is a goo_canvas_item_set_position or so,
> (something like canvas_item_translate but with an absolute position
> instead of an offset).

We do have goo_canvas_item_set_transform(), though maybe a convenience
function like goo_canvas_item_set_transform_values (position, scale,
rotation) would be useful.


> > Though if we switch to interpolating the translation/scale/rotation
> > separately, to get better animation, we might have to use relative
> > values instead. Unless someone knows a way to calculate the current
> > translation/scale/rotation from a transformation matrix.
> 
> Can't you just eliminate any interface for setting the matrix
> directly? Then you could always compute the matrix from the
> translation, rotation, and scale values you have available. It might
> also help eliminate any "badness" like I might have in my program
> above from directly changing the matrix.

The transform is part of the SVG-like model, so I wouldn't want to
remove it.

Damon