Just fyi: we have run into the same problem in our work using Java2D to render maps in the Smallworld Core GIS. Like Andrea, we introduced our own clipper to avoid throwing over-large polygons at the renderer.
That said, the renderer is generally excellent and gives high quality output. We use ductus, though I have briefly experimented with Laurent's marlin work. It also looked good quality-wise but I didn't do any performance tests. George -----Original Message----- From: 2d-dev [mailto:2d-dev-boun...@openjdk.java.net] On Behalf Of Jim Graham Sent: 06 April 2015 23:00 To: Andrea Aime; Laurent Bourgès Cc: graphics-rasterizer-...@openjdk.java.net; 2d-dev@openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths Hi Andrea, On 4/3/15 7:01 AM, Andrea Aime wrote: > PS: GeoServer will clip and simplify the geometry before > throwing it at java2d, exactly because we know > java2d is not so good at handling this kind of complexity > > > Do you have a fast and efficient polygon clipper in geoserver ? > > > We use this one for fast rectangular clipping: > https://github.com/geotools/geotools/blob/master/modules/library/main/ > src/main/java/org/geotools/geometry/jts/GeometryClipper.java > > It was introduced exactly because java2d does not do that, and can > lead to OOM easily with large shapes united with a dasharray stroke. If I understand the above correctly you will simplify a polygon to just the pieces that fall within the clip before you send them to the rendering/stroking engine? You mention dashing as the main case that you are concerned with, but doesn't that surgery on the polygon change the dash pattern? I suppose if you are just viewing the dash pattern as a periodic decoration then that wouldn't matter, but technically there is only one correct way for the in-clip dashes to appear. This does point out that our dashing engines (and stroking engines) do not take the clip into account at all and so generate widened and dashed geometry for parts of the shape that do not intersect the clip. We should look at adding that. The more responsible way to add it for dashing would be to compute the length of any omitted segment and consume the dash phase as appropriate, but that is much cheaper than generating all of the segments and then having them widened just to be ignored by the rendering phase. The dasher only needs to accumulate and account for segment lengths that are dropped. The stroker just needs to remember the angles at the nearest endpoint of the omitted segements. Another gotcha that comes up with stroking and bounds is that miter joins can extend a fairly large distance away from the path segments that generate them and you only know how far it extends when you have both segments that meet at the vertex and can compute their relative angle. There is a "miter limit" so if the segment is beyond that then it cannot intersect the clip regardless of the angles, but between that limit and the line width there is some computation to be done. Still, even if the simplest and worst case assumption that any segment would extend by the full miter limit, for extremely large or zoomed paths and reasonable values for miter limits that still leaves quite a lot of segments that could be trivially eliminated... ...jim
