[OpenJDK Rasterizer] Rasterizer replacement proposal

[Phil Race]

Roman,

Thanks for this. Jim Graham is the best person to comment
on this but he's on vacation until next week some time.

And congrats on getting married.

-phil.

Roman Kennke wrote:
> 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
>