JDK-8116718 : Dirty region optimization (dirtyopts) is not MT-safe
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-08-14
  • Updated: 2015-06-17
  • Resolved: 2012-08-24
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 :  
Relates :  
Description
This bug was largely masked by RT-24070, since it most easily reproduces with transparent stages.

The easiest way to reproduce this is to apply the following patch to Ensemble to enable using a transparent stage:

diff --git a/ga-samples/Ensemble/src/ensemble/Ensemble2.java b/ga-samples/Ensemb
le/src/ensemble/Ensemble2.java
--- a/ga-samples/Ensemble/src/ensemble/Ensemble2.java
+++ b/ga-samples/Ensemble/src/ensemble/Ensemble2.java
@@ -135,7 +135,7 @@
             isApplet = false;
         }
         if (!isApplet) {
-            stage.initStyle(StageStyle.UNDECORATED);
+            stage.initStyle(StageStyle.TRANSPARENT);
             // create window resize button
             windowResizeButton = new WindowResizeButton(stage, 1020,700);
             // create root

-----------------------------------------

Then run Ensemble and play around with the Animation "Interpolator" sample. It will sometimes stop animating when the mouse is over the thumbnail. The actual sample will also sometimes stop animating when you click on the sample and run it (it's a timing problem so doesn't always show up). If you run it with -Dprism.showdirty=true then you can see the dirty regions being drawn incorrectly. If you turn off multi-threading with -Dquantum.multithreaded=false then it runs fine.

Note that this bug can also be reproduced on Linux with the unmodified PathAnimation sample. It comes up with a black window on startup.
Comments
Fixed UploadingPainter. Changeset 2387ee02cff2.
24-08-2012

You can go ahead and push the change if you like. Please add the changeset as a comment when you do. Then go ahead and resolved it as "Fixed". I'll test and reopen if I see a problem. Thank you.
24-08-2012

I wasn't able to reproduce the issue with presenting painter (using PathAnimation demo) and I verified that locking renderLock in UploadingPainter fixes the issue in Ensemble. Can I close this issue or do you want to take it?
24-08-2012

This is definitely a bug and would explain why the problem is much worse when using the UploadingPainter. In fact, I am surprised we aren't seeing all sorts of problems when using UploadingPainter.
24-08-2012

I see that in UploadingPainter, the renderLock is aquired only if prism.threadcheck is set to true. Is there a reason why we don't acquire renderLock in UploadingPainter while we do it in PresentingPainter? As the renderLock is used during the synchronization (Scene calls impl_peer.waitForSynchronization(), which uses renderLock), it seems like the problem is that rendering might be happening in parallel with the synchronization, so the render graph might be in some strange middle-state while computing dirty regions, or might change between dirty region computation and rendering. I think this might also cause other issues outside of dirty regions, like rendering might happen in some sort of state where bounds don't match Node's properties, etc...
24-08-2012