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

[Denis Lila]

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