Affine transforms - matrix algebra

[Martin Desruisseaux]

Hello Jim

No worry, I don't think that anyone felt sent off. I think that peoples 
know that emails can give all kind of impression not always accurate.

I wasn't aware that a concept of transformation chains could be 
associated to nodes. Given that this chain is in reverse order compared 
to the one I was familiar with, I understand the difference in 
interpretation of "append". I agree that consistency is important. I 
have no problem with any choice, but I would just like the explanation 
about transformation chains (in the JavaFX sense) to appear somewhere in 
the javadoc, for helping some developers (including myself) to do the 
right association in their mind.

     Thanks and regards,

         Martin



Le 21/07/12 02:02, Jim Graham a écrit :
> 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:
>
> --------------
> 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);
> 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:
>
> - Node.getTransforms().add(new Foo(...));
> - t.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.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
>