Andra & Jim,<br><br>Here is the current status of my patch alpha version: <br><a href="http://jmmc.fr/~bourgesl/share/java2d-pisces/">http://jmmc.fr/~bourgesl/share/java2d-pisces/</a><br><br>There is still a lot to be done: clean-up, stats, pisces class instance recycling (renderer, stroker ...) and of course sizing correctly initial arrays (dirty or clean) in the RendererContext (thread local storage). <br>
For performance reasons, I am using now RendererContext members first (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).<br><br>I provided the patch as zip file and few benchmark using Andrea's MapBench (Xmx128m):<br>
- OpenJDK 8 PATCHED:<br>Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser<br>1 threads and 20 loops per thread, time: 3687 ms<br>2 threads and 20 loops per thread, time: 3693 ms<br>4 threads and 20 loops per thread, time: 6849 ms<br>
<br>Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser<br>Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}<br>Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser<br>
1 threads and 20 loops per thread, time: 27266 ms<br>2 threads and 20 loops per thread, time: 33628 ms<br>4 threads and 20 loops per thread, time: 61577 ms<br><br>- OpenJDK 8 REFERENCE:<br>Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser<br>
1 threads and 20 loops per thread, time: 3982 ms<br>2 threads and 20 loops per thread, time: 4852 ms<br>4 threads and 20 loops per thread, time: 8842 ms<br><br>Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser<br>
Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}<br>Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser<br>1 threads and 20 loops per thread, time: 55889 ms<br>
2 threads and 20 loops per thread, time: 77691 ms<br>4 threads and 20 loops per thread, time: 141981 ms<br><br>- Oracle JDK8 DUCTUS:<br>Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser<br>
1 threads and 20 loops per thread, time: 1894 ms<br>2 threads and 20 loops per thread, time: 3905 ms<br>4 threads and 20 loops per thread, time: 7485 ms<br><br>Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser<br>
Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}<br>Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser<br>1 threads and 20 loops per thread, time: 20911 ms<br>
2 threads and 20 loops per thread, time: 39297 ms<br>4 threads and 20 loops per thread, time: 103392 ms<br><br>As you can see, patched openJdk8 performs better and it is very noticeable on big drawings (dc_shp_alllayers_2013-00-30-07-00-47.ser) and better than ductus with 2 threads !!<br>
<br>Laurent<br><br><br><div class="gmail_quote">2013/3/30 Andrea Aime <span dir="ltr"><<a href="mailto:andrea.aime@geo-solutions.it" target="_blank">andrea.aime@geo-solutions.it</a>></span><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="im">On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès <span dir="ltr"><<a href="mailto:bourges.laurent@gmail.com" target="_blank">bourges.laurent@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- clipping issues (dasher, stroker) and spatial resolution (no cpu/memory waste)<br>
</blockquote><div><br></div></div><div>I see, yes. Indeed in the GeoServer code we already work around some of those issues by</div><div>clipping the geometries read from the database to the graphics2d viewport before giving them</div>

<div>to the renderer, we had to do that both for performance issues and to avoid OOM errors</div><div>when basic stroke with dasharray is used against a line that is many times longer than the</div><div>
current display area</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I don't have anything ready, the existing code loads data from spatial database, sets up styles from XML descriptions, turns each spatial db geomety in java shapes</div>


<div>and so on. But I guess I could concoct something close enough.</div><div>I'm writing some code to gather statistics about the shapes that are actually painted (scrolling over the path iterators) and then I'll try to make a randomized</div>



<div>shape painter that gets close to those stats.</div></div></div></div></blockquote></div><div><br>Great news ! I am waiting your test code to perform few benchmarks.<br><br>I am using J2DBench but it does not perform such complex drawing (complex shapes ...) or multi threading tests (parallel drawings on buffered images)</div>

</div></blockquote><div><br></div></div><div>Ok, I've created a "MapBench" by serializing shapes, strokes and fills from a real GeoServer instance to disk, and have them</div><div>play in a simple multithreaded test harness.</div>

<div>What you get in the output is not exactly the maps generated by GeoServer since we use a number of tricks to speed up rendering,</div><div>including painting over multiple drawing surfaces (the serializer only handles one), also, some maps have text showing up because</div>

<div>in order to pain "labels along a line" we actually turn the chars into shapes and place them along the line, but those labels that we</div><div>can predict are "straight" are painted with drawGlyphVector so they won't show up (haven't built a serialization for that case).</div>

<div><br></div><div>Regardless, the test should be good enough to test both performance and scalability.</div><div>Here is the package: <a href="http://demo.geo-solutions.it/share/mapbench.zip" target="_blank">http://demo.geo-solutions.it/share/mapbench.zip</a></div>

<div><br></div><div>It contains:</div><div>* ShapeDumpingGraphics2D, a Graphics2D wrapper writing on disk all draw(Shape) and</div><div>  fill(Shape) commands issued to it</div><div>* A bunch of *.ser files, that are the serialized drawing command sequences</div>

<div>* A bunch of *.png files, which are the rendered versions of the .ser files (for reference)</div><div>* MapDisplay, which reads all *.ser files from a directory and displays them in JFrame and</div><div>
   generates the .png files as well</div><div>* MapBench, which reads all *.ser files from a directory and repeatedly paints them in a loop</div><div>  with a growing number of threads </div><div>* Two txt files with the timings of the benchmarks on my machine for Oracle JDK 7 and </div>

<div>   OpenJDK 7, here is an example comparison:</div><div><br></div><div>OpenJDK7:</div><div><div>Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser</div><div>1 threads and 20 loops per thread, time: 3340 ms</div>
<div>2 threads and 20 loops per thread, time: 3688 ms</div><div>4 threads and 20 loops per thread, time: 4665 ms</div><div>8 threads and 20 loops per thread, time: 7343 ms</div><div><br></div><div>Oracle JDK 7:</div>
<div><div>Warm up took 29516 ms<br></div><div>Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser</div><div>1 threads and 20 loops per thread, time: 1754 ms</div><div>2 threads and 20 loops per thread, time: 2878 ms</div>

<div>4 threads and 20 loops per thread, time: 6792 ms</div><div>8 threads and 20 loops per thread, time: 14275 ms</div></div><div><br></div><div>As you can see ductus is significantly faster than pisces, but it has serious scalability</div>

<div>issues, while pisces scales up a lot better.</div><div><br></div><div>The code has been put together in a haste, sorry for the lack of comments, hopefully it is</div><div>simple enough that it's usable anyways.</div>

<div><br></div><div>Cheers</div><span class="HOEnZb"><font color="#888888"><div>Andrea</div><div><br></div></font></span></div></div><div class="im"><div><br></div>-- <br><div>==</div><div>Our support, Your Success! Visit <a href="http://opensdi.geo-solutions.it" target="_blank">http://opensdi.geo-solutions.it</a> for more information.</div>

<div>==</div><div><br></div><div>Ing. Andrea Aime </div><div>@geowolf</div><div>Technical Lead</div><div><br></div><div>GeoSolutions S.A.S.</div><div>Via Poggio alle Viti 1187</div><div>55054  Massarosa (LU)</div><div>Italy</div>

<div>phone: +39 0584 962313</div><div>fax: +39 0584 1660272</div><div>mob: +39  339 8844549</div><div><br></div><div><a href="http://www.geo-solutions.it" target="_blank">http://www.geo-solutions.it</a></div><div><a href="http://twitter.com/geosolutions_it" target="_blank">http://twitter.com/geosolutions_it</a></div>

<div><br></div><div>-------------------------------------------------------</div>
</div></div></div>
</blockquote></div><br>