LocalToScene Transformation (related to Affine Transforms)

[Dr. Michael Paus]

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

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


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