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

[Denis Lila]

> 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'll try looking into this.

> 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... :-(

Actually, according to some J2DBench tests I ran on bezier curves,
the version of Pisces in the webrev I sent out is already faster
than Ductus on many inputs (mainly fill operations, and stroke
operations performed on large curves. AA stroking smaller curves is
still slower, but maybe that's because we're producing unnecessarily
many edges in the curve->edge conversion. Or perhaps we need to
integrate the stroker and renderer more closely).

Regards,
Denis.

----- Original Message -----
> 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.
> 
>. 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. 
> 
> ...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
> >
> >