Hi Roman. > - 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).
I think it would require changing around some interfaces, but other than that, not much. In fact, it is a TODO in the webrev I sent and, time permitting, I'll try to implement it. > - 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? No, but I actually implemented that about half a year ago, and it slowed things down. Then again, there are a lot of optimizations in this version that I didn't have back then, so maybe it's worth trying this idea again. Regards, Denis. ----- Original Message ----- > 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. > > > Cheers, Roman
