Actually, I just finished implementing a solution to the problem I've been talking about. I've only tested it on the problematic curve I have talked about, but it works very well.
I've also changed the structure of the engine quite a bit. Mostly to optimize things and get rid of unnecessary object allocations, but also to clean things up a bit - the way it was, with nearly all the logic for widening and dashing in BezCurve.java wasn't very pleasing and it couldn't be made so unless we made the class completely immutable and threw performance out the window. It doesn't look like I'll be able to send a webrev out by today, but I'll work on it a bit during the weekend and I should have a good one by Monday. Regards, Denis. ----- "Jim Graham" <james.gra...@oracle.com> wrote: > Hi Denis, > > Things got really busy for me over the past week so I wasn't able to > keep up with the discussion on this, but I will be looking more at it > > next week. In the meantime it sounds like you are on the right track. > > I wish I'd have investigated it to the level you are at so I could be > of > more immediate help, but hopefully I'll get there when I review your > various changes... > > ...jim > > On 9/7/2010 2:11 PM, Denis Lila wrote: > >> 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. > > > > I figured out what the problem is. The problem isn't really tight > loops. > > The problem is cusps in the offset curves. These happen when the > line width > > is equal to the radius of curvature of the curve being processed > (although, > > this may be just a necessary condition and not sufficient, but this > doesn't > > matter). > > > > It seems like we have to split at values of t where the above > condition > > holds. However, I can't see a way to do this without resorting to > Newton's method > > for finding the roots of RadiusOfCurvature(t) - lineWidth. It would > be > > really easy, however, if we had the arc length parametrization of > the curve > > in question, but this won't necessarily be a polynomial. A good way > might be > > to find a polynomial approximation to its inverse (this would make > dashing considerably > > easier too). > > > > Regards, > > Denis. > > > > ----- "Denis Lila"<dl...@redhat.com> wrote: > > > > > >> > >> ----- "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
