JDK-8100622 : Allow QuantumRenderer thread and FX Application thread to run in parallel
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-07-20
  • Updated: 2015-06-16
  • Resolved: 2012-08-02
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-8113204 - Full screen overlay warning needs to be MT safe
Blocks :  
JDK-8101324 - Run app-thread and render thread in parallel
Blocks :  
JDK-8117514 - Canvas: PGUpdate: Syncing Buffer not MT safe
Blocks :  
JDK-8112747 - Render tree is modified during Text bounds calculation
Duplicate :  
JDK-8101324 - Run app-thread and render thread in parallel
Duplicate :  
JDK-8092246 - Delays in D3D Present affect performance
Relates :  
JDK-8101330 - QuantumToolkit can schedule the pulse better to improve performance
Relates :  
JDK-8088153 - If a Region refers to a transformed Shape, updates to the transforms are not correctly passed to the rendering layer
Relates :  
JDK-8092246 - Delays in D3D Present affect performance
Relates :  
JDK-8091129 - Simple animation runs at lower FPS when embedded into JFXPanel
Relates :  
JDK-8118353 - Animation or scrolling causes bad flickering on j2d pipeline with multithreading enabled
Description
Once all MT issues in the scene graph have been resolved, we should enable running the QuantumRendererThread and the FX Application thread in parallel. The attached info.txt file helps illustrate the parallelism that could be achieved.
Comments
I see, that Ekaterina Pavlova has compared measurements. So, close this issue as verified.
30-12-2013
There remain some multi-threading related issues, but it is now fully delivered and enabled by default, so this issue is resolved!
02-08-2012
changeset: 16471:2fba49dd0663 tag: tip user: rbair date: Wed Aug 01 20:45:43 2012 -0700 summary: Enable multi-threading by default. Added printout of whether multithreading is enabled or disabled. Use -Dquantum.verbose=true to print out the state of multithreading, and -Dquantum.multithreaded to enable / disable multithreading. It is enabled by default.
02-08-2012
Partial Fix: http://jfxsrc.us.oracle.com/javafx/3.0/scrum/graphics/rt/rev/0098446429d9 http://jfxsrc.us.oracle.com/javafx/3.0/scrum/graphics/rt-closed/rev/7997e8fe9a27 All of the work for enabling multithreading (ie: updating PaintCollector, etc) is contained in this patch. However there are several outstanding issues, so while they are outstanding multithreading is disabled by default and must be enabled by setting -Dquantum.multithreading=true.
01-08-2012
Attached latest webrevs. This fixes a reported problem when an app on Windows is running when the system goes to sleep, and then wakes (threw an assertion error). Also disables multithreading by default, but allows it to be switched on with -Dquantum.multithreading=true. This command line switch will be removed prior to 3.0 shipping, but will remain around for a while until we are confident we've shaken out all the issues, as it will be valuable for disabling multithreading when doing some debugging. Note that we will switch it to be enabled by default in the near future.
01-08-2012
I have updated the patch and tested on Windows and Mac. We were encountering various deadlocks on windows with the previous patches. Thanks to Morris for preparing those previous web-revs. I hadn't tested them on Windows before and I had made some errors in those previous versions. Class Count Reduction -------------------------------------- I noticed this time that GlassViewEventHandler, QuantumToolkit, and PaintCollector all declared their own private "verbose" flag, and used an anonymous inner class to read this value. I am bothered by having such booleans spread around in the code, and wanted to consolidate them. So I moved the verbose flag to QuantumToolkit, used a GetBooleanAction to cut down on class count, and made it public for use within the implementation. That removed 3 anonymous classes from the platform and 3 separate loads (which will help startup). I also moved the pulseDebug flag to QuantumToolkit. Even though it is only used (at the moment) by PaintCollector, I wanted to have all such flag reading in one place, much like Prism does. When Glass / Prism / FX are all taught to know about each other, perhaps we can have a single file where all command line properties are read from, rather than having multiple as it is today. This would help when we need to do things like switch to using GetXXXAction classes rather than anonymous classes or whatnot. I also made a couple other usages in QuantumToolkit to use GetXXXAction classes. Removed Unneeded Method Calls ----------------------------------------------------- I found that there are some instances where we are calling twice into PaintCollector for a single scene to indicate that it is finished rendering. PresentingPainter and UploadingPainter both use the CompletionListener in all cases. However they also would call collector.releaseScene in the case of liveRepaint.get() == false (ie: not live repaint). But this was unnecessary in this new implementation, so the entire releaseScene method was removed. Tightened Up ---------------------- I tightened up a few things in this patch. PrismPen has a reference which could be made final. QuantumRenderer's checkRendererIdle could be simplified and didn't need to cal the PaintCollector's isReleased, and a couple methods in ViewScene were never called. PaintCollector ---------------------------- The PaintCollector is of course where all the bulk of the changes occurred. The PaintCollector is pretty straightforward -- there are methods for adding a scene to a dirtyScene list, such that on the next renderAll that scene will be rendered. There is a renderAll method which will cause all dirty scenes to be rendered. And there is a completion listener which is called when each scene is completed. We have a synchronization aid (CountDownLatch allWorkCompletedLatch) which is initialized in renderAll to the number of scenes that need to be processed. It is decremented when each scene completes. renderAll blocks on allWorkCompletedLatch.await so that it will not issue a new batch of render jobs to scenes until the pending scenes have all completed. PaintCollector was made to implement CompletionListener just to cut down an extra class. Fields were made volatile as necessary and everything documented with respect to which thread calls which methods, with assertion checks for completeness.
31-07-2012
Uploaded webrev's for this issue
31-07-2012
WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/01/RT-15195-closed WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/01/RT-15195-open
25-07-2012
This cannot be implemented until dependent issue RT-13735 is implemented. That issue is scheduled for Lombard. If we are able to pull RT-13735 into a Presidio Updates release then this issue can be targeted earlier.
14-01-2012
The FX application thread and the QuantumRenderer thread are running in parallel now for part of the application pulse. On Windows using the prism-d3d pipeline the PresentingPainter releases the application thread early and allows the renderer to finish presenting the frame. The pulse finishes after the present is done, which guards against another pulse being run. In WindowStage.setVisible we guard against removing a window while the present is still occurring by grabbing the AbstractPainter.renderLock, which is held across the duration of the render operation.
13-01-2012
We should link this issue to MT issues that it depends on.
20-07-2011