[OpenJDK Rasterizer] [OpenJDK 2D-Dev] Path2d needRoom very slow for huge paths

Jim Graham james.graham at oracle.com
Mon Apr 6 21:59:44 UTC 2015


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


More information about the graphics-rasterizer-dev mailing list