JDK-4736213 : Swing icons not restored after other app goes fullscreen (Win2k, nVidia gf2Go)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2002-08-23
  • Updated: 2002-08-23
  • Resolved: 2002-08-23
Related Reports
Duplicate :  
JDK-4731131 - App crash drawing lines after display mode switch (windows/GeForce2Go chip only)
Description
On my win2k laptop (Toshiba Satellite 2085-s402 with an nVidia GeForce2 Go
chip), running another app in fullscreen mode causes a Swing app to lose
icon contents (that never get restored).

To duplicate:
- Run Notepad
- Move another window over all of the icon images to force them to all get
repainted at least once (this ensures that we are now using the vram-cached
version of the icons)
- Go to a DOS box and hit alt-enter (forcing it  into fullscreen mode)
- Hit alt-enter again (bringing DOS out of fullscreen mode)
- Note that all or the Notepad icons are now black or garbled.

Note: Due to bug 4731131, the app will probably just crash when you return out
of fullscreen mode.  I am working with a build that has a workaround in
the code for this bug, so I can see the effect of the icon content loss
where I would otherwise just see a crash.
Comments
WORK AROUND -Dsun.java2d.noddraw=true or -Dsun.java2d.ddoffscreen=false should both work (although they disable hardware acceleration for the app)
11-06-2004
EVALUATION It looks like we are not getting the expected errors from DDraw. When I put trace statements in the code, I see SURFACELOSS errors from the back buffer, which is eventually restored. But I never see any other errors when we have clearly lost the surfaces for the vram cached icons. Apparently those surfaces got restored somehow prior to doing any operations with them so that when we eventually did our Blt from the icons to the restored back buffer, Blt did not complain. But who did the restoration? We do not do it in our code unless we have encountered a SURFACELOSS error. Presumably there is some bug in the nvidia driver (version 7.5.9.0), perhaps in conjunction with this version of DirectX (8.1) that is doing some auto-restore operation without telling us. There may also be some problem with using an older DirectX interface (currently DX3 for our DirectDraw operations and DX5 for d3d) on this version of the DirectX driver. It would be nice to know whether this occurs on other systems; so far I have only seen this problem on my laptop. One possible fix to the problem is to propagate surfaceloss errors throughout the system. Currently, we only force restoration of surfaces for which we detect a surface loss. But we can probably safely assume that if one surface has been lost, they have all been lost and we need to restore or recreate them all. This assumes that we will get at least one error on one of the surfaces; I don't know if that is a safe bet or if there is some auto-restore mechanism that might kick in before we do any rendering from/to any of our surfaces such that we would never get the hint that we need to restore content. We probably need a good test case that ensures that we only render before and after the alt-enter event in the DOS box to make sure that we at least get one error once we're active again. Note that this bug could potentially be related to bug 4731131; although this bug is not d3d-related, they are both coming from a potentially buggy directX driver for this hardware. ###@###.### 2002-08-23 With more investigation, this looks like it is intimately connected to bug 4731131. For example: - running with -Dsun.java2d.d3d=false avoids the problem - It is the first call into d3d after getting out of the fullscreen DOS box that causes the problems, or at least that is what it looks like. I have DirectX debug messages enabled and I see a whole slew of "surface restore" messages upon calling the first d3d BeginScene call. This must be the source of both our mystery restore and the d3d crash detailed in 4731131; direct3d is doing some restoration upon all surfaces that is not adequate and ends up with the dual problems of: crashing d3d commands on restored surfaces and leaving garbled contents on surfaces that were restored without our knowledge. Given this new information, I am closing this bug as a duplicate of 4731131 and will continue work on the problem in that context. ###@###.### 2002-08-23
23-08-2002