[OpenJDK Rasterizer] Some questions

[Jim Graham]

Hi Roman,

Does the code which does the scan conversion also directly modify the 
pixels?  The reason I ask is that our rasterizers simply calculate data 
about how the pixels are to be modified (spans of pixels to fill for 
non-AA and buffers of coverage values for AA), but leave it to another 
piece of code to do the actual pixel modification.

 From your description it sounds like your AA rasterizer goes all the 
way from geometry down to actually modifying the destination pixels in 
one indivisible module - is that really the case?

			...jim

Roman Kennke wrote:
> Hi,
> 
>> How does your AA rasterizer plug in?
> 
> The ScanlineConverter class basically takes one Shape object (the actual
> Shape to be rendered), another one (the clip), an AffineTransform and a
> parameter which says how sub-pixel resolution to render. It also takes
> an object of an interface type to which the actual rendering is then
> delegated. Objects implementing this interface basically fill lines with
> pixels according to the coverage values passed into them.
> 
> It doesn't create tiles of larger areas yet, but that shouldn't be a big
> problem to add. This means more or less aggregating the data of multiple
> lines. Also, I don't deal with the data in a pixel-by-pixel format, but
> with ranges on a scanline. Basically I store the x location, length and
> coverage value for any scanline segment with one coverage value.
> 
> I haven't tested performance on JDK yet, Classpath can't easily plugged
> into hotspot as is. Rendering some shapes like glyphs with classpath,
> cacaovm and the Escher backend showed a performance difference of around
> 16x slower for non-AA rendering and 4x slower for AA rendering. The
> performance difference between hotspot and cacaovm is also around the
> factor 4x (cacao beeing 4x slower than hotspot). But takes these numbers
> with a large portion of salt, it's only been a very naive simplistic
> benchmark.
> 
> If you think this could be feasible and I should try to wire it to
> OpenJDK, let me know, and give me some pointers where to start.
> 
> /Roman
>