Affine transforms - matrix algebra

[Martin Desruisseaux]

Hello Jim

Just a my 2 cents:

Le 17/07/12 06:08, Jim Graham a écrit :
> - We already have GraphicsContext in 2.2 that has "translate, scale, 
> etc."  I would hope that the "appendFoo()" methods would work like 
> those, but I have the sneaky suspicion that I read in the discussion 
> that actually the prepend methods are closer to those. Consider how a 
> developer that was used to "I scaled then I translated" would view 
> append/prepend?  That sounds to me like the scale happened and then 
> the translate was "appended to the list of operations as if one called 
> it after scale in some Canvas code". Also, append should probably 
> reflect what happens when you get the list of Transform objects from a 
> Node and then append some new Transform objects to the end of that 
> list.  Prepend should match what happens when you place new Transform 
> objects at the head of that same Node.getTransforms() list.
I think that this operation order matches the proposal. In the proposal, 
"append" and "prepend" are from an operation order point of views rather 
than matrix multiplication order point of view.

The Java2D methods have the behaviour of "prepend" in the proposal. In 
Java2D, AffineTransform.scale(...) followed by 
AffineTransform.translate(...) mean "first translate, then scale" from 
an operation order point of view.

Nevertheless, I would have been comfortable with keeping the "translate" 
and "scale" method names with Java2D behaviour, if those names weren't 
already used by the static methods in the parent class... The "append" 
and "prepend" prefixes were one workaround we found; an earlier proposal 
was using longer method names...


> - append might mean a matrix operation with the math going one way, 
> but it might also mean "then after you step into that coordinate 
> system, you do this operation from that perspective", and it might 
> also mean "after you move everything around and you are staring at the 
> transformed objects from outside (i.e. the point of view of the 
> universe), you then move it again like this" and all of those will 
> result in different math.
I think that the above "coordinate system" perspective matches the 
current proposal.


> - 2x3, 3x4, etc - I would make those explicit in the method name 
> rather than side effected from the array length
The current proposal uses an enum. Would many methods be preferable to 
an enum in this case?


> - what about getRow(row, array) and getColumn(col, array) which can be 
> combined with vector methods to do fast custom matrix operations?
At this point, given the increasing amount of methods and the enum, I 
wonder if we should replace all those variants by a single method:

double[] getSubMatrix(int firstRow, int firstColumn, int numRows, int 
numColumns, double[] array);

This single method would provide the functionalities of getRow, 
getColumn, getMatrix with enum 2x3, 3x4 and 4x4 (we lost 3x3, but it it 
probably not a big deal). The enum would not be needed anymore.


> - what about classification methods so they can special case "uniform 
> scaling", "unrotated", "translation-only", etc. matrix cases?
Do you mean something similar to AffineTransform.getType() in Java2D? On 
my side, I didn't found lot of situations were I used this method. 
However in the JavaFX world, maybe an alternative could be some method 
returning the most specific subclass of Transform that can represent the 
Affine. For example if the Affine have only translation terms, then that 
method would return an instance of Translate. An "instanceof" check 
would allow the user to get the classification.


     Martin