[OpenJDK Rasterizer] Some questions
Jim.A.Graham at Sun.COM
Fri May 18 19:40:50 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.
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
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...
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
More information about the graphics-rasterizer-dev