[OpenJDK Rasterizer] Rasterizer replacement proposal

[Jim Graham]

Some preliminary thoughts in looking over the ScanlineConverter...

- It does quite a lot for such a small piece of code - very cool.

- It's also very basic in its mathematical techniques, though.  The math 
to trace the slope of a line is inefficient and inaccurate and it 
flattens everything before tracing.  There is a lot of room for 
improvement here.

- It uses a push technology - you call it with something to render, it 
then calls something else with the data to render.  This is opposite the 
designs in our pipeline which call the rasterizer and ask it to return 
the path coverage information and then hand the path coverage 
information off to a pixel pusher.  It will be hard to turn that calling 
sequence around for this code unfortunately to make it match the way we 
do things in our pipelines currently (via AATileGenerator).  Not 
impossible, it will just require slicing up the code a bit on one side 
or another.

- It ignores the winding rule of the path, shouldn't be too hard to add 
support for non-zero winding, though.

- Clipping is managed by rasterizing both the shape and the clip at the 
same time.  The advantage of rasterizing the clip along with the shape 
is that you can rasterize the clip at a higher resolution when doing AA, 
but it comes with some drawbacks:

     - It's easy for the Shape rasterizer to rasterize both at the
       same time, but other parts of the pipeline (text and imaging)
       won't be so lucky without a lot of added support code.

     - Clipping should restrict the same regardless of pipeline and
       attributes set, but this clipping will restrict AA and non-AA
       rendering differently (due to different resolutions).  It might
       also restrict rendering of text and image differently unless
       they duplicate its code.

     - There are a lot of calculations involved in rasterizing the
       clip each time something is rendered - a big performance hit.

- Since our pipelines manage clipping outside of the AATileGenerator, 
the clipping code could be ignored when adapting this code as a plugin 
for the AATG, so the above drawbacks won't have any immediate impact in 
the short term and we can discuss them for longer term use when we get 
to more extensive efforts at coming up with a new "best of breed" 
renderer.  In the end, I think we'll probably want to stick with our 
Region based clipping for performance and ease of integration, but that 
all remains TBD.

- There is little to no handling of large coordinates, the results of 
handling them are a by-product of the calculation used to convert them 
to fixed point.

- The slope calculation doesn't carry very much precision at all - it 
looks like the error can be as much as +/- 1 pixel for every 64 
samplings.  There are much better ways to manage the math there that 
provide much more accuracy.  The code in 
src/share/native/sun/java2d/pipe/ShapeSpanIterator.c traces the slope of 
flattened shapes much more accurately.

- We found some performance improvements in directly tracing the curves 
rather than flattening them.  These techniques are evidenced in the 
src/share/classes/sun/java2d/loops/ProcessPath.java code (also mirrored 
at the native level in src/share/native/sun/java2d/loops/ProcessPath.c).

I'd say for the short term, it might help get us off the ground wrt 
satisfying the AATileGenerator interface, but there are probably some 
simpler ways to achieve that end.  I have a quick and dirty prototype of 
using Region objects to generate alpha tiles that I'll try to clean up 
and throw out here for another straw man.  It performed about .1 to .5x 
of the speed of the production code, but it was small and simple and 
took Ductus out of the equation.

The one piece that neither my quick Region hack nor this Rasterizer that 
you are offering here satisfy is an alternate implementation of line 
widening...

			...jim