[OpenJDK Rasterizer] Some questions

[Roman Kennke]

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
> > 
-- 
Dipl.-Inf. Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt