Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8076529
This webrev contains the changes accumulated in the Graphics-Rasterizer
project forest that add the Marlin AA renderer to the JDK and make it
the default AA RenderingEngine for Java2D.
The webrev also includes a link to an HTML output of J2DAnalyzer showing
the relative performance on a few basic rendering tests for Ductus,
Marlin, and Pisces.
This change does not introduce any new API, but it does introduce a new
debugging property to see which RenderingEngine is in use.
Java2D already supported selecting a RenderingEngine on the fly using:
-Dsun.java2d.renderer=<classname>
The default is now set to Marlin.
You may now also see which RenderingEngine is in use by using (new with
this patch):
-Dsun.java2d.renderer.verbose=true
The default rendering engine used to be Pisces for OpenJDK and Ductus
for Oracle's products, but the new default will be the new Marlin
renderer for all builds. Pisces is still built and included in OpenJDK
builds and both Pisces and Ductus are still built and included in Oracle
builds, but the user must select those RenderingEngine implementations
on the command line to use them. The alternate engines may be
deprecated and removed over time.
Marlin already outperforms Pisces in every category by a wide margin
(except for a few basic tests where it has roughly the same performance
to within a margin of error, and roughly the same as Ductus as well). In
addition, Marlin just recently reached a level of performance comparable
to Ductus in single-threaded benchmarks. But, where Marlin shines is in
multi-threaded performance where Ductus had nearly 0% scalability (and
on some benchmarks would often take more than N times longer to render
something with N threads) due to a required java-level synchronized
access to the unprotected singleton native data structures. Marlin's
scalability is very high - in the 90% range. In MT tests with N threads
(N < #cores) Marlin can be about N times faster or more than Ductus
which is a huge win for server-side use.
In terms of accuracy, a quick test of comparing the AA renderers output
to a simple Super-Scalar renderer (render an object at 2^N x 2^N scale
and then use a series of N linear interpolation steps to cut the
resolution back to normal size) using 8x8 oversampling shows that Marlin
is, on average, about twice as accurate as Ductus, and close to 2.5 to 3
times more accurate than Pisces.
Here is the text summary from analyzing the J2DBench results included in
the webrev above. Note that Pisces is only 40-100% the performance of
Ductus (at best it achieves parity), whereas Marlin is 92-220% the
performance as Ductus (from near parity to over twice as fast):
Summary:
Ductus Renderer on Mac:
Number of tests: 14
Overall average: 271435.684621936
Best spread: 0.25% variance
Worst spread: 0.81% variance
(Basis for results comparison)
Marlin Renderer on Mac:
Number of tests: 14
Overall average: 278609.9151360187
Best spread: 0.24% variance
Worst spread: 0.94% variance
Comparison to basis:
Best result: 219.63% of basis
Worst result: 91.71% of basis
Number of wins: 5
Number of ties: 5
Number of losses: 4
Pisces Renderer on Mac:
Number of tests: 14
Overall average: 264688.87069247436
Best spread: 0.12% variance
Worst spread: 9.28% variance
Comparison to basis:
Best result: 101.71% of basis
Worst result: 40.04% of basis
Number of wins: 0
Number of ties: 6
Number of losses: 8
For multi-threaded performance, we are still modifying J2DBench to do MT
testing, but meanwhile here are some sample results from a
micro-mt-benchmark that I was using to measure Marlin's benefit over
Ductus, all tests run on my quad-core retina MacBook Pro:
RenderingEngine = sun.dc.DuctusRenderingEngine@2ea524fc
Results for 4 threads:
Filling Big Circle took 20000.7ms for 17513 ops = 1.1420479872666018ms/op
Stroking Big Circle took 20001.6ms for 12744 ops = 1.5694947735404898ms/op
Filling Small Circle took 20000.0ms for 650166 ops =
0.030761436459304237ms/op
Stroking Small Circle took 20000.2ms for 563230 ops =
0.03550988808657209ms/op
Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops =
3.1412907711997486ms/op
Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops =
4.958922349529003ms/op
Filling Big Even-Odd Polygon took 20046.0ms for 413 ops =
48.53754647457627ms/op
Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops =
120.74043964670658ms/op
RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine@3550b8ec
Results for 4 threads:
Filling Big Circle took 20000.4ms for 93097 ops = 0.2148343392483109ms/op
Stroking Big Circle took 20000.3ms for 74332 ops = 0.2690665217672066ms/op
Filling Small Circle took 20000.0ms for 3999239 ops =
0.0050009547403893585ms/op
Stroking Small Circle took 20000.0ms for 1692821 ops =
0.011814607555081133ms/op
Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops =
0.6346507143582422ms/op
Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops =
0.9029244853737812ms/op
Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops =
13.599594945652175ms/op
Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops =
34.748233308492196ms/op
RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine@2ea524fc
Results for 4 threads:
Filling Big Circle took 20000.7ms for 52844 ops = 0.37848658839224886ms/op
Stroking Big Circle took 20001.1ms for 39741 ops = 0.5032854199944641ms/op
Filling Small Circle took 20000.0ms for 1628357 ops =
0.012282338621076336ms/op
Stroking Small Circle took 20000.1ms for 809256 ops =
0.024714137085174535ms/op
Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops =
1.3557410718449234ms/op
Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops =
2.042433472582457ms/op
Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops =
17.572960124561405ms/op
Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops =
59.509273902077155ms/op
...jim
