Affine transforms - matrix algebra

[Pavel Safrata]

inverseTransform:
currently you can do createInverse().transform(...)
I think it may be better to leave it like that because inversion is an 
expensive operation and user now has to control how often is it called 
and when the inverted matrix can be gc'd. If we introduced some 
convenience method we would probably need some inverse matrix caching 
(with considerable space requirements). But this is already second 
request so it might be worth it. Any other opinions?

deltaTransform:
this discussion goes on under "Transform point using 
localToSceneTransform" subject. Please join there.

Thanks,
Pavel

On 24.7.2012 0:03, Jim Graham wrote:
> Also, what about inverseTransform(point/bounds) methods?  And 
> deltaTransform()?
>
>             ...jim
>
> On 7/23/2012 2:11 AM, Pavel Safrata wrote:
>> Hello,
>> looks like we reached the agreement on a (well documented)
>> append/prepend terminology with the original proposal semantics 
>> reversed.
>>
>> Before I post the final proposal, following changes need to be 
>> discussed:
>>
>> We need to add manual transformation methods to Transfrom class. This is
>> very important, I can't believe I've forgotten them..
>> public Point3D transform(Point3D point)
>> public Bounds transform(Bounds bounds)
>> Any other?
>>
>> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3,
>> MAT_3D_3x4, MAT_3D_4x4, do you agree?
>>
>> Keep the methods accepting arrays recognizing their types according to
>> their length and add
>> public Affine(double[] array, MatrixArrayType type, int beginIndex)
>> public void setToTransform(double[] array, MatrixArrayType type, int
>> beginIndex)
>> public void append(double[] array, MatrixArrayType type, int beginIndex)
>> public void prepend(double[] array, MatrixArrayType type, int 
>> beginIndex)
>> Do you agree? Or would you prefer different set of array-accepting 
>> methods?
>>
>> Regarding the getRow/getColumn: we again face the problem whether to
>> return 3 or 4 elements. Consistently with the toArray, I propose
>> VectorArrayType = { VAT_2D, VAT_3D }
>> public double[] getRow(int row, VectorArrayType type),
>> public double[] getRow(int row, VectorArrayType type, double[] array)
>> public double[] getColumn(int col, VectorArrayType type),
>> public double[] getColumn(int col, VectorArrayType type, double[] array)
>> Do you agree?
>>
>> Thanks,
>> Pavel
>>
>> On 21.7.2012 2:52, Martin Desruisseaux wrote:
>>> 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
>>>>
>>>
>>
>>