[OpenJDK Rasterizer] Some questions
roman.kennke at aicas.com
Sat May 19 00:55:43 PDT 2007
> 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)
> 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
> 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
More information about the graphics-rasterizer-dev