[OpenJDK Rasterizer] Rasterizer replacement proposal

[Jim Graham]

> True. However, the clipping can simply be ignored or ripped out of you
> don't need this. Should make the code simpler and faster.

It won't be needed to satisfy the needs of the RenderingEngine plugin 
API that I sent out a few days ago.  Longer term we may want to stick 
with Region clipping as well, but the other bullet items I wrote on the 
subject will represent the start of a design discussion on that front.

>> - 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.
> 
> It should be easy to do all calculations using float or double rather
> than fixed point.

There really aren't many calculations to do in fp/double in the first 
place.  If you look at the code pointers I sent out they go straight to 
integer incremental calculations fairly directly from the output of the 
flattening code.  The odd thing about what you had written is that you 
actually caused quite a lot of floating point calculations to be done 
when you asked the starting shape for a flattened iteration - that is 
done by subdividing in floating point, which is a lot of calculations - 
certainly more than are required to take the flattened results and 
calculate scanline stepping values from it.

(With respect to the 2 pieces of code that I pointed you to, the 
ProcessPath stuff is newer but rounds to integers right after flattening 
the shape - the ShapeSpanIterator stuff is older, but it maintains 
sub-pixel accuracy even as it traces the flattened outline.  The primary 
improvements in the ProcessPath stuff are the way that it traces the 
curves to generate the line segments and how it deals with STROKE_PURE 
vs. STROKE_NORMALIZE to keep the curves rounder...)

> I ask myself if it is worth the effort to continue with my
> ScanlineConverter and friends classes. There are not only the technical
> issues that you outlined above (plus more that might creep up), it also
> seems to be difficult to find a quick-enough solution for the legal
> stuff. An anti-aliasing rasterizer shouldn't be too much code anyway,
> and it might be worth starting from scratch (or from your prototype),
> with the special need of OpenJDK (and existing code in OpenJDK) in mind.
> What do you think?

My prototype doesn't perform well enough to be seriously considered.  I 
checked it into the workspace so that it will arrive in the OpenJDK 
repository (hopefully) at the same time as the Pluggable interface does. 
  You will find it in src/share/demo/java2d/.  It's mainly there to 
prove that the Pluggable interface can be plugged with alternate code, 
but in terms of a serious contender for the OpenJDK plug I think a 
modified version of your code with the accuracy problems fixed and 
turned into a pull technology instead of a push technology is likely 
more promising from a performance perspective.

That, or the ME code that we've been evaluating internally, but that is 
about as far from what we need as your code and it relies on fixed point 
in a more systemic way that will be harder to factor out.

> How's the read-only HG and/or SVN workspace for Java2D going?

I'm not working on that - I'll ping the people involved...

			...jim