[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work?
From:       linuxhippy () gmail ! com (Clemens Eisserer)
Date:       2007-10-04 10:02:09
Message-ID: 194f62550710040302g77dd9287mdbeadd1b39f2da29 () mail ! gmail ! com
[Download RAW message or body]

Hi,

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
mask-tiles?

Sorry for all the traffic ...

Thanks, lg Clemens


[prev in list] [next in list] [prev in thread] [next in thread]