JDK-6567564 : Canvas's graphics config does not change when moved across monitors, Linux
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_suse_sles_10
  • CPU: x86
  • Submitted: 2007-06-08
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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.
JDK 7
7 b15Fixed
Related Reports
Relates :  
JDK-4452373 - display change on win32 not propagating to all heavyweight components
Relates :  
JDK-6631680 - REGRESSION: api/java_awt/Container/index.html#isAncestorOf[Container2019] hangs up
Relates :  
JDK-6612497 - api/java_awt/Container/index.html#isAncestorOf Container2019 hangs since JDK 7 b15
Relates :  
JDK-5085626 - Exponential performance regression in AWT components (multiple monitors)
Description
I have a frame with a canvas created using Default screen's graphics configuration. After showing the frame, I am moving the frame (with canvas) from primary to secondary screen and trying to get the current graphics configuration by calling getGraphicsConfiguration(). Frame returns the secondary monitor's graphics config as the current config whereas Canvas still returns the primary screen's GC. Canvas is not inheriting the GC properly from the top-level window. 

This is reproducible on SuSE10 and not reproducible on WinXP (both are virtual screen enviroments). I tried on SuSE10 + xinerama as well as SuSE10 + TwinView and the bug is reproducible on both. For Twin-View, I used Nvidia GeForce FX5900. This bug is causing few false failures in the multimonitor testsuite. This is reproducible atleast since JDK5.

I have attached the same test. Run the test. You will see a frame with a blue canvas and a button. Click on the button and take a note of the GC shown on the console. Move the frame manually to the secondary monitor and click on the button again. If the canvas shows the same GC, the bug is reproduced.
Comments
EVALUATION While running all the AWT reg tests for the fix, I found some of them fail, both with or without the fix. In particular, the test for 5085626 (WPanelPeerPerf.java). Further investigation has shown the failure is caused by right the same mistake as in Windows code described in 5085626, in other words the fix for 5085626 is incomplete as doesn't touch XAWT. I have refactored our GraphicsConfiguration updates code a bit. After this I found that the call to XPanelPeer.resetLocalGC() is performed more often than prior to my changes. At first I thought it could be a performance drop, however later I found this is a required change. Without this change Panel's and its XPanelPeer's graphics configs are different which may lead to come problems, and after the change they are in sync.
09-06-2007
EVALUATION For some unknown reason XCanvasPeer has an empty resetTargetGC() method, while in XWindowPeer it is overridden to really fill the target's GC. This leads to the canvas peer to contain the correct GC value, but the canvas GC is always the default GC. To fix the problem I suggest just move resetTargetGC method from XWindowPeer to XCanvasPeer. Will investigate if this approach has any side effects.
09-06-2007