[OpenJDK Rasterizer] Rasterizer replacement proposal

[Roman Kennke]

Hello,

I finished up what I wanted to add to my rasterizer and want to make it
available to anybody who would like to review it or play with it. You
can download the code here:

http://kennke.org/~roman/rasterizer-rkennke-2007-05-24.zip

Legal note: Right now this is ripped straight out of GNU Classpath, to
which this code originally belongs. It is licensed under GPL+exception.
The FSF holds the copyright to that code through their copyright
assignment thingy. However, I am the original author of all of the code
and will do the copyright grantback procedure and sign the SCA (I think
my employer (aicas) already did so for me even) to make this code
available to OpenJDK. I would like to hear your opinion on the code
first, though. If that doesn't look feasible at all, then I can avoid
doing all that.

Technical notes:
- The entry point is the ScanlineConverter class. I have an instance of
this in my Graphics2D implementation and store it as a thread local
variable. The 'frontend' is ScanlineConverter.renderShape(), the
'backend' is specified by the interface Pixelizer. The Pixelizer
implementation is responsible for actually modifying the surface pixels.
It gets called once for each scanline. The coverage information is
carried by ScanlineCoverage instances. Use ScanlineCoverage.iterate() to
get the actual coverage information, and use getMaximumCoverage() to get
the scaling right.
- In order to convert this information to the tiles that you need, it
shouldn't be too hard to implement a Pixelizer that aggregates a couple
of scanlines into tiles. The interesting task here is to do this
efficiently.
- The rasterizer is a generic Shape rasterizer. I believe it is very
efficient for rasterizing arbitrary Shape objects, plus transform and
clipping. It uses a sophisticated scanline algorithm (if you want it, I
can write more about this, but this is going to be a small essay
then.. ;-) ). However, it is not (yet) optimized for certain frequent
special cases. Most importantly, I think lines and rectangles could be
done much faster in certain settings. I'll add that in the future.
- Most calculations are done using fixed point arithmetics (that's
because the original target have been platforms without FPU). I don't
know if that does any good for performance on usual desktop systems, but
it won't do any harm either.
- Datastructures are reused in almost all cases. That means that the
scanline converter doesn't allocate any new memory once it has its
datastructures set up after a couple of rendering cycles. New
allocations only happen when the datastructures need to be extended
(e.g. for extraordinary complex shapes).

I will still be around tomorrow, and starting from saturday I will be
offline for 2 weeks (or, at best be online sporadically) because I'm
going to marry, yay! If you have urgent questions it's a good idea to
ask them ASAP. Otherwise, I'll be curious to hear your opinions in two
weeks then.

Cheers, Roman

-- 
Dipl.-Inform. Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt