JDK-8101330 : QuantumToolkit can schedule the pulse better to improve performance
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-05-20
  • Updated: 2015-06-16
  • Resolved: 2012-01-13
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.
Other
fx2.1Fixed
Related Reports
Blocks :  
JDK-8113170 - A simple animation is jerky
Blocks :  
JDK-8100864 - Quantum threading
Blocks :  
JDK-8100719 - align Pulse to VBlank time to enable smooth, stutter-free animations
Relates :  
JDK-8104684 - Animation stutters
Relates :  
JDK-8100622 - Allow QuantumRenderer thread and FX Application thread to run in parallel
Relates :  
JDK-8092246 - Delays in D3D Present affect performance
Relates :  
JDK-8113170 - A simple animation is jerky
Description
Currently, pulseRunnable is not posted to the event queue if the previous pulse hasn't yet been processed. That may lead to noticeable periods of idleness from the moment when the current pulse is finished and until a new pulse is scheduled when we run at a rate less that 60 fps in regular mode.
If instead a new pulseRunnable is posted unless there is already a pending pulse event, performance improves. F.e., GUIMark2.Bitmap-3000 benchmark on a local machine improves from 42 fps to 60 fps (hitting the limit, so the actual improvement is even bigger).
Comments
Fixed in p21-graphics with this change set changeset: 15283:4ce4d30ab43d user: Morris Meyer <morris.meyer@sun.com> date: Thu Jan 12 22:17:45 2012 -0500 summary: RT-13660 PaintCollectorBehavior v07 - reviewed by Kevin R, Oleg S, Oleg M, Ekaterina P, Artem A, Kirill P, Chien Y, Brent C and many others
13-01-2012
Performance results for build #236 are here: http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-experimental-gfxthread There are following functional issues discovered. 1) many benchmarks hanged because Platform.runLater is not called. This issue happened for most of DirtyArea benchmarks which are run in fullspeed mode. FXFire tests also failed because of this. However, the issue is not fullspeedmode specific only, at least following tests hanged as well: ColorfulShapes.Blur2Circle ColorfulShapes.Blur2Circle-Transparent Charts.ScatterLive The issue happened on WindowsXP-mid-range and Mac-Mid-Range machines. No such issue on Win7-High-End machines. Unfortunately I can't reproduce this issue through KVM. 2) bunch of benchamrks failed with java.lang.IllegalStateException: already painting at com.sun.javafx.tk.quantum.PrismPen.repaint(PrismPen.java:104) at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:133) at com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:311) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:443) at com.sun.javafx.tk.quantum.QuantumToolkit$8.run(QuantumToolkit.java:322) I see this issue on Mac-Mid-Range and WindowsXP-mid-range as well. I was able to reproduce it on my Mac quite easy (I run SpiralText benchamrk in 20 iterations and got exception after 10 iters). From performance perspective I see big regression in most of WebNode tests. Ex: -75% (-4.01 fps) in WebNode.ColorfulShapes-Blur2Circle -321% (917.75 ms) WebNode-SunSpider The regression exist on all platforms. Perhaps Oleg S. can look at this tomorrow to understand what is going on. Other performance benchmarks either show small improvements or the same results as for fx2.1-b05. However, due to functional issues (hang and IllegalStateException) I am not sure we can fully rely on current performance results.
19-12-2011
Sent third version of RT-18435 out for review: http://javaweb.sfbay.sun.com/~mameyer/webrevs/03/RT-18435 Regression that Jennifer found has been filed as RT-18497 and is unrelated to this work.
14-12-2011
The behavior change set (4th of 4) has been sent out for review: http://javaweb.us.oracle.com/~mameyer/webrevs/01/RT-13660-PaintCollectorBehavior
12-12-2011
Based on Kirill's comments - second version of RT-18435 sent out for review: http://javaweb.us.oracle.com/~mameyer/webrevs/02/RT-18435
12-12-2011
Sent out to review: http://javaweb.sfbay.sun.com/~mm51552/webrevs/01/RT-18435
09-12-2011
Kirill Prazdnikov identified a problem with the ResourceFactory.isDeviceReady check in AbstractPainter - RT-18450 - fixed with this push to p21-graphics. changeset: 15077:331e3e5e6d5e tag: tip user: Morris Meyer <morris.meyer@oracle.com> date: Fri Dec 09 11:34:08 2011 -0500 summary: RT-18450 needs per frame isDeviceReady check - fix from Kirill Prazdnikov
09-12-2011
Chien Yang identified a problem with JFXPanel in SwingInterop that is only on Windows - RT-18435 This is because dirty opts is only turned on on Windows and not on Mac. I have a fix identified and should have this out for review soon.
08-12-2011
RT-14815 pushed after Kirill Prazdnikov approval. changeset: 15075:c81218389ead tag: tip user: Morris Meyer <morris.meyer@oracle.com> date: Thu Dec 08 11:07:47 2011 -0500 summary: RT-14815 - ensure ResourceFactory creation on the QuantumRenderer thread
08-12-2011
Sent out to review: http://javaweb.sfbay.sun.com/~mm51552/webrevs/03/RT-14815/
08-12-2011
RT-18405 pushed into p21-graphics after Chien Yang approval
08-12-2011
The Application.setDeviceDetails needs to be run before Application.Run() in the Glass Mac and X11 cases. The ResourceFactory creation needs to have the Glass Application instance around to do the Screen.getScreens(), so it must be after Application.Run(). Sent out to review: http://javaweb.sfbay.sun.com/~mm51552/webrevs/02/RT-18415/
07-12-2011
Two regression issues found - RT-18405 and RT-18415 - and fixed. Sent out to webrev: http://javaweb.sfbay.sun.com/~mm51552/webrevs/01/RT-18405 http://javaweb.sfbay.sun.com/~mm51552/webrevs/01/RT-14815
07-12-2011
Third change set pushed to p21-graphics after Chien Yang approval. changeset: 15053:60c231ac5272 tag: tip user: Morris Meyer <morris.meyer@sun.com> date: Mon Dec 05 18:51:10 2011 -0500 summary: Partial RT-13660 - PaintRunnable refactoring - Chien Yang approved
05-12-2011
PaintRunnableRefactor webrev updated with Kirill's comments here - http://javaweb.sfbay.sun.com/~mm51552/webrevs/02/RT-13660-PaintRunnableRefactor
05-12-2011
Preliminary update to the JavaFX Threading Architecture wiki under "Threading Architecture - Pulse Hinting" here http://wiki.se.oracle.com/display/JPGC/JavaFX+Threading+Architecture
05-12-2011
The first three sets will be pushed into p21-graphics and shouldn't cause any performance regressions. The fourth set will be tested in the gfx-threading sandbox in conjunction with the review.
05-12-2011
This bug has been broken out into four sets of changes, three refactoring and one behavioral. The first two of these changes have been pushed into the graphics scrum changeset: 15044:4da61ee247c1 user: Morris Meyer <morris.meyer@oracle.com> date: Fri Dec 02 16:23:46 2011 -0500 summary: Partial RT-13660 - Presentable refactoring into prepare() / present() changeset: 15048:e09da2838803 user: Morris Meyer <morris.meyer@oracle.com> date: Sat Dec 03 18:03:44 2011 -0500 summary: Partial RT-13660 - refactor and renaming changeset: 15047:105e576ae0da user: Morris Meyer <morris.meyer@oracle.com> date: Fri Dec 02 23:02:03 2011 -0500 summary: Partial RT-13660 - PaintRunnable NPE on Mac The third set of changes which is the PaintRunnable refactoring was sent out to review Sunday night. http://javaweb.sfbay.sun.com/~mm51552/webrevs/01/RT-13660-PaintRunnableRefactor The fourth set of changes are behavioral (reordering embedded and uploading painters prior to blocking presenting painters, and the vsync pulse hint). This change set is already in the gfx-threading sandbox and will be put out to review Monday evening
05-12-2011
can u pls update the bug with the doc u are working on and the latest status?
05-12-2011
Shooting for a web rev mid sprint17 Monday Nov 21 - for one week of testing and hopeful check-in at end sprint17 Mon Nov 28
16-11-2011
What does "sprint16/17" mean? What are the associated dates?
16-11-2011
Development in sprint16 and performance analysis and testing for sprint17
01-11-2011
SQE - OK to defer It is too late to fix it for Presidio but this one has several related issues filed by external people so this is a visible issue. If there is anything we can recommend to workaround it we need to release note this.
23-08-2011
OK to defer.
23-08-2011
Too late for Presidio. The fix turn out to be very risky and still needs few more days to finish it. We ave decided to work on this for the next release. Please target it to Lombard.
19-08-2011
The event queue can't grow as at any time there can be one pulseRunnable being processed and one pending pulseRunnable at most. The unresponsiveness issue is presumably due to RT-12675, which needs to be fixed.
20-05-2011
As far as I understand, the suggested changes changes for heavy scene with heavy painting may cause event queue growing and make an application unresponsive to input events.
20-05-2011