Hi Laurent,
I am going to move forward with intent to get this version 4.2 into the
client repos as the version we will go into Feature Complete milestone
with. Let me know if there is a more recent version I should be looking at.
I'm about to do some test builds and check performance and run any tests
I have in my personal testing repos on it...
...jim
On 10/19/2015 7:06 AM, Laurent Bourgès wrote:
Hi Jim,
Here is the new webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.2/
I added the OffHeapArray class used by Renderer and now by MarlinCache
to store rowAAChunk data.
Moreover I performed other small optimizations (heuristics,
Renderer.addLine() split in 2 methods) and many benchmarks to tune the
new approach.
Could you review that patch, please ?
Here are my last results:
Test Threads Ops Med Pct95 Avg StdDev Min Max
TotalOps
*CircleTests.ser * *1* *172* *61.064* *61.311*
*61.079* *0.131*
*60.823* *61.67* *172*
*EllipseTests-fill-false.ser * *1* *37* *278.548* *278.757*
*278.557* *0.112* *278.362* *278.868* *37*
*EllipseTests-fill-true.ser * *1* *25* *436.323* *436.866*
*436.403* *0.27* *436.026* *437.318* *25*
dc_boulder_2013-13-30-06-13-17.ser 1 114 91.316 91.75 91.355
0.279 90.803 92.505 114
dc_boulder_2013-13-30-06-13-20.ser 1 219 47.84 48.182 47.854
0.175 47.498 48.783 219
dc_shp_alllayers_2013-00-30-07-00-43.ser 1 265 39.432 39.61
39.433 0.108 39.21 40.052 265
dc_shp_alllayers_2013-00-30-07-00-47.ser 1 25 769.704
771.488
769.849 1.096 767.903 772.967 25
dc_spearfish_2013-11-30-06-11-15.ser 1 820 12.766 13.028 12.798
0.128 12.583 13.232 820
dc_spearfish_2013-11-30-06-11-19.ser 1 1637 6.413 6.613 6.438
0.067 6.375 6.777 1637
dc_topp:states_2013-11-30-06-11-06.ser 1 869 12.059 12.13 12.063
0.038 11.983 12.26 869
dc_topp:states_2013-11-30-06-11-07.ser 1 1421 7.391 7.453 7.392
0.023 7.329 7.52 1421
test_z_625k.ser 1 68 152.821 153.589 152.862
0.358 152.135
153.775 68
These are great results! And they are much easier to read with the
tables (which seem to get lost in my reply, oops!).
Thanks.
If it is just the dashing results I can believe that as Ductus does
a pretty good job of minimizing the number of segments in its
stroked output paths. The losses are pretty small in that case so
we are getting pretty close to being able to deprecate Ductus at
some point which would be awesome (still a bit of reliability
testing "in the wild" before we can actually switch full time,
though)...
As I mentioned few month ago, the Stroker can be improved to reduce the
number of generated segments related to caps & miter joins ie ignore
collinear edges. Moreover, it can be notably worth for dashed polygons
(many caps) or very complex polylines (many joins).
Thanks for your time,
Laurent
