FULL PRODUCT VERSION :
java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

(Reproduced on 1.4 FCS as well.)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]



EXTRA RELEVANT SYSTEM CONFIGURATION :
256Megs of SDRAM, Pentium 3 500mhz, NVDA TNT 16Meg Graphics
card, Tested with both DirectX 6.0 and DirectX 8.1.

A DESCRIPTION OF THE PROBLEM :
I've recently encountered a problem with the Fullscreen API
causing it to freeze up whenever I alt-tab, or recieve a IM
while it's occupying the video memory. It opens up fine and
I've, by over-riding the setVisible method, been able to
find that when it opens setVisible is called and set to
true. However when I close it (by alt-tabbing), the
setVisible method never recieves a "setVisible(false)"
call, nor does my animation loop fall into the code below
the if(bufferStrategy.contentsLost()) statement that is
called every 32 milliseconds by a java.util.Timer. When I
alt-tab, if I place a print statement in the animation
thread, I can see that it's still displaying in the
background and still iterating, and not finding that the
contents of the frame have been lost allthough my desktop
has obviously claimed them. Now, when I return to the
frame, it apears as if it is still atempting to animate
because I find more print statements after I exit yet
again, but now it waits for a couple of seconds, and then
turns pure white and won't allow me to close it unless I
explicitly have my task manager kill the process.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Get a computer system similar to my own,
run "MultiBufferTest" included with the Fullscreen API
documentation.
2.Alt-tab once the program has had a chance to display.

3.Wait a second.

4.Alt-tab again and notice how the screen doesn't display
anything any more.

5.Alt-tab again.

6.Notice how screen turns completely white, and you cannot
exit the program without killing the process.


EXPECTED VERSUS ACTUAL BEHAVIOR :
The BufferStrategy object reclaims the memory upon re-
entering the window, and continues to animate the rest of
the full-color screens.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
It works with MultiBufferTest.java.
---------- END SOURCE ----------
(Review ID: 138539) 
======================================================================

N/A

This is the ALT-TAB issue mentioned originally in 4480734.  Reproducible with Win2K / NVIDIA GeForce 3 and MultiBufferDuke, MultiBufferTest, FullScreenTest, or FullScreenTest2.  Committing to mantis.
 xxxxx@xxxxx  2002-05-22

The root cause of this is our multi-threaded use of DirectX.  The DirectX docs
specify that various operations should only be performed on the thread that
created the window (in our case, the Windows event thread).  In general, these
recommendations do not tend to affect DirectX functionality.  But in the case
of fullscreen functionality, they apparently really mean it.

I created a native app to duplicate the problem by creating the fullscreen 
window on a separate thread.  When I alt-tabbed out of the app and back
in, I got the exact same response: a white desktop and virtually no response
from the OS.  I could only quit the application and return to normality by
using the Task Manager.

So the fix to this bug involves putting fullscreen-related operations on
the Windows thread.  We do this by sending or posting event messages for
the following operations: CreateSurface, SetDisplayMode, EnterFullscreen,
ExitFullscreen, and RestoreDisplayMode.  Only CreateSurface is performed
synchronously (by using SendMessage() instead of PostMessage()); this operation
must be finished when we return from the function so we have to do it
serially.  The other operations all use PostMessage and are thus performed
asynchronously.  Ideally, all of these events would happen synchronously, but
there is always a danger of deadlocks in this code with too many thread
dependencies.

Note that eventually we should single-thread all DirectX (and probably all
rendering) operations on the Windows thread to avoid the deadlock problem
and other unknown DirectX problems (it could be that some unsolved
DirectX artifact bugs are related to our threading issue).  See 
4641854 as we work on that problem.

Other problems that are fixed as part of this bug are related to our
creation and use of back buffers.  Previously, we would get a new
attached surface from the primary for every request of the back buffer.  
When we could not alt-tab out and back in again, this did not cause
a big problem because there were not many requests for this buffer.  But
now that we are potentially going out and in again, changing display modes
several times, there are lots of recreations of the primary and new requests
for this buffer.  the problem is that there is really only one back buffer
associated with each primary; we should not be deleting or restoring that
back buffer directly, nor should we be getting multiple pointers to it from
GetAttachedSurface().  instead, we should get the buffer once and share
that resource appropriately.  All deletions and restorations of that
surface happen implicitly via the primary surface.

I have been trying the Java 1.4.1 FCS and came across this 
bug (or something similar). I am acually using passive 
rendering, but get the same behaviour through ALT-TAB 
and/or iconifying using DisplayModeTest (from the java 
tutorials), and the application I am currently working on.

Is there a planned release version for this bug to be fixed in?