LocalToScene Transformation (related to Affine Transforms)
Dr. Michael Paus
mp at jugs.org
Wed May 9 11:43:43 PDT 2012
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?
Am 09.05.2012 17:16, schrieb Pavel Safrata:
> 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?
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.
More information about the openjfx-dev