They do operate differently. They aren't meant to be mixed and matched.
One thing that may shed some light is the STROKE_CONTROL hint. If it is sent to Pure then there is no heuristic for how
to rasterize and all rasterizers should agree on how to scan convert shapes.
But, if it is set to another value, then it has some latitude to adjust the path for cleanliness with respect to keeping
line widths from varying depending on position and other consistency anomalies that can occur with a number of small
related paths rendered near each other. The two mechanisms were written with different goals and by different people to
meet those consistency requirements in different ways. The operation of one is more useful for a software renderer back
end and the other is more useful for a hardware renderer back end (which was the primary reason for creating
ProcessPath, not necessarily the distinction of how to apply the STROKE_CONTROL hint)...
...jim
On 9/25/16 4:33 AM, Clemens Eisserer wrote:
Hi,
I recently tried to track down JDK-8156100 (xrender: Subpixel drawing
bug in Java 8) - under some circumstances paths do not align with
fills when subpixel coordinates are used.
The issue seems to be caused by ProcessPath and ShapeSpanIterator
behaving differently with regards to rounding.
I've created a small testcase to illustrate the issue:
http://pastebin.com/hy5zCkPR - where a rectangle with subpixel
coordinates is "drawn" with bothl, SSI and ProcessPath.
The ShapeSpanIterator seems to truncate any subpixel values, whereas
ProcessPath always seems to "round up".
Is this expected behaviour? Should I avoid SSI and switch to
ProcessPath entirely?
Thank you in advance, Clemens
