JDK-8115939 : Incorrect coordinates determination
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 8
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2013-04-08
  • Updated: 2015-06-17
  • Resolved: 2013-04-17
Related Reports
Relates :  
JDK-8124340 - Menu : sequential menu have distance.
Relates :  
JDK-8115852 - PopupWindow with content with Shadow Effect, wrong position
Description
Run the code, click on combobox (you have only 3 seconds on click), and observe the output.

What I see : 

X : 860.0 Y 310.0
X1 : 860.0 Y1 511.0
Bounds in local BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:200.0, height:201.0, depth:0.0, maxX:200.0, maxY:201.0, maxZ:0.0]
Bounds in parent BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:200.0, height:201.0, depth:0.0, maxX:200.0, maxY:201.0, maxZ:0.0]

//About popup
X : 859.6000000238419 Y : 511.3999938964844
BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:216.0, height:46.0, depth:0.0, maxX:216.0, maxY:46.0, maxZ:0.0]
BoundingBox [minX:-8.0, minY:-8.0, minZ:0.0, width:216.0, height:46.0, depth:0.0, maxX:208.0, maxY:38.0, maxZ:0.0]
BoundingBox [minX:-8.0, minY:-8.0, minZ:0.0, width:216.0, height:46.0, depth:0.0, maxX:208.0, maxY:38.0, maxZ:0.0]
lv.localToScene(lv.getLayoutBounds()) BoundingBox [minX:8.0, minY:8.0, minZ:0.0, width:200.0, height:30.0, depth:0.0, maxX:208.0, maxY:38.0, maxZ:0.0]
X : 0.0 Y : 0.0
X : 859.6000000238419 Y : 511.3999938964844

Seeing lv.localToScene(lv.getLayoutBounds()) computations results, we can say, that listView is shifted on (8; 8) pixels (8 to right, 8 down). But at the same time, you can observe (move mouse on "1" in popup, and look at selection), that listView X and Y must the same, as popup X, Y (859,6; 511), which are the same, as left bottom corner of comboBox, which is located at 860, 511.

This makes us think, that listView is 8 pixels down and right, that it is actually is.

Please investigate, it is important for testing.
Comments
I tried on build, which shows sequential menus in correct order, and localToScreen works correctly, but manual coordinates evaluation - StageXY + SceneXY + LocalToScene don't show correct result - I need to add minXY. This is question of API incorrectness - after localToScene I don't need to think about any content allocation on scene.
07-05-2013
It does after RT-29728 was fixed. So now all you need to do is to use localToScreen and ensure that the layout calculation is finalized (or at least try with runLater).
07-05-2013
Lubomir, why doesn't localToScene method take into account "In that case you'll also need to add the minX, minY of the layout bounds of the Popup's root group to the calculated x, y. "?
07-05-2013
With fix for RT-29728 and modifications to PopupCoordinates.java (runLater and usage of Node.localToScreen conversion), the cursor is correctly and consistently moved to the menu item text.
17-04-2013
The localToScreen problem was filed yesterday as RT-29728.
16-04-2013
1. In that case you'll also need to add the minX, minY of the layout bounds of the Popup's root group to the calculated x, y. There is localToScreen method on a Node which was supposed to do this, but I forgot about its existence and didn't update it when fixing RT-28775. Could you file that as a separate issue? 2. The difference in layout bounds between first and subsequent runs is most probably not caused by RT-28775. Anyway in general it may take one or even several layout passes until a Scenegraph layout is finalized. So your test code shouldn't be dependent on constant layout bounds. You can try to postpone its execution after the first layout pass by wrapping it into Platform.runLater, but even that might not work in every case.
15-04-2013
1. I need to found coordinates of the node - not the scene. A test is irrelevant when you remove those lines. 2. The code works as expected on earlier builds (not sure yet at what moment it was broken). Could you point out what changes caused this change in behaviour? Is it really the 28775?
15-04-2013
If you observe the layout bounds of the menu in the moveMouseTo, you'll notice that the first time you get a different values than in subsequent calls. I assume that the first time the onShown handler is called, the layout of the Popup's root group is not finalized yet. If you want to use layoutBounds in your calculation and want your code to be somewhat robust, you'll need to install invalidation or change listener on the layout bounds and do the necessary corrections in it. Anyway with RT-28775 fix, you don't need to do any corrections for root layout bounds, because that correction is done automatically in the Popup code. So for Popup window (with default settings), you no longer specify or get the position of the upper left window corner, but the position of the root node coordinate space origin. This for your PopupCoordinates example means, that you don't need the following lines in the moveMouseTo method: Bounds b = menu.localToScene(menu.getLayoutBounds()); x += b.getMinX(); y += b.getMinY(); When I removed the lines, the mouse cursor was consistently positioned in the upper left corner of the submenu content.
15-04-2013
This bug is blocking testing. Please provide your feedback ASAP.
15-04-2013
Please node that the PopupCoordinates only misplaces the mouse on the first try. If you expand the menu for the second and consequent runs., it will work as expected Please also note that even GlassRobot war used only to show actual screen coordinates, AWT robot behaves the same. A robot is used only to show actual coordinates in the first place.
15-04-2013
The code demonstrates wrong screen coordinates
15-04-2013
This is how screen coordinates for a node are calculated: window's coordinates (getX(), getY()) plus scene's coordinates (getX(), getY()) plus node coordinates getLayoutBounds() relative to the scene localToScene(Bounds) This is how it works for non-popup windows. It is assumes to work the same for popup windows Either the implementation needs to be changed or the API needs to be changed by changing descriptions of the aforementioned methods or adding other methods.
15-04-2013
The coordinates reported by and set to popup are influenced by its root group layout bounds offset as requested in RT-28775. This should explain off by 8 error observed in the description.
09-04-2013