[OpenJDK 2D-Dev] Pisces AA renderer performance improvement.

[Jim Graham]

That's a good intermediate suggestion to consider, but I'd love to move 
beyond that (eventually) and not be held back by the need to support 
32x32 tiles for legacy reasons.  It would be nice to hand back whatever 
kind of tiles makes sense for the rasterizer, but I think that Dmitri 
mentioned that the D3D pipeline sort of hard-codes a 32x32 assumption in 
a few places.

It might be worth investigating how hard it would be to fix those 
dependencies so that we aren't held back with Pisces.  I can't imagine 
it can be that daunting a task (unfortunately I'm heavily committed to 
another project right now, or I'd investigate it myself).  I'm guessing 
it would involve changing the tile sizes from constants on the 
rasterizer to a method call on the tile generator and making the tile 
handlers more flexible to changes in tile sizes inside the renderers.

And, for that matter, if there is some alternate way of delivering the 
coverage information that makes Pisces work much faster we should start 
thinking along those lines.  If we let Ductus' design constraints (which 
were penned over a decade ago) hold Pisces back then we may never get to 
the point where Pisces can become our default renderer...  :-(

			...jim

On 7/19/2011 2:12 PM, Roman Kennke wrote:
> Hi Denis,
>
>
>> The version in the webrev is the fastest yet, and it uses
>> a class similar to the ScanlineIterator for the sorting
>> (but now it iterates through pixel rows, not scanlines).
>> Unfortunately this means that there still are two levels
>> of intermediate storage (edges and crossings, analogous
>> to edges and RLE elements in the old version), but the
>> only way I can think of how to get rid of one of them
>> and still take use an average linear time sort is if we
>> start outputting alphas pixelrow by pixelrow, rather than
>> in 32x32 tiles.
>
> - What speaks against doing that? E.g. outputting pixelrow by pixelrow?
> I was implementing a pure Java AA scanline converter for GNU Classpath
> some years ago and this is exactly what I did. I found that useful
> because drawing horizontal lines is often very cheap (i.e. filling
> adjacent bits/bytes in framebuffers).
> - What about writing 32 pixelrows into an intermediate buffer and then
> outputting those in 32x32 blocks when done? Or is this what you are
> currently doing?
>
> Cheers, Roman
>
>