[OpenJDK Rasterizer] Some questions

[Jim Graham]

As I've said, right now I'm working on creating a cleaner separation of 
our open code and the encumbered libraries that do the pixel coverage 
calculations.  In that effort, I'm creating an interface behind which 
the encumbered code can live and be replaced.

Since our current library is tile-based, that is the direction I'm 
taking the interface.  But, that begs the question - is that the right 
direction to choose?  Short term or long run?

In the short term, I can get the interfaces in place and the code 
factored out fairly quickly with this approach - in a week or two. 
Also, in the short, or short to intermediate term, we focus the 
replacement effort on a smaller piece and we can keep all of the 
rendering back end loops in several pipelines (software, OpenGL, D3D, 
X11) which have all been tuned.

In the long run, maybe we want to investigate different intermediate 
formats, but doing so will involve not only an analysis of how 
efficiently we can compute them, but also how efficiently they can be 
rendered across all of the different pipelines.  It would be a shame to 
integrate a new run-length-coverage based rasterizer only to find out 
that OpenGL renders such a format 10x as slow as it can manage a tile, 
for instance.  On the other hand, if I get this new interface out there 
in the next update and we find that the ClassPath rasterizer is slower 
by 4x or worse because it is not designed for that interface, we haven't 
really created a viable replacement yet anyway.

I think getting this straw man separate of "tile generation" into the 
workspace is a good starting point, though.  The fact that this might 
mean that your renderer will have to be shoe-horned in or converted into 
a new format isn't optimal, but we can get started on the road fairly 
quickly and at least achieve a 100% unencumbered milestone in this area 
sooner.

The alternative would be to start looking to replace the renderer at a 
higher level - at the "ShapeDrawPipe" level and doing so would involve 
completely replacing not only the "geometry to coverage" library, but 
also the backend renderers and possibly disabling the OpenGL pipelines 
until they can be updated...

			...jim

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