JDK-4664818 : Images disappear in SwingSet2 (win32) after fullscreen switch
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2002-04-09
  • Updated: 2002-06-27
  • Resolved: 2002-06-27
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 Availabitlity Release.

To download the current JDK release, click here.
1.4.1 rcFixed
Related Reports
Duplicate :  
Duplicate :  
When running SwingSet2 on various flavors of Windows, certain images
disappear after making another application (such as the command line tool)
go into fullscreen mode.  These images will alternately disappear and reappear
with each successive switch into fullscreen mode.  The images will reappear
correctly if another window is dragged over SwingSet2.

Note that this behavior is not reproducible if DirectDraw acceleration is
disabled using the -Dsun.java2d.noddraw=true property.

To reproduce, make command line tool go fullscreen and back to
window (or hit ctrl-alt-del to bring up the Task Manager) while
SwingSet2 is running.  The SwingSet2 will be repainted improperly:
certain images will be missing (especially the toolbar icons at top).
Drag a window over the SwingSet2 frame and it will repaint ok.

###@###.### 2002-06-14

Another CAP member reports the same problem, their app displays quite a 
few icons(attached 3 icon files), but it is only one that has the problem, 
and it only happens once at the beginning.  After an initial exposure event,
such as dragging a window over the button, or even pressing a button, it 
shows up no problem.

Also if add -Dsun.java2d.noddraw=true VM parameter and there is no problem 
with image. If clear the VM parameter problem shows up again.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc

SUGGESTED FIX Increase the number of attempts to complete rendering operation from, ahem.. 0 to 1. *** /tmp/geta25888 Thu Jun 20 14:53:02 2002 --- DrawImage.java Thu Jun 20 14:44:49 2002 *************** *** 399,405 **** // revalidate the source or dest surfaceData objects. ++attempts; sData = sData.getReplacement(); ! if (sg.surfaceData == null || sData == null || (attempts >= 1)) { return; } } --- 399,405 ---- // revalidate the source or dest surfaceData objects. ++attempts; sData = sData.getReplacement(); ! if (sg.surfaceData == null || sData == null || (attempts > 1)) { return; } } ###@###.### 2002-06-20

EVALUATION Need to fix for mantis. ###@###.### 2002-06-12 The problem was that after copying the backup copy to the accelerated surface we didn't copy the accelerated copy to the screen. In DrawImage.renderSurfaceData, we attempt to render the surface to the screen. Since the accelerated surface has lost its contents due to some event (ie display mode change), blitSurfaceData throws InvalidPipeException, which caught in renderSurfaceData. It then gets the replacement for the surface and attempts to render the surface to the destination again. That was the idea, anyway. Unfortunately, due to a mistake in checking the number of attempts we tried to render, we never actually attempted to copy the new surface to the destination after we got the replacement surface: attempts = 0; while (true) { try { // try to render catch (InvalidePipeException) { ++attempts; sData = sData.getReplacement(); if (sg.surfaceData == null || sData == null || (attempts >= 1)) { // note we go straight here since attempts is 1 the first time around return; } } } ###@###.### 2002-06-20

WORK AROUND Run SwingSet2 with the -Dsun.java2d.noddraw=true system property. ============== You can also use -Dsun.java2d.ddoffscreen=false as its impact on performance is not as bad as the 'noddraw' option. ###@###.### 2002-05-28