Bug ID: JDK-8099069 Add "localToParentTransform" and "localToSceneTransform" variables to Node.fx

Type: Enhancement
Component: javafx
Sub-Component: scenegraph

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2008-09-09
Updated: 2015-06-16
Resolved: 2012-05-16

JDK 7
7u6Fixed

We don't have a way to get the composite "local-to-parent" transform that will transform a point from a node's local coordinate system to its parent coordinate system. Ditto for local-to-scene transform. We have a way to get the bounds in parent and an arbitrary point in parent, but we can't get the transform itself. Consider adding public-read variables for "localToParentTransform" and "localToSceneTransform".

Unit tests: javafx/scene/Node_LocalToParentTransform_Test/* javafx/scene/Node_LocalToSceneTransform_Test/* The transform matrix getters testing added to the respective tests of the particular transformations.
18-05-2012
The properties were created according to the proposal, changeset c9ad5e531998. Note that I think this hasn't much value without the matrix algebra methods requested in RT-17942.
16-05-2012
Jasper sent me the link: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c9ad5e531998 Looks fine from API standpoint.
16-05-2012
Hi Pavel, can you attach the final patch to this issue? We didn't quite get approval for it on the thread but I know the general form of it sounded great to me, but I'd like to take a quick look at the final patch.
16-05-2012
This is our proposal. We will create a read-only properties localToParentTransform and localToSceneTransform on Node. They will be of type Transform. The local-to-scene property will have a special invalidating mechanism that will register invalidation listeners to parents only when somebody registers a listener (or a binding) on them, but this will be completely transparent to users, they will just be warned in the documentation that registering a lot of listeners to the property will significantly affect performance. In scope of this issue we will also add getters for the transformation matrix elements (getMxx() etc.) to the Transform class, so the transformation matrix will be obtainable from any implementation. There is a plan to add some basic matrix computations (returning a new Transform instance) to the Transform class and other methods (modifying the metrix in place) to the Affine class, but those will be treated in different issues.
14-05-2012
Storage is only an issue if this is exposed in a way that requires the object to be physically present at all times. Also, I'm guessing this would be read-only since you can't reverse propagate arbitrary changes they make back into the transform attributes of the node and its parents. Since it must be copy-out, it can really be "only ever calculated lazily when the method is called". If a property is desired to listen for changes, then something can be worked out that doesn't require the allocation of a "matrix property that always holds a matrix" to provide notifications - perhaps a synthetic property? Or a property that can lazily produce a matrix object only if someone gets its value?
04-05-2012
I think Java3D provides a nice API for this and could be a good source of inspiration.
04-05-2012
This is also useful for performing billboard behaviors. For instance I have a text node on my app that is a descender of some nodes, those nodes rotation and translation can change over time making the text rotation/translation also change. What I want is for the text node to remain readable, and for that it has to be kept parallel to the bottom of the screen.
27-02-2012
In an email thread, Pavel Safrata asked: "Do we really need a method that computes the compound matrix or would it be enough to speed up the coordinates translation methods?" Kevin Rushforth responded: "Yes, we really need a method to compute a compound matrix for various 3D algorithms (useful for 2D as well, but not as critically important)." John Yoon also responded: "I agree. We really do need the matrix itself."
01-02-2012
What we need is something lightweight but really fast. Alexander can you create a diff/patch for the change we made to Node for the JavaFX Labs demo. So we can show Pavel what we did. Also it would be good if we could create a simple test that shows the frame rate difference of the good vs bad approach. Then Pavel can see if he can come up with a way we can get the good performance with as minimal impact on node size etc. Seems like we need more specific use case here. The other part of this is we already have a localToScene method for transforming a point or bounds. Do we need one that will get us the Affine transform matrix for any given node to scene transform?
20-12-2011
To me having localToSceneTransform property seems too expensive. First, it means extra at least 136 (if I counted correctly) bytes per node. For any transformation change, we would have to walk whole subtree and mark all of the local-to-scene transformations invalid. With an animation on root node this sounds quite horrible (even if we don't need to descend to branches that are not using it). Maybe we could invent something more lightweight that would help you with the use-cases. We might for example introduce a utility method which would create the transformation, and if needed it would register some listeners to all node's parents to keep it up to date, or something like that.
20-12-2011
A "localToSceneTransform" is needed for use cases involving skinning of 3D geometry to joints/transforms. There are also a number of use cases that are both for 2D and 3D situations. Namely, a "localToSceneTransform" is also needed for transform constraints, especially when these transform constraints need to be applied across different branches of a scene graph. The most common transform constraints are: point, orient, and aim. For example, if you wish to have a child of branch1 to point at a child of branch2, "localToSceneTransform" is needed to perform this aim computation. In this case, it would be very useful if "localToSceneTransform" could be available as a property, so that it could be computed via bindings lazily. Brent Christian notes: "Brute forcing the transforms is expensive, 'cause you have to walk a bunch (or all of ) the scenegraph. The obvious way to cut that cost down (in exchange for some memory) is to cache a bunch of the information within nodes, groups, etc. And then the challenge becomes keeping all the cached information up-to-date. Probably what you really need is someone who really knows the guts of the scenegraph." Is there a possibility that "localToSceneTransform" could be implemented for 2.2?
16-12-2011
I would hold off on this until the actual need arises. As for whether it should be a property or a method, I guess it depends on the use case. I can imagine an application wanting to listen for changes in the composite transform of a node (e.g., if they using that transform to control some operation or drawing that needs to be kept in sync with the rendered node in the scene graph).
25-10-2010
Just seems like overkill. Is there a solid use case?
22-10-2010
Do these need to be variables or is a function sufficient? I guess a property is more useful if you want to bind this information to something else.
22-10-2010
Post-1.5
04-03-2009

Duplicate :	JDK-8101316 - Add getWorldTransform to public API
Duplicate :	JDK-8102371 - Provide a way to get the "cumulative" transform applied to a node
Relates :	JDK-8100722 - Provide Affine class with matrix manipulation methods (multiply, premultipy, negate, etc.)
Relates :	JDK-8098203 - need utility methods for converting to/from screen coordinates