LocalToScene Transformation (related to Affine Transforms)

[Pavel Safrata]

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