(Cloned from:http://bugzilla.clutter-project.org/show_bug.cgi?id=2378)

(This is probably 2.0 material)

Currently all of the rotation transformations and the scale transformation have
their own centre property. This makes it set up a translation before and after
each transformation. We also have a separate anchor point property which is
confusingly named because it is more like an extra transform that causes the
actor to pop out of its layout. The separate transformation centres are
probably overkill so lets replace them with just a single transformation
centre. This translation would be applied before all of the transformations and
then reversed afterwards. Currently the anchor point can be set using a gravity
as an alternative to setting an actual position. This is quite useful because
the gravity can automatically track the size of the actor. Lets keep this but
change it to be a 0.0->1.0 fraction of the size of the actor instead of an enum
so that we don't have to have a separate property for it. That way we will end
up with the following properties:

transform-center-x - gfloat
transform-center-y - gfloat
transform-center-z - gfloat

These define the center of the subsequent transforms.

transform-center-is-relative - gboolean

If this value is TRUE then the above positions are interpreted as a value from
0.0->1.0 relative to the size of the actor. The z transform center would be
ignored in this case. This replaces the anchor-gravity property and avoids the
confusing breakage that happens if you try to query the gravity after setting a
fixed anchor point.

translation-x - gfloat
translation-y - gfloat
translation-z - gfloat

These define an extra translation transformation on the actor. They can be used
to make the actor pop out of its allocation like the anchor point did
previously. These are always in actual coordinates rather than relative to the
size of the actor.

scale-x - gfloat
scale-y - gfloat
scale-z - gfloat

These specify the scale on the actor. The scale-z property is new. It would be
useful when drawing a 3D actor such as a model from Mash. There is no
scale-center.

rotation-angle-x - gfloat
rotation-angle-y - gfloat
rotation-angle-z - gfloat

The same rotation properties as before except there is no rotation center.

The sequence of transformations in clutter_actor_real_apply_transform would
then be like this:

Translate by allocation x and y position
Translate by depth position
Translate by transformation centre
Translate by translation transformation

(these four can be combined into one)

Scale transformation
Z rotation
Y rotation
X rotation

Translate by negative transformation centre

The clutter_actor_move_anchor_point function can be removed because the use
case for it can be replaced by just the translation transformation property.

The translation centre transformation has no effect unless there are other
transformations because it is cancelled out afterwards. If you want it to have
an effect you can use the translation transformation instead.
------- Comment #1 From Emmanuele Bassi 2010-10-22 10:41:38 [reply] -------
(In reply to comment #0)
> (This is probably 2.0 material)

thanks for filing this.

yes, it's probably 2.0 material, but it's nice to start thinking about it if we
want to get the 2.0 ball rolling.

nominally, I think all of this sounds good.

> transform-center-is-relative - gboolean
> 
> If this value is TRUE then the above positions are interpreted as a value from
> 0.0->1.0 relative to the size of the actor. The z transform center would be
> ignored in this case. This replaces the anchor-gravity property and avoids the
> confusing breakage that happens if you try to query the gravity after setting a
> fixed anchor point.

can we not always assume a relative center and just get along with it? I
understand absolute positioning of the transformation center, but we probably
want to have that as the non-default case. we could have an
"absolute-transform-center" (type: ClutterVertex) instead.
------- Comment #2 From Emmanuele Bassi 2011-03-14 00:59:22 [reply] -------
http://android-developers.blogspot.com/2011/02/animation-in-honeycomb.html

  Android has a similar "transformation point" called "pivot". we could
probably adapt the same terminology during 1.x, and deprecate all other points.

the API for scale and rotation could be maintained the same, and we could:

  • ignore the scale/rotation center arguments;
  • make them modify the "pivot" coordinates (last modification wins);

so this could work could probably be done piecemeal during 1.x, along with
deprecations, and for 2.0 we could just remove the deprecations.