LocalToScene Transformation (related to Affine Transforms)

[Dr. Michael Paus]

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


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.