# Affine transforms - matrix algebra

Jim Graham james.graham at oracle.com
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
perspective.

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:

--------------
---
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);
t.concatenate(tmp);
tmp.setToTranslate(tx, ty);
t.concatenate(tmp);
---
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:

- t.foo(...);
- t.concatenate(tmp.setToFoo(...));

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

- we don't have a Java2D reverse for t.foo();
- 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
(AffineTransform)...

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
discussion?

...jim

```