-
Enhancement
-
Resolution: Future Project
-
P3
-
None
-
7
-
None
-
generic
-
generic
When a hw component is reparented to another container, its peer usually gets recreated (via removeNotify() and subsequent call to addNotify()). Sometimes it does not happen if the native system allows reparenting w/o destroying the native window object. This even got eased with the fix for 6552803.
All this works quite fine now unless we try reparenting the hw component to another top-level window. Theoretically the native system does not put a constraint on this operation. However from the Java's point of view there's such property like the GraphicsConfiguration/GraphicsDevice for any hw component. Different application windows can obviously be located on different screens in a multi-screen environments, hence to move a hw component from one top-level window to another, we would need to change its graphics configuration. The current code does not provide such functionality, and hence the change request.
All this works quite fine now unless we try reparenting the hw component to another top-level window. Theoretically the native system does not put a constraint on this operation. However from the Java's point of view there's such property like the GraphicsConfiguration/GraphicsDevice for any hw component. Different application windows can obviously be located on different screens in a multi-screen environments, hence to move a hw component from one top-level window to another, we would need to change its graphics configuration. The current code does not provide such functionality, and hence the change request.
- relates to
-
JDK-6552803 the moveToFront causes Heavyweight components to be removed.
-
- Closed
-
-
JDK-6804747 Ensure consistent graphicsConfig member across components hierarchy
-
- Closed
-
-
JDK-6812298 Dynamic GraphicsConfig changes don't work on X11 platforms
-
- Closed
-