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
