[OpenJDK Rasterizer] Marlin #4

[Laurent Bourgès]

Jim,

just a reminder on my last patch waiting for review.

Meanwhile I improved a bit the array cleanup in the RLE case and got some
gains:

Test Threads Ops Med Pct95 Avg StdDev Min Max TotalOps CircleTests.ser 1 170
61.993 62.304 62.018 0.159 61.687 62.667 170 *EllipseTests-fill-false.ser *
*1* *42* *248.594* *248.88* *248.65* *0.156* *248.435* *249.151* *42*
*EllipseTests-fill-true.ser
* *1* *27* *386.145* *386.453* *386.164* *0.243* *385.776* *387.088*
*27* dc_boulder_2013-13-30-06-13-17.ser
1 117 90.063 90.623 90.106 0.255 89.682 91.224 117
dc_boulder_2013-13-30-06-13-20.ser
1 216 48.073 48.514 48.108 0.241 47.622 48.864 216
dc_shp_alllayers_2013-00-30-07-00-43.ser
1 265 39.533 39.851 39.466 0.257 39.054 40.075 265
dc_shp_alllayers_2013-00-30-07-00-47.ser
1 25 775.522 776.642 775.337 1.155 773.359 778.698 25
dc_spearfish_2013-11-30-06-11-15.ser
1 821 12.758 12.875 12.762 0.066 12.641 13.03 821
dc_spearfish_2013-11-30-06-11-19.ser
1 1629 6.425 6.517 6.441 0.035 6.4 6.609 1629
dc_topp:states_2013-11-30-06-11-06.ser
1 861 12.145 12.267 12.14 0.078 11.992 12.363 861
dc_topp:states_2013-11-30-06-11-07.ser
1 1372 7.663 7.722 7.653 0.045 7.467 7.807 1372 test_z_625k.ser 1 68 153.784
154.339 153.715 0.453 152.633 154.984 68

1. Do you prefer I send you another webrev including my last changes ?

2. I will be busy in november so I would like to anticipate Marlin
integration into jdk9 forest:
Integration Due: 2015-11-27

What is the plan according to you ?

Could you merge gr forrest with latest jdk9 forrest ?

Do you need me to perform some cleanup (system properties, code formatting
like modifiers ...) before pushing marlin into jdk9 ?

Should we refactor the array cache asap ? or it can be done after the first
integration.

Cheers,
Laurent


2015-10-19 16:06 GMT+02:00 Laurent Bourgès <bourges.laurent at gmail.com>:

> 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
>



-- 
-- 
Laurent Bourgès
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20151029/0b736886/attachment-0001.html>