Transform Points vs. Registration Points

Closed 12/12/2008

Problem:

Our definition of transform points in our graphics and components classes is inherited from early prototyping work done by Mark Anders, and defined in FXG.  But is it the right behavior?  And if not, what opportunity do we have to change it?

The current behavior

The current algorithm for our building our matrix is defined as:

translate(-transformX,-transformY)
scale(scaleX,scaleY)
rotate(rotation)
translate(x,y)
translate(transformX,transformY);

 The result is that the x/y value of a component always indicates where the origin of the component would be if no rotation/scale was applied, but may not represent any specific part of the component if it has rotation or scale.  The transformX/transformY indicates the point around which the component rotates/scales, defined as an offset from the origin of the component (in its parent coordinate space).

An alternate behavior

An alternate algorithm would be:

translate(-transformX,-transformY)
scale(scaleX,scaleY)
rotate(rotation)
translate(x,y)
(no final translation by transformX,transformY)

The result of this approach would be: the x/y value of a component always indicates where its transform point is located in its parent's coordinate space.  any rotation or scale happens around that point.

This effectively makes the transformX/Y property a way to set the registration point of the component. you can make sure multiple components/shapes align in a specific manner by setting their registration/transform point to a particular significant spot, then setting all of their x/y properties the same.

FXG

FXG specifically defines transformX/Y to match the behavior currently defined in Flex. However, the FXG aware tools have limited support for it:

Fireworks:  no support.  As far as I can tell, fireworks does not store any persistent concept of a transform center.
Photoshop: no support.  Same as above.
Illustrator:  no support for writing out transformX/transformY, but will attempt to respect it when it reads it back in. However, as far as I can tell, it applies the transform points incorrectly if you feed it a file with transformX/transformY defined.
Thermo: thermo currently has no plan to read or write transformX/Y.

 Current Proposal

The current proposal is as follows:

- remove the transformX/transformY properties from the FXG spec.

- leave the transformX/Y properties as is until we hit our first official beta. 

- see if any customers complain about our transformX/Y definitions, and reconsider changing to a registration point if they prefer.