Re: [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Jim Graham
All of your comments are spot on (modulo the confusion over Pisces/Marlin vs Path2D). And you are right that 500 seems pretty lean to me. 800K path segments seems to be a pretty large outlier, though, do we really see paths that large other than via a test case? I think I'm good with the pro

Re: [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Laurent Bourgès
I can understand to promote the 99% use case (small path) but the performance penalty is too important to me for large paths Let's have jim's point of view as he knows the complete story... Laurent Le 2 avr. 2015 19:33, "Phil Race" a écrit : > I should have paid more attention to the contex

Re: [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Phil Race
I should have paid more attention to the context. So it appears that 500 has been the value since 1998 and it was made that under this bugid when the code was all still in GeneralPath.java https://bugs.openjdk.java.net/browse/JDK-4134316 prior to that fix it was even smaller < static final

Re: [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Laurent Bourgès
Phil, Just a short comment: > pisces was originally written for the "ME" environment so I suspect that > it was very conservative in allocating new heap space. That clearly does not > matter so much on desktop so the proportional approach rather than > the fixed size approach seems better. 1/8th

Re: [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Phil Race
pisces was originally written for the "ME" environment so I suspect that it was very conservative in allocating new heap space. That clearly does not matter so much on desktop so the proportional approach rather than the fixed size approach seems better. 1/8th seems conservative and since the resu

Re: [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Laurent Bourgès
Hi again, I quickly tested the proposed solution: void needRoom(boolean needMove, int newCoords) { if (needMove && numTypes == 0) { throw new IllegalPathStateException("missing initial moveto "+ "in path defin

[OpenJDK Rasterizer] hg: graphics-rasterizer/jdk9/jdk: 8076529: Marlin antialiasing renderer integration

2015-04-02 Thread bourges . laurent
Changeset: e96a79f75039 Author:lbourges Date: 2015-04-02 15:02 +0200 URL: http://hg.openjdk.java.net/graphics-rasterizer/jdk9/jdk/rev/e96a79f75039 8076529: Marlin antialiasing renderer integration Summary: Initial marlin patch as a new standalone renderer 'sun.java2d.marlin.Marlin

[OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

2015-04-02 Thread Laurent Bourgès
Hi, Doing the Marlin integration and running my MapBench test suite, I figured out a performance issue with Path2D.needRoom (): EXPAND_MAX= 500 is a performance bottleneck for huge paths ! FYI I created a spiral test with 800k line segments: - Marlin renders it in 2s. - If I call createStrokedSha