[OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code
dlila at redhat.com
Mon Aug 9 21:03:01 UTC 2010
----- Forwarded Message -----
From: "Denis Lila" <dlila at redhat.com>
To: "Jim Graham" <james.graham at oracle.com>
Sent: Monday, August 9, 2010 4:58:10 PM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code
Good idea. I've implemented it. I also noticed the quicksort
method wasn't very friendly to 0 length arrays. I fixed that.
I ran Java2Demo and a few of my tests, and everything looks good.
Everything, except the joins demo, that is. The interior of the
star's right arm (our left) and left leg is not drawn exactly like
in proprietary java or openjdk6. I am not sure if this is a bug
since I don't know exactly how the results of a bs.createStrokedShape
are supposed to look. However, I am almost certain that this
isn't my fault, since I can reproduce the behaviour with an only
slightly changed version of openjdk7 with completely different
changes than what's in this patch. I'll run it next morning with
a fresh build of openjdk7 to be completely sure.
Can I push it?
----- "Jim Graham" <james.graham at oracle.com> wrote:
> To the end of getting rid of "flips" - all they are used for is to
> resize the crossings array, right? This is not a huge array that
> a lot to resize - why not simply use a default array of, say, 30
> elements and then resize it if we ever have more crossings than that?
> Only very complicated paths would have more than 30 crossings to
> The check for array length is only needed once per scanline since we
> know how many active edges are on each scan line (hi-lo) and you can
> only have 1 crossing per active edge so with one test per scanline we
> can keep the crossings array within range...
> Jim Graham wrote:
> > Hi Denis,
> > Well, I guess it's a good thing that Java2Demo had a path like that
> > it - not a very common case, so it's good we found it!
> > The fix looks fine. It still seems like there is way more logic
> > than is needed - hopefully if we can get rid of flips at some point,
> > much of it will go away.
> > Fixes look good to go to me...
> > ...jim
> > On 8/5/2010 3:58 PM, Denis Lila wrote:
> >> Hi Jim.
> >> I didn't know about Java2Demo. If I did I would have run it
> >> But I ran it a few hours ago, and everything looked fine
> >> high fps too) until I got to the append test.
> >> Apparently I introduced a bug when solving the "2 consecutive
> >> bug".
> >> Basically, when there's a close() after a horizontal lineTo(), the
> >> in close() won't be executed because it's inside the if
> >> (firstOrientation != 0)
> >> test. So instead of going back to the starting point, close will
> >> where
> >> it is, which will draw a triangle above the rectangle.
> >> I fixed this by introducing a variable that keeps track of the last
> >> method
> >> called (lineTo, moveTo, or close), and instead of checking for
> >> firstOrientation != 0
> >> in close(), I check for (last == LINE_TO).
> >> webrev (hopefully final):
> >> http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/
> >> I'm sorry about this. I wish I had known about Java2Demo sooner.
> >> Thanks,
> >> Denis.
> >> ----- "Jim Graham"<james.graham at oracle.com> wrote:
> >>> Hi Denis,
> >>> That's great! I just did a last minute double-check of your last
> >>> (final) webrevs to be sure.
> >>> Have you tested Java2Demo with these changes? I'd also run any
> >>> regression tests you can find with the changes. If there are no
> >>> problems there, then you are good to go to push it...
> >>> ...jim
> >>> On 8/5/2010 8:08 AM, Denis Lila wrote:
> >>>> Hello.
> >>>>> Are you a registered OpenJDK developer?
> >>>> I am now.
> >>>> Can I go ahead and push it?
> >>>> Regards,
> >>>> Denis.
More information about the 2d-dev