[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

Denis Lila dlila at redhat.com
Fri Sep 3 13:03:04 UTC 2010


> the cost of the context switches into native and back for each path
> segment dominate the performance of long paths.

I see. That makes sense.

> 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).

Do you think this will still be worth it after removing flattening?

Thanks,
Denis.

----- "Jim Graham" <james.graham at 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
  
> 
> 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.graham at 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.graham at 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



More information about the 2d-dev mailing list