JDK-7123951 : D3DScreenUpdateManager returns invalid surface data as a replacement.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: generic
  • Submitted: 2011-12-22
  • Updated: 2018-09-05
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 Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
If d3d acceleration  is disabled for some reasons (XOR composite for example) then
D3DScreenUpdateManager returns invalid instance of D3D surface data as a replacement.
Note that method getReplacementScreenSurface() does not check whether a surface data
instance cached in corresponding component peer is valid, and it does not check whether the cached surface data instance corresponds to current acceleration settings.

Comments
We are fixing issues on priority starting with issues reported on 9 and 8u builds. All other issues reported on older jdk versions are marked with tbd_major for now.
25-05-2016

Not a regression in 8u/9
12-02-2016

Does it affect JDK 9 ?
22-07-2015

EVALUATION From Andrew: Regarding the XOR problem, a solution could be make getReplacementScreenSurface() method aware on the fact that acceleration prohibited. Now it always returns the same surface data instance retrieved from corresponding peer, even if it is invalid. Instead, we can return GDI replacement if peer surface data is invalid, and acceleration is disabled. Attached patch illustrates this approach.
22-12-2011

EVALUATION getReplacementScreenSurface() should check whether a surface data instance retrieved from corresponding window peer is valid. If not, the surface data should be re-created according to current acceleration settings.
22-12-2011

SUGGESTED FIX --- a/src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java Thu Dec 15 15:55:53 2011 -0800 +++ b/src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java Thu Dec 22 16:47:00 2011 +0400 @@ -36,7 +36,6 @@ import java.security.PrivilegedAction; import java.util.ArrayList; import java.util.HashMap; -import sun.awt.SunToolkit; import sun.awt.AWTAccessor; import sun.awt.Win32GraphicsConfig; import sun.awt.windows.WComponentPeer; @@ -325,9 +324,23 @@ SurfaceData sd) { SurfaceData newSurface = super.getReplacementScreenSurface(peer, sd); + if (!newSurface.isValid()) { + java.awt.GraphicsConfiguration gc = peer.getGraphicsConfiguration( ); + if (gc instanceof Win32GraphicsConfig) { + Win32GraphicsConfig wgc = (Win32GraphicsConfig)gc; + + if (newSurface instanceof D3DWindowSurfaceData && + !canUseD3DOnScreen(peer, wgc, 0)) + { + newSurface = this.getGdiSurface((D3DWindowSurfaceData)newSurface); + } else { + newSurface = this.createScreenSurface(wgc, peer, 0, false); + } + } + } // if some outstanding graphics context wants to get a replacement we // need to make sure that the new surface (if it is accelerated) is - // being tracked + // being tracked trackScreenSurface(newSurface); return newSurface; }
22-12-2011