JDK-6364134 : Regression: java/awt/FullScreen/DisplayMode/CycleDMImage.java fails
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_redhat_3.0
  • CPU: generic
  • Submitted: 2005-12-16
  • Updated: 2008-02-06
  • Resolved: 2006-05-26
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
6 b86Fixed
Related Reports
Relates :  
JDK-6500686 - Fullscreen windows behind the taskbar on Linux
Description
JDK		    : Fails:  Mustang b59
Platform[s]         : Fails On: Red Hat AS 4
Failing Test [s]    : java/awt/FullScreen/DisplayMode/CycleDMImage.java


    Test source location:
    =====================
/net/cady/export/jdk1.6.0/promoted/all/b59/ws/j2se/test/java/awt/FullScreen/DisplayMode/CycleDMImage.java

    jtr file location:
    ==================
/net/cady/export6/results/mustang/b59b/reg/regression-reg-mustang-RHAS-amd-2005-12-05-11-47-34-0942/workDir/java/awt/FullScreen/DisplayMode/CycleDMImage.jtr

    How to reproduce:
    ====================
    - Set JAVA_HOME to Mustang b59 linux-i586
    - cd /net/cady/export/jdk1.6.0/promoted/all/b59/ws/j2se/test/java/awt/FullScreen/DisplayMode
    - /net/koori.sfbay/onestop/jct-tools/2.1.6/archive/fcs/binaries/linux/bin/jtreg -r:/tmp -w:/tmp ./CycleDMImage.java

    Test output:
    =============
----------System.err:(17/927)----------
java.lang.RuntimeException: 
    DisplayMode(800 x 600 x -1bpp x 85)
    Pixel 0: Expected ffff0000, got ffe6e6e6 at 0
        at CycleDMImage.main(CycleDMImage.java:266)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:589)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:83)
        at java.lang.Thread.run(Thread.java:620)

JavaTest Message: Test threw exception: java.lang.RuntimeException: 
    DisplayMode(800 x 600 x -1bpp x 85)
    Pixel 0: Expected ffff0000, got ffe6e6e6 at 0
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException:      DisplayMode(800 x 600 x -1bpp x 85)     Pixel 0: Expected ffff0000, got ffe6e6e6 at 0
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException:      DisplayMode(800 x 600 x -1bpp x 85)     Pixel 0: Expected ffff0000, got ffe6e6e6 at 0


    Test Machine:
    ============
Linux capella 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686 i386 GNU/Linux

*** /etc/lsb-release.d: directory ***

::::::::::::::
/etc/redhat-release
::::::::::::::
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
Comments
EVALUATION The problem here is that fullscreen apps will usually not show up on top of the GNOME (or other WM) taskbar, so if you have a GNOME panel that runs along the top of the screen and you try to position the fullscreen window at (0,0) the WM will force that window to appear vertically below the panel. Also, if you have another panel/taskbar that runs along the bottom of the screen, the fullscreen window may not always appear above that panel (in terms of z-order). So in this testcase, Robot will try to capture the window at (0,0) in screen coordintates, but the WM will have positioned the fullscreen window below the GNOME panel, and therefore Robot will capture the gray taskbar instead, thus the pixel mismatch failure. The only way to fix this is to start using the _NET_WM_FULLSCREEN hint, which will tell the WM to treat the fullscreen window, as, well, fullscreen. This will cause the fullscreen window to appear above any taskbars, panels, etc provided by the WM. Also related: the existing DisplayMode implementation on Linux/Solaris uses the older VidMode extension, which has a number of limitations, the biggest being that it does not resize the root window after a display change. To get around that, we had to add some hacky code (in the original putback of 4661156) that would grab the mouse/keyboard to prevent the user from triggering the X11 "virtual viewport" behavior if they move the mouse to the bounds of the window. This worked somewhat, but introduced some major problems, namely that alt-tab and other operations wouldn't work properly, and sometimes it would be impossible to exit the fullscreen app if the app didn't provide some means of escape. So the full and proper fix here is to a) implement the _NET_WM_FULLSCREEN stuff and b) replace our VidMode code with the newer/better Xrandr extension. The biggest benefit from Xrandr is that it properly resizes the root window upon a display change, so we no longer need that hacky keyboard/mouse grab code to prevent the virtual viewport scrolling behavior. With these two fixes in place, alt-tabbing, minimize/restore, and all that fun stuff works like a charm now. More importantly, the bug at hand is fixed because the fullscreen window will now appear over (in terms of z-order) any taskbar/panel windows. There is one potential issue with using _NET_WM_FULLSCREEN: if the fullscreen window has any decorations (or non-zero insets), the WM is encouraged but not required to remove those decorations when the window is in fullscreen mode. I've seen varying behavior depending on the WM, platform, etc with this flag (e.g. on Cinnabar a decorated frame will just not receive the benefits of _NET_WM_FULLSCREEN, so it will appear below/behind any panels). So if a fullscreen Java app uses decorated frames, all bets are off; I don't see a good way to get around this platform behavior on our side, so I think it is just something that developers will have to live with. Fortunately, I don't think there are too many apps out there that rely on decorated fullscreen windows, so it should not be a widespread issue. As an aside, Xrandr has the added benefit that it allows us (in theory) to receive display change events, even those that originate from outside the Java process (e.g. when the "Change Display Resolution" dialog is used). Note however that I'm leaving that as a future project because user initiated display changes are not all that common on X11 platforms. So for this putback things will work just as they did before with VidMode where we are in control of the display change from the Java process and that's all. These changes have been tested on a couple different Linux flavors using various fullscreen apps, and things are much better now overall than before. In theory these changes work well on Solaris (x64 with Xorg at least, where Xrandr is available; not yet on Xsun), but unfortunately there is an issue with the way we dlopen() libXrandr.so.2; that library is not on the default library search path on Solaris (see 6424870). Until that bug is fixed on the Solaris side, you can get display mode switching functionality working by setting LD_LIBRARY_PATH=/usr/lib/X11 (this isn't an ideal workaround as there are numerous problems that can crop up when setting LD_LIBRARY_PATH, but it should be good enough if you desperately need display mode and fullscreen functionality on Solaris.
11-05-2006
EVALUATION Based on the submitter's comments, it sounds like there may be a brief flash of gray (perhaps from the toolbar before it is hidden) that the testcase is detecting when taking the screen snapshot via Robot. So this issue probably does not affect real applications and is more an issue with the regression test itself.
08-02-2006