JDK-6662642 : java/awt/FullScreen/SetFSWindow/FSFrame.java fails in respin build pit on older gnome versions
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,sparc
  • Submitted: 2008-02-13
  • Updated: 2011-01-20
  • Resolved: 2008-03-25
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 6
6u10 b20Fixed
Related Reports
Duplicate :  
JDK-6603471 - closed/java/awt/FullScreen/SetFSWindow/FSFrame.java fails on Solaris SPARC Gnome desktop
Relates :  
JDK-6500686 - Fullscreen windows behind the taskbar on Linux
Description
ava/awt/FullScreen/SetFSWindow/FSFrame.java once again fails in pit build . I have attched the log file. Its a regression in the respin pit build also.
I fails on solaris 10.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u10/6662642.0
05-03-2008
EVALUATION I have updated the test to be more considerate. The changes include: - painting and taking the screenshot on the EDT - if the full-screen mode is not supported, adjust the bounds of the screenshot using screen's insets Toolkit.getScreenInsets(GC) - since the window may not overlap WM decorations if the fs is not supported - like when the security manager is set - dump the screenshot if the test fails Note that the test may may still fail on older (pre 2.6?) gnome versions because of Gnome bugs (like it does on Solaris 10) - the screen insets reported on Solaris 10 (JDS3) are 0x0x0x0 while they're clearly not. (it would be nice to get a definite answer about this from AWT) If the test does fail please consult the screenshot. If it shows parts of the desktop decorations (taskbar, menubar) it is likely to be a gnome issue.
27-02-2008
EVALUATION It seems the test fails on solaris because of the problem described in 6500686 and should be corrected.
27-02-2008
EVALUATION To determine exactly why it fails on a particular system, add this code which'll dump the screenshot into Test.png: *** /tmp/sccs.cuaaJW Thu Feb 14 13:49:42 2008 --- FSFrame.java Thu Feb 14 13:39:03 2008 *************** *** 65,70 **** --- 65,75 ---- colorCorrect &= checkColor(getWidth() - 1, getHeight() - 1, bImg); colorCorrect &= checkColor(getWidth() / 2, getHeight() / 2, bImg); if (!colorCorrect) { + try { + javax.imageio.ImageIO.write(bImg, "png", new java.io.File("Test.png")); + } catch (Exception e) { + System.err.println(e); + } throw new Error("Some pixel colors not correct; FS window may not" + " have been displayed correctly"); }
14-02-2008
EVALUATION Also, the test fails on solaris-sparc (Solaris 10) on 6u4 and earlier releases. The reason it fails is that the screen shot takes gnome's toolbar as well, and the test attempts to check the pixels in the lower right and left corners. The test should calculate the proper bounds for the screenshot by checking the screen insets.
14-02-2008
EVALUATION I have only looked at this on Windows, but I have been able to reproduce this on b11 (intermittently), so it's not a PIT bug. I think this is a bug in the test, highlighted (on windows) by the new on-screen rendering mechanism in the D3D pipeline. The test paints the frame on the EDT but takes the screen-shot from another thread. Depending on the timings it may get a screen shot of something it didn't expect.
14-02-2008