LocalToScene Transformation (related to Affine Transforms)

[Pavel Safrata]

On 14.5.2012 17:59, Dr. Michael Paus wrote:
> Am 14.05.2012 17:51, schrieb 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.
> If these methods are provided, I think I can live with that.

I commented on RT-17942, we will add the methods in scope of this issue.
http://javafx-jira.kenai.com/browse/RT-17942
Thanks,
Pavel

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