LocalToScene Transformation (related to Affine Transforms)

[Pavel Safrata]

Michael,
for the simple transformations (that are sufficient for a lot of 
applications) the specific transformation classes are considerably more 
efficient than Affine. You can work with Affine everywhere without using 
any of the other Transform implementations, except of the 
localToSceneTransform property value. We will provide methods on Affine 
to set the matrix to a particular transformation that you will be able 
to use instead of the factory methods on Transform. I think the reasons 
why the property cannot be of type Affine and why all the different 
classes cannot have all the Affine functionality were explained earlier 
in this thread (pasting below), so please let me know if you have a more 
specific suggestion that would meet (or disprove) all the constraints.
Thanks,
Pavel

Why the property cannot be of type Affine:
The first candidate is javafx.scene.transform.Affine. Unfortunately this 
class has each element of the matrix as a property, which makes it 
pretty impractical for that purpose. There are two options there:
- We can create a new Affine instance each time the transformation 
changes (and somebody calls the getter). This way all the elements would 
have to be immutable, so all their setters would need to throw 
exceptions (ugly) and whole their observability would be just a useless 
slowdown.
- Or we can keep the single instance and modify its elements. This way 
user would have to register twelve listeners to be notified of 
transformation changes.
None of those options seems good enough.

Why all the transformations cannot be subtypes of Affine:
These transformation classes provide a simple and efficient way to set 
basic transformations to nodes and it would be expensive to fill them 
with all the data and functionality that Affine has and will have after 
resolving RT-17942. Moreover, we would have to restrict many of the 
methods that will be there for altering the Affine class (to avoid 
things like Rotate becoming something else then rotation), which is not 
a nice approach.

On 14.5.2012 16:51, Dr. Michael Paus wrote:
> Not really.
> If the Affine class is the only one on which you can perform matrix 
> algebra then I would
> like to be able to work with only this class right from the beginning 
> and not having to
> convert other classes to Affine just in order to be able to perform 
> some math on them.
> I just find this all very confusing and inefficient. But maybe others 
> have an opinion on
> this too.
> Michael
>
> Am 14.05.2012 15:21, schrieb Pavel Safrata:
>> Hello,
>> I would provide some common algebra methods as 
>> "getInverseTransform()" or "getContatenation(Transform)" on the 
>> Transform class that would return a new transformation, and methods 
>> as "inverse()" or "concatenate(Transform)" on the Affine class, that 
>> would modify it in place. For the most common use-cases you should be 
>> fine with the specific transformations, for some more complex cases 
>> there will be an easy way to convert any of them to Affine (for 
>> instance Affine.setTransformation(Transform)) and perform the 
>> computation there. Does that sound good?
>> Thanks,
>> Pavel
>>
>> On 14.5.2012 14:12, Dr. Michael Paus wrote:
>>> Hi,
>>> could you please explain how this will fit into the current class 
>>> hierarchy for transforms?
>>> The general Transform class has all the static methods to create 
>>> specific transforms. If
>>> the Affine class will have all the matrix algebra, then how is this 
>>> supposed to work?
>>> All the specific transformation classes Translate, Rotate, ... are 
>>> not derived
>>> from Affine and thus will not inherit the matrix algebra methods.
>>> Michael
>>>
>>>
>>> Am 14.05.2012 13:49, schrieb Pavel Safrata:
>>>> Hi Alexander,
>>>>
>>>> On 14.5.2012 11:21, Alexander Kouznetsov wrote:
>>>>> Hi Pavel,
>>>>>
>>>>> On 11.05.2012 13:33, Pavel Safrata wrote:
>>>>>>>
>>>>>>> Can't we just make Affine3D public instead? That way we'll 
>>>>>>> provide matrices calculation layer and all we need is to provide 
>>>>>>> methods to convert Affine3D to Affine and vice versa. Just an idea.
>>>>>>
>>>>>> This sounds like a bad idea to me. From user's point of view, 
>>>>>> Affine3D and Affine would be duplicates except that Affine's 
>>>>>> members are observable. What I think we should do is to port some 
>>>>>> of the Affine3D functionality to the Affine class (which sounds 
>>>>>> close to RT-17942).
>>>>> I don't see a really big difference here. Newly added class 
>>>>> regardless of its name would be "a duplicate" of Affine class. 
>>>>
>>>> I'm not going to add any new class (except of an internal immutable 
>>>> implementation of Transform). The Affine class is already part of 
>>>> public API for a long time, so we should use it and not create any 
>>>> duplicates of it.
>>>>
>>>>> Moreover if you're not going to port all of its methods there 
>>>>> would always be a feature requests to port the rest of them. 
>>>>
>>>> We will consider all the feature requests and implement the 
>>>> reasonable ones. If we end up with something very close to 
>>>> Affine3D, we may then consider switching to the public classes 
>>>> internally.
>>>>
>>>>> On the other hand the Affine class wouldn't be just a class that 
>>>>> members are observable but would be also a class that has no 
>>>>> matrix algebra methods and that is part of Transforms API. 
>>>>> Affine3D is clearly a different layer then.
>>>>
>>>> The Affine class will have the matrix algebra methods. I don't 
>>>> think we should publish any other layer (our proposal tries to 
>>>> avoid that) - that would lead to more confusion and more work with 
>>>> converting matrices between the layers. Everything should work with 
>>>> the existing classes from the user's point of view.
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>>>
>>>>> Best regards,
>>>>> Alexander Kouznetsov
>>>>>
>>>>>
>>>
>>>
>
>