Hello Jim. So, I finally have a webrev for serious consideration: http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ There are still some printing statements I used for debugging, and the whitespace is probably pretty bad (tell me if this poses a problem when reading the code, and I'll clean it up), but I don't want to waste time removing that stuff unless necessary, since this is doubtlessly not the last version. I also included a Test.java file that I found useful for testing and debugging. It has a main method, and it allows pisces to run as a standalong project in eclipse (as long as you set the JRE to be openjdk7 since it needs to know about AATileGenerator and some other non public interfaces).
>From testing it, the only problem I noticed is that it doesn't do very well with tight loops. So, a path like p.moveTo(0,0);p.curveTo(1000, 1000, 400, 500, 0, -150); isn't stroked very well when using the rotating algorithm. When using just the "make monotonic" algorithm it is ok (right now, it is set to use the latter - you can change this by uncommenting Stroker.java:1011 and commenting out Stroker.java:1012). This leads me to believe that we need to detect and perhaps subdivide at loops in addition to the current subdivision locations. However, I have not yet looked too deeply into why the problem arises and how to fix it. I welcome suggestions. Thanks, Denis. ----- "Jim Graham" <james.gra...@oracle.com> wrote: > OK, I see. You were doubting that the "thing that came after Pisces" > > could be that much different considering that Pisces is rendering many > > more sub-pixels. > > Actually, embarrassingly I think it can. It just means the non-AA > renderer has some performance issues. One thing I can think of is > that > the SpanShapeIterator uses a native method call per path segment and > the > cost of the context switches into native and back for each path > segment > dominate the performance of long paths. It was something I was > meaning > to fix for a long time (when that code was first written native code > was > so much faster than Java and the native transition was quick - since > then Hotspot came along, got a lot better, and the native transitions > > got much, much slower). > > So, yes, this isn't out of the question... > > ...jim > > On 9/2/2010 3:40 PM, Denis Lila wrote: > >> 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
