JDK-8123929 : All JavaFX apps stop rendering when coming out of screen lock
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-08-30
  • Updated: 2015-06-17
  • Resolved: 2013-09-23
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
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Duplicate :  
Relates :  
Relates :  
Description
Open Ensemble (any)

Press ctrl+alt+del,
Press esc.

Application doesn't respond.
Comments
No. Please file a new bug. You can reference the existing bugs.
22-04-2014

I've tried 8.0.20-ea-b10 and unfortunately the same bug occurs as with 8.0 GA (or 8.0.05). It's basically the same as described in this bug here or RT-34410 or RT-33028. RT-33028 maybe comes closest, because the bug is gone when you pass -Dprism.dirtyopts=false and RT-33028 specifically mentions dirtyopts. Should I reopen this one (it's not closed).
22-04-2014

-Dprism.dirtyopts=false solves the problem
22-04-2014

I can still reproduce with JavaFX 8 GA (8.0.0-b132): Put JavaFX App to background (i.e. have focus on another Window), then lock the screen, then return to screen, then bring JavaFX to front again (e.g. by clicking on the taskbar icon): Application is black. Note that the application does not need to be iconified in the taskbar as in RT-31272. Just in the background. Reopen?
22-04-2014

Ok, I will try with 8u20.
22-04-2014

No, as I said, it's not RT-31272. It's reproducible with screen lock.
22-04-2014

Christian, can you try your test case with 8u20-b10? If it is fixed, then nothing more needs to be done. If the problem still reproduces for you, then it is a different issue from RT-31272, in which case you should file a new JIRA.
22-04-2014

No, a bug that is marked as fixed and for which a changset has been pushed is never reopened. In this case you are running into something different, since screen lock bugs such as the one fixed by this JIRA are unaffected by dirtyopts on/off. What you describe might be RT-31272 which is already fixed in 8u20.
22-04-2014

Verified in Lombard b110
08-10-2013

Fixed as of: changeset: 5127:01b29e231a77 date: Wed Sep 18 14:32:58 2013 -0700 Approved by Kevin and Chien
23-09-2013

I tracked it down using "hg bisect", and this was caused by the fix fot RT-26612 The first bad revision is: changeset: 4753:971dc9e115c3 user: Thor Johannesson date: Tue Aug 20 16:05:01 2013 -0700 summary: RT-26612: D3D Implementation of MSAA, and depth buffer fix
30-08-2013

I verified that this worked in b104 and fails in b105.
30-08-2013

This is a serious regression that appears to have been introduced within the last week, but I will test b104 to be sure.
30-08-2013