> 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" wrote:
>
> - "Jim Graham" 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" 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" 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 pisce
