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

[Denis Lila]

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.graham at 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"<dlila at redhat.com>  wrote:
> >
> >
> >>
> >> ----- "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