JDK-4754144 : FullScreenTest and FullScreenTest2 stuck in loop while alt-tabbed (windows only)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P5
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2002-09-26
  • Updated: 2004-08-10
  • Resolved: 2004-08-10
Related Reports
Relates :  
JDK-4690117 - VolatileImage never recovers lost surface in FullScreenTest
Description
This is essentially a reopening of bug 4690117.

If you uncomment out the code in FullScreenTest*.java (including the 
println statements) run the app, and alt-tab out of it, you will notice that
the app is stuck in an infinite loop trying to validate the volatile image.
The VolatileImage code should return an image that is validated (ie, 
contentsLost() will return false).  But it appears that if we alt-tab out
of the application and there is a problem creating teh vram-version of the
image, then the flags never get reset and the application is stuck in a loop
waiting for the image to be correctly restored.
Comments
EVALUATION The problem appears to be related to the ability to create a hardware version of the image. The app is written in a way that completely thrashes VRAM; we run in a tight loop, allocating a new VolatileImage every time through the loop. the garbage collector cannot keep up with this rate of creation, so eventually we run out of video memory and cannot create a hardware representation of the image. If we then alt-tab out of the application, we run in the inner loop validating and checking contentsLost(), which always returns true. Perhaps an alt-tabbed application has no ability to create VRAM surfaces (permission problem with minimized applications?), so again we cannot get the hardware version of the image. For whatever reason, we are not resetting the flags in VolatileImage appropriately, so we never exit the loop. If the application is rewritten to simply create one volatileImage and to reuse that (and recreate/restore it as necessary), then things work fine and we do not get trapped in the aloop. Check the way that our contentsLost flags interact with our ability to create a hardware version of the image. ###@###.### 2002-09-26 This problem appears to have been fixed and we no longer see the infinite loop in the current Tiger code base. The test is not well-behaved and does have some odd symptoms such as monopolizing the screen sometimes even when alt-tabbed out, but even when that's the case, we are still completing the contentsLost() loop correctly (whether we allocated a VRAM or software image) and returning. I'm closing the bug as Not Reproducible. ###@###.### 2004-08-10
10-08-2004