[OpenJDK Rasterizer] Task 2 - line widening

[Jim Graham]

Path widening algorithms are nothing new, but they can be a pain to work 
out all of the corner cases.  The widener in the Ductus library that 
we've licensed has some nice properties that we'd like to keep even as 
we replace it:

- It preserves curves in the widened outlines
- It can be used as a filter in an existing rendering pipeline
- It's fairly stable and has been working fine for several years now
- It has provisions for dropout control (minimum line widths)

It also has a couple of issues:

- Obviously it is encumbered by a license
- It's native code so can suffer from JNI performance issues
- There are still some cases where it can generate unexpected output

I'd love to just start hacking on a replacement, but for a couple of issues:

- I've seen the encumbered sources so I could probably be considered tainted
- The main area where I might be considered tainted is in how they 
preserve curves in the output
- I'd likely make all of the standard mistakes someone makes in their 
first draft of a line widening engine
- It's one step slightly more complicated to make one that acts like a 
filter like the current code rather than doing one that simple takes an 
input path and generates an output path as in 
BasicStroke.createStrokedShape.
- The sources that represent the interfaces that one needs to implement 
to use the existing line widener like a filter are part of the licensed 
sources.

I don't have any quick and dirty answers here...

It would be fairly easy to create a standalone polygonal line widener 
and run all paths through it flattened, but that would give up some 
quality (at least in the short term).  I could probably do that without 
even tainting the sources since such algorithms are very straightforward.

It would be fairly easy to integrate this into the code by doing the 
fairly obvious and straightforward step of calling 
BasicStroke.createStrokedShape on all paths, but we'd lose some 
performance there too in having to save the widened path in a temporary 
path structure before feeding it into the path filling machinery.  Also, 
creating such a variation might make it hard to have our product code 
continue to work like a filter - thereby either creating lots of 
differences between the OpenJDK and the production code or threatening a 
performance loss in the production code.

Has anyone started looking into replacing the line widening code yet at all?

			...jim