[OpenJDK Rasterizer] Some questions

[Roman Kennke]

Hi,

> 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.

Great. I will use the time to polish up my implementation and resolve
the legal issues so that I can actually send you my code. When you're
done with the interfaces, I'll look at implementing a conversion class
to allow us to easily plug in the rasterizer.

> 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.

Sure. In my experience, a run-length format is more efficient, because
for the tile format (when I understand it correctly) in order to find
the coverage for a given pixel, you have to actually look at each pixel.
While with a run-length form you directly find consecutive chunks which
can probably be rendered in one go. But then again, my primary targets
so far have been framebuffers (often a memset() for consecutive chunks)
and X11.

> 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.

Agreed.

> 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...

Has to be investigated then.

Kind regards, 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