[OpenJDK Rasterizer] Rasterizer replacement proposal

[Jim Graham]

I'm starting to look at this now, but first I wanted to give some 
feedback on the technical notes below:

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

I'd rather see it stored in a global cache so that we don't leak one if 
a thread does a little bit of rendering and then goes off to do only 
non-rendering tasks from that point onward.

> - 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.

If we stick with a 32x32 tile size to be kind to the current tradeoffs 
in the OpenGL pipeline then it would need enough memory to rasterize 32 
scanlines at a time.  That's not huge, but it would be nice to do 
better.  For the short term, I think it would work nicely.

> - 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.

It would be nice to have special case rasterizers for common objects if 
they can be managed in a small space.

I'll probably see as I review the implementation, but one question I 
have off hand is whether or not it handles STROKE_NORMALIZE vs. 
STROKE_PURE?  Also, does it work for stroking shapes directly, or does 
it rely on BasicStroke.createStrokedShape(), or is there another 
rendering process entirely for stroked shapes?

> - 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.

I think that all of our code uses fixed point in the final rendering 
loops, but it does most of the geometrical calculations in float or double.

We are currently evaluating another renderer from the embedded group 
that also converts to fixed point very early on.

One of the things we would have to evaluate for either body of code long 
term is if it can deal with large coordinates gracefully or if it 
overflows or crashes.  Our current code has (mostly, if not entirely) 
been vetted to deal with arbitrarily large coordinates (I say mostly 
because I don't know that we have full coverage on the testing of that 
support yet).

Long term we'd also like to share a rendering system with the embedded 
markets that would have the same restriction that you were worried about 
- missing or very poorly performing FPU.  We may want to have one body 
of code that can work both ways depending on the target for a given 
integration - but that may involve either doing it all natively or 
coming up with some kind of Java preprocessor so the code could be 
refactored for different numeric strategies prior to compilation.

> - 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).

How large can this grow?  Is it a potential problem if a program draws 
one really really huge shape and then goes back to really small shapes 
for the rest of its lifespan?

				...jim