> Use which? The stroking code or the rendering code? > I believe that the way I set it up was that Pisces replaced both the > stroke widening/dashing code and the AA renderer - both were parts that > we relied on Ductus for. But, the widening code would talk to one of > our other existing rasterizers for non-AA. Look at > LoopPipe.draw(sg2d, s). It (eventually) calls RenderEngine.strokeTo() > directed at a SpanShapeIterator...
I think there's a misunderstanding. All I meant was that, even when AA is off, we do use pisces for widening, but it doesn't do any rasterization. ----- "Jim Graham" <james.gra...@oracle.com> wrote: > ...jim > > On 9/2/2010 3:20 PM, Denis Lila wrote: > >> Do we use Pisces for non-AA? Pisces should clock in slower for AA > than > >> non-AA, but I think we use one of the other pipes (not Ductus) for > >> non-AA and maybe it just isn't as good as Pisces? > > > > We definitely use it for non-AA. > > I traced it. > > > > Denis. > > > > ----- "Jim Graham"<james.gra...@oracle.com> wrote: > > > >> On 9/2/2010 2:43 PM, Denis Lila wrote: > >>> Actually, I had a question about the test I wrote which takes 20 > >> seconds. When > >>> I turned antialiasing on, the test dropped from 20 seconds to > 2.5. > >> This is very > >>> puzzling, since antialiasing is a generalization of > non-antialiased > >> rendering > >>> (a generalization where we pretend there are 64 times more pixels > >> than there > >>> actually are). Of course, the paths followed after pisces for AA > and > >> non-AA are > >>> completely different, but whatever came after pisces in the > non-AA > >> case would > >>> have the same input as Renderer has in the AA case (input gotten > >> from Stroker). > >>> Can you take a guess as to what was causing such a large > >> difference? > >> > > > >> > >> I think Pisces was integrated only as a Ductus replacement which > means > >> > >> it was used only for AA, but check if I'm mistaken... > >> > >> ...jim
