-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
1.4.2
-
generic
-
generic
When we run the demo on one of our slower machines, it regularly happens that
the window containing the demo jumps off the screen when moved around. This
only happens with the Metal Toolkit where the code for moving toplevel windows
is implemented within Java2 SDK.
While tracing the problem, we hit on this piece of code in MetalRootPaneUI.java:
public void mouseDragged(MouseEvent ev) {
Window w = (Window)ev.getSource();
Point pt = ev.getPoint();
if (isMovingWindow) {
Point windowPt = w.getLocationOnScreen();
windowPt.x += pt.x - dragOffsetX;
windowPt.y += pt.y - dragOffsetY;
w.setLocation(windowPt);
}
...
What seems to cause our problem, is that ev.getPoint() retrieves relative
offsets from the source window of the event at the time the event occured.
On the other hand, w.getLocationOnScreen() retrieves the "current" position
of the source window on the screen. Given the asynchronous nature of event
handling, it may happen that the source window is at a different position
"now" than at the time the event occurred.
Experimentally using absolute pointer positions that are also available for
motion events within X, solved our problem. [ In canvas.c: case MotionNotify
new variables (x|y)_root can be set to (jint)event->xmotion.(x|y)_root;
awt_post_java_mouse_event() can be extended to also post the absolute
coordinates; and MouseEvent.java also can be extended to make the absolute
coordinates available. ]
the window containing the demo jumps off the screen when moved around. This
only happens with the Metal Toolkit where the code for moving toplevel windows
is implemented within Java2 SDK.
While tracing the problem, we hit on this piece of code in MetalRootPaneUI.java:
public void mouseDragged(MouseEvent ev) {
Window w = (Window)ev.getSource();
Point pt = ev.getPoint();
if (isMovingWindow) {
Point windowPt = w.getLocationOnScreen();
windowPt.x += pt.x - dragOffsetX;
windowPt.y += pt.y - dragOffsetY;
w.setLocation(windowPt);
}
...
What seems to cause our problem, is that ev.getPoint() retrieves relative
offsets from the source window of the event at the time the event occured.
On the other hand, w.getLocationOnScreen() retrieves the "current" position
of the source window on the screen. Given the asynchronous nature of event
handling, it may happen that the source window is at a different position
"now" than at the time the event occurred.
Experimentally using absolute pointer positions that are also available for
motion events within X, solved our problem. [ In canvas.c: case MotionNotify
new variables (x|y)_root can be set to (jint)event->xmotion.(x|y)_root;
awt_post_java_mouse_event() can be extended to also post the absolute
coordinates; and MouseEvent.java also can be extended to make the absolute
coordinates available. ]
- duplicates
-
JDK-4962534 JFrame dances very badly
-
- Resolved
-
- relates to
-
JDK-4470426 Merlinb66: Can't move undecorated JDialogs
-
- Resolved
-