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" 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 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
