[OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work?

Clemens Eisserer linuxhippy at gmail.com
Thu Oct 4 10:02:09 UTC 2007


Ok, after looking at the open rasterizer's source I pretty much throw
away the idea of implementing it as shader ;)
However one thing which still seems interesting to me is to do
scanline-rendering via a shader. A simple opcode-protocoll could be
uploaded to the texture which is read and executed by a simple shader.

As far as I've seen ProcessPath.c/h do the conversation between paths
and scanlines (btw. why is there a native and a java version).
Wouldn't it be possible to redirect AA rendering through the
non-antialiased path, somehow get the coverage values of the scanline
endpoints (maybe using fp left/right coordinates), upload it to a
texture and let the shader do all the pixel-calculation stuff?
Maybe even some batching could be performed, uploading several
scanlines one after another of no state-changes occur.
I'll do some experiments on my Geforce-FX5200 to see how the
shader-part would perform but I guess if it works in this card fast
... everything else should do it too ;)

Another thing which makes me curious are the results of the AA'd line
testcase mentioned in the bug-report:
1100.x11: 544.5535714 (var=1.61%) (100.0%)
1100.base: 376.7876787 (var=1.29%) (69.19%)
1100.align: 375.4134509 (var=1.48%) (68.94%)
1100.notex: 607.7712609 (var=1.58%) (111.61%)

So removing the texture-upload "only" increases performance relative
to x11 by about 40%. So I wonder where the other time is spent? How
large do you estimate the part consumed by doctus to create the

Sorry for all the traffic ...

Thanks, lg Clemens

More information about the 2d-dev mailing list