[OpenJDK Rasterizer] Some questions

[Jim Graham]

I'm making good headway on ridding our open code from build dependencies 
on the licensed Ductus library and package.  I'll try to send out some 
javadocs of the interface as soon as I get it all in order...

			...jim

Roman Kennke wrote:
> Hi Jim,
> 
> Is there anything I can do right now to make progress? You could point
> me to the pieces where the rasterizer has to be plugged in, or I could
> send you my code for review (currently it's FSF copyrighted code, but I
> can relatively easily make use of the copyright grantback clause because
> it's all written by myself).
> 
> /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
>>>