-
Enhancement
-
Resolution: Cannot Reproduce
-
P3
-
fx2.0
-
Windows XP
Increasing the size of empty (white) dummy window leads to significant performance drop.
The first time it was noted when
RT-11047 "If stage is set visible before scene is set, scene is not rendered until window is resized"
has been fixed.
Here is the difference between b1341 (the first build based on b15)
and b1343 (b15 + RT-11047 fix):
Blur2Circle: 35% (21.5 -> 13.9)
Blur10Circle: 9% (17 -> 15.5)
TallRectangle: 48% (57 -> 30)
WideRectangle: 49% (56 -> 28.5)
Note, the bug was fist fixed in b1359, then rollbacked in b1363 and
then finally fixed in b1375. So, this is why the performance got back in b1359,
dropped down in b1363 and then again got back in b1375.
See Aurora results for example for WideRectangle here:
http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-graphics-scrum-trend
According to Artem:
"it would be really, really strange if this fix was a source of performance regression:
the only changed thing is an additional notification from Window.setView(), that is
Stage.setScene(). Is setScene() called multiple times from the test? "
I did more experiments and if I run the test on my Windows laptop which has Intel card then I don't
see such big difference. Note, on my laptop I get much worse performance results.
- Intel Graphics Media Accelerator HD (Core i5), 256 mb
20.5 fps vs 15.5 fps
- Quadro FX 570, 256 mb (used in the lab)
57 fps vs 30 fps.
According to Performance Analyzer the time spent in
com.sun.prism.d3d.D3DContext.nSetRenderTarget(long, long) increased from
~0.02 to ~10.0. The results are gathered on fx-win-hi machine.
It would be nice to understand why larger size of the dummy window (it is static) lead to this.
Is it because something does not fit into VRAM or some buffers?
Filing this performance bug for further investigation as it could hide some more
performance issues.
The first time it was noted when
RT-11047 "If stage is set visible before scene is set, scene is not rendered until window is resized"
has been fixed.
Here is the difference between b1341 (the first build based on b15)
and b1343 (b15 + RT-11047 fix):
Blur2Circle: 35% (21.5 -> 13.9)
Blur10Circle: 9% (17 -> 15.5)
TallRectangle: 48% (57 -> 30)
WideRectangle: 49% (56 -> 28.5)
Note, the bug was fist fixed in b1359, then rollbacked in b1363 and
then finally fixed in b1375. So, this is why the performance got back in b1359,
dropped down in b1363 and then again got back in b1375.
See Aurora results for example for WideRectangle here:
http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-graphics-scrum-trend
According to Artem:
"it would be really, really strange if this fix was a source of performance regression:
the only changed thing is an additional notification from Window.setView(), that is
Stage.setScene(). Is setScene() called multiple times from the test? "
I did more experiments and if I run the test on my Windows laptop which has Intel card then I don't
see such big difference. Note, on my laptop I get much worse performance results.
- Intel Graphics Media Accelerator HD (Core i5), 256 mb
20.5 fps vs 15.5 fps
- Quadro FX 570, 256 mb (used in the lab)
57 fps vs 30 fps.
According to Performance Analyzer the time spent in
com.sun.prism.d3d.D3DContext.nSetRenderTarget(long, long) increased from
~0.02 to ~10.0. The results are gathered on fx-win-hi machine.
It would be nice to understand why larger size of the dummy window (it is static) lead to this.
Is it because something does not fit into VRAM or some buffers?
Filing this performance bug for further investigation as it could hide some more
performance issues.