JDK-8006421 : GraphicsConfiguration of a frame is changed when the frame is moved to another screen
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • Submitted: 2013-01-16
  • Updated: 2015-10-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorUnresolved
Description
Originally reported at: http://www.java.net/forum/topic/javadesktop/java-desktop-technologies/swing-awt/problem-graphicsconfiguration-frame

*************************************************************************
I have a simple program which builds a frame with a specific GraphicsConfiguration.
 When I launch this program on Linux and Java1.7 with multiscreens (TwinView), the GraphicsConfiguration of my frame changes to default configuration if it is moved onto the second screen.
 Why the default configuration is restored ? With Java1.6, this change doesn't occur.
*************************************************************************

Note that this may or may not be a bug. However, since the behavior has changed since 1.6, we should evaluate whether it is an expected change.
Comments
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
2014-08-10

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
2014-08-10

More details from a forum post in that thread: ************************************************************************* I've tested with a translucent window (GradientTranslucentWindowDemo from "How to Create Translucent and Shaped Windows" tutorial). On the first screen, a translucency-capable GraphicsConfig is found and it is not the default one (GraphicsDevice.getTranslucencyCapableGC()). To check graphics configurations, I print visual IDs: Default GC = 33, Frame GC = 284. When the window is moved to the second screen, visual IDs: Default GC = 33, Frame GC = 33. The GC of the frame is the default GC. If I move my frame back to the first screen, visual IDs: Default GC = 33, Frame GC = 33. The translucency-capable GraphicsConfig is never restored. So, for me, this is a bug, I think the chosen GraphicsConfig must be closest to the GC explicitly specified by the application. ************************************************************************* Since the window is transparent, I'd imagine it should choose a translucency-capable GC when moved back to a screen that provides one. Perhaps, even if we reset the transparent status of a window, we should nevertheless preserve it in a private field, and take into account when the window is moved to a new screen to choose the right GC for that window. In any case we should investigate why this wasn't a problem for Java 1.6 and see if we can restore the old behavior.
2013-04-30

As replied on the forum, different screens may have different graphics configs, so the change is expected. However, we should make sure that if a translucency-capable GraphicsConfig was explicitly specified by application, and the new screen also provides translucency-capable GraphicsConfig, this config should be chosen, otherwise the window will become opaque. If this is true, the bug must be closed as not a defect.
2013-01-21