Bug ID: JDK-8089182 8.0-graphics-scrum-1527: up to 20% performance regression in Guimark2.Vector and Charts.Stock benchmarks on Win7-High

Type: Bug
Component: javafx
Sub-Component: graphics
Affected Version: 8,9

Priority: P3
Status: Closed
Resolution: Won't Fix

Submitted: 2013-08-20
Updated: 2024-04-25
Resolved: 2024-04-25

There are following regressions first appeared in 8.0-graphics-scrum-1527 and 8.0-controls-scrum-715.
 -21% (-6.03 fps) in Charts.Stock
 -17% (-7.86 fps) in GUIMark2.Vector


Unfortunately, there are no 8.0-graphics-scrum-152[3-6] and 8.0-controls-scrum-714 builds available
and both 8.0-graphics-scrum-1527 and 8.0-controls-scrum-715 contains merges with MASTER. So, it is not
quite obvious which scrum introduced the regression.

According to JPA profiles for Guimark2.Vector the time spent in 
com.sun.prism.impl.shape.NativePiscesRasterizer.produceStrokeAlphas and produceFillAlphas 
has been increased correspondingly. 

The issue is not visible on WinXP-mid-range, but I can reproduce it on Dell laptopn with Intel graphics.

Steps to reproduce the issue (please, run on Windows):
> cd JFX_WS/tests/performance/GUIMark2
> ant
> java -Djavafx.animation.fullspeed=true
       -cp "JFX_HOME/rt/lib/ext/jfxrt.jar:./dist/GUIMark2.jar:../FXBenchmark/dist/FXBenchmark.jar:../../../import/benchmarks-2.1.1/benchmarks-2.1.1.jar"
 jrockit.bm.Main guimark2.bm.VectorBenchmark -i 1 -wt 5 -tr 30

We do not plan to fix this. We no longer use the Pisces rasterizer as of JavaFX 11 (and it it was removed from JavaFX 16).
25-04-2024
Requesting deferral out of FX 8 given the above.
30-10-2013
Jim: can you do the testing with /Ox and see what we get? Depending on the results, we might want to enable that option for FX 8. Anything we need to do to measure the performance of fp:fast, and possibly to enable it after fixing whatever issues are preventing from working correctly, should be a Tweak...and not something I would want to sign up for for Lombard.
07-09-2013
To summarize the previous comment. fp:fast is apparently worth 20%. That is definitely an interesting issue to track. As to whether that should be classified as a "regression bug" vs. an "opportunity/tweak for performance gain" remains unanswered until we complete our investigation of the effects of /Ox and also until we at least make a reasonable effort to see if we can figure out how to embrace fp:fast without having a rendering bug. But, without further investigation, this information on the 20% performance differential remains of interest...
30-08-2013
I think the decision over whether to close this bug should be made based on "we can't recover the lost performance" or "we can recover it". Right now we only know that we had a rendering bug when using the pre RT-31870 flags. RT-31870 took an expedient approach to fixing that bug by changing the flags. If there is no way to fix it other than with the current set of flags then we really do have to give up on the 20% we lost. But... - We might be able to change Pisces to be compatible with fp:fast and regain the 20% without the bug. - Ox vs O2 might recover the 20% in which case this bug would be a dup of the bug where we adjust those flags (though it does beg the question, can we adjust Pisces so that /Ox with fp:fast gives us even more performance than we had before without the rendering bug so even this scenario doesn't make this a clear-cut case to close the bug) - A compiler bug in the fp:fast handling may have caused the bug in which case a future compiler might be able to get the 20% back with fp:fast without the rendering bug. "It's to be expected so we should close the bug" really requires more intimate knowledge of why the bug occurred in the first place than the amount of analysis that went into the fix for RT-31870. If restoring /Ox gets us back to pre-gradle performance, and adding fp:fast on top of that doesn't give any additional performance benefit once we are back to using /Ox then this bug could probably be closed. Until then, it is a reminder that fixing whatever problems we had with fp:fast might gain us some performance (which is worth at least a Tweak status).
30-08-2013
Kevin, I'm already going to verify the performance impact of -Ox vs -O2 on RT-32309, thus I think you are good to close this bug..
29-08-2013
DirtyArea benchmarks also show up to 11% performance regression in SW pipeline in build 1527 comparing to 1522.
21-08-2013
The flags changed when we moved to gradle builds. The RT-31870 fix only addressed the issues that were causing functionality regressions (rendering bugs). It removed the "offending" flags. But, it did not add back the other optimization flags that were used pre-gradle. In particular, Pisces used to use /Ox, but it has not used that since the gradle switchover.
20-08-2013
Note that if the fix for RT-31870 was responsible, then this issue should be closed as "Not an issue" since the regression is really just reverting to the performance we had when rendering was correct.
20-08-2013
I suspect that this was caused by the fix for RT-31870, which reverted an unintended change to the Windows compiler flags that happened as part of the gradle build switch. The additional flags were causing rendering artifacts, so needed to be removed.
20-08-2013
On WindowsXP-Mid-Range the regression is seen in WebNode.GUIMark2-Vector. -21% (-6.31 fps) in WebNode.GUIMark2-Vector
20-08-2013

Relates :	JDK-8090370 - Investigate impact of compiler flags on performance
Relates :	JDK-8118152 - error rendering Arc.setStroke