JDK-8118822 : Regression: Background of controls becomes black after waking from sleep
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-09-24
  • Updated: 2015-06-17
  • Resolved: 2012-12-19
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.
JDK 8
8Fixed
Related Reports
Duplicate :  
JDK-8120465 - Black areas in the app after windows lock screen
Relates :  
JDK-8116851 - Some controls become black after screen lock or windowing environment change
Relates :  
JDK-8114867 - REGRESSION: JavaFX application starts to flicker on mouse move and actions after locking the screen
Description
Run program from attachment. Send your computer to sleep then wake up it. Background of tab pane will become black. This will work for every program. Some times you will need to move mouse over scene or controls before background turns to black.
Comments
SQE: verified in b104.
28-08-2013
(And yes, as reported above, I'm also seeing the flickering of the entire app. It happens with every app I tried. Jonathan also reproduced, so it is a good issue to file a bug on! I think it is a prism pipeline bug, just to make sure Region doesn't get guilt by association :-))
20-12-2012
Alexander, see Kevin's comment from Dec 19 above: This problem will now only reproduce on Windows XP and Windows Vista by default (or on a Windows 7 system that for some reason does not support D3D 9Ex). To reproduce it on Windows 7, run with the "-Dprism.disableD3D9Ex=true" system property.
20-12-2012
Richard, I've tried the fix using graphics scrum build 474. The original problems has gone however I observe nasty black flickering in UI on mouse movements and actions after I performed a screen lock.
20-12-2012
Filed RT-27121 to track it.
20-12-2012
Revision: 2032 Changeset: e96046ceeeca3d1c82808386dfec237db2c2f021 [e96046ceeeca] Parents: 2031 Author: Richard Bair <richard.bair@oracle.com> Date: December 19, 2012 2:49:29 PM PST Labels: tip Fix for RT-25178: Background of controls becomes black after waking from sleep Specifically this is a bug on windows due to images who's backing surface is lost (XP and Vista, or when D3DEx9 is disabled). The RegionImageCache takes care of making sure images are only returned for the right Screen, and that images who's surface is lost are thrown away. I also added PulseLogger instrumentation to know how often that happens, and how often we are creating new images and reusing images.
19-12-2012
Fix for the issue. I moved the fix from NGRegion into RegionImageCache, which also takes screens into account and better handles clearing the cache when a surface is lost. Also added performance tracker markers so we can see how well the cache is working for us.
19-12-2012
I don't see this exact issue on an un-patched 8 (with D3D9Ex disabled), but something similar. However using the patch provided above, I see no issues whatsoever. I'm going to push the patch and consider it fixed. There is still some question in my mind whether I need to be checking the "screen" associated with the graphics object and the image, but unless there is a test that shows it as being a problem, I'm not inclined to speculatively make the fix.
19-12-2012
See the comment I added to RT-25989. This problem will now only reproduce on Windows XP and Windows Vista by default (or on a Windows 7 system that for some reason does not support D3D 9Ex). To reproduce it on Windows 7, run with the "-Dprism.disableD3D9Ex=true" system property.
19-12-2012
I'm not seeing this. I'm seeing the messed up black rendering even though -Dprism.disableRegionCaching=true is set. In case you can still reproduce this issue, can you try the following patch and let me know if it resolves the issue? diff -r 90cdf27ba14e javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java --- a/javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java Tue Dec 18 19:25:38 2012 -0800 +++ b/javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java Tue Dec 18 22:09:29 2012 -0800 @@ -470,7 +470,7 @@ final boolean cache = backgroundCanBeCached && g.getTransformNoClone().isTranslateOrIdentity(); RTTexture cached = cache ? CACHE.getImage(null, textureWidth, textureHeight, background, shape) : null; // If there is not a cached texture already, then we need to render everything - if (cached == null) { + if (cached == null || cached.getNativeDestHandle() == 0L) { // We will here check to see if we CAN cache the region background. If not, then // we will render as normal. If we can cache it, however, then we will setup a // texture and swizzle rendering onto the RTTexture's graphics, and then at the @@ -609,7 +609,8 @@ g.getTransformNoClone().isTranslateOrIdentity(); RTTexture cached = cache ? CACHE.getImage(null, textureWidth, textureHeight, background) : null; // If there is not a cached texture already, then we need to render everything - if (cached == null) { + System.out.println("Richard's HACK IS WORKING"); + if (cached == null || cached.getNativeDestHandle() == 0L) { // We will here check to see if we CAN cache the region background. If not, then // we will render as normal. If we can cache it, however, then we will setup a // texture and swizzle rendering onto the RTTexture's graphics, and then at the @@ -736,6 +737,7 @@ // System.out.println("dstLeftX=" + dstLeftX + ", dstY1=" + dstY1 + ", dstRightX=" + dstRightX + ", dstY2=" + dstY2 + ", srcLeftX=" + srcLeftX + ", srcY1=" + srcY1 + ", srcRightX=" + srcRightX + ", srcY2=" + srcY2); // System.out.println("dstRightX=" + dstRightX + ", dstY1=" + dstY1 + ", dstX2=" + dstX2 + ", dstY2=" + dstY2 + ", srcRightX=" + srcRightX + ", srcY1=" + srcY1 + ", srcX2=" + srcX2 + ", srcY2=" + srcY2); + System.out.println("graphics screen=" + g.getAssociatedScreen() + ", img screen=" + cached.getAssociatedScreen()); // These assertions must hold, or rendering artifacts are highly likely to occur assert dstX1 != dstLeftX; assert dstLeftX != dstRightX;
19-12-2012
It's even enough to just do Ctrl-Alt-Delete and then back without actually locking computer or sending it to sleep for the black color to appear.
04-10-2012
It appears to be an error in the handling of lost surfaces, specifically for D3D.
24-09-2012
And it doesn't look like a dirty area issue, because the controls become black after the scene is rendered and remain black forever.
24-09-2012
This appears to be caused by the new region caching code. If I run with -Dprism.disableRegionCaching=true the bug does not occur. Assign to Richard to evaluate.
24-09-2012
Looks like rendering issue. I don't think there are any changes in Scenegraph after waking up. The problem is not reproducible with j2d pipeline.
24-09-2012