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
