JDK-8118353 : Animation or scrolling causes bad flickering on j2d pipeline with multithreading enabled
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-08-08
  • Updated: 2015-06-17
  • Resolved: 2012-08-14
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 :  
JDK-8101801 - Multi-Core scalability
Blocks :  
JDK-8116670 - Sometimes scene filled with solid color on Ubuntu with -Dquantum.multithreaded=true
Relates :  
JDK-8120656 - NPE in glass using J2DPipeline
Relates :  
JDK-8116718 - Dirty region optimization (dirtyopts) is not MT-safe
Relates :  
JDK-8096749 - OutOfMemoryError with FadeTransition under certain circumstances
Relates :  
JDK-8100622 - Allow QuantumRenderer thread and FX Application thread to run in parallel
Description
Run Ensemble with -Dprism.order=j2d and try to scroll the pane with sample buttons. You will see flickering as-if every second frame was completely white. I was also able to reproduce it on HelloListView/HelloTableView, but the flickering is harder to spot there, as the application has higher fps than Ensemble.

I wasn't able to reproduce it with es2 pipeline.

I've also tried it with -Dprism.occlusion.culling=false and also with -Dprism.dirtyopts=false to check if recent changes to culling are the cause of this issue, but it's still reproducible even with these optimizations turned off.
Comments
SQE: verified in b104.
30-08-2013
There is no unit test, since it only affects the final rendered pixels that are sent to glass from prism. The fix can be verified by running Ensemble on the j2d and sw pipelines, and by running a modified version of Ensemble (to enable transparent windows) on d3d, es2, j2d, and sw pipelines.
14-08-2012
Note that this issue was actually discussed during the code review of RT-22438. At one point during the review of that fix, I wrote the following: > This would help, but wouldn't solve the underlying MT issue. Probably OK for 2.2, but we would need a new issue filed for 3.0. Filing the new issue got lost in the shuffle (until Martin discovered it when we enabled multi-threading).
09-08-2012
The main part of the fix is the following in J2DPresentable.present: @@ -83,10 +85,15 @@ * TODO: make sure the imgrep matches the Pixels.getNativeFormat() * TODO: dirty region support */ + int w = getPhysicalWidth(); + int h = getPhysicalHeight(); if (pixels == null) { - pixels = app.createPixels(getPhysicalWidth(), getPhysicalHeight(), ib); + pixBuf = IntBuffer.allocate(w*h); + pixels = Application.GetApplication().createPixels(w, h, pixBuf); } - return (pixels != null); + assert ib.hasArray(); + System.arraycopy(ib.array(), 0, pixBuf.array(), 0, w*h); + return true; } else { return (false); }
09-08-2012
PresentingPainter is used for the prism-j2d and prism-sw pipelines. So while UploadingPainter almost certainly has the same bug (I haven't verified it, but code inspection shows that it is also wrong), this particular bug is in the prepare / present methods of the J2DPresentable and SWPresentable classes. The present method of these two classes calls the glass uploadPixels method by scheduling a runnable to run on the FX Application thread (since this call to glass must be done on that thread). The bug is that the pixel data buffer is passed to uploadPixels method by reference, but there is no guarantee that the uploadPixels will be processed before the rendering for the next frame is started. This means that the rendering of the next frame could be done concurrently with the uploading of what should be the pixels from the previous frame. Since they both use a reference to the same IntBuffer, changes done by the rendering thread for the next frame will affect the data that is uploaded for the current frame. Given this design, we must copy the data into a separate pixelData buffer in the prepare method of J2DPipeline and SWPipeline. Note that we can't double-buffer the pixel data for the J2D or SW surface because we need a stable back buffer for dirty opts. A similar fix will likely be needed for UploadingPainter.
09-08-2012
The prism-sw pipeline has the same issue, suggesting that the bug may be in UploadingPainter.
08-08-2012
Also very noticable with PathAnimation on the beagle with directfb/pisces A flashing white box around the car.
08-08-2012
The bug seems worse on Linux. Also, on Linux this is reproducible with PathAnimation (from apps/internal).
08-08-2012
I can reproduce this on my system. This looks like an MT issue. If I run with "-Dquantum.multithreaded=false" then it works fine.
08-08-2012
No, I've tried Linux and then Pavel tried it on Windows.
08-08-2012
What platform were you running it on? Is it platform-specific?
08-08-2012