[OpenJDK Rasterizer] Getting started - some background and status

[Jim Graham]

It looks like this mailing list has attracted a few subscribers now and 
so I'd like to get some discussion off the ground here.

At JavaOne we mentioned the (Antialiasing) Graphics Rasterizer project 
and didn't give many details other than the fact that we were looking at 
Pisces, a renderer used for some of our recent ME products as a possible 
replacement for our encumbered AA rasterizer.

If you've downloaded the OpenJDK sources and built them you may have 
noticed that not only is the Ductus Rendering engine supplied only as a 
binary plug, but many other classes and object files need to be supplied 
in binary form even though their sources are shipped with OpenJDK 
because they rely on interfaces and header files defined by the Ductus 
product.

There are basically two main pieces of functionality that the Ductus 
library supplied us with that are used in various places.

The first is, obviously, the AA rasterizer which turned paths into tiles 
of coverage values that we could apply to destinations using operations 
like MaskFill and MaskBlit, depending on whether the source color was a 
simple color or a raster from a Paint object.

The second piece of functionality is the code that widens paths.  We 
never developed our own code to widen paths because the Ductus library 
came with that functionality built-in so we leveraged it in other places 
in our code - including the BasicStroke object in its implementation of 
the createStrokedShape method and also for our non-AA rasterizer when it 
needs to deal with a widened path.

It's the second part which causes most of the incidental encumbrances 
which cause much of our open code to be unbuildable, but both represent 
encumbrances of some sort.

The Pisces renderer has some advantages to look at for a replacement:

- It was developed to implement Java rendering (though at the ME level)
- It is already open source
- It is a fairly complete implementation
- It has been tuned a bit already

Unfortunately it also has some disadvantages:

- It is tuned for tiny phone screens
    - It deals primarily with limited ranges of coordinates
    - It may not meet our quality goals
- It was not developed to fit into our desktop rendering architecture
- It's fairly large and requires a bit of porting to fit in
    - (What if we get done porting it and it just gets replaced anyway?)

We are still working on getting Pisces adapted to our internal 
architecture, but until we do that we still have no non-binary solution 
for AA rendering and line widening in the OpenJDK build tree.

In my next message I'll solicit some feedback on how to proceed...

			...jim