LocalToScene Transformation (related to Affine Transforms)

[Martin Desruisseaux]

Hello Pavel

That's fair, thank for considering.

     Martin


Le 16/05/12 09:46, Pavel Safrata a écrit :
> Hi,
>
> Kevin, I think you are right.
>
> Martin, we reconsidered your suggestion and although we agree we might 
> run into naming problems if we want to introduce some computation 
> classes for the general transformations in the future, we decided not 
> to complicate the API with something scenegraph won't be able to 
> support anyway.
>
> Thanks,
> Pavel
>
> On 11.5.2012 16:19, Kevin Rushforth wrote:
>> I'm not sure that the existing Transform class should ever support 
>> non-affine matrices. Perhaps it would be better to provide a 
>> different base class for that.
>>
>> -- Kevin
>>
>>
>> Martin Desruisseaux wrote:
>>> Hello Pavel
>>>
>>> Right, I was not expecting the scene graph to support such general 
>>> transform. To make my long email short, I was just pointing that 
>>> adding 'getScaleX()', 'getScaleY()' and similar methods in the 
>>> 'Transform' class effectively restrict the Transform class to the 
>>> Affine case, in which case the current class names become 
>>> problematic. Using a 'getMatrix' method (we could find a better 
>>> name) with a 'Point3d' argument would solve the conceptual problem, 
>>> without obligation for JavaFX to support such general transforms - 
>>> that would be left to users (I would be fine with JavaFX throwing an 
>>> exception if given a unrecognized transform).
>>>
>>> The intend was just to avoid a class naming problem while keeping 
>>> the current class hierarchy, and keeping door open for non-linear 
>>> transforms in the future.
>>>
>>>     Regards,
>>>
>>>         Martin
>>>
>>>
>>> Le 11/05/12 11:09, Pavel Safrata a écrit :
>>>> Hello Martin,
>>>> your comments make perfect sense. However, I seriously doubt our 
>>>> scene graph would ever be able to operate with such general 
>>>> transformations. Apart from the fact that we would most probably 
>>>> have a great trouble to implement all the existing functionality if 
>>>> such transformations were allowed, it would bring a serious 
>>>> performance drop and would create an API considerably less handy 
>>>> for the usual cases. Anyway, if we decide that the naming issue is 
>>>> serious and/or that we want to leave the door open to the generic 
>>>> transforms, we can do following: insert a new class (say 
>>>> AffineBase) as a subclass of Transform and superclass of all the 
>>>> existing transforms, then go with our proposed solution using 
>>>> AffineBase instead of Transform. To me it seems as a good thing to do.
>>>