DirtyArea test shows different performance results for equivalent dirty regions.
Here are the numbers for fx2.0-b30 running with fullspeed=true on Dell e6410.

(a) (b) (c)
Xddd dddd dddd
dddd dXdd dddd
dddd dddd dddd
dddd dddd dddX

where:
 d - dirty area
 X - dirty area where nodes are moving

(a) top-left area
  > java -cp "..." dirtyarea.DirtyAreaTest -columns 4 -rows 4 -type type05 -space 0.8 -innermove true -areasmove 0
  154 fps


(b) middle area
  > java -cp "..." dirtyarea.DirtyAreaTest -columns 4 -rows 4 -type type05 -space 0.8 -innermove true -areasmove 5
  132 fps


(c) bottom-right area
  > java -cp "..." dirtyarea.DirtyAreaTest -columns 4 -rows 4 -type type05 -space 0.8 -innermove true -areasmove 15
  175 fps


I am getting similar difference with graphics-scrum build 2108, which contains fullspeed fixes.


I also did run the test with other types of shapes and in particular with only
rectangles (type06) and only circles (type 02). Note, type05 draws both circles
and rectangles, so the number of shapes is in twice bigger in case of type05.
JavaPerformanceAanalyzer profiles show that the main difference is coming from
BaseRoundRectRep.fill,draw and BaseEllipseRep.fill,draw

Here are the results:

type05: circle + rectangle

                        | middle | bottom-right
--------------------------------------------------
+NGShape.renderContent | 30.754 sec | 26.483 sec
 -BaseEllipseRep.draw | 9.320 sec | 6.018 sec
 -BaseEllipseRep.fill | 9.796 sec | 5.535 sec
 -BaseRoundRectRep.draw | 5.921 sec | 9.964 sec
 -BaseRoundRectRep.fill | 5.519 sec | 4.868 sec
                    fps | 132 | 172


type02: only circles (the number of shapes is in twice less than in case of type05 => fps is bigger)

                        | middle | bottom-right
--------------------------------------------------
+NGShape.renderContent | 17.209 sec | 12.323 sec
 -BaseEllipseRep.draw | 8.466 sec | 5.743 sec
 -BaseEllipseRep.fill | 8.646 sec | 6.471 sec
                  fps | 220 | 290


type06: only rectangles (the number of shapes is in twice less than in case of type05 => fps is bigger)

                        | middle bottom-right
--------------------------------------------------
+NGShape.renderContent | 13.637 sec | 10.505 sec
 -BaseRoundRectRep.draw | 4.953 sec | 5.285 sec
 -BaseRoundRectRep.fill | 8.601 sec | 5.136 sec
                    fps | 267 | 345


 Looking at BaseRoundRectRep.fill profile shows the following:
[middle]
 +- 13.637 (13%) com.sun.javafx.sg.prism.NGShape.renderContent(com.sun.prism.Graphics)
 | +- 8.601 (8%) com.sun.prism.impl.shape.BasicRoundRectRep.fill(com.sun.prism.Graphics, com.sun.javafx.geom.Shape)
 | | +- 8.593 (8%) com.sun.prism.impl.shape.BasicRoundRectRep.fillRoundRect(com.sun.prism.Graphics, com.sun.javafx.geom.RoundRectangle2D)
 | | +- 4.776 (4%) com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(float, float, float, float)
 | | +- 3.727 (3%) com.sun.prism.impl.ps.BaseShaderGraphics.fillQuad(float, float, float, float)
 | | | +- 3.642 (3%) com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(com.sun.prism.impl.ps.BaseShaderGraphics, com.sun.javafx.geom.transform
 | | | | +- 3.640 (3%) com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(com.sun.prism.impl.ps.BaseShaderGraphics, com.sun.javafx.geom.transf
 | | | | +- 3.606 (3%) com.sun.prism.impl.ps.BaseShaderContext.checkState(com.sun.prism.impl.ps.BaseShaderGraphics, com.sun.javafx.geom.transform
 | | | | | +- 3.522 (3%) com.sun.prism.impl.BaseContext.flushVertexBuffer()
 | | | | | | +- 3.522 (3%) com.sun.prism.impl.VertexBuffer.flush()
 | | | | | | +- 3.520 (3%) com.sun.prism.d3d.D3DVertexBuffer.flush(int)
 | | | | | | +- 3.518 (3%) com.sun.prism.d3d.D3DVertexBuffer.nFlush(long, java.nio.Buffer, int)
 | | | | | | +- 3.513 (3%) Java_com_sun_prism_d3d_D3DVertexBuffer_nFlush


[bottom-right]
| +- 5.136 (5%) com.sun.prism.impl.shape.BasicRoundRectRep.fill(com.sun.prism.Graphics, com.sun.javafx.geom.Shape)
 | | +- 5.130 (5%) com.sun.prism.impl.shape.BasicRoundRectRep.fillRoundRect(com.sun.prism.Graphics, com.sun.javafx.geom.RoundRectangle2D)
 | | +- 4.924 (5%) com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(float, float, float, float)
 | | +- 0.140 (0%) com.sun.prism.impl.ps.BaseShaderGraphics.fillQuad(float, float, float, float)
 | | | +- 0.129 (0%) com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(com.sun.prism.impl.ps.BaseShaderGraphics, com.sun.javafx.geom.transform
 | | | | +- 0.129 (0%) com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(com.sun.prism.impl.ps.BaseShaderGraphics, com.sun.javafx.geom.transf
 | | | | +- 0.125 (0%) com.sun.prism.impl.ps.BaseShaderContext.checkState(com.sun.prism.impl.ps.BaseShaderGraphics, com.sun.javafx.geom.transform
 | | | | | +- 0.115 (0%) com.sun.prism.impl.BaseContext.flushVertexBuffer()
 | | | | | | +- 0.115 (0%) com.sun.prism.impl.VertexBuffer.flush()
 | | | | | | +- 0.115 (0%) com.sun.prism.d3d.D3DVertexBuffer.flush(int)
 | | | | | | +- 0.113 (0%) com.sun.prism.d3d.D3DVertexBuffer.nFlush(long, java.nio.Buffer, int)
 | | | | | | +- 0.111 (0%) Java_com_sun_prism_d3d_D3DVertexBuffer_nFlush



Why com.sun.prism.impl.BaseContext.flushVertexBuffer() takes different time in case of different dirty area
locations? Could it be that depending on dirty area location we actually render different number of shapes/regions?