Hello Jim. I think I finally have a version without correctness problems: http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
Assuming no bugs, there are still a few minor issues: - whitespace (I'll fix this tomorrow) - comments (also tomorrow) - in dasher, there are variables called sx1, sy1. They seem useless to me. It would help a lot if they are. Could you please look at this? If anything at all is confusing in it, please contact me (e-mail or irc: I'm on OFTC #openjdk. My nickname is dlila). Thank you, 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
