LocalToScene Transformation (related to Affine Transforms)

[Alexander Kouznetsov]

Hi Pavel,

I like the way you're going. Here is another issue you may want to 
concern: http://javafx-jira.kenai.com/browse/RT-17942

Having immutable matrix seems to be a reasonable solution and I agree 
that Affine doesn't fit there. However I agree with Jim that having 
mutable subclasses fakes the immutability of the base class. Moreover it 
increases garbage collection overhead.

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.

Best regards,
Alexander Kouznetsov


On 09.05.2012 19:16, Pavel Safrata wrote:
> 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