LocalToScene Transformation (related to Affine Transforms)

[Pavel Safrata]

Hi Michael,

On 9.5.2012 20:43, Dr. Michael Paus wrote:
> Your last proposal looks promising but could you provide some more 
> details? Will it, for example also
> be possible to apply the inverse transform of the local-to-scene 
> transform? 

You will be able to compute an inverse transformation and apply it to a 
different node, if that's what you mean. Among others, I've had 
inversion on my mind when I talked about "matrix operations on the 
Transform class", I just think I'll file a different issue to cover it.

> How is the currently
> existing Transform class hierarchy affected by these changes? Would it 
> be possible to make
> the existing classes Translate, Rotate, etc. sub-classes of Affine?

We most probably don't want to do that. These 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. But still, for a complex work 
with transformations you should be ok with the Affine class itself once 
RT-17942 is resolved.

Thanks,
Pavel

>
> LG, Michael
>
>
> Am 09.05.2012 17:16, schrieb Pavel Safrata:
>> Hello,
>> I've been working on the local-to-scene transform 
>> (http://javafx-jira.kenai.com/browse/RT-520). I have a prototype that 
>> makes it an observable (read-only) property, registering for 
>> invalidation notifications to parent only when somebody registers a 
>> listener to it. This is nicer than a simple "compute" method - it 
>> looks like a standard observable lazy property from user's point of 
>> view.
>>
>> The big question now is what the type of the property should be. 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.
>>
>> We considered another option: creating a new class 
>> TransformationMatrix. This class would be immutable and would contain 
>> various methods for work with matrices. All the transforms would have 
>> a getter that would return an instance of this class, the Affine 
>> class would have also a setter. Now the localToSceneTransformation 
>> property could be of type TransformationMatrix. This would spare us 
>> the above problems and provide an independent class for matrix 
>> operations, but on the other hand, converting transformations to the 
>> matrix and back may be an unnecessary burden, also doing some complex 
>> matrix computation with an immutable matrix class would result in 
>> pretty huge garbage production (slowing down the computation).
>>
>> So we propose yet another approach. In the base Transform class, 
>> introduce getters for all the elements of the transformation matrix 
>> (not observable, just getters). Each transformation would be able to 
>> return the values according to its current state. Our property would 
>> then be of type Transform, allowing only for getting the matrix 
>> values. This would make the property observable as a whole (creating 
>> a new instance each time), unmodifiable, and would leave us with a 
>> nicely open way to introduce the methods for matrix operations on the 
>> Transform class, most of them probably returning the Affine instance 
>> as a result, and the Affine class could then have a bunch of methods 
>> to be modified in place.
>>
>> What do you think?
>> Thanks,
>> Pavel
>
>