Affine transforms - matrix algebra

Jim Graham james.graham at
Fri Jul 20 17:02:15 PDT 2012

When I wrote my first reply in this thread I tried to warn people that I 
was coming back from vacation to a long thread and I hadn't double 
checked all of the math that was being proposed, so I was commenting 
from a general perspective that wasn't necessarily in agreement or 
conflict with the current proposal at the time.  I hope that I didn't 
send people off on a wild goose chase based on my list of points that 
may have come from a negative "we shouldn't do this or that" kind of 

To switch things around, let me make some positive statements of 
something that I would find acceptable and which I think may have 
actually been formally proposed here (but I didn't "do the math" to 
verify that).

I believe that the following produce equivalent transforms:

Node.getTransforms().add(new Scale(sx,sy));
Node.getTransforms().add(new Translate(tx,ty));
t = new java.awt.geom.AffineTransform();
t.scale(sx, sy);
t.translate(tx, ty);
t = new java.awt.geom.AffineTransform();
tmp = new java.awt.geom.AffineTransform();
tmp.setToScale(sx, sy);
tmp.setToTranslate(tx, ty);
Node n...;
Group g = new Group(n);
g.setScale(sx, sy);
n.setTranslate(tx, ty);

We also have the fact that "preConcatenate()" is mathematically 
reversed, and also inside-out from the perspective of what is being 
manipluated, as compared to concatenate().

So, if "appendFoo(...)" was essentially equivalent to:

- Node.getTransforms().add(new Foo(...));
- t.concatenate(tmp.setToFoo(...));

and "prependFoo(...)" was essentially equivalent to:

- Node.getTransforms().add(0, new Foo(...));
- we don't have a Java2D reverse for;
- t.preConcatenate(tmp.setToFoo(...));

then I could be happy.  It may not have complete unambiguity in an 
absolute sense, but it would at least establish an internal consistency 
and harmony of naming conventions with respect to the JavaFX Node 
transform attributes and with the prior art in the Java geometry family 

I feel that append, while we can argue the semantics of what it might 
mean mathematically, sounds like the more natural verb of the two forms 
of methods (comparing appendFoo to prependFoo), and in general it is the 
set of methods that they probably want to be using if they come from 
Java2D, or if they are writing code that takes a transform from 
somewhere else that defines their "transformation context" and they want 
to work within that (if you prepend, then you override the context 
someone set up for you, if you append, then you take their context and 
work relative to it).

Is that what was being proposed before I came in and stomped on the 


More information about the openjfx-dev mailing list