Bug 100 - Order of operations matters for fullscreen app
Summary: Order of operations matters for fullscreen app
Status: VERIFIED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All windows
: P3 normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2004-07-24 09:43 CEST by Sven Gothel
Modified: 2010-03-24 07:46 CET (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments
Example of "incorrect" order which fails in fullscreen (15.74 KB, text/plain)
2004-07-24 09:44 CEST, Sven Gothel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:46:48 CET


---- Reported by caoimhin 2004-07-24 09:43:29 ----

When trying to run a fullscreen application (attached Order.java source code), 
whether the canvas is attached to the frame before or after the frame is made 
visible critically affects the application's initialization.  When the canvas 
is attached before the application has entered fullscreen, the application 
fails to finish initialization, displaying an unresponsive "white screen of 
death" and never proceeding beyond that point.

Order of attachment does not seem to matter in windowed applications.

All combinations of ATI_WORKAROUND and sun.java3d.noddraw flags were tested 
without any affect.

Hardware and software tested under:
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

Jogl 1.1b04 (July 16)

------------------
System Information
------------------
Time of this report: 7/24/2004, 09:37:36
       Machine name: VENUS
   Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 1 
(2600.xpsp2.030422-1633)
           Language: English (Regional Setting: English)
System Manufacturer: Gateway                         
       System Model: Gateway 450RGH                  
               BIOS: Rev 1.0                 
          Processor: Intel(R) Pentium(R) M processor 1700MHz
             Memory: 1022MB RAM
          Page File: 182MB used, 2279MB available
        Windows Dir: C:\WINDOWS
    DirectX Version: DirectX 9.0b (4.09.0000.0902)
DX Setup Parameters: Not found
     DxDiag Version: 5.03.0001.0902 32bit Unicode

---------------
Display Devices
---------------
        Card name: ATI MOBILITY RADEON 9600
     Manufacturer: ATI Technologies Inc.
        Chip type: MOBILITY RADEON 9600 Series AGP (0x4E50)
         DAC type: Internal DAC(350MHz)
       Device Key: Enum\PCI\VEN_1002&DEV_4E50&SUBSYS_0475107B&REV_00
   Display Memory: 128.0 MB
     Current Mode: 1600 x 1200 (32 bit) (60Hz)
          Monitor: Default Monitor
  Monitor Max Res: 
      Driver Name: ati2dvag.dll
   Driver Version: 6.14.0010.6414 (English)
      DDI Version: 9 (or higher)
Driver Attributes: Final Retail
 Driver Date/Size: 4/17/2004 15:48:34, 384512 bytes
      WHQL Logo'd: Yes
  WHQL Date Stamp: n/a
              VDD: n/a
         Mini VDD: ati2mtag.sys
    Mini VDD Date: 4/17/2004 15:48:35, 647680 bytes
Device Identifier: {D7B71EE2-0D10-11CF-C56A-7F24A1C2CB35}
        Vendor ID: 0x1002
        Device ID: 0x4E50
        SubSys ID: 0x0475107B
      Revision ID: 0x0000
      Revision ID: 0x0000
      Video Accel: ModeMPEG2_C ModeMPEG2_D 
 Deinterlace Caps: {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=
(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,1) Caps=DeinterlaceTech_PixelAdaptive 
                   {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=
(YUY2,YUY2) Frames(Prev/Fwd/Back)=(0,0,0) 
Caps=DeinterlaceTech_BOBVerticalStretch 
                   {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=
(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,1) Caps=DeinterlaceTech_PixelAdaptive 
                   {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=
(UYVY,UYVY) Frames(Prev/Fwd/Back)=(0,0,0) 
Caps=DeinterlaceTech_BOBVerticalStretch 
                   {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=
(YV12,0x32315659) Frames(Prev/Fwd/Back)=(0,0,1) 
Caps=DeinterlaceTech_PixelAdaptive 
                   {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=
(YV12,0x32315659) Frames(Prev/Fwd/Back)=(0,0,0) 
Caps=DeinterlaceTech_BOBVerticalStretch 
                   {6E8329FF-B642-418B-BCF0-BCB6591E255F}: Format(In/Out)=
(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,1) 
Caps=DeinterlaceTech_PixelAdaptive 
                   {335AA36E-7884-43A4-9C91-7F87FAF3E37E}: Format(In/Out)=
(NV12,0x3231564e) Frames(Prev/Fwd/Back)=(0,0,0) 
Caps=DeinterlaceTech_BOBVerticalStretch 
         Registry: OK
     DDraw Status: Enabled
       D3D Status: Enabled
       AGP Status: Enabled



---- Additional Comments From caoimhin 2004-07-24 09:44:41 ----

Created an attachment
Example of "incorrect" order which fails in fullscreen




---- Additional Comments From kbr 2005-01-31 09:54:55 ----

This test case now no longer crashes/freezes on either ATI or NVidia hardware
with the latest sources in the JOGL CVS repository, which will be released in
1.1 b08 and which include enhanced code for the single-threaded ATI workaround.
However, when running with -Dsun.java2d.noddraw=true on ATI hardware, the
application frequently believes the window is incorrectly sized, taking up
roughly four times the visible screen area. This may be a bug in the JDK's
full-screen support, but it would be good to find the root cause and either work
around it or fix it in the JDK.




---- Additional Comments From kbr 2005-01-31 09:56:14 ----

Actually it appears that the application believes the fullscreen window is
incorrectly sized on any hardware with -Dsun.java2d.noddraw=true, not just ATI's.




---- Additional Comments From kbr 2005-01-31 15:51:24 ----

Confirmed that there is a change in behavior of setFullScreenWindow() /
setDisplayMode() between 1.4.0 and 1.4.1. Although 1.4.0 appears to work
correctly, I believe this is a fluke, because the top-level JFrame is resized to
the dimensions of the screen before the display mode change, and only the
GLCanvas retains its original size and location (upper-left corner of the
JFrame, and 640x480 size). A workaround is to schedule a setSize(640, 480) on
the GLDrawable inside of the GLEventListener's init() method using
EventQueue.invokeLater() (doing this inside of the GLEventListener's callback
causes OpenGL operations to fail -- this could be a problem).

I'm going to mark this as "works for me" because the underlying
JOGL_SINGLE_THREADED_WORKAROUND, done for another bug, is the true fix. I'm also
going to file a new bug to try to work around the full-screen issue.




--- Bug imported by sgothel@jausoft.com 2010-03-24 07:46 EDT  ---

This bug was previously known as _bug_ 100 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=100
Imported an attachment (id=25)

The original submitter of attachment 25 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.