From dlila at redhat.com  Wed Sep  1 21:51:51 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 1 Sep 2010 17:51:51 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <2086388786.3985441283377194819.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1548541835.3986441283377911110.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

> I think this would actually ensure that every resulting curve can 
> be rotated to be made monotonic in both x and y (at least after 
> inflections are eliminated), which means it's at least as good as
> what I have now.

While that first statement is true, it unfortunately does not mean it's
"at least as good as" breaking the curve into monotonic pieces. I
implemented the angle checking method, and the problem is that for
curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's
because I implemented it by subdividing at t=0.5, so the angles
in the resulting curves' polygons are still wide. After enough
subdivisions the polygons would have angles below 45, but that would
defeat the point, since we're trying to minimize the number of output
curves.
I can't think of a good way to chose the subdivision t so that
this method is as good as the rotation and make monotonic one (nothing
with any properties I can prove, anyway), so I'll implement the 
rotating version, as much as I don't like it. At least it gives a good
upper bound in the number of output curves.

Regards,
Denis.

----- "Denis Lila" <dlila at redhat.com> wrote:

> Hello Jim.
> Thanks for taking the time to think about this.
> 
> I implemented a few different offsetting schemes. On well behaved
> curves, my original "parallel first and last control vectors and go
> through B(0.5)" algorithm was by far the best. Theoretically it is
> also somewhat better justified than the others (some of which were
> like Apache Harmony's way - offsetting p2 and p3), since we're
> interpolating instead of just using some heuristic. It is also
> the only one I've encountered that widens quarter circles optimally,
> and it only needs one curve per side too (i.e. if we have to widen
> the path of a PathIterator of a circle with radius r, using width w,
> Pisces' output will be identical to the output of the PathIterators
> of 2 circles with radii r+w and r-w (perhaps not identical identical,
> since PathIterators can use doubles, and we only use floats in pisces,
> but... that's nitpicking)).
> 
> As I've said before, the only 2 problems with it were that it was bad
> on high curvatures (but this was fixed by breaking down the curves
> into
> monotonic ones), and it was bad on curves like
> p.moveTo(0,0);p.curveTo(100,100,0,100,100,1). I thought the latter was
> fixable with the "d1/(d1+d2)" algorithm I suggested in my previous
> e-mail.
> I implemented it, and it turns out I was wrong. Then I came up with my
> own
> variation of that algorithm (the original one I used was from Don
> Lancaster's
> website) that did sort of work. But then I implemented your suggestion
> of
> splitting the curve at the inflection points as well as breaking it
> into
> monotonic pieces, and the problem was gone. I didn't even have to use
> the
> fancy variation of the "d1/(d1 + d2)" algorithm - just the plain old
> interpolation one worked (I should say that the fancy one is still
> probably
> better, but undetectably so, now that we break at inflection points
> and at
> xy direction changes, so the added complexity is probably not worth
> it).
> 
> I've attached my latest Stroker.java, if you want to take a look at
> these
> algorithms (they're in computeOffsetWay1 (for the old interpolation)
> and
> computeOffsetWay3 (for the fancy version). There are 2 more, but these
> aren't as good, and one is just shameful). I didn't make a webrev
> because
> I still need to fix how it handles cusps (which should be easy), and I
> need to implement a way to avoid subdividing a rotated quarter circle.
> I can do this either by rotating curves so that p2-p1 is parallel to
> the
> x axis and then subdivide like I do now (i.e. make monotonic, break at
> inflections) or get rid of the monotonic subdivision, and instead
> subdivide
> by checking the angles of the control polygon. I could make it so it
> subdivides whenever the angles between p2-p1 and p3-p2 or p3-p2 and
> p4-p3
> are greater than 45 degrees. 
> 
> Very well. I've convinced myself. I'll implement the latter.
> 
> Thanks,
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
> > Hi Denis,
> >
> > Just to let you know that I've seen this and I'm thinking.
> >
> > But it will take a bit of "more thinking" when I have time for more.
> > Hopefully in a couple of days.
> >
> > For one thing, it sounds like you already understand the Apache
> > Harmony
> > approach quite a bit better than I ever did and, in particular, why
> it
> >
> > didn't work well - which is encouraging.  Hopefully your solution
> will
> >
> > sound pretty good when I get around to wrapping my head around it...
> >
> > 			...jim
> >
> > On 8/30/2010 3:03 PM, Denis Lila wrote:
> > > Hello Jim.
> > >
> > >> One way in which they may not break enough is that I think that
> > >> inflections also need to be broken in order to find a parallel
> > curve
> > >> (though I suppose a very tiny inflection might still be
> > approximated by
> > >> a parallel curve easily) and inflections can happen at any angle
> > without
> > >> going horizontal or vertical.
> > >
> > >      It wouldn't be hard to add additional breaks at the
> inflection
> > points.
> > >
> > >> Secondly, although a circle tends to be represented by quadrant
> > sections
> > >> which are monotonic, a circle rotated by 45 degrees would have
> > >> horizontal and vertical sections in the middle of each quadrant
> and
> > you
> > >> would split those, but really they can be made parallel
> regardless
> > of
> > >> angle so these would be unnecessary splits.
> > >
> > >      That's true, and it's one reason I didn't like my method very
> > much when I sent
> > > my previous e-mail. However, what if we rotated curves so that
> B'(0)
> > is
> > > parallel to the x-axis before splitting at points where dx/dt or
> > dy/dt are 0?
> > > This would certainly get rid of this problem for circles, and
> > probably for
> > > other curves. All it would cost is 1 Math.cos and 1 Math.sin and a
> > few
> > > multiplications and additions per curve.
> > >
> > > The biggest problem with my implementation was that some curves
> that
> > were almost
> > > lines were drawn horribly. I computed the parallel (p1', p2', p3',
> > p4') of
> > > a given curve (p1, p2, p3, p4) by making p2'-p1' parallel to
> p2-p1,
> > > making p4'-p3' parallel to p4-p3. This leaves a 2 unknowns, so to
> > get 2 more
> > > equations I made the computed parallel at t=0.5 equal to the ideal
> > parallel
> > > at t=0.5. The problem was that for some curves (ones with very
> high
> > curvature)
> > > p2'-p1' and p4'-p3' were parallel to p2-p1 and p4-p3 but their
> > directions were
> > > opposite, so you can imagine what the computed "parallel" looked
> > like.
> > > However, I am almost certain that the problem was caused by making
> > C(0.5) = P(0.5)
> > > (where C is the computed curve, and P is the ideal parallel). A
> much
> > better
> > > restriction, that I think would eliminate the problem would be
> > C(d1/(d1 + d2)) = P(0.5).
> > > where d1 = ||P(0.5)-P(0)|| and d2 = ||P(1)-P(0.5)||.
> > >
> > >> My belief is that lengths and angles of the control polygon help
> > >> determine if it is well-behaved and can be made parallel simply
> by
> > >> offsetting.  Some formula involving those values would likely be
> > happy
> > >> with circle sections regardless of their angle of rotation.  I
> > believe
> > >> the Apache Harmony version of BasicStroke used those criteria...
> > >
> > >      I've been reading the Apache Harmony file. The way they do it
> > is compute
> > > the tangent of an angle using the line width and a predefined
> > constant
> > > (which doesn't seem to be related to the curve's polygon - it's
> just
> > a decreasing
> > > function with the range (-1,1)), and if some angles in the polygon
> > are smaller than
> > > the computed angle, offset curves are computed. Otherwise the
> curve
> > is subdivided.
> > > However, I can't understand how offsets for the control points are
> > computed (i.e.
> > > why they use the equations they use, and why they work).
> > > If we're using the widening of quarter circles as a yard stick,
> then
> > Apache Harmony's
> > > BasicStroke does not do very well. If we have a quarter circle
> from
> > (1,0) to (0,1),
> > > then the control points c1 and c2 should be (1,k) and (k,1) where
> k
> > = 4*(sqrt(2)-1)/3.
> > > A parallel curve w away from this quarter circle should have
> control
> > points
> > > (1+w,k+k*w) and (k+k*w,1+w). I traced Apache Harmony's
> computations
> > on a quarter
> > > circle, and this is not what it outputs. Furthermore, all quarter
> > circles with line
> > > width<  9.65 will be subdivided. My method with the modifications
> > suggested above
> > > doesn't have these problems.
> > >
> > >      But perhaps it's better to not interpolate through P(0.5)
> after
> > all.
> > > In addition to making p4'-p3' and p2'-p1' parallel to p4-p3 and
> > p2-p1, we could
> > > also make p3'-p2' parallel to p3-p2. These constraints leave just
> > one unknown, which
> > > needs to be eliminated. I am not sure how to do this. I thought
> > about making the line
> > > (p2',p3') be a distance of w from (p2,p3) (which is exactly what
> > needs to be done for
> > > (p1',p2') and (p3',p4')) but this doesn't get us what we want for
> > quarter circles. So, finding
> > > the control points would boil down to finding intersections of 3
> > lines.
> > >
> > > Do you have any suggestions on how to do the offsetting for the
> > control points?
> > >
> > > Thank you,
> > > Denis.
> > >
> > > ----- "Jim Graham"<james.graham at oracle.com>  wrote:
> > >
> > >> Hi Denis,
> > >>
> > >> At the bottom-most rendering level monotonic curves can be cool
> to
> > deal
> > >> with, but I'm dubious that they help with widening.  For one
> > things, I
> > >> think you need more breaks than they would give you and also they
> > might
> > >> sometimes break a curve when it doesn't need it.
> > >>
> > >> 		...jim
> > >>
> > >> On 8/25/2010 2:36 PM, Denis Lila wrote:
> > >>> Hello Jim.
> > >>>
> > >>>> I think a more dynamic approach that looked at how "regular"
> the
> > >> curve
> > >>>> was would do better.  Regular is hard to define, but for
> > instance
> > >> a
> > >>>> bezier section of a circle could have parallel curves computed
> > >> very
> > >>>> easily without having to flatten or subdivide further.  Curves
> > >> with
> > >>>> inflections probably require subdividing to get an accurate
> > >> parallel
> > >>>> curve.
> > >>>
> > >>> I'm not sure if you read it, but after the email with the webrev
> > >> link
> > >>> I sent another describing a different method of widening: split
> > the
> > >>> curve at every t where dx/dt == 0 and dy/dt == 0. This
> guarantees
> > >> that
> > >>> there will be no more than 5 curves per side, and since each
> > curve
> > >> will
> > >>> be monotonic in both x and y the curve that interpolates its
> > >> parallel
> > >>> should do a pretty good job.
> > >>>
> > >>> This is far better than interpolating at regular t intervals,
> but
> > >> I'm
> > >>> trying to find a better way. I don't like this because the split
> > >>> depend not only on the curve itself, but also on the axes. The
> > axes
> > >> are
> > >>> arbitrary, so this is not good. For example a curve like this
> > >>> |
> > >>> \_ would get widened by 1 curve per side (which is good and
> > >> optimal), but
> > >>> if we rotate this curve by, say, 30 degrees it would be widened
> by
> > 2
> > >> curves
> > >>> per side.
> > >>> It also doesn't handle cusps and locations of high curvature
> very
> > >> well (although
> > >>> I think the latter is a numerical issue that could be made
> better
> > by
> > >> using
> > >>> doubles).
> > >>>
> > >>> Regards,
> > >>> Denis.
> > >>>
> > >>> ----- "Jim Graham"<james.graham at oracle.com>   wrote:
> > >>>
> > >>>> Hi Denis,
> > >>>>
> > >>>> On 8/23/2010 4:18 PM, Denis Lila wrote:
> > >>>>>        To widen cubic curves, I use a cubic spline with a
> fixed
> > >> number
> > >>>> of curves for
> > >>>>> each curve to be widened. This was meant to be temporary,
> until
> > I
> > >>>> could find a
> > >>>>> better algorithm for determining the number of curves in the
> > >> spline,
> > >>>> but I
> > >>>>> discovered today that that won't do it.
> > >>>>>        For example, the curve p.moveTo(0,0),p.curveTo(84.0,
> > 62.0,
> > >>>> 32.0, 34.0, 28.0, 5.0)
> > >>>>> looks bad all the way up to ~200 curves. Obviously, this is
> > >>>> unacceptable.
> > >>>>>
> > >>>>> It would be great if anyone has any better ideas for how to go
> > >> about
> > >>>> this.
> > >>>>> To me it seems like the problem is that in the webrev I chop
> up
> > >> the
> > >>>> curve to be
> > >>>>> interpolated at equal intervals of the parameter.
> > >>>
> > >>>>
> > >>>> Perhaps looking at the rate of change of the slope (2nd and/or
> > 3rd
> > >>>> derivatives) would help to figure out when a given section of
> > >> curve
> > >>>> can
> > >>>> be approximated with a parallel version?
> > >>>>
> > >>>> I believe that the BasicStroke class of Apache Harmony returns
> > >> widened
> > >>>>
> > >>>> curves, but when I tested it it produced a lot more curves than
> > >> Ductus
> > >>>>
> > >>>> (still, probably a lot less than the lines that would be
> > produced
> > >> by
> > >>>> flattening) and it had some numerical problems.  In the end I
> > >> decided
> > >>>> to
> > >>>> leave our Ductus stuff in there until someone could come up
> with
> > a
> > >>>> more
> > >>>> reliable Open Source replacement, but hopefully that code is
> > close
> > >>>> enough to be massaged into working order.
> > >>>>
> > >>>> You can search the internet for "parallel curves" and find lots
> > of
> > >>>> literature on the subject.  I briefly looked through the web
> > >> sites,
> > >>>> but
> > >>>> didn't have enough time to remember enough calculus and
> > >> trigonometry
> > >>>> to
> > >>>> garner a solution out of it all with the time that I had. 
> Maybe
> > >>>> you'll
> > >>>> have better luck following the algorithms... ;-)
> > >>>>
> > >>>> As far as flattening at the lowest level when doing scanline
> > >>>> conversion,
> > >>>> I like the idea of using forward differencing as it can create
> > an
> > >>>> algorithm that doesn't require all of the intermediate storage
> > that
> > >> a
> > >>>>
> > >>>> subdividing flattener requires.  One reference that describes
> > the
> > >>>> technique is on Dr. Dobbs site, though I imagine there are many
> > >>>> others:
> > >>>>
> > >>>>
> > >>
> >
> http://www.drdobbs.com/184403417;jsessionid=O5N5MDJRDMIKHQE1GHOSKH4ATMY32JVN
> > >>>>
> > >>>> You can also look at the code in
> > >>>> src/share/native/sun/java2d/pipe/ProcessPath.c for some
> examples
> > >> of
> > >>>> forward differencing in use (and that code also has similar
> > >> techniques
> > >>>>
> > >>>> to what you did to first chop the path into vertical pieces).
> > BUT
> > >>>> (*Nota Bene*), I must warn you that the geometry of the path is
> > >>>> somewhat
> > >>>> perturbed in that code since it tries to combine "path
> > >> normalization"
> > >>>>
> > >>>> and rasterization into a single process.  It's not rendering
> > pure
> > >>>> geometry, it is rendering tweaked geometry which tries to make
> > >> non-AA
> > >>>>
> > >>>> circles look round and other such aesthetics-targeted
> > impurities.
> > >>>> While
> > >>>> the code does have good examples of how to set up and evaluate
> > >> forward
> > >>>>
> > >>>> differencing equations, don't copy too many of the details or
> > you
> > >>>> might
> > >>>> end up copying some of the tweaks and the results will look
> > >> strange
> > >>>> under AA.  The Dr. Dobbs article should be your numerical
> > >> reference
> > >>>> and
> > >>>> that reference code a practical, but incompatible, example...
> > >>>>
> > >>>> 			...jim


From dlila at redhat.com  Thu Sep  2 14:08:58 2010
From: dlila at redhat.com (Denis Lila)
Date: Thu, 2 Sep 2010 10:08:58 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <631760858.4032811283436393009.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1505054830.4033161283436538688.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

Sorry for all the e-mails.
I implemented the rotating version. The rotation introduces small
numerical errors, so when I solve for the roots of dx/dt and dy/dt,
the values of t I get are slightly off. So for a rotated quarter
circle, what happens is that it gives me a root at, say, t=0.9996...
so I still end up subdividing quarter circles. I "fixed" this by
ignoring all roots outside of (0.001,0.999), instead of ignoring
roots outside of (0,1) which is the ideal solution. I don't like
hardcoding constants like this. Add to this the higher complexity
of the rotation, and I'm tempted to say it might be better to just
bite the bullet on rotated quarter circles and widen them using 2
curves per side.

I had one question: what do you think of widening all curves using
quadratic curves? Their great simplicity might make things safer. We
can guarantee that none of the strange behaviour I've seen and described
with cubic curves will arise (but we'd have to use more of them).

Also, I've tested the current implementation with a few hundred random
cubic paths, and everything looks good so far.

Thanks,
Denis.

----- "Denis Lila" <dlila at redhat.com> wrote:

> Hello Jim.
> 
> > I think this would actually ensure that every resulting curve can
> > be rotated to be made monotonic in both x and y (at least after
> > inflections are eliminated), which means it's at least as good as
> > what I have now.
> 
> While that first statement is true, it unfortunately does not mean
> it's
> "at least as good as" breaking the curve into monotonic pieces. I
> implemented the angle checking method, and the problem is that for
> curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's
> because I implemented it by subdividing at t=0.5, so the angles
> in the resulting curves' polygons are still wide. After enough
> subdivisions the polygons would have angles below 45, but that would
> defeat the point, since we're trying to minimize the number of output
> curves.
> I can't think of a good way to chose the subdivision t so that
> this method is as good as the rotation and make monotonic one (nothing
> with any properties I can prove, anyway), so I'll implement the
> rotating version, as much as I don't like it. At least it gives a good
> upper bound in the number of output curves.
> 
> Regards,
> Denis.
> 
> ----- "Denis Lila" <dlila at redhat.com> wrote:
> 
> > Hello Jim.
> > Thanks for taking the time to think about this.
> >
> > I implemented a few different offsetting schemes. On well behaved
> > curves, my original "parallel first and last control vectors and go
> > through B(0.5)" algorithm was by far the best. Theoretically it is
> > also somewhat better justified than the others (some of which were
> > like Apache Harmony's way - offsetting p2 and p3), since we're
> > interpolating instead of just using some heuristic. It is also
> > the only one I've encountered that widens quarter circles optimally,
> > and it only needs one curve per side too (i.e. if we have to widen
> > the path of a PathIterator of a circle with radius r, using width w,
> > Pisces' output will be identical to the output of the PathIterators
> > of 2 circles with radii r+w and r-w (perhaps not identical
> identical,
> > since PathIterators can use doubles, and we only use floats in
> pisces,
> > but... that's nitpicking)).
> >
> > As I've said before, the only 2 problems with it were that it was
> bad
> > on high curvatures (but this was fixed by breaking down the curves
> > into
> > monotonic ones), and it was bad on curves like
> > p.moveTo(0,0);p.curveTo(100,100,0,100,100,1). I thought the latter
> was
> > fixable with the "d1/(d1+d2)" algorithm I suggested in my previous
> > e-mail.
> > I implemented it, and it turns out I was wrong. Then I came up with
> my
> > own
> > variation of that algorithm (the original one I used was from Don
> > Lancaster's
> > website) that did sort of work. But then I implemented your
> suggestion
> > of
> > splitting the curve at the inflection points as well as breaking it
> > into
> > monotonic pieces, and the problem was gone. I didn't even have to
> use
> > the
> > fancy variation of the "d1/(d1 + d2)" algorithm - just the plain old
> > interpolation one worked (I should say that the fancy one is still
> > probably
> > better, but undetectably so, now that we break at inflection points
> > and at
> > xy direction changes, so the added complexity is probably not worth
> > it).
> >
> > I've attached my latest Stroker.java, if you want to take a look at
> > these
> > algorithms (they're in computeOffsetWay1 (for the old interpolation)
> > and
> > computeOffsetWay3 (for the fancy version). There are 2 more, but
> these
> > aren't as good, and one is just shameful). I didn't make a webrev
> > because
> > I still need to fix how it handles cusps (which should be easy), and
> I
> > need to implement a way to avoid subdividing a rotated quarter
> circle.
> > I can do this either by rotating curves so that p2-p1 is parallel to
> > the
> > x axis and then subdivide like I do now (i.e. make monotonic, break
> at
> > inflections) or get rid of the monotonic subdivision, and instead
> > subdivide
> > by checking the angles of the control polygon. I could make it so it
> > subdivides whenever the angles between p2-p1 and p3-p2 or p3-p2 and
> > p4-p3
> > are greater than 45 degrees.
> >
> > Very well. I've convinced myself. I'll implement the latter.
> >
> > Thanks,
> > Denis.
> >
> > ----- "Jim Graham" <james.graham at oracle.com> wrote:
> >
> > > Hi Denis,
> > >
> > > Just to let you know that I've seen this and I'm thinking.
> > >
> > > But it will take a bit of "more thinking" when I have time for
> more.
> > > Hopefully in a couple of days.
> > >
> > > For one thing, it sounds like you already understand the Apache
> > > Harmony
> > > approach quite a bit better than I ever did and, in particular,
> why
> > it
> > >
> > > didn't work well - which is encouraging.  Hopefully your solution
> > will
> > >
> > > sound pretty good when I get around to wrapping my head around
> it...
> > >
> > > 			...jim
> > >
> > > On 8/30/2010 3:03 PM, Denis Lila wrote:
> > > > Hello Jim.
> > > >
> > > >> One way in which they may not break enough is that I think that
> > > >> inflections also need to be broken in order to find a parallel
> > > curve
> > > >> (though I suppose a very tiny inflection might still be
> > > approximated by
> > > >> a parallel curve easily) and inflections can happen at any
> angle
> > > without
> > > >> going horizontal or vertical.
> > > >
> > > >      It wouldn't be hard to add additional breaks at the
> > inflection
> > > points.
> > > >
> > > >> Secondly, although a circle tends to be represented by quadrant
> > > sections
> > > >> which are monotonic, a circle rotated by 45 degrees would have
> > > >> horizontal and vertical sections in the middle of each quadrant
> > and
> > > you
> > > >> would split those, but really they can be made parallel
> > regardless
> > > of
> > > >> angle so these would be unnecessary splits.
> > > >
> > > >      That's true, and it's one reason I didn't like my method
> very
> > > much when I sent
> > > > my previous e-mail. However, what if we rotated curves so that
> > B'(0)
> > > is
> > > > parallel to the x-axis before splitting at points where dx/dt or
> > > dy/dt are 0?
> > > > This would certainly get rid of this problem for circles, and
> > > probably for
> > > > other curves. All it would cost is 1 Math.cos and 1 Math.sin and
> a
> > > few
> > > > multiplications and additions per curve.
> > > >
> > > > The biggest problem with my implementation was that some curves
> > that
> > > were almost
> > > > lines were drawn horribly. I computed the parallel (p1', p2',
> p3',
> > > p4') of
> > > > a given curve (p1, p2, p3, p4) by making p2'-p1' parallel to
> > p2-p1,
> > > > making p4'-p3' parallel to p4-p3. This leaves a 2 unknowns, so
> to
> > > get 2 more
> > > > equations I made the computed parallel at t=0.5 equal to the
> ideal
> > > parallel
> > > > at t=0.5. The problem was that for some curves (ones with very
> > high
> > > curvature)
> > > > p2'-p1' and p4'-p3' were parallel to p2-p1 and p4-p3 but their
> > > directions were
> > > > opposite, so you can imagine what the computed "parallel" looked
> > > like.
> > > > However, I am almost certain that the problem was caused by
> making
> > > C(0.5) = P(0.5)
> > > > (where C is the computed curve, and P is the ideal parallel). A
> > much
> > > better
> > > > restriction, that I think would eliminate the problem would be
> > > C(d1/(d1 + d2)) = P(0.5).
> > > > where d1 = ||P(0.5)-P(0)|| and d2 = ||P(1)-P(0.5)||.
> > > >
> > > >> My belief is that lengths and angles of the control polygon
> help
> > > >> determine if it is well-behaved and can be made parallel simply
> > by
> > > >> offsetting.  Some formula involving those values would likely
> be
> > > happy
> > > >> with circle sections regardless of their angle of rotation.  I
> > > believe
> > > >> the Apache Harmony version of BasicStroke used those
> criteria...
> > > >
> > > >      I've been reading the Apache Harmony file. The way they do
> it
> > > is compute
> > > > the tangent of an angle using the line width and a predefined
> > > constant
> > > > (which doesn't seem to be related to the curve's polygon - it's
> > just
> > > a decreasing
> > > > function with the range (-1,1)), and if some angles in the
> polygon
> > > are smaller than
> > > > the computed angle, offset curves are computed. Otherwise the
> > curve
> > > is subdivided.
> > > > However, I can't understand how offsets for the control points
> are
> > > computed (i.e.
> > > > why they use the equations they use, and why they work).
> > > > If we're using the widening of quarter circles as a yard stick,
> > then
> > > Apache Harmony's
> > > > BasicStroke does not do very well. If we have a quarter circle
> > from
> > > (1,0) to (0,1),
> > > > then the control points c1 and c2 should be (1,k) and (k,1)
> where
> > k
> > > = 4*(sqrt(2)-1)/3.
> > > > A parallel curve w away from this quarter circle should have
> > control
> > > points
> > > > (1+w,k+k*w) and (k+k*w,1+w). I traced Apache Harmony's
> > computations
> > > on a quarter
> > > > circle, and this is not what it outputs. Furthermore, all
> quarter
> > > circles with line
> > > > width<  9.65 will be subdivided. My method with the
> modifications
> > > suggested above
> > > > doesn't have these problems.
> > > >
> > > >      But perhaps it's better to not interpolate through P(0.5)
> > after
> > > all.
> > > > In addition to making p4'-p3' and p2'-p1' parallel to p4-p3 and
> > > p2-p1, we could
> > > > also make p3'-p2' parallel to p3-p2. These constraints leave
> just
> > > one unknown, which
> > > > needs to be eliminated. I am not sure how to do this. I thought
> > > about making the line
> > > > (p2',p3') be a distance of w from (p2,p3) (which is exactly what
> > > needs to be done for
> > > > (p1',p2') and (p3',p4')) but this doesn't get us what we want
> for
> > > quarter circles. So, finding
> > > > the control points would boil down to finding intersections of 3
> > > lines.
> > > >
> > > > Do you have any suggestions on how to do the offsetting for the
> > > control points?
> > > >
> > > > Thank you,
> > > > Denis.
> > > >
> > > > ----- "Jim Graham"<james.graham at oracle.com>  wrote:
> > > >
> > > >> Hi Denis,
> > > >>
> > > >> At the bottom-most rendering level monotonic curves can be cool
> > to
> > > deal
> > > >> with, but I'm dubious that they help with widening.  For one
> > > things, I
> > > >> think you need more breaks than they would give you and also
> they
> > > might
> > > >> sometimes break a curve when it doesn't need it.
> > > >>
> > > >> 		...jim
> > > >>
> > > >> On 8/25/2010 2:36 PM, Denis Lila wrote:
> > > >>> Hello Jim.
> > > >>>
> > > >>>> I think a more dynamic approach that looked at how "regular"
> > the
> > > >> curve
> > > >>>> was would do better.  Regular is hard to define, but for
> > > instance
> > > >> a
> > > >>>> bezier section of a circle could have parallel curves
> computed
> > > >> very
> > > >>>> easily without having to flatten or subdivide further. 
> Curves
> > > >> with
> > > >>>> inflections probably require subdividing to get an accurate
> > > >> parallel
> > > >>>> curve.
> > > >>>
> > > >>> I'm not sure if you read it, but after the email with the
> webrev
> > > >> link
> > > >>> I sent another describing a different method of widening:
> split
> > > the
> > > >>> curve at every t where dx/dt == 0 and dy/dt == 0. This
> > guarantees
> > > >> that
> > > >>> there will be no more than 5 curves per side, and since each
> > > curve
> > > >> will
> > > >>> be monotonic in both x and y the curve that interpolates its
> > > >> parallel
> > > >>> should do a pretty good job.
> > > >>>
> > > >>> This is far better than interpolating at regular t intervals,
> > but
> > > >> I'm
> > > >>> trying to find a better way. I don't like this because the
> split
> > > >>> depend not only on the curve itself, but also on the axes. The
> > > axes
> > > >> are
> > > >>> arbitrary, so this is not good. For example a curve like this
> > > >>> |
> > > >>> \_ would get widened by 1 curve per side (which is good and
> > > >> optimal), but
> > > >>> if we rotate this curve by, say, 30 degrees it would be
> widened
> > by
> > > 2
> > > >> curves
> > > >>> per side.
> > > >>> It also doesn't handle cusps and locations of high curvature
> > very
> > > >> well (although
> > > >>> I think the latter is a numerical issue that could be made
> > better
> > > by
> > > >> using
> > > >>> doubles).
> > > >>>
> > > >>> Regards,
> > > >>> Denis.
> > > >>>
> > > >>> ----- "Jim Graham"<james.graham at oracle.com>   wrote:
> > > >>>
> > > >>>> Hi Denis,
> > > >>>>
> > > >>>> On 8/23/2010 4:18 PM, Denis Lila wrote:
> > > >>>>>        To widen cubic curves, I use a cubic spline with a
> > fixed
> > > >> number
> > > >>>> of curves for
> > > >>>>> each curve to be widened. This was meant to be temporary,
> > until
> > > I
> > > >>>> could find a
> > > >>>>> better algorithm for determining the number of curves in the
> > > >> spline,
> > > >>>> but I
> > > >>>>> discovered today that that won't do it.
> > > >>>>>        For example, the curve p.moveTo(0,0),p.curveTo(84.0,
> > > 62.0,
> > > >>>> 32.0, 34.0, 28.0, 5.0)
> > > >>>>> looks bad all the way up to ~200 curves. Obviously, this is
> > > >>>> unacceptable.
> > > >>>>>
> > > >>>>> It would be great if anyone has any better ideas for how to
> go
> > > >> about
> > > >>>> this.
> > > >>>>> To me it seems like the problem is that in the webrev I chop
> > up
> > > >> the
> > > >>>> curve to be
> > > >>>>> interpolated at equal intervals of the parameter.
> > > >>>
> > > >>>>
> > > >>>> Perhaps looking at the rate of change of the slope (2nd
> and/or
> > > 3rd
> > > >>>> derivatives) would help to figure out when a given section of
> > > >> curve
> > > >>>> can
> > > >>>> be approximated with a parallel version?
> > > >>>>
> > > >>>> I believe that the BasicStroke class of Apache Harmony
> returns
> > > >> widened
> > > >>>>
> > > >>>> curves, but when I tested it it produced a lot more curves
> than
> > > >> Ductus
> > > >>>>
> > > >>>> (still, probably a lot less than the lines that would be
> > > produced
> > > >> by
> > > >>>> flattening) and it had some numerical problems.  In the end I
> > > >> decided
> > > >>>> to
> > > >>>> leave our Ductus stuff in there until someone could come up
> > with
> > > a
> > > >>>> more
> > > >>>> reliable Open Source replacement, but hopefully that code is
> > > close
> > > >>>> enough to be massaged into working order.
> > > >>>>
> > > >>>> You can search the internet for "parallel curves" and find
> lots
> > > of
> > > >>>> literature on the subject.  I briefly looked through the web
> > > >> sites,
> > > >>>> but
> > > >>>> didn't have enough time to remember enough calculus and
> > > >> trigonometry
> > > >>>> to
> > > >>>> garner a solution out of it all with the time that I had.
> > Maybe
> > > >>>> you'll
> > > >>>> have better luck following the algorithms... ;-)
> > > >>>>
> > > >>>> As far as flattening at the lowest level when doing scanline
> > > >>>> conversion,
> > > >>>> I like the idea of using forward differencing as it can
> create
> > > an
> > > >>>> algorithm that doesn't require all of the intermediate
> storage
> > > that
> > > >> a
> > > >>>>
> > > >>>> subdividing flattener requires.  One reference that describes
> > > the
> > > >>>> technique is on Dr. Dobbs site, though I imagine there are
> many
> > > >>>> others:
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> http://www.drdobbs.com/184403417;jsessionid=O5N5MDJRDMIKHQE1GHOSKH4ATMY32JVN
> > > >>>>
> > > >>>> You can also look at the code in
> > > >>>> src/share/native/sun/java2d/pipe/ProcessPath.c for some
> > examples
> > > >> of
> > > >>>> forward differencing in use (and that code also has similar
> > > >> techniques
> > > >>>>
> > > >>>> to what you did to first chop the path into vertical pieces).
> > > BUT
> > > >>>> (*Nota Bene*), I must warn you that the geometry of the path
> is
> > > >>>> somewhat
> > > >>>> perturbed in that code since it tries to combine "path
> > > >> normalization"
> > > >>>>
> > > >>>> and rasterization into a single process.  It's not rendering
> > > pure
> > > >>>> geometry, it is rendering tweaked geometry which tries to
> make
> > > >> non-AA
> > > >>>>
> > > >>>> circles look round and other such aesthetics-targeted
> > > impurities.
> > > >>>> While
> > > >>>> the code does have good examples of how to set up and
> evaluate
> > > >> forward
> > > >>>>
> > > >>>> differencing equations, don't copy too many of the details or
> > > you
> > > >>>> might
> > > >>>> end up copying some of the tweaks and the results will look
> > > >> strange
> > > >>>> under AA.  The Dr. Dobbs article should be your numerical
> > > >> reference
> > > >>>> and
> > > >>>> that reference code a practical, but incompatible, example...
> > > >>>>
> > > >>>> 			...jim


From omajid at redhat.com  Thu Sep  2 14:51:31 2010
From: omajid at redhat.com (Omair Majid)
Date: Thu, 02 Sep 2010 10:51:31 -0400
Subject: [OpenJDK 2D-Dev] fix for 6697721 is incomplete
Message-ID: <4C7FB9F3.4090301@redhat.com>

Hi,

I recently ran into a problem with using fractional font metrics with 
OpenJDK. The attached code (FractionalTextMetricsBug.java) reproduces 
the problem and the attached image shows the result on OpenJDK6 (which 
is the same as the result on OpenJDK7).

I believe this problem was introduced with the fix for 6697721 [1] as I 
observed this behaviour with OpenJDK6 after that particular fix was 
backported. The value of advh is based on ftglyph->linearHoriAdvance, 
which is the advance for the unhinted glyph [2]. If the glyph is hinted 
(which is often the case), ftglyph->metrics.horiAdvance gives a better 
value.

The attached patch is one attempt at fixing the problem. I am not sure 
if TEXT_AA_OFF (the antialiasing mode) is related to hinting - even 
though the comments in freetypescaler say that it is. With the patch, my 
test case works, and the text is rendered correctly with antialising set 
to either VALUE_TEXT_ANTIALIAS_ON, VALUE_TEXT_ANTIALIAS_OFF or 
VALUE_TEXT_ANTIALIAS_LCD_HRGB.

Thanks,
Omair

[1] http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4092c04aeae7
[2] 
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.html#FT_GlyphSlotRec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk-fractional-metrics-advance-bug.png
Type: image/png
Size: 8439 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100902/c73d616b/openjdk-fractional-metrics-advance-bug.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: FractionalTextMetricsBug.java
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100902/c73d616b/FractionalTextMetricsBug.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk-fractional-metrics-bug.patch
Type: text/x-patch
Size: 723 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100902/c73d616b/openjdk-fractional-metrics-bug.patch>

From lana.steuck at oracle.com  Thu Sep  2 17:58:41 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 17:58:41 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 3 new changesets
Message-ID: <20100902175841.DDF634767A@hg.openjdk.java.net>

Changeset: 43096cccf1ce
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/43096cccf1ce

Added tag jdk7-b105 for changeset 9f96a4269d77

! .hgtags

Changeset: 7d396ad455c3
Author:    cl
Date:      2010-08-19 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/7d396ad455c3

Added tag jdk7-b106 for changeset 43096cccf1ce

! .hgtags

Changeset: 140fdef4ddf5
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/140fdef4ddf5

Added tag jdk7-b107 for changeset 7d396ad455c3

! .hgtags



From lana.steuck at oracle.com  Thu Sep  2 17:58:47 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 17:58:47 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 3 new changesets
Message-ID: <20100902175852.D153A4767D@hg.openjdk.java.net>

Changeset: 519daea48888
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/519daea48888

Added tag jdk7-b105 for changeset 6f21b030092f

! .hgtags

Changeset: 232adb83eae8
Author:    cl
Date:      2010-08-19 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/232adb83eae8

Added tag jdk7-b106 for changeset 519daea48888

! .hgtags

Changeset: 8d810527b499
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/8d810527b499

Added tag jdk7-b107 for changeset 232adb83eae8

! .hgtags



From lana.steuck at oracle.com  Thu Sep  2 17:59:44 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 17:59:44 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 65 new changesets
Message-ID: <20100902180141.74B7E4767E@hg.openjdk.java.net>

Changeset: 3dc64719cf18
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3dc64719cf18

Added tag jdk7-b105 for changeset 6709c14587c2

! .hgtags

Changeset: a81afd9c293c
Author:    alanb
Date:      2010-07-16 13:14 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a81afd9c293c

6649594: Intermittent IOExceptions during dynamic attach on linux and solaris
Reviewed-by: dcubed, dholmes

! src/os/linux/vm/attachListener_linux.cpp
! src/os/solaris/vm/attachListener_solaris.cpp

Changeset: 920aa833fd16
Author:    apangin
Date:      2010-07-17 21:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/920aa833fd16

Merge


Changeset: a5c9d63a187d
Author:    apangin
Date:      2010-07-20 08:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a5c9d63a187d

6964170: Verifier crashes
Summary: Check if klassOop != NULL rather than klass_part != NULL
Reviewed-by: kamg, never

! src/share/vm/classfile/verificationType.cpp
! src/share/vm/classfile/verifier.cpp

Changeset: 7f0fdccac34f
Author:    apangin
Date:      2010-07-25 07:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7f0fdccac34f

Merge

! src/share/vm/classfile/verifier.cpp

Changeset: 3d90023429ec
Author:    aph
Date:      2010-07-28 17:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3d90023429ec

6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows
Reviewed-by: dcubed, dholmes

! src/os/linux/vm/globals_linux.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: a64438a2b7e8
Author:    coleenp
Date:      2010-07-28 17:57 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a64438a2b7e8

6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue
Summary: Fix compilation errors.  Made non-const references const so can be assigned with lvalue.
Reviewed-by: phh, xlu

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp

Changeset: 126ea7725993
Author:    bobv
Date:      2010-08-03 08:13 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/126ea7725993

6953477: Increase portability and flexibility of building Hotspot
Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail.
Reviewed-by: phh, never, coleenp, dholmes

! agent/src/os/linux/ps_proc.c
! make/Makefile
! make/defs.make
! make/linux/makefiles/build_vm_def.sh
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/product.make
! make/linux/makefiles/sa.make
! make/linux/makefiles/saproc.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/defs.make
! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/interpreterRT_sparc.cpp
! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/javaFrameAnchor_x86.hpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/os/linux/launcher/java_md.c
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp
! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/includeDB_compiler1
! src/share/vm/includeDB_core
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp
! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/arrayKlassKlass.hpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.hpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constMethodKlass.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolKlass.hpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/cpCacheKlass.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/oops/klassKlass.hpp
! src/share/vm/oops/oop.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnvThreadState.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaFrameAnchor.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/sharedRuntimeTrans.cpp
! src/share/vm/runtime/signature.hpp
! src/share/vm/runtime/stubCodeGenerator.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/macros.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: e5dfb3ccb88b
Author:    kvn
Date:      2010-07-23 10:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e5dfb3ccb88b

6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value()
Summary: Add missing is_static guard.
Reviewed-by: twisti

! src/share/vm/ci/ciField.cpp
! src/share/vm/opto/macro.cpp

Changeset: 99ceb0e99c9e
Author:    never
Date:      2010-07-26 15:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/99ceb0e99c9e

Merge


Changeset: 66c5dadb4d61
Author:    kvn
Date:      2010-07-30 10:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/66c5dadb4d61

6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path()
Summary: set Z = 0 (not equal) before repne_scan() to indicate that class was not found when RCX == 0.
Reviewed-by: never, phh

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 0e35fa8ebccd
Author:    kvn
Date:      2010-08-03 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0e35fa8ebccd

6973963: SEGV in ciBlock::start_bci() with EA
Summary: Added more checks into ResourceObj and growableArray to verify correctness of allocation type.
Reviewed-by: never, coleenp, dholmes

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethodBlocks.cpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/utilities/growableArray.hpp

Changeset: 0e09207fc81b
Author:    kvn
Date:      2010-08-04 17:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0e09207fc81b

6974682: CTW: assert(target != NULL) failed: must not be null
Summary: Add address table size to constant section size.
Reviewed-by: never

! src/share/vm/opto/output.cpp

Changeset: fb8abd207dbe
Author:    kvn
Date:      2010-08-06 11:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fb8abd207dbe

6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586
Summary: Tell C++ to not inline so much by using flag -xspace.
Reviewed-by: ysr

! make/solaris/makefiles/sparcWorks.make

Changeset: 2dfd013a7465
Author:    kvn
Date:      2010-08-09 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2dfd013a7465

6975078: assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()
Summary: Pass the check in ResourceObj() if _allocation value is already set and object is allocated on stack.
Reviewed-by: dholmes, johnc

! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: f4f596978298
Author:    never
Date:      2010-08-09 17:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f4f596978298

Merge

! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 36519c19beeb
Author:    never
Date:      2010-08-10 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/36519c19beeb

6975027: use of movptr to set length of array
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: 4a665be40fd3
Author:    twisti
Date:      2010-08-11 01:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4a665be40fd3

6975855: don't emit deopt MH handler in C1 if not required
Summary: This CR implements the same for C1 as 6926782 for C2.
Reviewed-by: never

! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/code/nmethod.cpp

Changeset: d2ede61b7a12
Author:    twisti
Date:      2010-08-11 05:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d2ede61b7a12

6976186: integrate Shark HotSpot changes
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: kvn, twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! make/Makefile
! make/linux/Makefile
! make/linux/makefiles/gcc.make
+ make/linux/makefiles/shark.make
! make/linux/makefiles/top.make
! make/linux/makefiles/vm.make
! src/cpu/zero/vm/disassembler_zero.hpp
+ src/cpu/zero/vm/shark_globals_zero.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/disassembler.cpp
+ src/share/vm/includeDB_shark
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vm_version.cpp
+ src/share/vm/shark/llvmHeaders.hpp
+ src/share/vm/shark/llvmValue.hpp
+ src/share/vm/shark/sharkBlock.cpp
+ src/share/vm/shark/sharkBlock.hpp
+ src/share/vm/shark/sharkBuilder.cpp
+ src/share/vm/shark/sharkBuilder.hpp
+ src/share/vm/shark/sharkCacheDecache.cpp
+ src/share/vm/shark/sharkCacheDecache.hpp
+ src/share/vm/shark/sharkCodeBuffer.hpp
+ src/share/vm/shark/sharkCompiler.cpp
+ src/share/vm/shark/sharkCompiler.hpp
+ src/share/vm/shark/sharkConstant.cpp
+ src/share/vm/shark/sharkConstant.hpp
+ src/share/vm/shark/sharkContext.cpp
+ src/share/vm/shark/sharkContext.hpp
+ src/share/vm/shark/sharkEntry.hpp
+ src/share/vm/shark/sharkFunction.cpp
+ src/share/vm/shark/sharkFunction.hpp
+ src/share/vm/shark/sharkInliner.cpp
+ src/share/vm/shark/sharkInliner.hpp
+ src/share/vm/shark/sharkIntrinsics.cpp
+ src/share/vm/shark/sharkIntrinsics.hpp
+ src/share/vm/shark/sharkInvariants.cpp
+ src/share/vm/shark/sharkInvariants.hpp
+ src/share/vm/shark/sharkMemoryManager.cpp
+ src/share/vm/shark/sharkMemoryManager.hpp
+ src/share/vm/shark/sharkNativeWrapper.cpp
+ src/share/vm/shark/sharkNativeWrapper.hpp
+ src/share/vm/shark/sharkRuntime.cpp
+ src/share/vm/shark/sharkRuntime.hpp
+ src/share/vm/shark/sharkStack.cpp
+ src/share/vm/shark/sharkStack.hpp
+ src/share/vm/shark/sharkState.cpp
+ src/share/vm/shark/sharkState.hpp
+ src/share/vm/shark/sharkStateScanner.cpp
+ src/share/vm/shark/sharkStateScanner.hpp
+ src/share/vm/shark/sharkTopLevelBlock.cpp
+ src/share/vm/shark/sharkTopLevelBlock.hpp
+ src/share/vm/shark/sharkType.hpp
+ src/share/vm/shark/sharkValue.cpp
+ src/share/vm/shark/sharkValue.hpp
+ src/share/vm/shark/shark_globals.cpp
+ src/share/vm/shark/shark_globals.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 6c9cc03d8726
Author:    kvn
Date:      2010-08-11 10:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6c9cc03d8726

6973329: C2 with Zero based COOP produces code with broken anti-dependency on x86
Summary: Recompile without subsuming loads if RA try to clone a node with anti_dependence.
Reviewed-by: never

! src/share/vm/includeDB_compiler2
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/reg_split.cpp
+ test/compiler/6973329/Test.java

Changeset: ab3fd720516c
Author:    rasbold
Date:      2010-08-10 19:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ab3fd720516c

6378314: Bad warning message when agent library not found. local directory is not searched.
Summary: Print a more detailed error message for agent library load failure.
Reviewed-by: jcoomes, never, ohair, coleenp
Contributed-by: jeremymanson at google.com

! src/share/vm/runtime/thread.cpp

Changeset: 21e519b91576
Author:    dcubed
Date:      2010-08-13 07:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/21e519b91576

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 688a538aa654
Author:    trims
Date:      2010-08-13 10:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/688a538aa654

Merge


Changeset: 5f3c8db59d83
Author:    trims
Date:      2010-08-13 10:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5f3c8db59d83

6977051: Bump the HS19 build number to 06
Summary: Update the HS19 build number to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1b81ca701fa5
Author:    trims
Date:      2010-08-17 09:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1b81ca701fa5

Merge


Changeset: 30266066c77c
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/30266066c77c

Added tag jdk7-b106 for changeset 1b81ca701fa5

! .hgtags

Changeset: 295c3ae4ab5b
Author:    trims
Date:      2010-08-19 18:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/295c3ae4ab5b

Added tag hs19-b05 for changeset cc3fdfeb54b0

! .hgtags

Changeset: bf496cbe9b74
Author:    trims
Date:      2010-08-19 18:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/bf496cbe9b74

Added tag hs19-b06 for changeset 688a538aa654

! .hgtags

Changeset: e44a93947ccb
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e44a93947ccb

Added tag jdk7-b107 for changeset bf496cbe9b74

! .hgtags

Changeset: f6f3eef8a521
Author:    kevinw
Date:      2010-07-30 22:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f6f3eef8a521

6581734: CMS Old Gen's collection usage is zero after GC which is incorrect
Summary: Management code enabled for use by a concurrent collector.
Reviewed-by: mchung, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/services/management.cpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp
+ test/gc/6581734/Test6581734.java

Changeset: 63f4675ac87d
Author:    kevinw
Date:      2010-07-31 15:10 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/63f4675ac87d

Merge

- src/os/linux/vm/vtune_linux.cpp
- src/os/solaris/vm/vtune_solaris.cpp
- src/os/windows/vm/vtune_windows.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
- src/share/vm/runtime/vtune.hpp

Changeset: 2d160770d2e5
Author:    johnc
Date:      2010-08-02 12:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2d160770d2e5

6814437: G1: remove the _new_refs array
Summary: The per-worker _new_refs array is used to hold references that point into the collection set. It is populated during RSet updating and subsequently processed. In the event of an evacuation failure it processed again to recreate the RSets of regions in the collection set. Remove the per-worker _new_refs array by processing the references directly. Use a DirtyCardQueue to hold the cards containing the references so that the RSets of regions in the collection set can be recreated when handling an evacuation failure.
Reviewed-by: iveresov, jmasa, tonyp

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 9d7a8ab3736b
Author:    tonyp
Date:      2010-07-22 10:27 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9d7a8ab3736b

6962589: remove breadth first scanning code from parallel gc
Summary: Remove the breadth-first copying order from ParallelScavenge and use depth-first by default.
Reviewed-by: jcoomes, ysr, johnc

! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/oops/klassPS.hpp
! src/share/vm/oops/methodDataKlass.cpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlassKlass.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/symbolKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 0ce1569c90e5
Author:    tonyp
Date:      2010-08-04 13:03 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0ce1569c90e5

6963209: G1: remove the concept of abandoned pauses
Summary: As part of 6944166 we disabled the concept of abandoned pauses (i.e., if the collection set is empty, we would still try to do a pause even if it is to update the RSets and scan the roots). This changeset removes the code and structures associated with abandoned pauses.
Reviewed-by: iveresov, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

Changeset: a03ae377b2e8
Author:    johnc
Date:      2010-08-06 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a03ae377b2e8

6930581: G1: assert(ParallelGCThreads > 1 || n_yielded() == _hrrs->occupied(),"Should have yielded all the ..
Summary: During RSet updating, when ParallelGCThreads is zero, references that point into the collection set are added directly the referenced region's RSet. This can cause the sparse table in the RSet to expand. RSet scanning and the "occupied" routine will then operate on different instances of the sparse table causing the assert to trip. This may also cause some cards added post expansion to be missed during RSet scanning. When ParallelGCThreads is non-zero such references are recorded on the "references to be scanned" queue and the card containing the reference is recorded in a dirty card queue for use in the event of an evacuation failure. Employ the parallel code in the serial case to avoid expanding the RSets of regions in the collection set.
Reviewed-by: iveresov, ysr, tonyp

! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp

Changeset: 5f429ee79634
Author:    jcoomes
Date:      2010-08-09 05:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5f429ee79634

6966222: G1: simplify TaskQueue overflow handling
Reviewed-by: tonyp, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/utilities/taskqueue.cpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 94251661de76
Author:    jcoomes
Date:      2010-08-09 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/94251661de76

6970376: ParNew: shared TaskQueue statistics
Reviewed-by: ysr

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp

Changeset: a6bff45449bc
Author:    ysr
Date:      2010-08-10 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a6bff45449bc

6973570: OrderAccess::storestore() scales poorly on multi-socket x64 and sparc: cache-line ping-ponging
Summary: volatile store to static variable removed in favour of a volatile store to stack to avoid excessive cache coherency traffic; verified that the volatile store is not elided by any of our current compilers.
Reviewed-by: dholmes, dice, jcoomes, kvn

! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp
! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp
! src/share/vm/runtime/orderAccess.cpp
! src/share/vm/runtime/orderAccess.hpp

Changeset: 2d6b74c9a797
Author:    jcoomes
Date:      2010-08-11 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2d6b74c9a797

6976378: ParNew:  stats are printed unconditionally in debug builds
Reviewed-by: tonyp

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp

Changeset: 7fcd5f39bd7a
Author:    johnc
Date:      2010-08-14 00:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7fcd5f39bd7a

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp
! src/share/vm/oops/arrayKlassKlass.cpp
! src/share/vm/oops/compiledICHolderKlass.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/klassKlass.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: f121b2772674
Author:    trims
Date:      2010-08-18 16:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f121b2772674

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 495caa35b1b5
Author:    asaha
Date:      2010-08-17 22:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/495caa35b1b5

6977952: Test: Sync missing tests from hs16.3 to hs17.x
Reviewed-by: wrockett

+ test/compiler/6894807/IsInstanceTest.java
+ test/compiler/6894807/Test6894807.sh
+ test/runtime/6626217/IFace.java
+ test/runtime/6626217/Loader2.java
+ test/runtime/6626217/Test6626217.sh
+ test/runtime/6626217/You_Have_Been_P0wned.java
+ test/runtime/6626217/bug_21227.java
+ test/runtime/6626217/from_loader2.java
+ test/runtime/6626217/many_loader1.java.foo
+ test/runtime/6626217/many_loader2.java.foo

Changeset: be3f9c242c9d
Author:    ysr
Date:      2010-08-16 15:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/be3f9c242c9d

6948538: CMS: BOT walkers can fall into object allocation and initialization cracks
Summary: GC workers now recognize an intermediate transient state of blocks which are allocated but have not yet completed initialization. blk_start() calls do not attempt to determine the size of a block in the transient state, rather waiting for the block to become initialized so that it is safe to query its size. Audited and ensured the order of initialization of object fields (klass, free bit and size) to respect block state transition protocol. Also included some new assertion checking code enabled in debug mode.
Reviewed-by: chrisphi, johnc, poonam

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp
! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/includeDB_core
! src/share/vm/memory/blockOffsetTable.cpp
! src/share/vm/memory/blockOffsetTable.hpp
! src/share/vm/memory/blockOffsetTable.inline.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 688c3755d7af
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/688c3755d7af

6959014: G1: assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check
Summary: There are a few issues in the code that calculates whether to resize the heap and by how much: a) some calculations can overflow 32-bit size_t's, b) min_desired_capacity is not bounded by the max heap size, and c) the assrt that fires is in the wrong place. The fix also includes some tidying up of the related verbose code.
Reviewed-by: ysr, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: bb847e31b836
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/bb847e31b836

6974928: G1: sometimes humongous objects are allocated in young regions
Summary: as the title says, sometimes we are allocating humongous objects in young regions and we shouldn't.
Reviewed-by: ysr, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: b63010841f78
Author:    tonyp
Date:      2010-08-17 14:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b63010841f78

6975964: G1: print out a more descriptive message for evacuation failure when +PrintGCDetails is set
Summary: we're renaming "evacuation failure" to "to-space overflow". I'm also piggy-backing a small additional change which removes the "Mark closure took..." output.
Reviewed-by: ysr, johnc

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 5ed703250bff
Author:    ysr
Date:      2010-08-18 11:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5ed703250bff

6977970: CMS: concurrentMarkSweepGeneration.cpp:7947 assert(addr <= _limit) failed: sweep invariant
Summary: Allow for the possibility (when the heap is expanding) that the sweep might skip over and past, rather than necessarily step on, the sweep limit determined at the beginning of a concurrent marking cycle.
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: 413ad0331a0c
Author:    johnc
Date:      2010-08-18 10:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/413ad0331a0c

6977924: Changes for 6975078 produce build error with certain gcc versions
Summary: The changes introduced for 6975078 assign badHeapOopVal to the _allocation field in the ResourceObj class. In 32 bit linux builds with certain versions of gcc this assignment will be flagged as an error while compiling allocation.cpp. In 32 bit builds the constant value badHeapOopVal (which is cast to an intptr_t) is negative. The _allocation field is typed as an unsigned intptr_t and gcc catches this as an error.
Reviewed-by: jcoomes, ysr, phh

! src/share/vm/memory/allocation.cpp

Changeset: effb55808a18
Author:    johnc
Date:      2010-08-18 17:44 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/effb55808a18

Merge


Changeset: 1b0104ab1e5e
Author:    tonyp
Date:      2010-08-19 14:08 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1b0104ab1e5e

Merge


Changeset: 0e509ddd9962
Author:    trims
Date:      2010-08-20 03:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0e509ddd9962

6978726: Bump the HS19 build number to 07
Summary: Update the HS19 build number to 07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 09cdb1e1c77b
Author:    trims
Date:      2010-08-20 04:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/09cdb1e1c77b

Merge

- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 71faaa8e3ccc
Author:    never
Date:      2010-08-12 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/71faaa8e3ccc

6974176: ShouldNotReachHere, instanceKlass.cpp:1426
Reviewed-by: kvn, twisti

! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp

Changeset: da877bdc9000
Author:    never
Date:      2010-08-12 23:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/da877bdc9000

6975006: assert(check.is_deoptimized_frame()) failed: missed deopt
Reviewed-by: kvn, twisti

! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/safepoint.hpp
! src/share/vm/runtime/thread.cpp

Changeset: a62d332029cf
Author:    never
Date:      2010-08-13 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a62d332029cf

6976372: #  assert(_owner == Thread::current()) failed: invariant
Reviewed-by: kvn, twisti

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 13b87063b4d8
Author:    twisti
Date:      2010-08-18 01:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/13b87063b4d8

6977640: Zero and Shark fixes
Summary: A number of fixes for Zero and Shark.
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp
! src/cpu/zero/vm/javaFrameAnchor_zero.hpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp

Changeset: f55c4f82ab9d
Author:    never
Date:      2010-08-19 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f55c4f82ab9d

6978249: spill between cpu and fpu registers when those moves are fast
Reviewed-by: kvn

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/init.cpp

Changeset: ee5cc9e78493
Author:    never
Date:      2010-08-20 09:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ee5cc9e78493

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp

Changeset: 52f2bc645da5
Author:    ysr
Date:      2010-08-19 12:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/52f2bc645da5

6978533: CMS: Elide BOT  update asserts until 6977974 is fixed correctly
Reviewed-by: jcoomes, jmasa, tonyp

! src/share/vm/memory/blockOffsetTable.hpp

Changeset: 66b9f90a9211
Author:    tonyp
Date:      2010-08-20 13:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/66b9f90a9211

Merge


Changeset: 26faca352942
Author:    tonyp
Date:      2010-08-20 12:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/26faca352942

Merge


Changeset: 571f6b35140b
Author:    trims
Date:      2010-08-20 12:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/571f6b35140b

6978889: Remove premature change of build number to Hotspot 19 Build 07
Summary: Change the build number back to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b0b9d64ed9bc
Author:    trims
Date:      2010-08-20 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b0b9d64ed9bc

6978915: Remove Mercurial tags for Hotspot 19 Build 06
Summary: Delete the hs19-b06 Hg tag, as it was put on incorrectly
Reviewed-by: jcoomes

! .hgtags

Changeset: 6c43216df135
Author:    trims
Date:      2010-08-31 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6c43216df135

Merge

! .hgtags

Changeset: 0803c0f69b51
Author:    trims
Date:      2010-08-31 17:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0803c0f69b51

Added tag hs19-b06 for changeset 6c43216df135

! .hgtags



From lana.steuck at oracle.com  Thu Sep  2 18:02:16 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 18:02:16 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 3 new changesets
Message-ID: <20100902180216.E063A4767F@hg.openjdk.java.net>

Changeset: 5ba8469212a6
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/5ba8469212a6

Added tag jdk7-b105 for changeset 3233b9a4c12e

! .hgtags

Changeset: 20ee37c1372a
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/20ee37c1372a

Added tag jdk7-b106 for changeset 5ba8469212a6

! .hgtags

Changeset: 7d379f8934ca
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/7d379f8934ca

Added tag jdk7-b107 for changeset 20ee37c1372a

! .hgtags



From lana.steuck at oracle.com  Thu Sep  2 18:02:21 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 18:02:21 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 3 new changesets
Message-ID: <20100902180221.CC92647680@hg.openjdk.java.net>

Changeset: bc45ccc5bcca
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/bc45ccc5bcca

Added tag jdk7-b105 for changeset 39eb4f3031f4

! .hgtags

Changeset: 017612ea6af4
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/017612ea6af4

Added tag jdk7-b106 for changeset bc45ccc5bcca

! .hgtags

Changeset: b1ca39340238
Author:    cl
Date:      2010-08-26 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/b1ca39340238

Added tag jdk7-b107 for changeset 017612ea6af4

! .hgtags



From lana.steuck at oracle.com  Thu Sep  2 18:03:13 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 18:03:13 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 45 new changesets
Message-ID: <20100902181028.D939E47682@hg.openjdk.java.net>

Changeset: 9ad95be9deae
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9ad95be9deae

Added tag jdk7-b105 for changeset 3b0abcb51280

! .hgtags

Changeset: f8bbf376595c
Author:    yhuang
Date:      2010-08-11 02:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f8bbf376595c

6959252: convert the anonymous arrays to named arrays in Java List Resource files
Reviewed-by: katakai, psun

! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java
! src/share/classes/sun/applet/resources/MsgAppletViewer.java
! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java

Changeset: 413cede85120
Author:    yhuang
Date:      2010-08-13 01:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/413cede85120

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: b91ef6b60f4e
Author:    cl
Date:      2010-08-16 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b91ef6b60f4e

Merge


Changeset: 882103f334bb
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/882103f334bb

Added tag jdk7-b106 for changeset b91ef6b60f4e

! .hgtags

Changeset: 17a5d84b7561
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/17a5d84b7561

Added tag jdk7-b107 for changeset 882103f334bb

! .hgtags

Changeset: 654145d6560a
Author:    lana
Date:      2010-08-23 19:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/654145d6560a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: d0e314d59f84
Author:    malenkov
Date:      2010-08-10 19:29 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d0e314d59f84

6960267: JTable.getRowHeight() returns value different from the specified default (16.0) with GTK L&F
Reviewed-by: peterz

! src/share/classes/javax/swing/JTable.java

Changeset: 58626b4eedcb
Author:    lana
Date:      2010-08-12 11:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/58626b4eedcb

Merge

- test/java/net/Socket/AccurateTimeout.java

Changeset: 23f72ec0d8e8
Author:    peytoia
Date:      2010-08-23 14:14 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/23f72ec0d8e8

6977550: (tz) Support tzdata2010l
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java

Changeset: a18a82d2d506
Author:    lana
Date:      2010-08-23 19:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a18a82d2d506

Merge


Changeset: 367b90ed38b1
Author:    chegar
Date:      2010-08-03 12:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/367b90ed38b1

6973030: NTLM proxy authentication fails with https
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java

Changeset: a21c46dac6cf
Author:    mullan
Date:      2010-08-03 09:39 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a21c46dac6cf

6653372: Error in java.security.KeyStore example code
Reviewed-by: weijun

! src/share/classes/java/security/KeyStore.java

Changeset: 2feeefb45a44
Author:    mullan
Date:      2010-08-03 09:55 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2feeefb45a44

Merge


Changeset: 3b63e506b57e
Author:    martin
Date:      2010-08-03 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3b63e506b57e

6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94
Summary: let arraycopy throw AIOOBE for invalid negative length
Reviewed-by: chegar, forax

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 188f156148ea
Author:    apangin
Date:      2010-08-04 20:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/188f156148ea

6945961: SIGSEGV in memcpy() during class loading on linux-i586
Summary: Check the result of strchr() in Bytecode Verifier
Reviewed-by: kamg, acorn

! src/share/native/common/check_code.c

Changeset: d47f5dcda481
Author:    dcubed
Date:      2010-08-06 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d47f5dcda481

6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure
Summary: Disable MonitorVmStartTerminate.sh until 6543856 is fixed.
Reviewed-by: ohair

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh

Changeset: 3e239fe92832
Author:    lancea
Date:      2010-08-10 10:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3e239fe92832

6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax
Reviewed-by: minqi

! src/share/classes/java/sql/Date.java

Changeset: 1f996198877b
Author:    chegar
Date:      2010-08-10 17:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1f996198877b

6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled.
Reviewed-by: alanb

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/PlainSocketImpl.c
! src/solaris/native/sun/nio/ch/Net.c

Changeset: da5b67ac7755
Author:    sherman
Date:      2010-08-10 13:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/da5b67ac7755

6923794: About 40 JCK test case fail with AssertionError if -esa option is specified
Summary: removed the assert
Reviewed-by: alanb

! src/solaris/classes/java/io/UnixFileSystem.java
! src/windows/classes/java/io/Win32FileSystem.java

Changeset: 11ee8b471f9c
Author:    alanb
Date:      2010-08-12 19:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/11ee8b471f9c

6971825: (so) improve scatter/gather implementation
Reviewed-by: chegar, sherman

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/IOVecWrapper.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java

Changeset: 389bc53d0945
Author:    mchung
Date:      2010-08-12 16:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/389bc53d0945

6973831: NPE when printing stack trace of OOME
Summary: Initialize suppressedExceptions field to null
Reviewed-by: briangoetz, dholmes, forax

! src/share/classes/java/lang/Throwable.java

Changeset: cdd6d518f47e
Author:    mchung
Date:      2010-08-12 16:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cdd6d518f47e

Merge


Changeset: 041997c49f15
Author:    lana
Date:      2010-08-12 19:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/041997c49f15

Merge


Changeset: 0cdd73548292
Author:    gbenson
Date:      2010-08-13 22:26 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0cdd73548292

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/jdk_generic_profile.sh

Changeset: 8329ebeabc10
Author:    mchung
Date:      2010-08-16 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8329ebeabc10

6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin
Summary: Add check for CYGWIN
Reviewed-by: ohair

! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh

Changeset: 42eaa082a4e6
Author:    michaelm
Date:      2010-08-17 14:49 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/42eaa082a4e6

6339649: URI.create should include a detail message when throwing IllegalArgumentException
Summary: create enclosing exception with message of enclosed
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java

Changeset: bfc3855a9341
Author:    sherman
Date:      2010-08-17 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bfc3855a9341

6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS
Summary: changed to use more appropriate nfs file time
Reviewed-by: martin

! test/tools/jar/JarEntryTime.java

Changeset: 01dec49e95c4
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/01dec49e95c4

6974005: Use of cygpath in Makefile logic needs to silence error messages
Reviewed-by: mchung

! make/common/shared/Defs-windows.gmk

Changeset: 42bfa43f2ae1
Author:    ohair
Date:      2010-08-18 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/42bfa43f2ae1

6932743: Makefiles not parsing version strings with - from uname -r
Reviewed-by: mchung

! make/common/shared/Defs.gmk

Changeset: 4abd65f04638
Author:    weijun
Date:      2010-08-19 11:26 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4abd65f04638

6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default.
Reviewed-by: valeriep

! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
+ test/sun/security/krb5/BadKdcDefaultValue.java

Changeset: 95bb147c7c33
Author:    weijun
Date:      2010-08-19 12:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/95bb147c7c33

6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException
Reviewed-by: vinnie, xuelei

! src/share/classes/com/sun/jndi/ldap/Connection.java

Changeset: 1ce9c1690080
Author:    ksrini
Date:      2010-08-19 14:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1ce9c1690080

6888127: java.util.jar.Pack200.Packer Memory Leak
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java
! src/share/classes/com/sun/java/util/jar/pack/Driver.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/Package.java
! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java
+ src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
! src/share/classes/com/sun/java/util/jar/pack/Utils.java

Changeset: 16e43f336262
Author:    ksrini
Date:      2010-08-20 08:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/16e43f336262

6966737: (pack200) the pack200 regression tests need to be more robust.
Reviewed-by: jrose, ohair

+ test/tools/pack200/CommandLineTests.java
- test/tools/pack200/Pack200Simple.sh
! test/tools/pack200/Pack200Test.java
! test/tools/pack200/PackageVersionTest.java
! test/tools/pack200/SegmentLimit.java
+ test/tools/pack200/Utils.java
+ test/tools/pack200/pack200-verifier/data/README
+ test/tools/pack200/pack200-verifier/data/golden.jar
+ test/tools/pack200/pack200-verifier/make/build.xml
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/ClassCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Globals.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/JarFileCompare.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Main.java
+ test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/VerifyTreeSet.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/CommandLineParser.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/TokenList.java
+ test/tools/pack200/pack200-verifier/src/xmlkit/XMLKit.java

Changeset: db1b7c10de61
Author:    ksrini
Date:      2010-08-20 08:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/db1b7c10de61

Merge


Changeset: fd28003bc1d6
Author:    chegar
Date:      2010-08-23 14:35 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fd28003bc1d6

6968584: Thread should not be Cloneable
Reviewed-by: dholmes

! src/share/classes/java/lang/Thread.java

Changeset: 03218163f4d5
Author:    chegar
Date:      2010-08-23 16:27 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/03218163f4d5

6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe
Reviewed-by: michaelm

! src/share/classes/java/net/HttpCookie.java

Changeset: 47ab0dcec3e8
Author:    alanb
Date:      2010-08-23 17:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/47ab0dcec3e8

6978511: (file) Path.toRealPath should fail if not resolving links and file does not exist
Reviewed-by: forax, chegar

! src/solaris/classes/sun/nio/fs/UnixPath.java
! test/java/nio/file/Path/Misc.java

Changeset: f4a2b4e7a831
Author:    alanb
Date:      2010-08-23 17:35 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f4a2b4e7a831

6431344: (fc) FileChannel.transferTo() doesn't work if address space runs out
Reviewed-by: forax, chegar

! src/share/classes/sun/nio/ch/FileChannelImpl.java

Changeset: 6317f7e2c4fd
Author:    ksrini
Date:      2010-08-23 08:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6317f7e2c4fd

6531345: Memory leak in unpack200
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
+ test/tools/pack200/UnpackerMemoryTest.java
! test/tools/pack200/Utils.java

Changeset: cb67f0263bd4
Author:    chegar
Date:      2010-08-23 21:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cb67f0263bd4

6977851: NPE from FileURLConnection.connect
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.java
+ test/sun/net/www/protocol/file/DirPermissionDenied.sh

Changeset: 2585368bfc7c
Author:    ksrini
Date:      2010-08-23 10:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2585368bfc7c

6969063: (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
+ test/tools/pack200/Pack200Props.java
- test/tools/pack200/SegmentLimit.java

Changeset: 732f59013e78
Author:    ksrini
Date:      2010-08-23 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/732f59013e78

6966740: (pack200) need to add the timezone regression test
Reviewed-by: jrose

+ test/tools/pack200/TimeStamp.java
! test/tools/pack200/Utils.java

Changeset: 62d37c19c213
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/62d37c19c213

Merge

- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 043d2736d44c
Author:    lana
Date:      2010-08-29 22:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/043d2736d44c

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java



From lana.steuck at oracle.com  Thu Sep  2 18:12:04 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 02 Sep 2010 18:12:04 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 20 new changesets
Message-ID: <20100902181245.CEC2947683@hg.openjdk.java.net>

Changeset: 112fcc00659d
Author:    cl
Date:      2010-08-13 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/112fcc00659d

Added tag jdk7-b105 for changeset aaecac256d39

! .hgtags

Changeset: 2c1c657f69a4
Author:    cl
Date:      2010-08-19 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2c1c657f69a4

Added tag jdk7-b106 for changeset 112fcc00659d

! .hgtags

Changeset: a408ebb8b3d4
Author:    cl
Date:      2010-08-26 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a408ebb8b3d4

Added tag jdk7-b107 for changeset 2c1c657f69a4

! .hgtags

Changeset: 0fe472f4a332
Author:    mcimadamore
Date:      2010-08-05 09:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0fe472f4a332

6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException
Summary: default annotation value is not attributed
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/6881115/T6881115.java
+ test/tools/javac/annotations/6881115/T6881115.out

Changeset: 237f3bd52242
Author:    mcimadamore
Date:      2010-08-05 09:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/237f3bd52242

6857948: Calling a constructor with a doubly bogus argument causes an internal error
Summary: problem when constructor resolution returns an erroneous symbol
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/6857948/T6857948.java
+ test/tools/javac/6857948/T6857948.out

Changeset: a2d8c7071f24
Author:    mcimadamore
Date:      2010-08-10 14:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a2d8c7071f24

6975275: diamond implementation needs some cleanup
Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError()
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: ea1930f4b789
Author:    mcimadamore
Date:      2010-08-10 14:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ea1930f4b789

6975231: Regression test for 6881115 is failing with compiler output not matching expected output
Summary: missing symbols are collected in an HashSet which doesn't preserve ordering
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/annotations/6881115/T6881115.out
+ test/tools/javac/diags/examples/AnnotationMissingValues1.java

Changeset: c04ae2714f52
Author:    lana
Date:      2010-08-12 19:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c04ae2714f52

Merge


Changeset: 27bae58329d5
Author:    mcimadamore
Date:      2010-08-16 14:56 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/27bae58329d5

6976649: javac does not enforce required annotation elements in arrays
Summary: type annotation should take advantage of recursive annotation checking
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/annotations/6881115/T6881115.java
! test/tools/javac/annotations/6881115/T6881115.out
! test/tools/javac/annotations/pos/TrailingComma.java

Changeset: dc550520ed6f
Author:    mcimadamore
Date:      2010-08-16 14:58 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/dc550520ed6f

6369605: Unconstrained type variables fails to include bounds
Summary: unconstrained type-variables with recursive bounds are not inferred properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/InvalidInferredTypes.java
+ test/tools/javac/generics/inference/6369605/T6369605a.java
+ test/tools/javac/generics/inference/6369605/T6369605b.java
! test/tools/javac/generics/inference/6638712/T6638712a.out

Changeset: a31c511db424
Author:    jjg
Date:      2010-08-16 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a31c511db424

6976833: options included twice in Example SimpleCompiler
Reviewed-by: darcy

! test/tools/javac/diags/Example.java

Changeset: c655e0280bdc
Author:    mcimadamore
Date:      2010-08-19 11:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c655e0280bdc

6886247: regression: javac crashes with an assertion error in Attr.java
Summary: capture conversion does not work on nested types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_1.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.java
+ test/tools/javac/generics/wildcards/6886247/T6886247_2.out

Changeset: d6fe0ea070aa
Author:    mcimadamore
Date:      2010-08-19 11:52 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d6fe0ea070aa

6885255: Improve usability of raw warnings
Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out
+ test/tools/javac/warnings/6885255/T6885255.java
+ test/tools/javac/warnings/6885255/T6885255.out

Changeset: a75770c0d7f6
Author:    mcimadamore
Date:      2010-08-19 11:54 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a75770c0d7f6

6977800: Regression: invalid resolution of supertype for local class
Summary: resolution of superclass/superinterfaces in extends/implements clause skips local classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/T6977800.java
! test/tools/javac/generics/typevars/5060485/Compatibility.java
+ test/tools/javac/generics/typevars/5060485/Compatibility.out
+ test/tools/javac/generics/typevars/5060485/Compatibility02.java
+ test/tools/javac/generics/typevars/5060485/Compatibility02.out

Changeset: 995bcdb9a41d
Author:    mcimadamore
Date:      2010-08-23 16:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/995bcdb9a41d

6932571: Compiling Generics causing Inconvertible types
Summary: Types.rewriteQuantifiers() does not work well with recursive type-variable bounds
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6270087/T6270087.java
+ test/tools/javac/cast/6270087/T6270087neg.java
+ test/tools/javac/cast/6270087/T6270087neg.out
+ test/tools/javac/cast/6507317/T6507317.java
+ test/tools/javac/cast/6569057/T6569057.java
+ test/tools/javac/cast/6932571/T6932571a.java
+ test/tools/javac/cast/6932571/T6932571b.java
+ test/tools/javac/cast/6932571/T6932571neg.java
+ test/tools/javac/cast/6932571/T6932571neg.out

Changeset: 594b3c2ef585
Author:    mcimadamore
Date:      2010-08-23 17:00 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/594b3c2ef585

6978574: return statement in try block with multi-catch causes ClassFormatError
Summary: Wrong nested loops in Gen.java causes javac to generate bad bytecode
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/multicatch/T6978574.java

Changeset: 6b95dd682538
Author:    jjg
Date:      2010-08-23 11:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6b95dd682538

6975005: improve JavacProcessingEnvironment.Round abstraction
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/T6358024.java
! test/tools/javac/T6403466.out
! test/tools/javac/processing/filer/TestLastRound.out

Changeset: a626d8c1de6e
Author:    jjg
Date:      2010-08-23 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a626d8c1de6e

6976747: JCDiagnostic: replace "boolean mandatory" with new "Set<JCDiagnostic.Flag>"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java

Changeset: 0c81bff15ced
Author:    lana
Date:      2010-08-23 19:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0c81bff15ced

Merge


Changeset: ba774f919ad0
Author:    lana
Date:      2010-08-29 22:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ba774f919ad0

Merge




From james.graham at oracle.com  Thu Sep  2 21:06:12 2010
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 02 Sep 2010 14:06:12 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1505054830.4033161283436538688.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1505054830.4033161283436538688.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C8011C4.1040107@oracle.com>

Are quarter circles easy to detect?  Their 2 angles should both be 45 
degrees and their lengths should be similar (I don't think the middle 
control segment is the same length as the outer 2, but there is probably 
some tolerance where a single subdivision works fine).

Either way, hopefully the performance is much better now that the 
dashing and widening code has to process a lot fewer segments.  Is it?

			...jim

On 9/2/2010 7:08 AM, Denis Lila wrote:
> Hello Jim.
>
> Sorry for all the e-mails.
> I implemented the rotating version. The rotation introduces small
> numerical errors, so when I solve for the roots of dx/dt and dy/dt,
> the values of t I get are slightly off. So for a rotated quarter
> circle, what happens is that it gives me a root at, say, t=0.9996...
> so I still end up subdividing quarter circles. I "fixed" this by
> ignoring all roots outside of (0.001,0.999), instead of ignoring
> roots outside of (0,1) which is the ideal solution. I don't like
> hardcoding constants like this. Add to this the higher complexity
> of the rotation, and I'm tempted to say it might be better to just
> bite the bullet on rotated quarter circles and widen them using 2
> curves per side.
>
> I had one question: what do you think of widening all curves using
> quadratic curves? Their great simplicity might make things safer. We
> can guarantee that none of the strange behaviour I've seen and described
> with cubic curves will arise (but we'd have to use more of them).
>
> Also, I've tested the current implementation with a few hundred random
> cubic paths, and everything looks good so far.
>
> Thanks,
> Denis.
>
> ----- "Denis Lila"<dlila at redhat.com>  wrote:
>
>> Hello Jim.
>>
>>> I think this would actually ensure that every resulting curve can
>>> be rotated to be made monotonic in both x and y (at least after
>>> inflections are eliminated), which means it's at least as good as
>>> what I have now.
>>
>> While that first statement is true, it unfortunately does not mean
>> it's
>> "at least as good as" breaking the curve into monotonic pieces. I
>> implemented the angle checking method, and the problem is that for
>> curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's
>> because I implemented it by subdividing at t=0.5, so the angles
>> in the resulting curves' polygons are still wide. After enough
>> subdivisions the polygons would have angles below 45, but that would
>> defeat the point, since we're trying to minimize the number of output
>> curves.
>> I can't think of a good way to chose the subdivision t so that
>> this method is as good as the rotation and make monotonic one (nothing
>> with any properties I can prove, anyway), so I'll implement the
>> rotating version, as much as I don't like it. At least it gives a good
>> upper bound in the number of output curves.
>>
>> Regards,
>> Denis.
>>
>> ----- "Denis Lila"<dlila at redhat.com>  wrote:
>>
>>> Hello Jim.
>>> Thanks for taking the time to think about this.
>>>
>>> I implemented a few different offsetting schemes. On well behaved
>>> curves, my original "parallel first and last control vectors and go
>>> through B(0.5)" algorithm was by far the best. Theoretically it is
>>> also somewhat better justified than the others (some of which were
>>> like Apache Harmony's way - offsetting p2 and p3), since we're
>>> interpolating instead of just using some heuristic. It is also
>>> the only one I've encountered that widens quarter circles optimally,
>>> and it only needs one curve per side too (i.e. if we have to widen
>>> the path of a PathIterator of a circle with radius r, using width w,
>>> Pisces' output will be identical to the output of the PathIterators
>>> of 2 circles with radii r+w and r-w (perhaps not identical
>> identical,
>>> since PathIterators can use doubles, and we only use floats in
>> pisces,
>>> but... that's nitpicking)).
>>>
>>> As I've said before, the only 2 problems with it were that it was
>> bad
>>> on high curvatures (but this was fixed by breaking down the curves
>>> into
>>> monotonic ones), and it was bad on curves like
>>> p.moveTo(0,0);p.curveTo(100,100,0,100,100,1). I thought the latter
>> was
>>> fixable with the "d1/(d1+d2)" algorithm I suggested in my previous
>>> e-mail.
>>> I implemented it, and it turns out I was wrong. Then I came up with
>> my
>>> own
>>> variation of that algorithm (the original one I used was from Don
>>> Lancaster's
>>> website) that did sort of work. But then I implemented your
>> suggestion
>>> of
>>> splitting the curve at the inflection points as well as breaking it
>>> into
>>> monotonic pieces, and the problem was gone. I didn't even have to
>> use
>>> the
>>> fancy variation of the "d1/(d1 + d2)" algorithm - just the plain old
>>> interpolation one worked (I should say that the fancy one is still
>>> probably
>>> better, but undetectably so, now that we break at inflection points
>>> and at
>>> xy direction changes, so the added complexity is probably not worth
>>> it).
>>>
>>> I've attached my latest Stroker.java, if you want to take a look at
>>> these
>>> algorithms (they're in computeOffsetWay1 (for the old interpolation)
>>> and
>>> computeOffsetWay3 (for the fancy version). There are 2 more, but
>> these
>>> aren't as good, and one is just shameful). I didn't make a webrev
>>> because
>>> I still need to fix how it handles cusps (which should be easy), and
>> I
>>> need to implement a way to avoid subdividing a rotated quarter
>> circle.
>>> I can do this either by rotating curves so that p2-p1 is parallel to
>>> the
>>> x axis and then subdivide like I do now (i.e. make monotonic, break
>> at
>>> inflections) or get rid of the monotonic subdivision, and instead
>>> subdivide
>>> by checking the angles of the control polygon. I could make it so it
>>> subdivides whenever the angles between p2-p1 and p3-p2 or p3-p2 and
>>> p4-p3
>>> are greater than 45 degrees.
>>>
>>> Very well. I've convinced myself. I'll implement the latter.
>>>
>>> Thanks,
>>> Denis.
>>>
>>> ----- "Jim Graham"<james.graham at oracle.com>  wrote:
>>>
>>>> Hi Denis,
>>>>
>>>> Just to let you know that I've seen this and I'm thinking.
>>>>
>>>> But it will take a bit of "more thinking" when I have time for
>> more.
>>>> Hopefully in a couple of days.
>>>>
>>>> For one thing, it sounds like you already understand the Apache
>>>> Harmony
>>>> approach quite a bit better than I ever did and, in particular,
>> why
>>> it
>>>>
>>>> didn't work well - which is encouraging.  Hopefully your solution
>>> will
>>>>
>>>> sound pretty good when I get around to wrapping my head around
>> it...
>>>>
>>>> 			...jim
>>>>
>>>> On 8/30/2010 3:03 PM, Denis Lila wrote:
>>>>> Hello Jim.
>>>>>
>>>>>> One way in which they may not break enough is that I think that
>>>>>> inflections also need to be broken in order to find a parallel
>>>> curve
>>>>>> (though I suppose a very tiny inflection might still be
>>>> approximated by
>>>>>> a parallel curve easily) and inflections can happen at any
>> angle
>>>> without
>>>>>> going horizontal or vertical.
>>>>>
>>>>>       It wouldn't be hard to add additional breaks at the
>>> inflection
>>>> points.
>>>>>
>>>>>> Secondly, although a circle tends to be represented by quadrant
>>>> sections
>>>>>> which are monotonic, a circle rotated by 45 degrees would have
>>>>>> horizontal and vertical sections in the middle of each quadrant
>>> and
>>>> you
>>>>>> would split those, but really they can be made parallel
>>> regardless
>>>> of
>>>>>> angle so these would be unnecessary splits.
>>>>>
>>>>>       That's true, and it's one reason I didn't like my method
>> very
>>>> much when I sent
>>>>> my previous e-mail. However, what if we rotated curves so that
>>> B'(0)
>>>> is
>>>>> parallel to the x-axis before splitting at points where dx/dt or
>>>> dy/dt are 0?
>>>>> This would certainly get rid of this problem for circles, and
>>>> probably for
>>>>> other curves. All it would cost is 1 Math.cos and 1 Math.sin and
>> a
>>>> few
>>>>> multiplications and additions per curve.
>>>>>
>>>>> The biggest problem with my implementation was that some curves
>>> that
>>>> were almost
>>>>> lines were drawn horribly. I computed the parallel (p1', p2',
>> p3',
>>>> p4') of
>>>>> a given curve (p1, p2, p3, p4) by making p2'-p1' parallel to
>>> p2-p1,
>>>>> making p4'-p3' parallel to p4-p3. This leaves a 2 unknowns, so
>> to
>>>> get 2 more
>>>>> equations I made the computed parallel at t=0.5 equal to the
>> ideal
>>>> parallel
>>>>> at t=0.5. The problem was that for some curves (ones with very
>>> high
>>>> curvature)
>>>>> p2'-p1' and p4'-p3' were parallel to p2-p1 and p4-p3 but their
>>>> directions were
>>>>> opposite, so you can imagine what the computed "parallel" looked
>>>> like.
>>>>> However, I am almost certain that the problem was caused by
>> making
>>>> C(0.5) = P(0.5)
>>>>> (where C is the computed curve, and P is the ideal parallel). A
>>> much
>>>> better
>>>>> restriction, that I think would eliminate the problem would be
>>>> C(d1/(d1 + d2)) = P(0.5).
>>>>> where d1 = ||P(0.5)-P(0)|| and d2 = ||P(1)-P(0.5)||.
>>>>>
>>>>>> My belief is that lengths and angles of the control polygon
>> help
>>>>>> determine if it is well-behaved and can be made parallel simply
>>> by
>>>>>> offsetting.  Some formula involving those values would likely
>> be
>>>> happy
>>>>>> with circle sections regardless of their angle of rotation.  I
>>>> believe
>>>>>> the Apache Harmony version of BasicStroke used those
>> criteria...
>>>>>
>>>>>       I've been reading the Apache Harmony file. The way they do
>> it
>>>> is compute
>>>>> the tangent of an angle using the line width and a predefined
>>>> constant
>>>>> (which doesn't seem to be related to the curve's polygon - it's
>>> just
>>>> a decreasing
>>>>> function with the range (-1,1)), and if some angles in the
>> polygon
>>>> are smaller than
>>>>> the computed angle, offset curves are computed. Otherwise the
>>> curve
>>>> is subdivided.
>>>>> However, I can't understand how offsets for the control points
>> are
>>>> computed (i.e.
>>>>> why they use the equations they use, and why they work).
>>>>> If we're using the widening of quarter circles as a yard stick,
>>> then
>>>> Apache Harmony's
>>>>> BasicStroke does not do very well. If we have a quarter circle
>>> from
>>>> (1,0) to (0,1),
>>>>> then the control points c1 and c2 should be (1,k) and (k,1)
>> where
>>> k
>>>> = 4*(sqrt(2)-1)/3.
>>>>> A parallel curve w away from this quarter circle should have
>>> control
>>>> points
>>>>> (1+w,k+k*w) and (k+k*w,1+w). I traced Apache Harmony's
>>> computations
>>>> on a quarter
>>>>> circle, and this is not what it outputs. Furthermore, all
>> quarter
>>>> circles with line
>>>>> width<   9.65 will be subdivided. My method with the
>> modifications
>>>> suggested above
>>>>> doesn't have these problems.
>>>>>
>>>>>       But perhaps it's better to not interpolate through P(0.5)
>>> after
>>>> all.
>>>>> In addition to making p4'-p3' and p2'-p1' parallel to p4-p3 and
>>>> p2-p1, we could
>>>>> also make p3'-p2' parallel to p3-p2. These constraints leave
>> just
>>>> one unknown, which
>>>>> needs to be eliminated. I am not sure how to do this. I thought
>>>> about making the line
>>>>> (p2',p3') be a distance of w from (p2,p3) (which is exactly what
>>>> needs to be done for
>>>>> (p1',p2') and (p3',p4')) but this doesn't get us what we want
>> for
>>>> quarter circles. So, finding
>>>>> the control points would boil down to finding intersections of 3
>>>> lines.
>>>>>
>>>>> Do you have any suggestions on how to do the offsetting for the
>>>> control points?
>>>>>
>>>>> Thank you,
>>>>> Denis.
>>>>>
>>>>> ----- "Jim Graham"<james.graham at oracle.com>   wrote:
>>>>>
>>>>>> Hi Denis,
>>>>>>
>>>>>> At the bottom-most rendering level monotonic curves can be cool
>>> to
>>>> deal
>>>>>> with, but I'm dubious that they help with widening.  For one
>>>> things, I
>>>>>> think you need more breaks than they would give you and also
>> they
>>>> might
>>>>>> sometimes break a curve when it doesn't need it.
>>>>>>
>>>>>> 		...jim
>>>>>>
>>>>>> On 8/25/2010 2:36 PM, Denis Lila wrote:
>>>>>>> Hello Jim.
>>>>>>>
>>>>>>>> I think a more dynamic approach that looked at how "regular"
>>> the
>>>>>> curve
>>>>>>>> was would do better.  Regular is hard to define, but for
>>>> instance
>>>>>> a
>>>>>>>> bezier section of a circle could have parallel curves
>> computed
>>>>>> very
>>>>>>>> easily without having to flatten or subdivide further.
>> Curves
>>>>>> with
>>>>>>>> inflections probably require subdividing to get an accurate
>>>>>> parallel
>>>>>>>> curve.
>>>>>>>
>>>>>>> I'm not sure if you read it, but after the email with the
>> webrev
>>>>>> link
>>>>>>> I sent another describing a different method of widening:
>> split
>>>> the
>>>>>>> curve at every t where dx/dt == 0 and dy/dt == 0. This
>>> guarantees
>>>>>> that
>>>>>>> there will be no more than 5 curves per side, and since each
>>>> curve
>>>>>> will
>>>>>>> be monotonic in both x and y the curve that interpolates its
>>>>>> parallel
>>>>>>> should do a pretty good job.
>>>>>>>
>>>>>>> This is far better than interpolating at regular t intervals,
>>> but
>>>>>> I'm
>>>>>>> trying to find a better way. I don't like this because the
>> split
>>>>>>> depend not only on the curve itself, but also on the axes. The
>>>> axes
>>>>>> are
>>>>>>> arbitrary, so this is not good. For example a curve like this
>>>>>>> |
>>>>>>> \_ would get widened by 1 curve per side (which is good and
>>>>>> optimal), but
>>>>>>> if we rotate this curve by, say, 30 degrees it would be
>> widened
>>> by
>>>> 2
>>>>>> curves
>>>>>>> per side.
>>>>>>> It also doesn't handle cusps and locations of high curvature
>>> very
>>>>>> well (although
>>>>>>> I think the latter is a numerical issue that could be made
>>> better
>>>> by
>>>>>> using
>>>>>>> doubles).
>>>>>>>
>>>>>>> Regards,
>>>>>>> Denis.
>>>>>>>
>>>>>>> ----- "Jim Graham"<james.graham at oracle.com>    wrote:
>>>>>>>
>>>>>>>> Hi Denis,
>>>>>>>>
>>>>>>>> On 8/23/2010 4:18 PM, Denis Lila wrote:
>>>>>>>>>         To widen cubic curves, I use a cubic spline with a
>>> fixed
>>>>>> number
>>>>>>>> of curves for
>>>>>>>>> each curve to be widened. This was meant to be temporary,
>>> until
>>>> I
>>>>>>>> could find a
>>>>>>>>> better algorithm for determining the number of curves in the
>>>>>> spline,
>>>>>>>> but I
>>>>>>>>> discovered today that that won't do it.
>>>>>>>>>         For example, the curve p.moveTo(0,0),p.curveTo(84.0,
>>>> 62.0,
>>>>>>>> 32.0, 34.0, 28.0, 5.0)
>>>>>>>>> looks bad all the way up to ~200 curves. Obviously, this is
>>>>>>>> unacceptable.
>>>>>>>>>
>>>>>>>>> It would be great if anyone has any better ideas for how to
>> go
>>>>>> about
>>>>>>>> this.
>>>>>>>>> To me it seems like the problem is that in the webrev I chop
>>> up
>>>>>> the
>>>>>>>> curve to be
>>>>>>>>> interpolated at equal intervals of the parameter.
>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps looking at the rate of change of the slope (2nd
>> and/or
>>>> 3rd
>>>>>>>> derivatives) would help to figure out when a given section of
>>>>>> curve
>>>>>>>> can
>>>>>>>> be approximated with a parallel version?
>>>>>>>>
>>>>>>>> I believe that the BasicStroke class of Apache Harmony
>> returns
>>>>>> widened
>>>>>>>>
>>>>>>>> curves, but when I tested it it produced a lot more curves
>> than
>>>>>> Ductus
>>>>>>>>
>>>>>>>> (still, probably a lot less than the lines that would be
>>>> produced
>>>>>> by
>>>>>>>> flattening) and it had some numerical problems.  In the end I
>>>>>> decided
>>>>>>>> to
>>>>>>>> leave our Ductus stuff in there until someone could come up
>>> with
>>>> a
>>>>>>>> more
>>>>>>>> reliable Open Source replacement, but hopefully that code is
>>>> close
>>>>>>>> enough to be massaged into working order.
>>>>>>>>
>>>>>>>> You can search the internet for "parallel curves" and find
>> lots
>>>> of
>>>>>>>> literature on the subject.  I briefly looked through the web
>>>>>> sites,
>>>>>>>> but
>>>>>>>> didn't have enough time to remember enough calculus and
>>>>>> trigonometry
>>>>>>>> to
>>>>>>>> garner a solution out of it all with the time that I had.
>>> Maybe
>>>>>>>> you'll
>>>>>>>> have better luck following the algorithms... ;-)
>>>>>>>>
>>>>>>>> As far as flattening at the lowest level when doing scanline
>>>>>>>> conversion,
>>>>>>>> I like the idea of using forward differencing as it can
>> create
>>>> an
>>>>>>>> algorithm that doesn't require all of the intermediate
>> storage
>>>> that
>>>>>> a
>>>>>>>>
>>>>>>>> subdividing flattener requires.  One reference that describes
>>>> the
>>>>>>>> technique is on Dr. Dobbs site, though I imagine there are
>> many
>>>>>>>> others:
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>> http://www.drdobbs.com/184403417;jsessionid=O5N5MDJRDMIKHQE1GHOSKH4ATMY32JVN
>>>>>>>>
>>>>>>>> You can also look at the code in
>>>>>>>> src/share/native/sun/java2d/pipe/ProcessPath.c for some
>>> examples
>>>>>> of
>>>>>>>> forward differencing in use (and that code also has similar
>>>>>> techniques
>>>>>>>>
>>>>>>>> to what you did to first chop the path into vertical pieces).
>>>> BUT
>>>>>>>> (*Nota Bene*), I must warn you that the geometry of the path
>> is
>>>>>>>> somewhat
>>>>>>>> perturbed in that code since it tries to combine "path
>>>>>> normalization"
>>>>>>>>
>>>>>>>> and rasterization into a single process.  It's not rendering
>>>> pure
>>>>>>>> geometry, it is rendering tweaked geometry which tries to
>> make
>>>>>> non-AA
>>>>>>>>
>>>>>>>> circles look round and other such aesthetics-targeted
>>>> impurities.
>>>>>>>> While
>>>>>>>> the code does have good examples of how to set up and
>> evaluate
>>>>>> forward
>>>>>>>>
>>>>>>>> differencing equations, don't copy too many of the details or
>>>> you
>>>>>>>> might
>>>>>>>> end up copying some of the tweaks and the results will look
>>>>>> strange
>>>>>>>> under AA.  The Dr. Dobbs article should be your numerical
>>>>>> reference
>>>>>>>> and
>>>>>>>> that reference code a practical, but incompatible, example...
>>>>>>>>
>>>>>>>> 			...jim


From dlila at redhat.com  Thu Sep  2 21:43:01 2010
From: dlila at redhat.com (Denis Lila)
Date: Thu, 2 Sep 2010 17:43:01 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <2031894941.25341283463761329.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <265307286.25361283463781083.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

> Either way, hopefully the performance is much better now that the 
> dashing and widening code has to process a lot fewer segments.  Is
> it?

In some cases, it's as much as 20x better. I wrote a small program to
draw extremely high numbers of random curves, so that I could test 
performance, and notice obvious mistakes. This function split a 
1000x1000 frame in 100 100x100 squares drew 20 random curves in each of them.
I set a stroke with line width = 2, so that pisces would get used. The 
operation took about 18-20 seconds per frame on my machine. Then I tried
a very early version of this changeset (the one where the subdivisions were
uniformly spaced, with 5 curves per side), and it took less than 2 seconds.

That algorithm was faster, so we can't expect the same gains with the current
version (which is actually correct (I think)), but after we do some optimizations
it should be close.

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?

> Are quarter circles easy to detect?  Their 2 angles should both be 45 
> degrees and their lengths should be similar (I don't think the middle 
> control segment is the same length as the outer 2, but there is probably 
> some tolerance where a single subdivision works fine).

What I'm doing now is that for every curve, I rotate it so that p2-p1 is 
parallel to the x-axis. So if the curve was a quarter circle, after the
rotation it should be monotonic in both x and y. This is similar to
detecting quarter circles by looking at the angles, but it's more general.
And, I think, it has the same numerical problems. Because of this, I don't
think we should treat them as a special case.
But anyway, this isn't a big deal. My main concern with ignoring dx/dt and
dy/dt roots outside of (0.001,0.999) was a stylistic one, but it won't
really affect correctness much. The worst that can happen is that a curve
that bends a tiny bit more than 90 degrees will be widened by 1 curve, 
instead of 2, which is what we would like.

Regards,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:
> 			...jim
> 
> On 9/2/2010 7:08 AM, Denis Lila wrote:
> > Hello Jim.
> >
> > Sorry for all the e-mails.
> > I implemented the rotating version. The rotation introduces small
> > numerical errors, so when I solve for the roots of dx/dt and dy/dt,
> > the values of t I get are slightly off. So for a rotated quarter
> > circle, what happens is that it gives me a root at, say,
> t=0.9996...
> > so I still end up subdividing quarter circles. I "fixed" this by
> > ignoring all roots outside of (0.001,0.999), instead of ignoring
> > roots outside of (0,1) which is the ideal solution. I don't like
> > hardcoding constants like this. Add to this the higher complexity
> > of the rotation, and I'm tempted to say it might be better to just
> > bite the bullet on rotated quarter circles and widen them using 2
> > curves per side.
> >
> > I had one question: what do you think of widening all curves using
> > quadratic curves? Their great simplicity might make things safer.
> We
> > can guarantee that none of the strange behaviour I've seen and
> described
> > with cubic curves will arise (but we'd have to use more of them).
> >
> > Also, I've tested the current implementation with a few hundred
> random
> > cubic paths, and everything looks good so far.
> >
> > Thanks,
> > Denis.
> >
> > ----- "Denis Lila"<dlila at redhat.com>  wrote:
> >
> >> Hello Jim.
> >>
> >>> I think this would actually ensure that every resulting curve can
> >>> be rotated to be made monotonic in both x and y (at least after
> >>> inflections are eliminated), which means it's at least as good as
> >>> what I have now.
> >>
> >> While that first statement is true, it unfortunately does not mean
> >> it's
> >> "at least as good as" breaking the curve into monotonic pieces. I
> >> implemented the angle checking method, and the problem is that for
> >> curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's
> >> because I implemented it by subdividing at t=0.5, so the angles
> >> in the resulting curves' polygons are still wide. After enough
> >> subdivisions the polygons would have angles below 45, but that
> would
> >> defeat the point, since we're trying to minimize the number of
> output
> >> curves.
> >> I can't think of a good way to chose the subdivision t so that
> >> this method is as good as the rotation and make monotonic one
> (nothing
> >> with any properties I can prove, anyway), so I'll implement the
> >> rotating version, as much as I don't like it. At least it gives a
> good
> >> upper bound in the number of output curves.
> >>
> >> Regards,
> >> Denis.
> >>
> >> ----- "Denis Lila"<dlila at redhat.com>  wrote:
> >>
> >>> Hello Jim.
> >>> Thanks for taking the time to think about this.
> >>>
> >>> I implemented a few different offsetting schemes. On well behaved
> >>> curves, my original "parallel first and last control vectors and
> go
> >>> through B(0.5)" algorithm was by far the best. Theoretically it
> is
> >>> also somewhat better justified than the others (some of which
> were
> >>> like Apache Harmony's way - offsetting p2 and p3), since we're
> >>> interpolating instead of just using some heuristic. It is also
> >>> the only one I've encountered that widens quarter circles
> optimally,
> >>> and it only needs one curve per side too (i.e. if we have to
> widen
> >>> the path of a PathIterator of a circle with radius r, using width
> w,
> >>> Pisces' output will be identical to the output of the
> PathIterators
> >>> of 2 circles with radii r+w and r-w (perhaps not identical
> >> identical,
> >>> since PathIterators can use doubles, and we only use floats in
> >> pisces,
> >>> but... that's nitpicking)).
> >>>
> >>> As I've said before, the only 2 problems with it were that it was
> >> bad
> >>> on high curvatures (but this was fixed by breaking down the
> curves
> >>> into
> >>> monotonic ones), and it was bad on curves like
> >>> p.moveTo(0,0);p.curveTo(100,100,0,100,100,1). I thought the
> latter
> >> was
> >>> fixable with the "d1/(d1+d2)" algorithm I suggested in my
> previous
> >>> e-mail.
> >>> I implemented it, and it turns out I was wrong. Then I came up
> with
> >> my
> >>> own
> >>> variation of that algorithm (the original one I used was from Don
> >>> Lancaster's
> >>> website) that did sort of work. But then I implemented your
> >> suggestion
> >>> of
> >>> splitting the curve at the inflection points as well as breaking
> it
> >>> into
> >>> monotonic pieces, and the problem was gone. I didn't even have to
> >> use
> >>> the
> >>> fancy variation of the "d1/(d1 + d2)" algorithm - just the plain
> old
> >>> interpolation one worked (I should say that the fancy one is
> still
> >>> probably
> >>> better, but undetectably so, now that we break at inflection
> points
> >>> and at
> >>> xy direction changes, so the added complexity is probably not
> worth
> >>> it).
> >>>
> >>> I've attached my latest Stroker.java, if you want to take a look
> at
> >>> these
> >>> algorithms (they're in computeOffsetWay1 (for the old
> interpolation)
> >>> and
> >>> computeOffsetWay3 (for the fancy version). There are 2 more, but
> >> these
> >>> aren't as good, and one is just shameful). I didn't make a webrev
> >>> because
> >>> I still need to fix how it handles cusps (which should be easy),
> and
> >> I
> >>> need to implement a way to avoid subdividing a rotated quarter
> >> circle.
> >>> I can do this either by rotating curves so that p2-p1 is parallel
> to
> >>> the
> >>> x axis and then subdivide like I do now (i.e. make monotonic,
> break
> >> at
> >>> inflections) or get rid of the monotonic subdivision, and instead
> >>> subdivide
> >>> by checking the angles of the control polygon. I could make it so
> it
> >>> subdivides whenever the angles between p2-p1 and p3-p2 or p3-p2
> and
> >>> p4-p3
> >>> are greater than 45 degrees.
> >>>
> >>> Very well. I've convinced myself. I'll implement the latter.
> >>>
> >>> Thanks,
> >>> Denis.
> >>>
> >>> ----- "Jim Graham"<james.graham at oracle.com>  wrote:
> >>>
> >>>> Hi Denis,
> >>>>
> >>>> Just to let you know that I've seen this and I'm thinking.
> >>>>
> >>>> But it will take a bit of "more thinking" when I have time for
> >> more.
> >>>> Hopefully in a couple of days.
> >>>>
> >>>> For one thing, it sounds like you already understand the Apache
> >>>> Harmony
> >>>> approach quite a bit better than I ever did and, in particular,
> >> why
> >>> it
> >>>>
> >>>> didn't work well - which is encouraging.  Hopefully your
> solution
> >>> will
> >>>>
> >>>> sound pretty good when I get around to wrapping my head around
> >> it...
> >>>>
> >>>> 			...jim
> >>>>
> >>>> On 8/30/2010 3:03 PM, Denis Lila wrote:
> >>>>> Hello Jim.
> >>>>>
> >>>>>> One way in which they may not break enough is that I think
> that
> >>>>>> inflections also need to be broken in order to find a parallel
> >>>> curve
> >>>>>> (though I suppose a very tiny inflection might still be
> >>>> approximated by
> >>>>>> a parallel curve easily) and inflections can happen at any
> >> angle
> >>>> without
> >>>>>> going horizontal or vertical.
> >>>>>
> >>>>>       It wouldn't be hard to add additional breaks at the
> >>> inflection
> >>>> points.
> >>>>>
> >>>>>> Secondly, although a circle tends to be represented by
> quadrant
> >>>> sections
> >>>>>> which are monotonic, a circle rotated by 45 degrees would have
> >>>>>> horizontal and vertical sections in the middle of each
> quadrant
> >>> and
> >>>> you
> >>>>>> would split those, but really they can be made parallel
> >>> regardless
> >>>> of
> >>>>>> angle so these would be unnecessary splits.
> >>>>>
> >>>>>       That's true, and it's one reason I didn't like my method
> >> very
> >>>> much when I sent
> >>>>> my previous e-mail. However, what if we rotated curves so that
> >>> B'(0)
> >>>> is
> >>>>> parallel to the x-axis before splitting at points where dx/dt
> or
> >>>> dy/dt are 0?
> >>>>> This would certainly get rid of this problem for circles, and
> >>>> probably for
> >>>>> other curves. All it would cost is 1 Math.cos and 1 Math.sin
> and
> >> a
> >>>> few
> >>>>> multiplications and additions per curve.
> >>>>>
> >>>>> The biggest problem with my implementation was that some curves
> >>> that
> >>>> were almost
> >>>>> lines were drawn horribly. I computed the parallel (p1', p2',
> >> p3',
> >>>> p4') of
> >>>>> a given curve (p1, p2, p3, p4) by making p2'-p1' parallel to
> >>> p2-p1,
> >>>>> making p4'-p3' parallel to p4-p3. This leaves a 2 unknowns, so
> >> to
> >>>> get 2 more
> >>>>> equations I made the computed parallel at t=0.5 equal to the
> >> ideal
> >>>> parallel
> >>>>> at t=0.5. The problem was that for some curves (ones with very
> >>> high
> >>>> curvature)
> >>>>> p2'-p1' and p4'-p3' were parallel to p2-p1 and p4-p3 but their
> >>>> directions were
> >>>>> opposite, so you can imagine what the computed "parallel"
> looked
> >>>> like.
> >>>>> However, I am almost certain that the problem was caused by
> >> making
> >>>> C(0.5) = P(0.5)
> >>>>> (where C is the computed curve, and P is the ideal parallel). A
> >>> much
> >>>> better
> >>>>> restriction, that I think would eliminate the problem would be
> >>>> C(d1/(d1 + d2)) = P(0.5).
> >>>>> where d1 = ||P(0.5)-P(0)|| and d2 = ||P(1)-P(0.5)||.
> >>>>>
> >>>>>> My belief is that lengths and angles of the control polygon
> >> help
> >>>>>> determine if it is well-behaved and can be made parallel
> simply
> >>> by
> >>>>>> offsetting.  Some formula involving those values would likely
> >> be
> >>>> happy
> >>>>>> with circle sections regardless of their angle of rotation.  I
> >>>> believe
> >>>>>> the Apache Harmony version of BasicStroke used those
> >> criteria...
> >>>>>
> >>>>>       I've been reading the Apache Harmony file. The way they
> do
> >> it
> >>>> is compute
> >>>>> the tangent of an angle using the line width and a predefined
> >>>> constant
> >>>>> (which doesn't seem to be related to the curve's polygon - it's
> >>> just
> >>>> a decreasing
> >>>>> function with the range (-1,1)), and if some angles in the
> >> polygon
> >>>> are smaller than
> >>>>> the computed angle, offset curves are computed. Otherwise the
> >>> curve
> >>>> is subdivided.
> >>>>> However, I can't understand how offsets for the control points
> >> are
> >>>> computed (i.e.
> >>>>> why they use the equations they use, and why they work).
> >>>>> If we're using the widening of quarter circles as a yard stick,
> >>> then
> >>>> Apache Harmony's
> >>>>> BasicStroke does not do very well. If we have a quarter circle
> >>> from
> >>>> (1,0) to (0,1),
> >>>>> then the control points c1 and c2 should be (1,k) and (k,1)
> >> where
> >>> k
> >>>> = 4*(sqrt(2)-1)/3.
> >>>>> A parallel curve w away from this quarter circle should have
> >>> control
> >>>> points
> >>>>> (1+w,k+k*w) and (k+k*w,1+w). I traced Apache Harmony's
> >>> computations
> >>>> on a quarter
> >>>>> circle, and this is not what it outputs. Furthermore, all
> >> quarter
> >>>> circles with line
> >>>>> width<   9.65 will be subdivided. My method with the
> >> modifications
> >>>> suggested above
> >>>>> doesn't have these problems.
> >>>>>
> >>>>>       But perhaps it's better to not interpolate through P(0.5)
> >>> after
> >>>> all.
> >>>>> In addition to making p4'-p3' and p2'-p1' parallel to p4-p3 and
> >>>> p2-p1, we could
> >>>>> also make p3'-p2' parallel to p3-p2. These constraints leave
> >> just
> >>>> one unknown, which
> >>>>> needs to be eliminated. I am not sure how to do this. I thought
> >>>> about making the line
> >>>>> (p2',p3') be a distance of w from (p2,p3) (which is exactly
> what
> >>>> needs to be done for
> >>>>> (p1',p2') and (p3',p4')) but this doesn't get us what we want
> >> for
> >>>> quarter circles. So, finding
> >>>>> the control points would boil down to finding intersections of
> 3
> >>>> lines.
> >>>>>
> >>>>> Do you have any suggestions on how to do the offsetting for the
> >>>> control points?
> >>>>>
> >>>>> Thank you,
> >>>>> Denis.
> >>>>>
> >>>>> ----- "Jim Graham"<james.graham at oracle.com>   wrote:
> >>>>>
> >>>>>> Hi Denis,
> >>>>>>
> >>>>>> At the bottom-most rendering level monotonic curves can be
> cool
> >>> to
> >>>> deal
> >>>>>> with, but I'm dubious that they help with widening.  For one
> >>>> things, I
> >>>>>> think you need more breaks than they would give you and also
> >> they
> >>>> might
> >>>>>> sometimes break a curve when it doesn't need it.
> >>>>>>
> >>>>>> 		...jim
> >>>>>>
> >>>>>> On 8/25/2010 2:36 PM, Denis Lila wrote:
> >>>>>>> Hello Jim.
> >>>>>>>
> >>>>>>>> I think a more dynamic approach that looked at how "regular"
> >>> the
> >>>>>> curve
> >>>>>>>> was would do better.  Regular is hard to define, but for
> >>>> instance
> >>>>>> a
> >>>>>>>> bezier section of a circle could have parallel curves
> >> computed
> >>>>>> very
> >>>>>>>> easily without having to flatten or subdivide further.
> >> Curves
> >>>>>> with
> >>>>>>>> inflections probably require subdividing to get an accurate
> >>>>>> parallel
> >>>>>>>> curve.
> >>>>>>>
> >>>>>>> I'm not sure if you read it, but after the email with the
> >> webrev
> >>>>>> link
> >>>>>>> I sent another describing a different method of widening:
> >> split
> >>>> the
> >>>>>>> curve at every t where dx/dt == 0 and dy/dt == 0. This
> >>> guarantees
> >>>>>> that
> >>>>>>> there will be no more than 5 curves per side, and since each
> >>>> curve
> >>>>>> will
> >>>>>>> be monotonic in both x and y the curve that interpolates its
> >>>>>> parallel
> >>>>>>> should do a pretty good job.
> >>>>>>>
> >>>>>>> This is far better than interpolating at regular t intervals,
> >>> but
> >>>>>> I'm
> >>>>>>> trying to find a better way. I don't like this because the
> >> split
> >>>>>>> depend not only on the curve itself, but also on the axes.
> The
> >>>> axes
> >>>>>> are
> >>>>>>> arbitrary, so this is not good. For example a curve like this
> >>>>>>> |
> >>>>>>> \_ would get widened by 1 curve per side (which is good and
> >>>>>> optimal), but
> >>>>>>> if we rotate this curve by, say, 30 degrees it would be
> >> widened
> >>> by
> >>>> 2
> >>>>>> curves
> >>>>>>> per side.
> >>>>>>> It also doesn't handle cusps and locations of high curvature
> >>> very
> >>>>>> well (although
> >>>>>>> I think the latter is a numerical issue that could be made
> >>> better
> >>>> by
> >>>>>> using
> >>>>>>> doubles).
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Denis.
> >>>>>>>
> >>>>>>> ----- "Jim Graham"<james.graham at oracle.com>    wrote:
> >>>>>>>
> >>>>>>>> Hi Denis,
> >>>>>>>>
> >>>>>>>> On 8/23/2010 4:18 PM, Denis Lila wrote:
> >>>>>>>>>         To widen cubic curves, I use a cubic spline with a
> >>> fixed
> >>>>>> number
> >>>>>>>> of curves for
> >>>>>>>>> each curve to be widened. This was meant to be temporary,
> >>> until
> >>>> I
> >>>>>>>> could find a
> >>>>>>>>> better algorithm for determining the number of curves in
> the
> >>>>>> spline,
> >>>>>>>> but I
> >>>>>>>>> discovered today that that won't do it.
> >>>>>>>>>         For example, the curve
> p.moveTo(0,0),p.curveTo(84.0,
> >>>> 62.0,
> >>>>>>>> 32.0, 34.0, 28.0, 5.0)
> >>>>>>>>> looks bad all the way up to ~200 curves. Obviously, this is
> >>>>>>>> unacceptable.
> >>>>>>>>>
> >>>>>>>>> It would be great if anyone has any better ideas for how to
> >> go
> >>>>>> about
> >>>>>>>> this.
> >>>>>>>>> To me it seems like the problem is that in the webrev I
> chop
> >>> up
> >>>>>> the
> >>>>>>>> curve to be
> >>>>>>>>> interpolated at equal intervals of the parameter.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Perhaps looking at the rate of change of the slope (2nd
> >> and/or
> >>>> 3rd
> >>>>>>>> derivatives) would help to figure out when a given section
> of
> >>>>>> curve
> >>>>>>>> can
> >>>>>>>> be approximated with a parallel version?
> >>>>>>>>
> >>>>>>>> I believe that the BasicStroke class of Apache Harmony
> >> returns
> >>>>>> widened
> >>>>>>>>
> >>>>>>>> curves, but when I tested it it produced a lot more curves
> >> than
> >>>>>> Ductus
> >>>>>>>>
> >>>>>>>> (still, probably a lot less than the lines that would be
> >>>> produced
> >>>>>> by
> >>>>>>>> flattening) and it had some numerical problems.  In the end
> I
> >>>>>> decided
> >>>>>>>> to
> >>>>>>>> leave our Ductus stuff in there until someone could come up
> >>> with
> >>>> a
> >>>>>>>> more
> >>>>>>>> reliable Open Source replacement, but hopefully that code is
> >>>> close
> >>>>>>>> enough to be massaged into working order.
> >>>>>>>>
> >>>>>>>> You can search the internet for "parallel curves" and find
> >> lots
> >>>> of
> >>>>>>>> literature on the subject.  I briefly looked through the web
> >>>>>> sites,
> >>>>>>>> but
> >>>>>>>> didn't have enough time to remember enough calculus and
> >>>>>> trigonometry
> >>>>>>>> to
> >>>>>>>> garner a solution out of it all with the time that I had.
> >>> Maybe
> >>>>>>>> you'll
> >>>>>>>> have better luck following the algorithms... ;-)
> >>>>>>>>
> >>>>>>>> As far as flattening at the lowest level when doing scanline
> >>>>>>>> conversion,
> >>>>>>>> I like the idea of using forward differencing as it can
> >> create
> >>>> an
> >>>>>>>> algorithm that doesn't require all of the intermediate
> >> storage
> >>>> that
> >>>>>> a
> >>>>>>>>
> >>>>>>>> subdividing flattener requires.  One reference that
> describes
> >>>> the
> >>>>>>>> technique is on Dr. Dobbs site, though I imagine there are
> >> many
> >>>>>>>> others:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> http://www.drdobbs.com/184403417;jsessionid=O5N5MDJRDMIKHQE1GHOSKH4ATMY32JVN
> >>>>>>>>
> >>>>>>>> You can also look at the code in
> >>>>>>>> src/share/native/sun/java2d/pipe/ProcessPath.c for some
> >>> examples
> >>>>>> of
> >>>>>>>> forward differencing in use (and that code also has similar
> >>>>>> techniques
> >>>>>>>>
> >>>>>>>> to what you did to first chop the path into vertical
> pieces).
> >>>> BUT
> >>>>>>>> (*Nota Bene*), I must warn you that the geometry of the path
> >> is
> >>>>>>>> somewhat
> >>>>>>>> perturbed in that code since it tries to combine "path
> >>>>>> normalization"
> >>>>>>>>
> >>>>>>>> and rasterization into a single process.  It's not rendering
> >>>> pure
> >>>>>>>> geometry, it is rendering tweaked geometry which tries to
> >> make
> >>>>>> non-AA
> >>>>>>>>
> >>>>>>>> circles look round and other such aesthetics-targeted
> >>>> impurities.
> >>>>>>>> While
> >>>>>>>> the code does have good examples of how to set up and
> >> evaluate
> >>>>>> forward
> >>>>>>>>
> >>>>>>>> differencing equations, don't copy too many of the details
> or
> >>>> you
> >>>>>>>> might
> >>>>>>>> end up copying some of the tweaks and the results will look
> >>>>>> strange
> >>>>>>>> under AA.  The Dr. Dobbs article should be your numerical
> >>>>>> reference
> >>>>>>>> and
> >>>>>>>> that reference code a practical, but incompatible,
> example...
> >>>>>>>>
> >>>>>>>> 			...jim


From james.graham at oracle.com  Thu Sep  2 22:12:58 2010
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 02 Sep 2010 15:12:58 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <265307286.25361283463781083.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <265307286.25361283463781083.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C80216A.1070503@oracle.com>

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?

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?

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


From dlila at redhat.com  Thu Sep  2 22:20:57 2010
From: dlila at redhat.com (Denis Lila)
Date: Thu, 2 Sep 2010 18:20:57 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <4C80216A.1070503@oracle.com>
Message-ID: <2018298659.28761283466057252.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

> 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


From james.graham at oracle.com  Thu Sep  2 22:29:47 2010
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 02 Sep 2010 15:29:47 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <2018298659.28761283466057252.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <2018298659.28761283466057252.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C80255B.5000208@oracle.com>

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

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


From dlila at redhat.com  Thu Sep  2 22:40:57 2010
From: dlila at redhat.com (Denis Lila)
Date: Thu, 2 Sep 2010 18:40:57 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <486364480.29261283467223483.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1032157289.29281283467257057.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

> 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


From james.graham at oracle.com  Fri Sep  3 00:01:47 2010
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 02 Sep 2010 17:01:47 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1032157289.29281283467257057.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1032157289.29281283467257057.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C803AEB.1030208@oracle.com>

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


From dlila at redhat.com  Fri Sep  3 13:03:04 2010
From: dlila at redhat.com (Denis Lila)
Date: Fri, 3 Sep 2010 09:03:04 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <4C803AEB.1030208@oracle.com>
Message-ID: <1037035688.59781283518984456.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

> 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


From dlila at redhat.com  Fri Sep  3 21:13:34 2010
From: dlila at redhat.com (Denis Lila)
Date: Fri, 3 Sep 2010 17:13:34 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <590478246.107181283548404639.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <194389473.107261283548414481.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

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


From james.graham at oracle.com  Fri Sep  3 22:01:24 2010
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 03 Sep 2010 15:01:24 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1037035688.59781283518984456.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1037035688.59781283518984456.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C817034.8060704@oracle.com>

On 9/3/2010 6:03 AM, Denis Lila wrote:
>> 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?

That depends on the performance differential after your de-flattening 
fixes.  Are both now relatively close in performance?

Either way I imagine that performance will improve if we reduce the 
native interface transitions - it just may change in relative priority 
if your new widener is less abusive towards it...

			...jim


From andrew.brygin at sun.com  Tue Sep  7 13:18:18 2010
From: andrew.brygin at sun.com (andrew.brygin at sun.com)
Date: Tue, 07 Sep 2010 13:18:18 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk:
	6972495:	javax/imageio/CachePremissionsTest/CachePermissionsTest.java
	failed
Message-ID: <20100907131844.6389D47796@hg.openjdk.java.net>

Changeset: d4012b86a6e9
Author:    bae
Date:      2010-09-07 16:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d4012b86a6e9

6972495: javax/imageio/CachePremissionsTest/CachePermissionsTest.java failed
Reviewed-by: prr

! test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java



From dlila at redhat.com  Tue Sep  7 21:11:55 2010
From: dlila at redhat.com (Denis Lila)
Date: Tue, 7 Sep 2010 17:11:55 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <950578331.306631283893532953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1546296806.307271283893915029.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

> 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


From andrew.brygin at sun.com  Thu Sep  9 12:50:23 2010
From: andrew.brygin at sun.com (andrew.brygin at sun.com)
Date: Thu, 09 Sep 2010 12:50:23 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6523398: OSS CMM: Need to
	implement writing ICC	profile tags in new lcms library
Message-ID: <20100909125100.8AF0047845@hg.openjdk.java.net>

Changeset: fd7eb86ac690
Author:    bae
Date:      2010-09-09 16:20 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fd7eb86ac690

6523398: OSS CMM: Need to implement writing ICC profile tags in new lcms library
Reviewed-by: igor, prr

! make/sun/cmm/lcms/FILES_c_unix.gmk
! make/sun/cmm/lcms/FILES_c_windows.gmk
! make/sun/cmm/lcms/Makefile
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/native/sun/java2d/cmm/lcms/LCMS.c
! src/share/native/sun/java2d/cmm/lcms/cmscam02.c
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
! src/share/native/sun/java2d/cmm/lcms/cmscgats.c
! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c
! src/share/native/sun/java2d/cmm/lcms/cmserr.c
! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c
! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c
! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c
! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! src/share/native/sun/java2d/cmm/lcms/cmsio1.c
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
+ src/share/native/sun/java2d/cmm/lcms/cmsmd5.c
! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c
! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c
+ src/share/native/sun/java2d/cmm/lcms/cmsopt.c
! src/share/native/sun/java2d/cmm/lcms/cmspack.c
! src/share/native/sun/java2d/cmm/lcms/cmspcs.c
+ src/share/native/sun/java2d/cmm/lcms/cmsplugin.c
! src/share/native/sun/java2d/cmm/lcms/cmsps2.c
! src/share/native/sun/java2d/cmm/lcms/cmssamp.c
+ src/share/native/sun/java2d/cmm/lcms/cmssm.c
+ src/share/native/sun/java2d/cmm/lcms/cmstypes.c
! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c
! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c
! src/share/native/sun/java2d/cmm/lcms/cmsxform.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h
+ src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h



From ptisnovs at redhat.com  Fri Sep 10 10:12:40 2010
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Fri, 10 Sep 2010 12:12:40 +0200
Subject: [OpenJDK 2D-Dev] Please review change in regression test
	sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
Message-ID: <4C8A0498.10706@redhat.com>

Hi,

can anybody please review the simple change in regression test
sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java?

Webrev containing this change is available here:
http://cr.openjdk.java.net/~ptisnovs/OnScreenRenderingResizeTest/

I replaced the call of a method Point.move() by Point.translate()
because this test did not work correctly in those cases when the top
(and probably left) screen area is occupied by a toolbar/panel (which is
the default settings for GNOME for example).

I've successfully tested this changed regression test on RHEL5 with
GNOME installed (with and without top panel).

Cheers
Pavel T.

PS: the name of the method Point.move() is a bit confusing for me as I
(and probably also author of the test) have thought it is similar to
Point.translate() ;-)


From james.graham at oracle.com  Fri Sep 10 19:55:17 2010
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 10 Sep 2010 12:55:17 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1546296806.307271283893915029.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1546296806.307271283893915029.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C8A8D25.5020003@oracle.com>

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


From dlila at redhat.com  Fri Sep 10 20:11:15 2010
From: dlila at redhat.com (Denis Lila)
Date: Fri, 10 Sep 2010 16:11:15 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1649475113.605111284149035733.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1934527130.605741284149475584.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Actually, I just finished implementing a solution to the problem I've
been talking about. I've only tested it on the problematic curve I
have talked about, but it works very well.

I've also changed the structure of the engine quite a bit. Mostly
to optimize things and get rid of unnecessary object allocations,
but also to clean things up a bit - the way it was, with nearly all
the logic for widening and dashing in BezCurve.java wasn't very pleasing
and it couldn't be made so unless we made the class completely immutable
and threw performance out the window.

It doesn't look like I'll be able to send a webrev out by today, but I'll
work on it a bit during the weekend and I should have a good one by Monday.

Regards,
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


From artem.ananiev at oracle.com  Mon Sep 13 12:31:43 2010
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 13 Sep 2010 16:31:43 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Please review change in regression
	test	sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
In-Reply-To: <4C8A0498.10706@redhat.com>
References: <4C8A0498.10706@redhat.com>
Message-ID: <4C8E19AF.1020302@oracle.com>

Hi, Pavel,

indeed, the names are confusing. Your changes look correct.

Thanks,

Artem

On 9/10/2010 2:12 PM, Pavel Tisnovsky wrote:
> Hi,
>
> can anybody please review the simple change in regression test
> sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java?
>
> Webrev containing this change is available here:
> http://cr.openjdk.java.net/~ptisnovs/OnScreenRenderingResizeTest/
>
> I replaced the call of a method Point.move() by Point.translate()
> because this test did not work correctly in those cases when the top
> (and probably left) screen area is occupied by a toolbar/panel (which is
> the default settings for GNOME for example).
>
> I've successfully tested this changed regression test on RHEL5 with
> GNOME installed (with and without top panel).
>
> Cheers
> Pavel T.
>
> PS: the name of the method Point.move() is a bit confusing for me as I
> (and probably also author of the test) have thought it is similar to
> Point.translate() ;-)


From omajid at redhat.com  Mon Sep 13 15:51:21 2010
From: omajid at redhat.com (Omair Majid)
Date: Mon, 13 Sep 2010 11:51:21 -0400
Subject: [OpenJDK 2D-Dev] Fixes for two bugs in stroker
Message-ID: <4C8E4879.9060008@redhat.com>

Hi,

A while ago I filed
http://bugs.openjdk.java.net/show_bug.cgi?id=100046
and
http://bugs.openjdk.java.net/show_bug.cgi?id=100047
which contain fixes for two bugs in lines drawn by the Stroker. Will 
someone be kind enough to review these patches? The bug reports contain 
patches and images showing the differences in output.

Thanks,
Omair


From dlila at redhat.com  Mon Sep 13 23:01:58 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 13 Sep 2010 19:01:58 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <799038207.720981284418887967.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1314141409.721021284418918818.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

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


From james.graham at oracle.com  Tue Sep 14 01:28:26 2010
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 13 Sep 2010 18:28:26 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1314141409.721021284418918818.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1314141409.721021284418918818.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C8ECFBA.6050907@oracle.com>

Hi Denis,

sx1,sy1 have lost their way along the way somewhere.  Here is the thing 
I think they may have once been used for that seems to be gone now...

- If the first dash starts in the middle of an "on" phase then you 
shouldn't send it to the output right away.  Remember its segments until 
it turns "off" then save those segments aside.  If the path is closed 
and if you ended in the middle of a dash "on" phase and you have some of 
those "initial on" segments saved then send those original segments from 
the first "on" dash as an extension of the closing "on" segment.  If the 
path doesn't close, or if it closes but isn't on when it gets back to 
the original point, then send those first segments starting with a 
moveto so that they form their own isolated dash.

All of that support code to save aside that first "on" dash seems to 
have gone missing and so sx1,sy1 don't make sense any more.

I don't think you actually need sx1, sy1 - instead you need to buffer 
and save aside the first set of dashes and I don't see that buffer 
anywhere...

			...jim

On 9/13/2010 4:01 PM, Denis Lila wrote:
> 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


From ptisnovs at redhat.com  Tue Sep 14 08:36:20 2010
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 14 Sep 2010 10:36:20 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> Please review change in regression
	test	sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
In-Reply-To: <4C8E19AF.1020302@oracle.com>
References: <4C8A0498.10706@redhat.com> <4C8E19AF.1020302@oracle.com>
Message-ID: <4C8F3404.4010702@redhat.com>

Hi Artem,

could you please create a bug id so I'll be able to push this change to tl?

Thank you in advance
Pavel

Artem Ananiev wrote:
> Hi, Pavel,
> 
> indeed, the names are confusing. Your changes look correct.
> 
> Thanks,
> 
> Artem
> 
> On 9/10/2010 2:12 PM, Pavel Tisnovsky wrote:
>> Hi,
>>
>> can anybody please review the simple change in regression test
>> sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java?
>>
>>
>> Webrev containing this change is available here:
>> http://cr.openjdk.java.net/~ptisnovs/OnScreenRenderingResizeTest/
>>
>> I replaced the call of a method Point.move() by Point.translate()
>> because this test did not work correctly in those cases when the top
>> (and probably left) screen area is occupied by a toolbar/panel (which is
>> the default settings for GNOME for example).
>>
>> I've successfully tested this changed regression test on RHEL5 with
>> GNOME installed (with and without top panel).
>>
>> Cheers
>> Pavel T.
>>
>> PS: the name of the method Point.move() is a bit confusing for me as I
>> (and probably also author of the test) have thought it is similar to
>> Point.translate() ;-)



From artem.ananiev at oracle.com  Tue Sep 14 12:45:31 2010
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 14 Sep 2010 16:45:31 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Please review change in
	regression	test	sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
In-Reply-To: <4C8F3404.4010702@redhat.com>
References: <4C8A0498.10706@redhat.com> <4C8E19AF.1020302@oracle.com>
	<4C8F3404.4010702@redhat.com>
Message-ID: <4C8F6E6B.3020007@oracle.com>


On 9/14/2010 12:36 PM, Pavel Tisnovsky wrote:
> Hi Artem,
>
> could you please create a bug id so I'll be able to push this change to tl?

6984543: Test sun/java2d/DirectX/OnScreenRenderingResizeTest fails on GNOME

It will be available at bugs.sun.com in a few hours/days.

Thanks,

Artem

> Thank you in advance
> Pavel
>
> Artem Ananiev wrote:
>> Hi, Pavel,
>>
>> indeed, the names are confusing. Your changes look correct.
>>
>> Thanks,
>>
>> Artem
>>
>> On 9/10/2010 2:12 PM, Pavel Tisnovsky wrote:
>>> Hi,
>>>
>>> can anybody please review the simple change in regression test
>>> sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java?
>>>
>>>
>>> Webrev containing this change is available here:
>>> http://cr.openjdk.java.net/~ptisnovs/OnScreenRenderingResizeTest/
>>>
>>> I replaced the call of a method Point.move() by Point.translate()
>>> because this test did not work correctly in those cases when the top
>>> (and probably left) screen area is occupied by a toolbar/panel (which is
>>> the default settings for GNOME for example).
>>>
>>> I've successfully tested this changed regression test on RHEL5 with
>>> GNOME installed (with and without top panel).
>>>
>>> Cheers
>>> Pavel T.
>>>
>>> PS: the name of the method Point.move() is a bit confusing for me as I
>>> (and probably also author of the test) have thought it is similar to
>>> Point.translate() ;-)
>


From dlila at redhat.com  Tue Sep 14 17:48:37 2010
From: dlila at redhat.com (Denis Lila)
Date: Tue, 14 Sep 2010 13:48:37 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1514655111.796031284486261033.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1737603966.796281284486517453.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

> - If the first dash starts in the middle of an "on" phase then you 
> shouldn't send it to the output right away.  Remember its segments
> until it turns "off" then save those segments aside.  If the path is
> closed and if you ended in the middle of a dash "on" phase and you 
> have some of those "initial on" segments saved then send those original
> segments from the first "on" dash as an extension of the closing "on"
> segment. If the path doesn't close, or if it closes but isn't on when
> it gets back to the original point, then send those first segments
> starting with a moveto so that they form their own isolated dash.

I see. That makes sense.

> sx1,sy1 have lost their way along the way somewhere.

I think that was my fault:

> I don't think you actually need sx1, sy1 - instead you need to buffer
> and save aside the first set of dashes and I don't see that buffer 
> anywhere...

sx1, sy1 were the buffer themselves, because we used to do flattening
so there were no curves, and no need for an array. I did not see what
they were used for, so I did not implement a buffer to replace them.
I have now. I also fixed a couple of bugs (one related to drawing square
caps and the other related to drawing joins), and I have tried to
fix the whitespace (please tell me if I missed anything).
The link is the same:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/

(For some reason, 2 unchanged files are appearing in the webrev. Please
ignore this)
There are a few smallish issues I wanted to discuss:
1. To subdivide at arbitrary t, I use equations like (1-t)*p1 + t*p2.
Should I use the more intuitive p1+t*(p2-p1)? It's clearer and should be
faster since it has 1 fewer multiplication.
2. When computing offset curves, I check for degenerate curves (i.e. equal
control and end points). I don't use == for comparisons. I use a function
that returns true if 2 floats are close to each other, for fear of
catastrophic cancellation. Is this really a good idea? If so, how close
should the numbers be before I return true?
3. Should line 862 in Stroker be enabled (I give some reasons for wanting to
in a comment below it).

Thanks,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 

> 

> 
> All of that support code to save aside that first "on" dash seems to 
> have gone missing and so sx1,sy1 don't make sense any more.
> 
> 
> 			...jim
> 
> On 9/13/2010 4:01 PM, Denis Lila wrote:
> > 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


From james.graham at oracle.com  Tue Sep 14 21:12:53 2010
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 14 Sep 2010 14:12:53 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1737603966.796281284486517453.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <1737603966.796281284486517453.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C8FE555.10301@oracle.com>

On 9/14/2010 10:48 AM, Denis Lila wrote:
> Hello Jim.
>
>> sx1,sy1 have lost their way along the way somewhere.
>
> I think that was my fault:

Not entirely - see below.

>> I don't think you actually need sx1, sy1 - instead you need to buffer
>> and save aside the first set of dashes and I don't see that buffer
>> anywhere...
>
> sx1, sy1 were the buffer themselves, because we used to do flattening
> so there were no curves, and no need for an array. I did not see what

Actually then they were already buggy.  It isn't enough to save 2 
values.  If the first "on" dash length is fairly long, and there are, 
say, 50 segments of various types (though even when we were flattening 
there could be multiple segments in the first "dash", they'd just all be 
lines) then you need to save *all* of them aside and then spit them back 
out connected to the final set of dash segments.  If the old code was 
only saving 2 coordinates then it wasn't doing it right.

So, a buffer should have always been provided/used and sx1,sy1 should 
never have been sufficient (though they may have been a "broken" attempt 
to achieve the same goal).

> they were used for, so I did not implement a buffer to replace them.
> I have now. I also fixed a couple of bugs (one related to drawing square
> caps and the other related to drawing joins), and I have tried to
> fix the whitespace (please tell me if I missed anything).
> The link is the same:
> http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/

I'll take a look at this if I can, but last minute JavaOne issues (like 
a rewrite of my slides - gulp) are starting to take over my life for the 
next couple of weeks.

> There are a few smallish issues I wanted to discuss:
> 1. To subdivide at arbitrary t, I use equations like (1-t)*p1 + t*p2.
> Should I use the more intuitive p1+t*(p2-p1)? It's clearer and should be
> faster since it has 1 fewer multiplication.

I like that other equation.  Both are find and equally understandable so 
use whatever makes the code flow or perform better for your cases.

> 2. When computing offset curves, I check for degenerate curves (i.e. equal
> control and end points). I don't use == for comparisons. I use a function
> that returns true if 2 floats are close to each other, for fear of
> catastrophic cancellation. Is this really a good idea? If so, how close
> should the numbers be before I return true?

That's a great question.  In device space I think a very small 
difference (like 1/256 of a pixel) could be enough to ignore the curve, 
but in user space it's harder to make a judgment call without knowing 
how much they'll be scaled up.  In cases like that I've sometimes used 
the Math.ulp() method to figure out how many "bits of error" we have. 
That method gives you the smallest increment for a given float or double 
so what it is telling you is the magnitude of an "off by 1 bit" error. 
If you allow differences less than 3*ulp(one of the values) then that is 
allowing 1 or 2 bits of precision error.  I'd use more than 2*ulp 
because the numbers you are comparing might be close to a cutoff where 
the binary exponent is increased.  You can also choose the largest 
(magnitude) of the values you are comparing and the ulp() of that value 
gives you a safer estimate of being "off by a bit or two", but that 
requires you to do a max() (and possibly an abs()) test just to find out 
how big of a difference to allow so I usually use a multiplier of at 
least 3 or so.

> 3. Should line 862 in Stroker be enabled (I give some reasons for wanting to
> in a comment below it).

That'll take me a day or two just to understand and figure out... 
<crosseyed smiley>

			...jim


From ptisnovs at redhat.com  Thu Sep 16 16:31:27 2010
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Thu, 16 Sep 2010 18:31:27 +0200
Subject: [OpenJDK 2D-Dev] Need reviewer for change in freetypeScaler.c
Message-ID: <4C92465F.3060707@redhat.com>

Hi,

can anybody please review simple but IMHO important change in
src/share/native/sun/font/freetypeScaler.c source file?

Webrev is available here:

http://cr.openjdk.java.net/~ptisnovs/freetypeScaler/

This change is related to the bug #6703377:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6703377
and regression test
java/awt/font/Rotate/TranslatedOutlineTest.java created for this bug
which fails due to conversion to unsigned int.

I think it should be pushed to both OpenJDK6 and OpenJDK7.

Cheers
Pavel T.


From dlila at redhat.com  Wed Sep 22 13:30:16 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 22 Sep 2010 09:30:16 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fixes for two bugs in stroker
In-Reply-To: <116099227.238701285162021466.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1320037402.239141285162216722.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Omair.

I'm sorry it took me so long to get to this.
The first patch looks good.
The second one breaks miter joins for counter clockwise paths. For
example, if the path is p.moveTo(0, 0);p.lineTo(0, 100);p.lineTo(100,100);
p.lineTo(100,0);p.closePath(); the miter join on the close won't be
drawn properly and new artifacts will be introduced on round joins (bevel
joins will simply not be drawn).

PS. I don't think that this (bug 6850438) is a bug. The specification
is a bit loose on the behaviour of BasicStroke.createStrokedShape. As
long as the created shape is filled properly, the behaviour is correct.
It would probably be a good idea to reclassify this as a RFE.
Anyway, the last thing I've been working on fixes this:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/

Regards,
Denis.

----- "Omair Majid" <omajid at redhat.com> wrote:

> Hi,
> 
> A while ago I filed
> http://bugs.openjdk.java.net/show_bug.cgi?id=100046
> and
> http://bugs.openjdk.java.net/show_bug.cgi?id=100047
> which contain fixes for two bugs in lines drawn by the Stroker. Will 
> someone be kind enough to review these patches? The bug reports
> contain 
> patches and images showing the differences in output.
> 
> Thanks,
> Omair


From dlila at redhat.com  Wed Sep 22 21:22:39 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 22 Sep 2010 17:22:39 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1632305540.307411285190080371.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <99603380.308151285190559715.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hello Jim.

> I'll take a look at this if I can, but last minute JavaOne issues (like 
> a rewrite of my slides - gulp) are starting to take over my life for the 
> next couple of weeks.

That's ok. That webrev wasn't as polished as I thought. I've done a lot of
testing since then and fixed many bugs. I ran Java2D without any problems.
The frame rate for the animations isn't noticeably different, but that's because
they don't draw many curves. I put timers in pisces and the time spent in it
(including line/move/quad/curve calls to the output PathConsumer2D) is at least
3-4 times smaller than in pisces without this changeset. When many curves are
widened the improvement goes up to a factor of 17-20.
Anti aliasing was also a bit better (this did come with a frame rate improvement). 

I also ran a 2D graphics test suite: http://icedtea.classpath.org/hg/gfx-test/
It generates thousands of images using combinations of different strokes
colours and shapes. It is fairly exhaustive, in that it uses all caps, all joins
many different line widths, different dashing patterns, different colours,
different shapes, and so on. It does this for a java implementation to be tested
and for a reference implementation and compares the generated images against each
other. I've been using the closed source java as a reference. Compared to
icedtea6 version 1.8, openjdk7 with my patch does much better. The number of
generated images that are identical to closed java has more than doubled. No
test suite performs worse and every image I've seen is closer to the reference
images. I have not put any of the test results online yet because that would be
400 megabytes and I'm not sure I'm allowed. I'll try tomorrow.

I've also rendered at least 50000 random curves using this changeset
just to make sure there are no catastrophic failures (things like crashes, half
the screen going black, etc.) Everything looked good.

I should give a high level overview of how things have changed:
1) Antialiasing uses adaptive forward differencing. Now I rasterize each curve
as soon as I receive it and store the crossings instead of storing curves and computing
the crossings as needed. This is faster, but not as memory friendly so I'm a bit uneasy
about this decision. What do you think?
2) In Dasher.java I implemented the buffer to store initial segments.
3) For dashing, I compute curve lengths using the algorithm you told me about.
4) Transforms are handled differently. We used to transform everything before feeding
it to pisces. Since pisces has to compute offsets, it needed to know about these
transforms. This made things very confusing. I have introduced a class which Stroker
and Dasher use for IO that knows about transformations. So, when a shape is being
rendered its path iterator transforms the points. These transformed points are
then normalized (if normalization is on). Then they are passed through this IO
handler which untransforms the points and feeds them to Dasher or Stroker, which
pass their output through the IO handler again which transforms them. Unfortunately,
this will do many more transformations than before. The reason I did this is to
avoid going back and forth between user space and device space coordinates in the
same file.
5) In stroker, we used to keep variables that stored the previous point (px0,py0)
and the second point (sx1 and sy1, I think). I eliminated these. They were
misleading and unnecessary and just don't make sense if we have curves. They were
misleading because the only way they were ever used was to get tangent vectors at
the start and current position in the path. I replaced them with variables that
hold these tangents. This is much clearer and saves us many subtractions. Because
of this some of the methods parameters have changed. The computeMiter parameters
are a good example of ones that should have changed but didn't because I didn't
have time to refactor it. This should be done because if we use vectors it will
be clearer and will help with 9).
6) 0 length curves and lines were being ignored. This isn't what proprietary java
does (which is drawing caps/joins as if a tiny horizontal line going right had
just been drawn). I "fixed" this to match the behaviour of proprietary java.
Because of the change above, this turned out to be a 3 liner.
7) I put code that draws joins in its own method (drawJoin). This made the close
and finish methods much clearer and allowed me to fix this createStrokedShape
issue: http://bugs.openjdk.java.net/show_bug.cgi?id=100046
8) To compute cubic offset curves first I subdivide the original curve at points
where it starts bending too much (i.e. more than 90 degrees since the last
subdivision), has inflection points, and where one of the offset curves has
cusps (see comments in the file for more on this). Finding the offset cusps was
the main reason for 4, since if we worked with transformed coordinates there
could be shears and the linewidth would not be constant (we need the line width
because offset cusps occur when the radius of curvature is equal to the width).
Then for each of these curves, I find a left offset and a right offset using
constraints that the curve and the offsets must have parallel tangents at t=0
and t=1 and that the computed offsets at t=0.5 must be equal to the ideal
true offsets at t=0.5.
9) To compute quadratic offsets I subdivide as above (except for the inflection
points, of which there are none). Then for each subdivision I compute the start
and end point in the obvious manner, and I compute the control point as the
intersection of the lines that go through the end points and are parallel to
the tangents at the end points.
10) I have included my old patch for drawing round joins using bezier curves.
11) The side and isCCW methods have changed are are almost exactly the same
as each other. I still keep them both so that round joins can be drawn in cases
such as: p.moveTo(x,y);p.lineTo(x+c,y);p.lineTo(x,y). Proprietary java does not
do this, but I think it should, since joins are meant to join different segments
in a path. In the example above there are 2 segments, and it is possible to
draw a round join, so why not? Does the specification say anything about this case?
I changed the side() algorithm because I think what I use now also works (or at
least it certainly works for all cases in which we use it), it is faster and
it is more accurate.

I think the above are all the important changes.
Some things I wanted to discuss:
1. Should I change antialiasing and make it store the curves instead of the crossings?
2. I'm not completely comfortable with the way special cases are handled in
the somethingTo, computeOffsetQuad, and computeOffsetCubic methods in Stroker.java
("special cases" being very tiny curves).
3. From tests it looks to me like offsets for quads might not be good enough. It's
barely visible, but I don't know if I'm comfortable with it (fixing this would be
pretty simple - either add some subdivisions, or approximate quad curves with cubics
(the latter might be especially nice, since we could use the same code for both
curve types)).

>> 3. Should line 862 in Stroker be enabled (I give some reasons for wanting to
>> in a comment below it).
> That'll take me a day or two just to understand and figure out... 
> <crosseyed smiley>
I'm sorry, I should have explained it. That line was a check for lineWidth2 > 1.5 &&
subdivisionsSoFar < 5. It was meant to avoid trying to find points where the offset
curves have cusps if we already have "enough" subdivisions. Now I always try to find
these points because I don't think this procedure is expensive enough to jeopardize
rendering quality.

I would very much appreciate any comments or suggestions.

Thank you,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> On 9/14/2010 10:48 AM, Denis Lila wrote:
> > Hello Jim.
> >
> >> sx1,sy1 have lost their way along the way somewhere.
> >
> > I think that was my fault:
> 
> Not entirely - see below.
> 
> >> I don't think you actually need sx1, sy1 - instead you need to
> buffer
> >> and save aside the first set of dashes and I don't see that buffer
> >> anywhere...
> >
> > sx1, sy1 were the buffer themselves, because we used to do
> flattening
> > so there were no curves, and no need for an array. I did not see
> what
> 

> 
> > they were used for, so I did not implement a buffer to replace
> them.
> > I have now. I also fixed a couple of bugs (one related to drawing
> square
> > caps and the other related to drawing joins), and I have tried to
> > fix the whitespace (please tell me if I missed anything).
> > The link is the same:
> > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
> 

> 
> > There are a few smallish issues I wanted to discuss:
> > 1. To subdivide at arbitrary t, I use equations like (1-t)*p1 +
> t*p2.
> > Should I use the more intuitive p1+t*(p2-p1)? It's clearer and
> should be
> > faster since it has 1 fewer multiplication.
> 
> I like that other equation.  Both are find and equally understandable
> so 
> use whatever makes the code flow or perform better for your cases.
> 
> > 2. When computing offset curves, I check for degenerate curves (i.e.
> equal
> > control and end points). I don't use == for comparisons. I use a
> function
> > that returns true if 2 floats are close to each other, for fear of
> > catastrophic cancellation. Is this really a good idea? If so, how
> close
> > should the numbers be before I return true?
> 
> That's a great question.  In device space I think a very small 
> difference (like 1/256 of a pixel) could be enough to ignore the
> curve, 
> but in user space it's harder to make a judgment call without knowing
> 
> how much they'll be scaled up.  In cases like that I've sometimes used
> 
> the Math.ulp() method to figure out how many "bits of error" we have.
> 
> That method gives you the smallest increment for a given float or
> double 
> so what it is telling you is the magnitude of an "off by 1 bit" error.
> 
> If you allow differences less than 3*ulp(one of the values) then that
> is 
> allowing 1 or 2 bits of precision error.  I'd use more than 2*ulp 
> because the numbers you are comparing might be close to a cutoff where
> 
> the binary exponent is increased.  You can also choose the largest 
> (magnitude) of the values you are comparing and the ulp() of that
> value 
> gives you a safer estimate of being "off by a bit or two", but that 
> requires you to do a max() (and possibly an abs()) test just to find
> out 
> how big of a difference to allow so I usually use a multiplier of at 
> least 3 or so.
> 

> 
> 			...jim


From linuxhippy at gmail.com  Fri Sep 24 21:55:28 2010
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 24 Sep 2010 23:55:28 +0200
Subject: [OpenJDK 2D-Dev] CR 6974985 Redispatched,
 P3 java/classes_2d Jave2Demo threw exceptions when xrender enabled
 in OEL5.5
In-Reply-To: <4C9A90DB.9010907@oracle.com>
References: <4C5CA334.2090400@oracle.com>
	<AANLkTimzi1R-1bSienzLfhKAamBqicKu41cQQ=W5uOp=@mail.gmail.com>
	<AANLkTimpf7rja4g2x3AY0=4Edu+N=753Rwmis3_gBjEN@mail.gmail.com>
	<4C76DA39.8080500@oracle.com>
	<AANLkTikEOVZFthU8emgKw5jh7eSQ0unJt9qHrUFyqbRP@mail.gmail.com>
	<AANLkTimFnm9shV6OGs9hYKtWP0yKvY_nP56d3u_Hierh@mail.gmail.com>
	<AANLkTin0dMK=8kYHZiLkFsfWB5s=uenq64QLqwFAa99s@mail.gmail.com>
	<4C9A90DB.9010907@oracle.com>
Message-ID: <AANLkTi=UeOzBOcYSu+AtMk72y95Z_D7Ti=e38wBscUeL@mail.gmail.com>

Hi Phil,


> It doesn't sound right to me that this behaviour is an implementation detail of X.org.
> Developers need to know that either it does or it doesn't. Were you given a
> good rationale?

The explanation was that Pixmaps are reference counted, and therefor
stay alive if a XRender-picture points to it. A window is not
reference counted, and therefor all its resources are destroyed
immediatly. GC's are not affected because they are not bound to a
drawable, thats why it hasn't been a problem for the JDK to free GCs
later than the Window.
I find this explanation fishy, but the general recommendation was to
free Pictures before the drawable in any case.

The patch attached does free the picture before destroying the window,
however casting surfaceData to XRSurfaceData in XWindow.java is ugly -
and the patch assumes nobody calls XDestroyWindow for a
SurfaceData-Drawable except destroy(). Suggestions welcome ;)

With that patch I get rid of all XErrors and also can't reproduce the
XDnD-Exception anymore.

> I don't see how that helped on its own. If the Picture is implicitly freed
> by XDestroyWindow then
> xsdo->xrPic is still going to be != None .. or am I overlooking something?

My initial analysis was wrong - somehow I thought the problem is
solved, but it wasn't.

Thanks Clemens

PS: Is there some java-side equivalent in SurfaceData for X11SD_Dispose?
I have a GC on the java side with no references on the native side and
if possible would like to free it at dispose time without writing C
code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freepictfix1.patch
Type: text/x-patch
Size: 4552 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100924/a8c1295d/freepictfix1.patch>

From james.graham at oracle.com  Sat Sep 25 00:03:48 2010
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 24 Sep 2010 17:03:48 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <99603380.308151285190559715.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <99603380.308151285190559715.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4C9D3C64.3060707@oracle.com>

Hi Denis,

Sorry for being so distracted (on the other hand, it was for JavaOne 
;-), but it looks like you made some incredible progress in the meantime!

On 9/22/2010 2:22 PM, Denis Lila wrote:
> I also ran a 2D graphics test suite: http://icedtea.classpath.org/hg/gfx-test/
> icedtea6 version 1.8, openjdk7 with my patch does much better. The number of
> generated images that are identical to closed java has more than doubled. No

Woohoo!

> I should give a high level overview of how things have changed:
> 1) Antialiasing uses adaptive forward differencing. Now I rasterize each curve
> as soon as I receive it and store the crossings instead of storing curves and computing
> the crossings as needed. This is faster, but not as memory friendly so I'm a bit uneasy
> about this decision. What do you think?

How much faster?  I'm worried about this, especially given our tiled 
approach to requesting the data.  What was the bottleneck before?  (It's 
been a while since I visited the code - we weren't computing the 
crossings for every curve in the path for every tile being generated 
were we?)

> 2) In Dasher.java I implemented the buffer to store initial segments.
> 3) For dashing, I compute curve lengths using the algorithm you told me about.

Cool.  Keep in mind that I never did an exhaustive search for "best way 
to measure curve length" so we may very well find a better algorithm if 
we need to.

> 4) Transforms are handled differently. We used to transform everything before feeding
> it to pisces. Since pisces has to compute offsets, it needed to know about these
> transforms. This made things very confusing. I have introduced a class which Stroker
> and Dasher use for IO that knows about transformations. So, when a shape is being
> rendered its path iterator transforms the points. These transformed points are
> then normalized (if normalization is on). Then they are passed through this IO
> handler which untransforms the points and feeds them to Dasher or Stroker, which
> pass their output through the IO handler again which transforms them. Unfortunately,
> this will do many more transformations than before. The reason I did this is to
> avoid going back and forth between user space and device space coordinates in the
> same file.

I can see your points here.  I think there are solutions to avoid much 
of the untransforming we can consider, but your solution works well so 
let's get it in and then we can look at optimizations if we feel they 
are causing a measurable problem later.

> 5) In stroker, we used to keep variables that stored the previous point (px0,py0)
> and the second point (sx1 and sy1, I think). I eliminated these. They were
> misleading and unnecessary and just don't make sense if we have curves. They were
> misleading because the only way they were ever used was to get tangent vectors at
> the start and current position in the path. I replaced them with variables that
> hold these tangents. This is much clearer and saves us many subtractions. Because
> of this some of the methods parameters have changed. The computeMiter parameters
> are a good example of ones that should have changed but didn't because I didn't
> have time to refactor it. This should be done because if we use vectors it will
> be clearer and will help with 9).

Cool!

> 6) 0 length curves and lines were being ignored. This isn't what proprietary java
> does (which is drawing caps/joins as if a tiny horizontal line going right had
> just been drawn). I "fixed" this to match the behaviour of proprietary java.
> Because of the change above, this turned out to be a 3 liner.

I'm glad these restructuring changes are starting to pay off.  Hopefully 
a lot more tweaks will get easier in the future.

> 7) I put code that draws joins in its own method (drawJoin). This made the close
> and finish methods much clearer and allowed me to fix this createStrokedShape
> issue: http://bugs.openjdk.java.net/show_bug.cgi?id=100046

Saner outlines are a good indication of cleaner internal processes.

> 8) To compute cubic offset curves first I subdivide the original curve at points
> where it starts bending too much (i.e. more than 90 degrees since the last
> subdivision), has inflection points, and where one of the offset curves has
> cusps (see comments in the file for more on this). Finding the offset cusps was
> the main reason for 4, since if we worked with transformed coordinates there
> could be shears and the linewidth would not be constant (we need the line width
> because offset cusps occur when the radius of curvature is equal to the width).
> Then for each of these curves, I find a left offset and a right offset using
> constraints that the curve and the offsets must have parallel tangents at t=0
> and t=1 and that the computed offsets at t=0.5 must be equal to the ideal
> true offsets at t=0.5.

Note that these kinds of heuristics are the kinds of things that people 
could probably create dissertations on, so my hat is off to you. 
Hopefully I'll be able to wrap my head around it without too much trouble.

> 9) To compute quadratic offsets I subdivide as above (except for the inflection
> points, of which there are none). Then for each subdivision I compute the start
> and end point in the obvious manner, and I compute the control point as the
> intersection of the lines that go through the end points and are parallel to
> the tangents at the end points.

I'm not sure I understand the reasoning of the control point 
calculation.  I'll have to look at the code to register an opinion.

> 10) I have included my old patch for drawing round joins using bezier curves.

Yay!

> 11) The side and isCCW methods have changed are are almost exactly the same
> as each other. I still keep them both so that round joins can be drawn in cases
> such as: p.moveTo(x,y);p.lineTo(x+c,y);p.lineTo(x,y). Proprietary java does not
> do this, but I think it should, since joins are meant to join different segments
> in a path. In the example above there are 2 segments, and it is possible to
> draw a round join, so why not? Does the specification say anything about this case?
> I changed the side() algorithm because I think what I use now also works (or at
> least it certainly works for all cases in which we use it), it is faster and
> it is more accurate.

It sounds like you are correct here.  What does the closed source code draw?

> I think the above are all the important changes.
> Some things I wanted to discuss:
> 1. Should I change antialiasing and make it store the curves instead of the crossings?

It's a topic for discussion.  I'm wary of the memory footprint, but I 
don't want to kill performance.  Is it a simple change to switch?  I'm 
also a fan of "get what you have in now as a stake in the ground and 
then deal with some of these issues as follow-on optimizations".

> 2. I'm not completely comfortable with the way special cases are handled in
> the somethingTo, computeOffsetQuad, and computeOffsetCubic methods in Stroker.java
> ("special cases" being very tiny curves).

I'll take a look and report my comfort level too.

> 3. From tests it looks to me like offsets for quads might not be good enough. It's
> barely visible, but I don't know if I'm comfortable with it (fixing this would be
> pretty simple - either add some subdivisions, or approximate quad curves with cubics
> (the latter might be especially nice, since we could use the same code for both
> curve types)).

I'll need to look at code here too before I can comment.

>>> 3. Should line 862 in Stroker be enabled (I give some reasons for wanting to
>>> in a comment below it).
>> That'll take me a day or two just to understand and figure out...
>> <crosseyed smiley>
> I'm sorry, I should have explained it. That line was a check for lineWidth2>  1.5&&
> subdivisionsSoFar<  5. It was meant to avoid trying to find points where the offset
> curves have cusps if we already have "enough" subdivisions. Now I always try to find
> these points because I don't think this procedure is expensive enough to jeopardize
> rendering quality.

Are you saying that I can ignore that question now?

> I would very much appreciate any comments or suggestions.

I'm afraid to make too many more before you get a chance to check in 
what you have now and at least get us several concrete steps towards a 
quality implementation.

I don't think I've given much in the way of counter-opinions above so if 
you are comfortable with my answers above then let's work on reviewing 
the code with an eye towards getting it in as an important milestone 
before we muck with it too much more...

			...jim


From dlila at redhat.com  Mon Sep 27 14:43:51 2010
From: dlila at redhat.com (Denis Lila)
Date: Mon, 27 Sep 2010 10:43:51 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <618169693.714331285598513853.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <974207292.714761285598631908.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hi Jim.
> How much faster?  I'm worried about this, especially given our tiled 
> approach to requesting the data.  What was the bottleneck before? 
> (It's been a while since I visited the code - we weren't computing the 
> crossings for every curve in the path for every tile being generated 
> were we?)

    Not much faster. I'm working on someting better.
    I'm not sure about the bottleneck, but what we were doing before is:
1. Flatten (by subdividing) every curve so that we deal only with lines.
2. Add each line to a list sorted by y0. When end_rendering was called
for each scanline we found the crossings of the scanline and every line
in our line list, which we used to compute the alpha for that scanline's
pixel row. All this would be put into RLE encoded temporary storage and it
would be read back and converted into tile form by PiscesTileGenerator.

    Speaking of which, would it not be better to get rid of PiscesCache and
just keep a buffer with the current tile row in Renderer.java. This would
be possible because the specification for AATileGenerator says the iteration
is like: for (y...) for (x...);.
Why is PiscesCache there? It isn't being used as a cache at all. Could it be?
Also, why do we output tiles, instead of just pixel rows (which I guess would
just be nx1 tiles). Is it because we would like to use getTypicalAlpha to eliminate
completely transparent or completely opaque regions as soon as possible (and the
longer a tile is the less of a chance it has at being either of those two)?

> I can see your points here.  I think there are solutions to avoid much 
> of the untransforming we can consider, but your solution works well so 
> let's get it in and then we can look at optimizations if we feel they 
> are causing a measurable problem later.

    I should say this isn't quite as bad as I might have made it seem. Firstly,
this IO handler class I made elimiinates transformations when Dasher
communicates with Stroker. More importantly, no untransforming is done
when the transformation is just a translation or is the identity or is singular
and when STROKE_CONTROL is off, we only transform the output path. That's
because the most important reason for handling transforms the way I do now
is because we can't normalize untransformed paths, otherwise coordinate
adjustments might be magnified too much. So, we need to transform paths
before normalization. But we also can't do the stroking and widening
before the normalization. But if normalization is removed we can just pass
untransformed paths into Stroker, and transform its output (which is still
somewhat more expensive than only trasnforming the input path, since
Stroker produces many 3-7 curves for each input curve).

> Note that these kinds of heuristics are the kinds of things that
> people could probably create dissertations on, so my hat is off to you. 
> Hopefully I'll be able to wrap my head around it without too much
> trouble.

    Thanks :)

> I'm not sure I understand the reasoning of the control point 
> calculation.  I'll have to look at the code to register an opinion.

    I'm sorry, my explanation wasn't very clear. I attached a picture that
will hopefully clarify things.
But, in a way, the computation I use is forced on us. Suppose we have a
quadratic curve B and we need to compute one of its offsets C. C'(0)
and C'(1) will be parallel to B'(0) and B'(1) so we need to make sure
our computed offset has this property too (or it would look weird around
the endpoints). Now, B'(0) and B'(1) are parallel to p2-p1 and p3-p2
where p1,p2,p3 are the 3 control points that define B, so if the control
points of C are q1, q2, q3 then q2-q1 and q3-q2 must be parallel to p2-p1
and p3-p2 respectively. At this point, we need more constraint, since
our system is underdetermined. We use the constraints that q1 = C(0)
and q3 = C(1) (so, the endpoints of the computed offset are equal to the
endpoints of the ideal offset). All we have left to compute is q2, but
we know the direction of q2-q1 and the direction of q3-q2, so q2 must
lie on the lines defined by q1+t*(q2-q1) and q3+t*(q3-q2) so q2 must
be the intersection of these lines.

> It sounds like you are correct here.  What does the closed source code
> draw?

    I thought closed source java simply didn't draw the round joins in
these cases, but I did some more testing and it turns out it does for
some curves and it doesn't for others. I've included the results of a
test I wrote that tries to draw paths like: moveTo(0,0);p.lineTo(cos,sin);p.lineTo(0,0);
where cos and sin are coordinates on a circle (source1.png is the output
of closed java. Source2.png is my output). As you can see, my
version draws the round joins on all tested cases, while closed java
is inconsistent.

> Are you saying that I can ignore that question now?

    Yes.

> let's work on reviewing the code with an eye towards getting it in
> as an important milestone before we muck with it too much more...

    That sounds good. Hopefully by the end of today I'll have a
less memory hungry AA implementation that is also faster.

Thank you,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 
> Sorry for being so distracted (on the other hand, it was for JavaOne 
> ;-), but it looks like you made some incredible progress in the
> meantime!
> 
> On 9/22/2010 2:22 PM, Denis Lila wrote:
> > I also ran a 2D graphics test suite:
> http://icedtea.classpath.org/hg/gfx-test/
> > icedtea6 version 1.8, openjdk7 with my patch does much better. The
> number of
> > generated images that are identical to closed java has more than
> doubled. No
> 
> Woohoo!
> 
> > I should give a high level overview of how things have changed:
> > 1) Antialiasing uses adaptive forward differencing. Now I rasterize
> each curve
> > as soon as I receive it and store the crossings instead of storing
> curves and computing
> > the crossings as needed. This is faster, but not as memory friendly
> so I'm a bit uneasy
> > about this decision. What do you think?
> 

> 
> > 2) In Dasher.java I implemented the buffer to store initial
> segments.
> > 3) For dashing, I compute curve lengths using the algorithm you told
> me about.
> 
> Cool.  Keep in mind that I never did an exhaustive search for "best way 
> to measure curve length" so we may very well find a better algorithm if 
> we need to.
> 
> > 4) Transforms are handled differently. We used to transform
> everything before feeding
> > it to pisces. Since pisces has to compute offsets, it needed to know
> about these
> > transforms. This made things very confusing. I have introduced a
> class which Stroker
> > and Dasher use for IO that knows about transformations. So, when a
> shape is being
> > rendered its path iterator transforms the points. These transformed
> points are
> > then normalized (if normalization is on). Then they are passed
> through this IO
> > handler which untransforms the points and feeds them to Dasher or
> Stroker, which
> > pass their output through the IO handler again which transforms
> them. Unfortunately,
> > this will do many more transformations than before. The reason I did
> this is to
> > avoid going back and forth between user space and device space
> coordinates in the
> > same file.
> 

> 
> > 5) In stroker, we used to keep variables that stored the previous
> point (px0,py0)
> > and the second point (sx1 and sy1, I think). I eliminated these.
> They were
> > misleading and unnecessary and just don't make sense if we have
> curves. They were
> > misleading because the only way they were ever used was to get
> tangent vectors at
> > the start and current position in the path. I replaced them with
> variables that
> > hold these tangents. This is much clearer and saves us many
> subtractions. Because
> > of this some of the methods parameters have changed. The
> computeMiter parameters
> > are a good example of ones that should have changed but didn't
> because I didn't
> > have time to refactor it. This should be done because if we use
> vectors it will
> > be clearer and will help with 9).
> 
> Cool!
> 
> > 6) 0 length curves and lines were being ignored. This isn't what
> proprietary java
> > does (which is drawing caps/joins as if a tiny horizontal line going
> right had
> > just been drawn). I "fixed" this to match the behaviour of
> proprietary java.
> > Because of the change above, this turned out to be a 3 liner.
> 
> I'm glad these restructuring changes are starting to pay off. 
> Hopefully a lot more tweaks will get easier in the future.
> 
> > 7) I put code that draws joins in its own method (drawJoin). This
> made the close
> > and finish methods much clearer and allowed me to fix this
> createStrokedShape
> > issue: http://bugs.openjdk.java.net/show_bug.cgi?id=100046
>  
> Saner outlines are a good indication of cleaner internal processes.
> 
> > 8) To compute cubic offset curves first I subdivide the original
> curve at points
> > where it starts bending too much (i.e. more than 90 degrees since
> the last
> > subdivision), has inflection points, and where one of the offset
> curves has
> > cusps (see comments in the file for more on this). Finding the
> offset cusps was
> > the main reason for 4, since if we worked with transformed
> coordinates there
> > could be shears and the linewidth would not be constant (we need the
> line width
> > because offset cusps occur when the radius of curvature is equal to
> the width).
> > Then for each of these curves, I find a left offset and a right
> offset using
> > constraints that the curve and the offsets must have parallel
> tangents at t=0
> > and t=1 and that the computed offsets at t=0.5 must be equal to the
> ideal
> > true offsets at t=0.5.
> 

> 
> > 9) To compute quadratic offsets I subdivide as above (except for the
> inflection
> > points, of which there are none). Then for each subdivision I
> compute the start
> > and end point in the obvious manner, and I compute the control point
> as the
> > intersection of the lines that go through the end points and are
> parallel to
> > the tangents at the end points.
> 

> 
> > 10) I have included my old patch for drawing round joins using
> bezier curves.
> 
> Yay!
> 
> > 11) The side and isCCW methods have changed are are almost exactly
> the same
> > as each other. I still keep them both so that round joins can be
> drawn in cases
> > such as: p.moveTo(x,y);p.lineTo(x+c,y);p.lineTo(x,y). Proprietary
> java does not
> > do this, but I think it should, since joins are meant to join
> different segments
> > in a path. In the example above there are 2 segments, and it is
> possible to
> > draw a round join, so why not? Does the specification say anything
> about this case?
> > I changed the side() algorithm because I think what I use now also
> works (or at
> > least it certainly works for all cases in which we use it), it is
> faster and
> > it is more accurate.
> 

> 
> > I think the above are all the important changes.
> > Some things I wanted to discuss:
> > 1. Should I change antialiasing and make it store the curves instead
> of the crossings?
> 
> It's a topic for discussion.  I'm wary of the memory footprint, but I
> 
> don't want to kill performance.  Is it a simple change to switch?  I'm
> 
> also a fan of "get what you have in now as a stake in the ground and 
> then deal with some of these issues as follow-on optimizations".
> 
> > 2. I'm not completely comfortable with the way special cases are
> handled in
> > the somethingTo, computeOffsetQuad, and computeOffsetCubic methods
> in Stroker.java
> > ("special cases" being very tiny curves).
> 
> I'll take a look and report my comfort level too.
> 
> > 3. From tests it looks to me like offsets for quads might not be
> good enough. It's
> > barely visible, but I don't know if I'm comfortable with it (fixing
> this would be
> > pretty simple - either add some subdivisions, or approximate quad
> curves with cubics
> > (the latter might be especially nice, since we could use the same
> code for both
> > curve types)).
> 
> I'll need to look at code here too before I can comment.
> 
> >>> 3. Should line 862 in Stroker be enabled (I give some reasons for
> wanting to
> >>> in a comment below it).
> >> That'll take me a day or two just to understand and figure out...
> >> <crosseyed smiley>
> > I'm sorry, I should have explained it. That line was a check for
> lineWidth2>  1.5&&
> > subdivisionsSoFar<  5. It was meant to avoid trying to find points
> where the offset
> > curves have cusps if we already have "enough" subdivisions. Now I
> always try to find
> > these points because I don't think this procedure is expensive
> enough to jeopardize
> > rendering quality.
> 
> 
> > I would very much appreciate any comments or suggestions.
> 
> I'm afraid to make too many more before you get a chance to check in 
> what you have now and at least get us several concrete steps towards a
> 
> quality implementation.
> 

> 
> 			...jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quadCtrlComp.png
Type: image/png
Size: 20208 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100927/eeedfcfc/quadCtrlComp.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source1.png
Type: image/png
Size: 7286 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100927/eeedfcfc/source1.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source2.png
Type: image/png
Size: 7615 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20100927/eeedfcfc/source2.png>

From james.graham at oracle.com  Mon Sep 27 22:58:53 2010
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 27 Sep 2010 15:58:53 -0700
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <974207292.714761285598631908.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <974207292.714761285598631908.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4CA121AD.3010303@oracle.com>

Hi Denis,

On 9/27/2010 7:43 AM, Denis Lila wrote:
> Hi Jim.
>> How much faster?  I'm worried about this, especially given our tiled
>> approach to requesting the data.  What was the bottleneck before?
>> (It's been a while since I visited the code - we weren't computing the
>> crossings for every curve in the path for every tile being generated
>> were we?)
>
>      Not much faster. I'm working on someting better.

Then hopefully we can get to something with better memory and CPU costs.

>      I'm not sure about the bottleneck, but what we were doing before is:
> 1. Flatten (by subdividing) every curve so that we deal only with lines.
> 2. Add each line to a list sorted by y0. When end_rendering was called
> for each scanline we found the crossings of the scanline and every line
> in our line list, which we used to compute the alpha for that scanline's
> pixel row. All this would be put into RLE encoded temporary storage and it
> would be read back and converted into tile form by PiscesTileGenerator.
>
>      Speaking of which, would it not be better to get rid of PiscesCache and
> just keep a buffer with the current tile row in Renderer.java. This would
> be possible because the specification for AATileGenerator says the iteration
> is like: for (y...) for (x...);.
> Why is PiscesCache there? It isn't being used as a cache at all. Could it be?
> Also, why do we output tiles, instead of just pixel rows (which I guess would
> just be nx1 tiles). Is it because we would like to use getTypicalAlpha to eliminate
> completely transparent or completely opaque regions as soon as possible (and the
> longer a tile is the less of a chance it has at being either of those two)?

That was basically "cramming what we had into the interface's box".  The 
cache existed for something that was being done on mobile, but it 
doesn't have much of a place in our APIs so it was just reused for tile 
generation.  If we have a much more direct way of doing it then it would 
be great to get rid of it.

I think we can support "ALL1s" and "ALL0s" reasonably without the cache.

>> I can see your points here.  I think there are solutions to avoid much
>> of the untransforming we can consider, but your solution works well so
>> let's get it in and then we can look at optimizations if we feel they
>> are causing a measurable problem later.
>
>      I should say this isn't quite as bad as I might have made it seem. Firstly,
> this IO handler class I made elimiinates transformations when Dasher
> communicates with Stroker. More importantly, no untransforming is done
> when the transformation is just a translation or is the identity or is singular
> and when STROKE_CONTROL is off, we only transform the output path. That's
> because the most important reason for handling transforms the way I do now
> is because we can't normalize untransformed paths, otherwise coordinate
> adjustments might be magnified too much. So, we need to transform paths
> before normalization. But we also can't do the stroking and widening
> before the normalization. But if normalization is removed we can just pass
> untransformed paths into Stroker, and transform its output (which is still
> somewhat more expensive than only trasnforming the input path, since
> Stroker produces many 3-7 curves for each input curve).

Can the untransform be eliminated in the case of scaling?  (Whether just 
for uniform scaling, or maybe even for non-uniform scaling with no 
rotation or shearing?)

>> I'm not sure I understand the reasoning of the control point
>> calculation.  I'll have to look at the code to register an opinion.
>
>      I'm sorry, my explanation wasn't very clear. I attached a picture that
> will hopefully clarify things.
> But, in a way, the computation I use is forced on us. Suppose we have a
> quadratic curve B and we need to compute one of its offsets C. C'(0)
> and C'(1) will be parallel to B'(0) and B'(1) so we need to make sure
> our computed offset has this property too (or it would look weird around
> the endpoints). Now, B'(0) and B'(1) are parallel to p2-p1 and p3-p2
> where p1,p2,p3 are the 3 control points that define B, so if the control
> points of C are q1, q2, q3 then q2-q1 and q3-q2 must be parallel to p2-p1
> and p3-p2 respectively. At this point, we need more constraint, since
> our system is underdetermined. We use the constraints that q1 = C(0)
> and q3 = C(1) (so, the endpoints of the computed offset are equal to the
> endpoints of the ideal offset). All we have left to compute is q2, but
> we know the direction of q2-q1 and the direction of q3-q2, so q2 must
> lie on the lines defined by q1+t*(q2-q1) and q3+t*(q3-q2) so q2 must
> be the intersection of these lines.

I agree that if you are creating a parallel curve then intersection is 
the way to go.  I guess what I was potentially confused about was 
whether there are cases where you need to subdivide at all?  Regardless 
of subdivision, when you get down to the final step of creating the 
parallel curves then I believe offsetting and finding the intersection 
is correct (though I reserve the possibility that there might still be a 
simpler way - I haven't done any investigation to know if that is true).

>> It sounds like you are correct here.  What does the closed source code
>> draw?
>
>      I thought closed source java simply didn't draw the round joins in
> these cases, but I did some more testing and it turns out it does for
> some curves and it doesn't for others. I've included the results of a
> test I wrote that tries to draw paths like: moveTo(0,0);p.lineTo(cos,sin);p.lineTo(0,0);
> where cos and sin are coordinates on a circle (source1.png is the output
> of closed java. Source2.png is my output). As you can see, my
> version draws the round joins on all tested cases, while closed java
> is inconsistent.

You rock then!  A bug should be filed on closed JDK.  Can you file it or 
send me your test case and I'll do it?

>      That sounds good. Hopefully by the end of today I'll have a
> less memory hungry AA implementation that is also faster.

Yay!

> Thank you,

Ummm...  Thank *you*.  You're doing all the good work here, I'm just 
sitting back, throwing out tiny crumbs of past experience and watching 
the ensuing woodchips fly with awe.  I've had on my wish list for some 
time to be able to eliminate these last few closed source holdouts, but 
the quality of the Ductus code was so high that I never got motivated to 
try.  Who knows now...  ;-)

			...jim


From lana.steuck at oracle.com  Tue Sep 28 05:07:42 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:07:42 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 15 new changesets
Message-ID: <20100928050742.D2E6047CC2@hg.openjdk.java.net>

Changeset: 0df9c57eb80d
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/0df9c57eb80d

Added tag jdk7-b108 for changeset 140fdef4ddf5

! .hgtags

Changeset: d6ea39e0d3eb
Author:    ohair
Date:      2010-09-07 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/d6ea39e0d3eb

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 81dfc728d7bb
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/81dfc728d7bb

Merge


Changeset: f241877c0ac9
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/f241877c0ac9

Added tag jdk7-b109 for changeset 81dfc728d7bb

! .hgtags

Changeset: 782c0c738f6d
Author:    ohair
Date:      2010-09-08 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/782c0c738f6d

6974017: Upgrade required Solaris Studio compilers to 5.10 (12 update 1 + patches)
Reviewed-by: jcoomes

! README-builds.html

Changeset: 973560f0387d
Author:    cl
Date:      2010-09-08 17:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/973560f0387d

Merge


Changeset: c129c592e9d6
Author:    ohair
Date:      2010-09-09 17:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/c129c592e9d6

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! make/templates/gpl-cp-header
! make/templates/gpl-header

Changeset: 2a02d4a6955c
Author:    cl
Date:      2010-09-15 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/2a02d4a6955c

Merge


Changeset: 9702d6fef68e
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/9702d6fef68e

Added tag jdk7-b110 for changeset 2a02d4a6955c

! .hgtags

Changeset: 989da1ce9287
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/989da1ce9287

Added tag jdk7-b111 for changeset 9702d6fef68e

! .hgtags

Changeset: 1fbed32d2ddd
Author:    gbenson
Date:      2010-08-24 13:27 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/1fbed32d2ddd

6976186: Integrate Shark
Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure.
Reviewed-by: ohair

! make/hotspot-rules.gmk

Changeset: 90357eee5234
Author:    lana
Date:      2010-09-02 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/90357eee5234

Merge


Changeset: b331aef4bef0
Author:    ohair
Date:      2010-09-07 15:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/b331aef4bef0

Merge


Changeset: 87e98a1df774
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/87e98a1df774

Merge


Changeset: b852103caf73
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/rev/b852103caf73

Merge




From lana.steuck at oracle.com  Tue Sep 28 05:07:48 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:07:48 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 11 new changesets
Message-ID: <20100928050757.12EC047CC3@hg.openjdk.java.net>

Changeset: 74d57b218468
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/74d57b218468

Added tag jdk7-b108 for changeset 8d810527b499

! .hgtags

Changeset: 3821536d79ab
Author:    ohair
Date:      2010-09-07 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/3821536d79ab

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: c3dd858e09b2
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/c3dd858e09b2

Merge


Changeset: 0e1f80fda227
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/0e1f80fda227

Added tag jdk7-b109 for changeset c3dd858e09b2

! .hgtags

Changeset: 640fa4d4e2ad
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/640fa4d4e2ad

Added tag jdk7-b110 for changeset 0e1f80fda227

! .hgtags

Changeset: 21c218f9a7be
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/21c218f9a7be

Added tag jdk7-b111 for changeset 640fa4d4e2ad

! .hgtags

Changeset: 0f60cf26c5b5
Author:    ohair
Date:      2010-08-30 14:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/0f60cf26c5b5

6981043: Clean out all native code makefile logic from corba repository
Reviewed-by: jjg

! make/Makefile
! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/common/Defs-windows.gmk
! make/common/Defs.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
! make/common/Rules.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk
! make/common/shared/Defs-java.gmk
! make/common/shared/Defs-linux.gmk
! make/common/shared/Defs-solaris.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Platform.gmk
! make/org/omg/idl/Makefile

Changeset: d6297db2b9dd
Author:    lana
Date:      2010-09-02 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/d6297db2b9dd

Merge


Changeset: 0a91416c1402
Author:    ohair
Date:      2010-09-07 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/0a91416c1402

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk

Changeset: ae60f98d2f42
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/ae60f98d2f42

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk

Changeset: cc67fdc4fee9
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/corba/rev/cc67fdc4fee9

Merge

- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Compiler.gmk



From lana.steuck at oracle.com  Tue Sep 28 05:08:39 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:08:39 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 5 new changesets
Message-ID: <20100928050855.4C47847CC4@hg.openjdk.java.net>

Changeset: 2fe09e2e70d0
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2fe09e2e70d0

Added tag jdk7-b108 for changeset e44a93947ccb

! .hgtags

Changeset: cc4bb3022b31
Author:    cl
Date:      2010-09-09 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/cc4bb3022b31

Merge

! .hgtags
- src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp

Changeset: 2f25f2b8de27
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2f25f2b8de27

Added tag jdk7-b109 for changeset cc4bb3022b31

! .hgtags

Changeset: 07b042e13dde
Author:    cl
Date:      2010-09-16 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/07b042e13dde

Added tag jdk7-b110 for changeset 2f25f2b8de27

! .hgtags

Changeset: 8d5897b4230f
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8d5897b4230f

Added tag jdk7-b111 for changeset 07b042e13dde

! .hgtags



From lana.steuck at oracle.com  Tue Sep 28 05:09:36 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:09:36 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 11 new changesets
Message-ID: <20100928050936.EA08C47CC5@hg.openjdk.java.net>

Changeset: 840d6acde4e8
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/840d6acde4e8

Added tag jdk7-b108 for changeset 7d379f8934ca

! .hgtags

Changeset: cc845b339690
Author:    ohair
Date:      2010-09-07 15:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/cc845b339690

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 0f382d6120fc
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/0f382d6120fc

Merge


Changeset: d422dbdd0976
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/d422dbdd0976

Added tag jdk7-b109 for changeset 0f382d6120fc

! .hgtags

Changeset: 8106c747067c
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/8106c747067c

Added tag jdk7-b110 for changeset d422dbdd0976

! .hgtags

Changeset: 028a06f776c0
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/028a06f776c0

Added tag jdk7-b111 for changeset 8106c747067c

! .hgtags

Changeset: a3fe5892cd26
Author:    ohair
Date:      2010-09-01 13:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/a3fe5892cd26

6981408: Upgrade jaxp to 1.4.4
Reviewed-by: darcy
Contributed-by: Joe Wang <huizhe.wang at oracle.com>

! jaxp.properties

Changeset: 4a249814b147
Author:    lana
Date:      2010-09-02 22:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/4a249814b147

Merge


Changeset: e58a0bea47f6
Author:    ohair
Date:      2010-09-07 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/e58a0bea47f6

Merge


Changeset: b23fd715a158
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/b23fd715a158

Merge


Changeset: 1b0525424288
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/1b0525424288

Merge




From lana.steuck at oracle.com  Tue Sep 28 05:09:42 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:09:42 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 11 new changesets
Message-ID: <20100928050942.64FE147CC6@hg.openjdk.java.net>

Changeset: ef7838f988c5
Author:    cl
Date:      2010-09-03 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/ef7838f988c5

Added tag jdk7-b108 for changeset b1ca39340238

! .hgtags

Changeset: 06c51671c84b
Author:    ohair
Date:      2010-09-07 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/06c51671c84b

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 4f626e0d70bd
Author:    cl
Date:      2010-09-08 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/4f626e0d70bd

Merge


Changeset: 95ecac35fb11
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/95ecac35fb11

Added tag jdk7-b109 for changeset 4f626e0d70bd

! .hgtags

Changeset: 2575ebca96c7
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/2575ebca96c7

Added tag jdk7-b110 for changeset 95ecac35fb11

! .hgtags

Changeset: 3c8627862d07
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/3c8627862d07

Added tag jdk7-b111 for changeset 2575ebca96c7

! .hgtags

Changeset: c6c2f9094bdd
Author:    ohair
Date:      2010-08-30 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/c6c2f9094bdd

6962317: jdk7 jaxws source bundle still needs rebranding
6955300: Missing files in the jaf source bundle
Reviewed-by: ramap

! jaxws.properties

Changeset: 5dd2cc894d0c
Author:    lana
Date:      2010-09-02 22:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/5dd2cc894d0c

Merge


Changeset: 74737bd256fa
Author:    ohair
Date:      2010-09-07 15:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/74737bd256fa

Merge


Changeset: 4635da51e3cb
Author:    lana
Date:      2010-09-16 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/4635da51e3cb

Merge


Changeset: 8e0f0054817f
Author:    lana
Date:      2010-09-24 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/8e0f0054817f

Merge




From lana.steuck at oracle.com  Tue Sep 28 05:11:22 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:11:22 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 78 new changesets
Message-ID: <20100928052400.3D52347CC8@hg.openjdk.java.net>

Changeset: df049d0b973f
Author:    ohair
Date:      2010-09-07 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/df049d0b973f

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: 4571856d4628
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4571856d4628

Added tag jdk7-b108 for changeset 17a5d84b7561

! .hgtags

Changeset: ab0d3f54a63f
Author:    cl
Date:      2010-09-09 13:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ab0d3f54a63f

Merge


Changeset: 3937dd29f45a
Author:    cl
Date:      2010-09-09 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3937dd29f45a

Added tag jdk7-b109 for changeset ab0d3f54a63f

! .hgtags

Changeset: c5f6cd3bd70b
Author:    ohair
Date:      2010-09-08 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c5f6cd3bd70b

6974017: Upgrade required Solaris Studio compilers to 5.10 (12 update 1 + patches)
Reviewed-by: jcoomes

! make/common/shared/Compiler-sun.gmk
! make/common/shared/Defs-versions.gmk

Changeset: 8f5a6ea8c9e9
Author:    ohair
Date:      2010-09-09 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8f5a6ea8c9e9

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! make/templates/gpl-cp-header
! make/templates/gpl-header
! src/share/classes/java/lang/CharacterName.java
! src/share/classes/sun/font/GlyphDisposedListener.java
! src/share/classes/sun/jvmstat/monitor/Units.java
! src/share/classes/sun/jvmstat/monitor/Variability.java
! src/solaris/classes/sun/font/XRGlyphCache.java
! src/solaris/classes/sun/font/XRGlyphCacheEntry.java
! src/solaris/classes/sun/font/XRTextRenderer.java
! src/solaris/classes/sun/java2d/jules/IdleTileCache.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/java2d/jules/JulesPathBuf.java
! src/solaris/classes/sun/java2d/jules/JulesRenderingEngine.java
! src/solaris/classes/sun/java2d/jules/JulesShapePipe.java
! src/solaris/classes/sun/java2d/jules/JulesTile.java
! src/solaris/classes/sun/java2d/jules/TileWorker.java
! src/solaris/classes/sun/java2d/jules/TrapezoidList.java
! src/solaris/classes/sun/java2d/xr/DirtyRegion.java
! src/solaris/classes/sun/java2d/xr/GrowableByteArray.java
! src/solaris/classes/sun/java2d/xr/GrowableEltArray.java
! src/solaris/classes/sun/java2d/xr/GrowableIntArray.java
! src/solaris/classes/sun/java2d/xr/GrowablePointArray.java
! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java
! src/solaris/classes/sun/java2d/xr/MaskTile.java
! src/solaris/classes/sun/java2d/xr/MaskTileManager.java
! src/solaris/classes/sun/java2d/xr/MutableInteger.java
! src/solaris/classes/sun/java2d/xr/XIDGenerator.java
! src/solaris/classes/sun/java2d/xr/XRBackend.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRColor.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRDrawImage.java
! src/solaris/classes/sun/java2d/xr/XRGraphicsConfig.java
! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java
! src/solaris/classes/sun/java2d/xr/XRMaskFill.java
! src/solaris/classes/sun/java2d/xr/XRMaskImage.java
! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/solaris/classes/sun/java2d/xr/XRPaints.java
! src/solaris/classes/sun/java2d/xr/XRRenderer.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceDataProxy.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java
! src/solaris/classes/sun/java2d/xr/XRVolatileSurfaceManager.java
! src/solaris/classes/sun/java2d/xr/XcbRequestCounter.java
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
! src/solaris/native/sun/java2d/x11/XRSurfaceData.c
! test/com/sun/java/swing/plaf/gtk/Test6963870.java
! test/java/lang/StringBuffer/Capacity.java
! test/java/security/cert/CertificateFactory/openssl/BadFooter.java
! test/java/util/zip/GZIP/GZIPInputStreamRead.java
! test/javax/swing/JFormattedTextField/Test6462562.java
! test/javax/swing/JTabbedPane/6670274/bug6670274.java
! test/javax/swing/JTable/6768387/bug6768387.java
! test/javax/swing/JTable/6788484/bug6788484.java
! test/javax/swing/JTable/6937798/bug6937798.java
! test/javax/swing/JTableHeader/6884066/bug6884066.java
! test/javax/swing/JTableHeader/6889007/bug6889007.java
! test/javax/swing/JTextArea/6925473/bug6925473.java
! test/javax/swing/JTextArea/6940863/bug6940863.java
! test/javax/swing/JViewport/6953396/bug6953396.java
! test/javax/swing/border/Test6910490.java
! test/javax/swing/plaf/synth/SynthToolBarUI/6739756/bug6739756.java
! test/javax/swing/text/WrappedPlainView/6857057/StubBranchElement.java
! test/javax/swing/text/WrappedPlainView/6857057/StubLeafElement.java
! test/javax/swing/text/WrappedPlainView/6857057/bug6857057.java
! test/sun/security/krb5/MicroTime.java

Changeset: 448387146bb8
Author:    yhuang
Date:      2010-09-09 23:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/448387146bb8

6980510: Fix for 6959252 broke JConsole mnemonic keys
Reviewed-by: mfang, yhuang

! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java

Changeset: 9a1549d682ce
Author:    yhuang
Date:      2010-09-09 23:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9a1549d682ce

Merge


Changeset: 4aaac9fb2293
Author:    yhuang
Date:      2010-09-13 02:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4aaac9fb2293

Merge


Changeset: 176586cd040e
Author:    kamg
Date:      2010-09-13 13:10 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/176586cd040e

6983225: libjvm_db.so is not imported into solaris-x86 builds, and libjvm_dtrace.so not imported at all.
Summary: Removed sparc-only libjvm_db code and added rules for libjvm_dtrace
Reviewed-by: ohair

! make/java/redist/Makefile

Changeset: fb63a2688db8
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fb63a2688db8

Added tag jdk7-b110 for changeset 176586cd040e

! .hgtags

Changeset: c2cdc8c94b65
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c2cdc8c94b65

Added tag jdk7-b111 for changeset fb63a2688db8

! .hgtags

Changeset: abe6a61835cb
Author:    lana
Date:      2010-09-16 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/abe6a61835cb

Merge

- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h

Changeset: 7e26538596be
Author:    art
Date:      2010-08-24 12:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7e26538596be

6949936: Provide API for running nested events loops, similar to what modal dialogs do
Reviewed-by: ant, anthony

! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQueue.java
+ src/share/classes/java/awt/SecondaryLoop.java
+ src/share/classes/java/awt/WaitDispatchSupport.java
+ test/java/awt/EventQueue/SecondaryLoopTest/SecondaryLoopTest.java

Changeset: d3fdf9e7e9c2
Author:    dav
Date:      2010-08-31 15:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d3fdf9e7e9c2

6480547: REG: bug 4118621 which got Integrated in 1.1.8 fails in mustang from b25 onwards.
6808185: test/closed/java/awt/Menu/NullMenuLabelTest crashes
Reviewed-by: dcherepanov

! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_TextField.cpp
! src/windows/native/sun/windows/awt_TextField.h
+ test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java
! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java
! test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java

Changeset: 7f8a9157544a
Author:    lana
Date:      2010-09-02 12:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7f8a9157544a

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: c12a03da538b
Author:    ant
Date:      2010-09-03 11:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c12a03da538b

6867293: switching TAB in a browser doesn't deactivate EmbeddedFrame
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_Window.h

Changeset: 252af007f819
Author:    lana
Date:      2010-09-16 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/252af007f819

Merge


Changeset: 48070a2633a1
Author:    naoto
Date:      2010-08-31 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/48070a2633a1

4700857: RFE: separating user locale and user interface locale
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/TimeZone.java
! src/share/native/java/lang/System.c
! src/share/native/java/lang/java_props.h
! src/solaris/native/java/lang/java_props_md.c
! src/windows/native/java/lang/java_props_md.c
! src/windows/native/sun/windows/awt_DataTransferer.cpp
! src/windows/native/sun/windows/awt_InputMethod.cpp
! test/java/util/Formatter/Constructors.java
+ test/java/util/Locale/LocaleCategory.sh
! test/java/util/Locale/PrintDefaultLocale.java
! test/java/util/Locale/data/deflocale.c
+ test/java/util/Locale/data/deflocale.input
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
+ test/java/util/Locale/data/deflocale.rhel5
+ test/java/util/Locale/data/deflocale.rhel5.fmtasdefault
! test/java/util/Locale/data/deflocale.sh
! test/java/util/Locale/data/deflocale.sol10
+ test/java/util/Locale/data/deflocale.sol10.fmtasdefault
+ test/java/util/Locale/data/deflocale.win7
+ test/java/util/Locale/data/deflocale.win7.fmtasdefault
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 3b64274e3cda
Author:    naoto
Date:      2010-08-31 23:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3b64274e3cda

6981466: Adding missing test LocaleCategory.java
Reviewed-by: okutsu

+ test/java/util/Locale/LocaleCategory.java

Changeset: de0f18fe09e7
Author:    okutsu
Date:      2010-09-01 15:19 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/de0f18fe09e7

4267450: (cal) API: Need public API to calculate, format and parse "year of week"
6549953: (cal) WEEK_OF_YEAR and DAY_OF_YEAR calculation problems around Gregorian cutover
Reviewed-by: peytoia

! make/java/text/base/FILES_java.gmk
+ src/share/classes/java/text/CalendarBuilder.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/GregorianCalendar.java
+ test/java/text/Format/DateFormat/WeekDateTest.java
+ test/java/util/Calendar/WeekDateTest.java

Changeset: 513a9ae0bbdd
Author:    okutsu
Date:      2010-09-02 10:52 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/513a9ae0bbdd

Merge


Changeset: 8af4eca2e2be
Author:    lana
Date:      2010-09-01 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8af4eca2e2be

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/pack200/Pack200Simple.sh
- test/tools/pack200/SegmentLimit.java

Changeset: 7b92a8ecece2
Author:    lana
Date:      2010-09-02 00:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7b92a8ecece2

Merge


Changeset: b83701dcae1e
Author:    naoto
Date:      2010-09-02 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b83701dcae1e

6981759: copyright header fix for test/java/util/Locale/LocaleCategory.java
Reviewed-by: okutsu

! test/java/util/Locale/LocaleCategory.java

Changeset: 93d13ea00faf
Author:    naoto
Date:      2010-09-02 11:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/93d13ea00faf

6930062: Need to remove or build as part of the test file jdk/test/java/util/Locale/data/deflocale.exe
Reviewed-by: okutsu

- test/java/util/Locale/data/deflocale.exe

Changeset: c47eb064d6ba
Author:    okutsu
Date:      2010-09-09 15:37 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c47eb064d6ba

4919632: RFE: SimpleDateFormat should fully support ISO8601 standard for timezone
Reviewed-by: peytoia

! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/ISO8601ZoneTest.java

Changeset: 4f1eacca4e6b
Author:    peytoia
Date:      2010-09-10 17:22 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4f1eacca4e6b

6983724: redundant @exception description for Character.Subset(String name)
Reviewed-by: okutsu

! src/share/classes/java/lang/Character.java

Changeset: afae9229e4a7
Author:    okutsu
Date:      2010-09-10 17:51 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/afae9229e4a7

6912560: Timezone is not set correctly on Win Vista when Security manager is present.
6941137: DST broken in 6u18 when jre/lib/zi is moved elsewhere and replaced with symlink.
Reviewed-by: peytoia

! src/share/classes/sun/util/calendar/ZoneInfoFile.java
+ test/java/util/TimeZone/Bug6912560.java

Changeset: 4fea9ea1661d
Author:    malenkov
Date:      2010-09-10 20:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4fea9ea1661d

6915566: Closed swing tests failing with assert errors when run with -ea -esa
Reviewed-by: art, peterz

! src/share/classes/com/sun/java/swing/SwingUtilities3.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java

Changeset: ee4d92fb6df3
Author:    naoto
Date:      2010-09-10 15:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ee4d92fb6df3

6875847: Java Locale Enhancement
Reviewed-by: srl
Contributed-by: Yoshito Umaoka <y.umaoka at gmail.com>, Doug Felt <dougfelt at google.com>, Mark Davis <markdavis at google.com>

! make/java/java/FILES_java.gmk
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/util/Calendar.java
+ src/share/classes/java/util/IllformedLocaleException.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/spi/LocaleNameProvider.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/sun/util/LocaleServiceProviderPool.java
+ src/share/classes/sun/util/locale/AsciiUtil.java
+ src/share/classes/sun/util/locale/BaseLocale.java
+ src/share/classes/sun/util/locale/Extension.java
+ src/share/classes/sun/util/locale/InternalLocaleBuilder.java
+ src/share/classes/sun/util/locale/LanguageTag.java
+ src/share/classes/sun/util/locale/LocaleExtensions.java
+ src/share/classes/sun/util/locale/LocaleObjectCache.java
+ src/share/classes/sun/util/locale/LocaleSyntaxException.java
+ src/share/classes/sun/util/locale/ParseStatus.java
+ src/share/classes/sun/util/locale/StringTokenIterator.java
+ src/share/classes/sun/util/locale/UnicodeLocaleExtension.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/LocaleNames.properties
! src/share/classes/sun/util/resources/LocaleNames_zh.properties
! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
+ test/java/util/Locale/LocaleEnhanceTest.java
! test/java/util/Locale/LocaleTestFmwk.java
+ test/java/util/Locale/icuLocales.txt
+ test/java/util/Locale/serialized/java6locale_ROOT
+ test/java/util/Locale/serialized/java6locale__US
+ test/java/util/Locale/serialized/java6locale___Java
+ test/java/util/Locale/serialized/java6locale_en
+ test/java/util/Locale/serialized/java6locale_en_US
+ test/java/util/Locale/serialized/java6locale_en_US_Java
+ test/java/util/Locale/serialized/java6locale_iw_IL
+ test/java/util/Locale/serialized/java6locale_ja_JP_JP
+ test/java/util/Locale/serialized/java6locale_no_NO_NY
+ test/java/util/Locale/serialized/java6locale_th_TH_TH

Changeset: 903f44341e34
Author:    kalli
Date:      2010-09-13 15:12 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/903f44341e34

6941027: Gervill update, April 2010
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java
! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
! src/share/classes/com/sun/media/sound/ModelInstrument.java
+ src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
! src/share/classes/com/sun/media/sound/SoftSynthesizer.java
! src/share/classes/com/sun/media/sound/SoftVoice.java
+ test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
+ test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java
+ test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java
+ test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java

Changeset: 3fa6114faa54
Author:    kalli
Date:      2010-09-13 15:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3fa6114faa54

6943053: Gervill: failures on invalid ranges and 14-bit banks
Summary: ModelStandardIndexedDirector fails on invalid ranges. Program changes with 14-bit banks where handled incorectly as 7-bit banks.
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
+ test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
+ test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java

Changeset: c610f475558d
Author:    okutsu
Date:      2010-09-14 16:47 +0900
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c610f475558d

6984418: (cal) GregorianCalendar.setWeekDate doesn't check parameter consistency in non-lenient
Reviewed-by: peytoia

! src/share/classes/java/util/GregorianCalendar.java
! test/java/util/Calendar/WeekDateTest.java

Changeset: 7fe3d0fd99b8
Author:    amenkov
Date:      2010-09-14 12:38 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7fe3d0fd99b8

6944033: RFE: add PCM_FLOAT support
Reviewed-by: dav

! src/share/classes/com/sun/media/sound/AudioFloatConverter.java
! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/share/classes/com/sun/media/sound/SoftMixingMixer.java
! src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
+ test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java

Changeset: c3c28ce45273
Author:    amenkov
Date:      2010-09-14 14:07 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c3c28ce45273

4937708: AudioFormat.matches should allow NOT_SPECIFY in all fields
Reviewed-by: denis

! src/share/classes/javax/sound/sampled/AudioFormat.java
+ test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java

Changeset: 167a6a4634f5
Author:    amenkov
Date:      2010-09-14 14:09 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/167a6a4634f5

Merge

! src/share/classes/javax/sound/sampled/AudioFormat.java

Changeset: 82e98a8dccec
Author:    amenkov
Date:      2010-09-14 14:14 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/82e98a8dccec

4933700: RFE: Add way to get device from Receiver and Transmitter
Reviewed-by: art

! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
+ src/share/classes/com/sun/media/sound/MidiDeviceReceiverEnvelope.java
+ src/share/classes/com/sun/media/sound/MidiDeviceTransmitterEnvelope.java
! src/share/classes/com/sun/media/sound/SoftReceiver.java
! src/share/classes/javax/sound/midi/MidiDevice.java
+ src/share/classes/javax/sound/midi/MidiDeviceReceiver.java
+ src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java
! src/share/classes/javax/sound/midi/MidiSystem.java
+ test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java

Changeset: bb733c150f94
Author:    omajid
Date:      2010-09-14 10:45 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bb733c150f94

6979979: Rounding error in font sizes selected by the GTK Look and Feel
Summary: Use floating point font sizes
Reviewed-by: prr

! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java
! src/share/classes/sun/font/FontUtilities.java

Changeset: 7fc59f27318c
Author:    malenkov
Date:      2010-09-14 19:12 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7fc59f27318c

6978482: MetalBorders.ToolBarBorder should specify that its getBorderInsets impl accepts only JToolBar inst
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/motif/MotifBorders.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/metal/MetalBorders.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java
+ test/javax/swing/border/Test6978482.java

Changeset: 2ffd71748740
Author:    malenkov
Date:      2010-09-14 21:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2ffd71748740

6635395: javax.swing.JDialog constructors should specify IAE throwing if invalid owners passed
Reviewed-by: alexp

! src/share/classes/javax/swing/JDialog.java

Changeset: 49650448c3c7
Author:    malenkov
Date:      2010-09-14 22:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/49650448c3c7

6977726: JColorChooser.getPreviewPanel() returnes null starting from jdk7 b105.
Reviewed-by: alexp

! src/share/classes/javax/swing/JColorChooser.java
! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java
+ test/javax/swing/JColorChooser/Test6977726.html
+ test/javax/swing/JColorChooser/Test6977726.java

Changeset: bf89c7fc48fd
Author:    malenkov
Date:      2010-09-16 09:07 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bf89c7fc48fd

6741392: libmawt.so crash at Java_com_sun_java_swing_plaf_gtk_GTKEngine_nativeFinishPainting+0x4f
Reviewed-by: peterz

! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/awt/swing_GTKEngine.c

Changeset: 21562f873588
Author:    lana
Date:      2010-09-16 11:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/21562f873588

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp

Changeset: 93c49f01a4c2
Author:    darcy
Date:      2010-08-25 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/93c49f01a4c2

6980019: Finish rename of ARM -> try-with-resources in jdk repository
Reviewed-by: jjg

! src/share/classes/java/lang/AutoCloseable.java
! src/share/classes/java/lang/Throwable.java

Changeset: 1470dffe6551
Author:    martin
Date:      2010-08-28 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1470dffe6551

6980747: Runtime.exec can fail due to SecurityException (lnx)
Summary: Add missing doPrivileged to UNIXProcess.java.linux
Reviewed-by: alanb

! src/solaris/classes/java/lang/UNIXProcess.java.linux
+ test/java/lang/ProcessBuilder/SecurityManagerClinit.java

Changeset: 9be643e70f42
Author:    weijun
Date:      2010-08-30 14:37 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9be643e70f42

6911951: NTLM should be a supported Java SASL mechanism
Reviewed-by: vinnie, michaelm

+ src/share/classes/com/sun/security/ntlm/Client.java
+ src/share/classes/com/sun/security/ntlm/NTLM.java
+ src/share/classes/com/sun/security/ntlm/NTLMException.java
+ src/share/classes/com/sun/security/ntlm/Server.java
+ src/share/classes/com/sun/security/ntlm/Version.java
! src/share/classes/com/sun/security/sasl/Provider.java
+ src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java
+ src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java
+ src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
+ test/com/sun/security/sasl/ntlm/NTLMTest.java

Changeset: 6586ab5b79f4
Author:    mchung
Date:      2010-08-31 09:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6586ab5b79f4

6981005: TEST BUG: java/lang/ClassLoader/TestCrossDelegate.sh timeout on windows
Summary: Increase timeout value
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh

Changeset: def50d3ad78e
Author:    mchung
Date:      2010-08-31 09:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/def50d3ad78e

6977548: Broken link in ClassLoader.defineClass javadoc
Reviewed-by: valeriep

! src/share/classes/java/lang/ClassLoader.java

Changeset: bb8f48e1e042
Author:    martin
Date:      2010-09-01 09:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bb8f48e1e042

6981145: (se) Eliminate JNI*Critical when creating pipes and other cleanups
Summary: Avoid *Critical; fix compile warnings; improve readability
Reviewed-by: alanb

! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/share/classes/sun/nio/ch/IOUtil.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/PipeImpl.java
! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java
! src/solaris/native/sun/nio/ch/IOUtil.c

Changeset: b200263f1b68
Author:    mchung
Date:      2010-09-01 17:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b200263f1b68

6977887: (doc) Java 6 API missing info about encoding parameter in storeToXML method
Reviewed-by: sherman

! src/share/classes/java/util/Properties.java

Changeset: b790c1ecee19
Author:    ksrini
Date:      2010-09-03 07:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b790c1ecee19

6981001: (launcher) EnsureJREInstallation is not being called in order
Reviewed-by: darcy

! src/windows/bin/java_md.c
+ test/tools/launcher/MiscTests.java
- test/tools/launcher/VerifyExceptions.java

Changeset: 80a8742483bf
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/80a8742483bf

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java

Changeset: 10728041e814
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/10728041e814

Merge

- test/tools/launcher/VerifyExceptions.java

Changeset: 174916d435c9
Author:    alanb
Date:      2010-09-03 13:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/174916d435c9

6965072: Need API to create SDP sockets
Reviewed-by: michaelm

! make/com/Makefile
+ make/com/oracle/Makefile
+ make/com/oracle/net/Makefile
! make/docs/NON_CORE_PKGS.gmk
! make/java/net/FILES_c.gmk
! make/java/net/Makefile
! make/java/net/mapfile-vers
! make/java/nio/FILES_java.gmk
! make/sun/net/FILES_java.gmk
+ src/share/classes/com/oracle/net/Sdp.java
+ src/share/classes/java/net/SdpSocketImpl.java
! src/share/classes/java/net/ServerSocket.java
+ src/share/classes/sun/net/sdp/SdpSupport.java
+ src/share/classes/sun/nio/ch/Secrets.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/net/NetHooks.java
+ src/solaris/classes/sun/net/sdp/SdpProvider.java
- src/solaris/classes/sun/net/spi/SdpProvider.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
+ src/solaris/native/sun/net/sdp/SdpSupport.c
- src/solaris/native/sun/net/spi/SdpProvider.c
+ test/com/oracle/net/Sanity.java
+ test/com/oracle/net/sanity.sh
! test/sun/net/sdp/ProbeIB.java
! test/sun/net/sdp/sanity.sh

Changeset: e17654f00d93
Author:    alanb
Date:      2010-09-03 21:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e17654f00d93

Merge

- src/share/classes/sun/java2d/pisces/PiscesMath.java
- src/share/classes/sun/java2d/pisces/Transform4.java
- test/tools/launcher/VerifyExceptions.java

Changeset: a6c142240837
Author:    darcy
Date:      2010-09-03 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a6c142240837

4881419: The type of X[].clone() should be X[]
Reviewed-by: martin

! src/share/classes/java/lang/Object.java

Changeset: 1f99ad63eb9e
Author:    lancea
Date:      2010-09-04 12:21 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1f99ad63eb9e

6861385: Updated SQLException subclasses to clarify that they may be thrown for vendor specific conditions
Reviewed-by: alanb

! src/share/classes/java/sql/SQLDataException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java

Changeset: d44696691445
Author:    lancea
Date:      2010-09-04 13:56 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d44696691445

6843995: RowSet 1.1 updates
Reviewed-by: darcy, valeriep

+ src/share/classes/com/sun/rowset/RowSetFactoryImpl.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
+ src/share/classes/javax/sql/rowset/RowSetFactory.java
+ src/share/classes/javax/sql/rowset/RowSetProvider.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java

Changeset: c4defe31c94a
Author:    lancea
Date:      2010-09-04 15:30 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c4defe31c94a

6680198: UnmarshalException caused by incompatible serialVersionUID
Reviewed-by: sherman

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
! src/share/classes/com/sun/rowset/internal/InsertRow.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java
! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
! src/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java

Changeset: 5cf79568f0b9
Author:    lancea
Date:      2010-09-04 15:37 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5cf79568f0b9

6982510: Updated SQLException subclasses  from the outback for 6861385 so that the copyrights only have 2 years
Reviewed-by: alanb

! src/share/classes/java/sql/SQLDataException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java

Changeset: cecc431cd78a
Author:    alanb
Date:      2010-09-07 08:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cecc431cd78a

6971706: sun/nio/cs/ext/* classes are duplicated between rt.jar, charsets.jar, and localedata.jar
Reviewed-by: ohair

! make/common/Release.gmk

Changeset: 299955417217
Author:    ohair
Date:      2010-09-07 15:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/299955417217

Merge

- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java

Changeset: fa00d112bb00
Author:    darcy
Date:      2010-09-08 17:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fa00d112bb00

6294399: (reflect) Constructor.getName() returns fully qualified name of declaring class
Reviewed-by: alanb

! src/share/classes/java/lang/reflect/Constructor.java

Changeset: da7835e74005
Author:    ksrini
Date:      2010-09-09 11:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/da7835e74005

6390477: (launcher) replace unsafe usages of sprintf with snprintf
Reviewed-by: darcy, mchung

! src/share/bin/java.c
! src/solaris/bin/java_md.c
! src/windows/bin/java_md.c

Changeset: 6960b4f07bf9
Author:    chegar
Date:      2010-09-10 15:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6960b4f07bf9

6980517: TEST_BUG sun\net\www\http\ChunkedInputStream\ChunkedEncodingTest.java NullPointerException
Reviewed-by: michaelm

! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingTest.java

Changeset: 55eb9f25bf7a
Author:    alanb
Date:      2010-09-10 16:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/55eb9f25bf7a

6881498: (file) Re-examine DirectoryStream exception handling
Reviewed-by: forax

! make/java/nio/FILES_java.gmk
+ src/share/classes/java/nio/file/DirectoryIteratorException.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/util/ConcurrentModificationException.java
! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java
! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java
! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java
! test/java/nio/file/DirectoryStream/Basic.java
! test/java/nio/file/DirectoryStream/SecureDS.java
+ test/java/nio/file/etc/Exceptions.java

Changeset: b1f49e54be97
Author:    alanb
Date:      2010-09-10 18:48 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b1f49e54be97

6983794: TEST_BUG: test/java/nio/channels/Selector/ConnectWrite.java failing
Reviewed-by: chegar

! test/java/nio/channels/Selector/ConnectWrite.java

Changeset: 186d0259f5d6
Author:    alanb
Date:      2010-09-10 18:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/186d0259f5d6

Merge


Changeset: c786a9c927fd
Author:    lancea
Date:      2010-09-10 15:26 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c786a9c927fd

6589685: JDBC 4.1 updates
Reviewed-by: darcy

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DatabaseMetaData.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/Driver.java
! src/share/classes/java/sql/PreparedStatement.java
+ src/share/classes/java/sql/PseudoColumnUsage.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/sql/Statement.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/javax/sql/CommonDataSource.java

Changeset: 73872b992aab
Author:    lancea
Date:      2010-09-10 18:51 -0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/73872b992aab

6983984: Fixed typo in DatabaseMetaData.getPseudoColumns() javadocs
Reviewed-by: darcy

! src/share/classes/java/sql/DatabaseMetaData.java

Changeset: f7915efcba1b
Author:    weijun
Date:      2010-09-13 09:32 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f7915efcba1b

6845220: Need to update Policytool for Rowset 1.1 and JDBC 4.1 MR added permissions
Reviewed-by: lancea

! src/share/classes/sun/security/tools/policytool/PolicyTool.java

Changeset: be1ca1f90114
Author:    dl
Date:      2010-09-13 09:55 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/be1ca1f90114

6978087: jsr166y Updates
Summary: Simplify the ForkJoinPool API, reworking some of the internals
Reviewed-by: martin, dholmes, chegar

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/Phaser.java
! test/java/util/concurrent/forkjoin/Integrate.java

Changeset: 5c3bad1d7f8a
Author:    weijun
Date:      2010-09-14 10:18 +0800
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5c3bad1d7f8a

6982840: sun/security/tools/jarsigner/emptymanifest.sh fails
Reviewed-by: dholmes

! test/sun/security/tools/jarsigner/emptymanifest.sh

Changeset: a248eb631aa2
Author:    alanb
Date:      2010-09-15 15:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a248eb631aa2

6984545: (fc) transferFrom does not throw NonReadableChannelException when target is size 0 and non-readable
Reviewed-by: forax

! src/share/classes/sun/nio/ch/FileChannelImpl.java
! test/java/nio/channels/FileChannel/Transfer.java

Changeset: 441e86ab3233
Author:    ptisnovs
Date:      2010-09-16 13:25 +0200
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/441e86ab3233

6984543: Test sun/java2d/DirectX/OnScreenRenderingResizeTest fails on GNOME
Summary: Testcase correction.
Reviewed-by: art

! test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java

Changeset: 61f1bbd49a5e
Author:    lana
Date:      2010-09-16 11:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/61f1bbd49a5e

Merge

- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/tools/launcher/VerifyExceptions.java

Changeset: b53f226b1d91
Author:    lana
Date:      2010-09-24 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b53f226b1d91

Merge

- src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java
- src/share/native/sun/java2d/cmm/lcms/cmscam97.c
- src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c
- src/share/native/sun/java2d/cmm/lcms/icc34.h
- src/share/native/sun/java2d/cmm/lcms/lcms.h
- src/solaris/classes/sun/net/spi/SdpProvider.java
- src/solaris/native/sun/net/spi/SdpProvider.c
- test/java/util/Locale/data/deflocale.exe
- test/java/util/Locale/data/deflocale.jds3
- test/java/util/Locale/data/deflocale.rhel4
- test/java/util/Locale/data/deflocale.winvista
- test/java/util/Locale/data/deflocale.winxp
- test/tools/launcher/VerifyExceptions.java



From lana.steuck at oracle.com  Tue Sep 28 05:27:03 2010
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 28 Sep 2010 05:27:03 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 40 new changesets
Message-ID: <20100928052820.7958447CC9@hg.openjdk.java.net>

Changeset: 47e7ff871196
Author:    ohair
Date:      2010-09-07 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/47e7ff871196

6982946: Change make/jprt.properties to defer to JPRT itself for jdk platform list
Reviewed-by: kamg

! make/jprt.properties

Changeset: f4d91b4f7153
Author:    cl
Date:      2010-09-03 12:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f4d91b4f7153

Added tag jdk7-b108 for changeset a408ebb8b3d4

! .hgtags

Changeset: 4826378eaade
Author:    cl
Date:      2010-09-09 13:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4826378eaade

Merge


Changeset: 1c13c5ea73b5
Author:    cl
Date:      2010-09-09 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/1c13c5ea73b5

Added tag jdk7-b109 for changeset 4826378eaade

! .hgtags

Changeset: b599cc9a9c22
Author:    ohair
Date:      2010-09-09 16:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/b599cc9a9c22

6982137: Rebranding pass 2 - missed copyright changes
Reviewed-by: mbykov

! test/tools/javac/generics/inference/6938454/T6938454a.java
! test/tools/javac/generics/inference/6938454/T6938454b.java

Changeset: 32da0f38d2fe
Author:    cl
Date:      2010-09-15 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/32da0f38d2fe

Merge


Changeset: 8bec624274ef
Author:    cl
Date:      2010-09-16 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/8bec624274ef

Added tag jdk7-b110 for changeset 32da0f38d2fe

! .hgtags

Changeset: 7ad86852c38a
Author:    cl
Date:      2010-09-23 17:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/7ad86852c38a

Added tag jdk7-b111 for changeset 8bec624274ef

! .hgtags

Changeset: e9d09e97d669
Author:    jjg
Date:      2010-08-24 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e9d09e97d669

6935638: -implicit:none prevents compilation with annotation processing
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/processing/options/TestImplicitNone.java

Changeset: f3323b1c65ee
Author:    jjg
Date:      2010-08-24 15:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f3323b1c65ee

6929404: Filer.getResource(SOURCE_PATH, ...) does not work when -sourcepath contains >1 entry
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java
+ test/tools/javac/processing/filer/TestGetResource2.java

Changeset: 6ef801fa38b7
Author:    jjg
Date:      2010-08-25 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6ef801fa38b7

6979564: ":" for path separator in dist/bin/javac does not work on Windows
Reviewed-by: jjh

! make/build.xml
! src/share/bin/launcher.sh-template

Changeset: 70ebdef189c9
Author:    jjg
Date:      2010-08-25 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/70ebdef189c9

6960424: new option -Xpkginfo for better control of when package-info.class is generated
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/main/OptionName.java
! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/TestPkgInfo.java

Changeset: ecff24121064
Author:    naoto
Date:      2010-08-25 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ecff24121064

6875847: Java Locale Enhancement
Summary: Fix for javac to allow "sun.util.locale" package accessible.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/resources/legacy.properties

Changeset: cfd047f3cf60
Author:    jjg
Date:      2010-08-26 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/cfd047f3cf60

6604599: ToolProvider should be less compiler-specific
Reviewed-by: darcy

! src/share/classes/javax/tools/ToolProvider.java
+ test/tools/javac/api/ToolProvider/HelloWorldTest.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest1.java
+ test/tools/javac/api/ToolProvider/ToolProviderTest2.java

Changeset: ae3acbf63943
Author:    jjg
Date:      2010-08-26 16:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ae3acbf63943

6980017: javap -XDdetail:source behaves badly if source not available.
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/SourceWriter.java
+ test/tools/javap/T6980017.java

Changeset: 3a9f319be48a
Author:    jjg
Date:      2010-08-27 17:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/3a9f319be48a

6980724: test/tools/javac/InterfaceAssert.java sometimes fails
Reviewed-by: darcy

! test/tools/javac/InterfaceAssert.java

Changeset: b4e7a57af8df
Author:    jjg
Date:      2010-08-27 17:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/b4e7a57af8df

6570730: com.sun.source.tree.ModifiersTree.getFlags() should return class type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/T6341023.java
+ test/tools/javac/tree/ClassTreeTest.java
+ test/tools/javac/tree/TreeKindTest.java

Changeset: eb7c263aab73
Author:    jjg
Date:      2010-08-27 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/eb7c263aab73

6980707: Reduce use of IOException in JavaCompiler
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/FatalError.java
! test/tools/javac/diags/examples.not-yet.txt

Changeset: 4124840b35fe
Author:    jjg
Date:      2010-08-30 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4124840b35fe

6403465: javac should defer diagnostics until it can be determined they are persistent
Reviewed-by: mcimadamore, darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/processing/6430209/b6341534.java
+ test/tools/javac/processing/errors/TestSuppression.java

Changeset: d3ead6731a91
Author:    jrose
Date:      2010-09-01 03:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d3ead6731a91

6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case
Summary: Allow casts which narrow and then unbox.
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java
+ test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD35.java
+ test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD36.java
+ test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD37.java
+ test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD38.java
+ test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog
+ test/tools/javac/6979683/TestCast6979683_BAD39.java
+ test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog
+ test/tools/javac/6979683/TestCast6979683_GOOD.java

Changeset: f37253c9e082
Author:    sundar
Date:      2010-09-02 23:10 +0530
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f37253c9e082

6458749: TypeParameterElement.getEnclosedElements throws NPE within javac.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/T6458749.java

Changeset: 3ff3f20471b4
Author:    jjg
Date:      2010-09-02 18:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/3ff3f20471b4

6921495: spurious semicolons in class def cause empty NOPOS blocks
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/ExtraSemiTest.java

Changeset: 25dd23fa2511
Author:    sundar
Date:      2010-09-03 11:25 +0530
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/25dd23fa2511

6458823: Messager messages on TypeParamterElements to not include position information.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/T6458823/MyProcessor.java
+ test/tools/javac/T6458823/T6458823.java
+ test/tools/javac/T6458823/TestClass.java

Changeset: d54300fb3554
Author:    sundar
Date:      2010-09-03 12:36 +0530
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d54300fb3554

6956462: AssertionError exception thrown in the Compiler Tree API in JDK 7.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/T6956462/T6956462.java
+ test/tools/javac/T6956462/TestClass.java

Changeset: 3fba23db9619
Author:    lana
Date:      2010-09-02 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/3fba23db9619

Merge


Changeset: 68e765b1e9ed
Author:    lana
Date:      2010-09-03 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/68e765b1e9ed

Merge


Changeset: ea54372637a5
Author:    jjg
Date:      2010-09-06 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ea54372637a5

6930507: Symbols for anonymous and local classes made too late for use by java tree API
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/api/TestGetElement.java
! test/tools/javac/processing/model/element/TestAnonClassNames.java
! test/tools/javac/processing/model/element/TestAnonSourceNames.java

Changeset: 7ae4016c5938
Author:    mcimadamore
Date:      2010-09-07 17:31 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/7ae4016c5938

6337171: javac should create bridge methods when type variable bounds restricted
Summary: javac should add synthetic overrides for inherited abstract methods in order to preserve binary compatibility
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ src/share/classes/com/sun/tools/javac/util/Filter.java
+ test/tools/javac/generics/OverrideBridge.java

Changeset: 584365f256a7
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/584365f256a7

6979327: method handle invocation should use casts instead of type parameters to specify return type
Summary: infer return type for polymorphic signature calls according to updated JSR 292 draft
Reviewed-by: jjg
Contributed-by: john.r.rose at oracle.com

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/Names.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java
+ test/tools/javac/diags/examples/UnsupportedExoticID.java
! test/tools/javac/meth/InvokeDyn.java
+ test/tools/javac/meth/InvokeDynTrans.java
+ test/tools/javac/meth/InvokeDynTrans.out
! test/tools/javac/meth/InvokeMH.java
+ test/tools/javac/meth/InvokeMHTrans.java
+ test/tools/javac/meth/InvokeMHTrans.out
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
! test/tools/javac/quid/QuotedIdent.java
! test/tools/javac/quid/QuotedIdent2.java

Changeset: 12d8f7e417fd
Author:    mcimadamore
Date:      2010-09-07 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/12d8f7e417fd

6981185: com.sun.tools.model.JavacTypes.contains() calls Type.contains instead of Types.containsType
Summary: wrong implementation is causing trivial containment tests to fail unexpectedly (when such tests are executed using compiler API)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
+ test/tools/javac/api/TestContainTypes.java

Changeset: bfdfc13fe641
Author:    mcimadamore
Date:      2010-09-07 17:33 +0100
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/bfdfc13fe641

6970584: Flow.java should be more error-friendly
Summary: Added a post-attribution visitor that fixup uninitialized types/symbol in AST after erroneous attribution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/failover/CheckAttributedTree.java
+ test/tools/javac/failover/FailOver01.java
+ test/tools/javac/failover/FailOver01.out
+ test/tools/javac/failover/FailOver02.java
+ test/tools/javac/failover/FailOver02.out
+ test/tools/javac/failover/FailOver03.java
+ test/tools/javac/failover/FailOver03.out
+ test/tools/javac/failover/FailOver04.java
+ test/tools/javac/failover/FailOver04.out
+ test/tools/javac/failover/FailOver05.java
+ test/tools/javac/failover/FailOver05.out
+ test/tools/javac/failover/FailOver06.java
+ test/tools/javac/failover/FailOver06.out
+ test/tools/javac/failover/FailOver07.java
+ test/tools/javac/failover/FailOver07.out
+ test/tools/javac/failover/FailOver08.java
+ test/tools/javac/failover/FailOver08.out
+ test/tools/javac/failover/FailOver09.java
+ test/tools/javac/failover/FailOver09.out
+ test/tools/javac/failover/FailOver10.java
+ test/tools/javac/failover/FailOver10.out
+ test/tools/javac/failover/FailOver11.java
+ test/tools/javac/failover/FailOver11.out
+ test/tools/javac/failover/FailOver12.java
+ test/tools/javac/failover/FailOver12.out
+ test/tools/javac/failover/FailOver13.java
+ test/tools/javac/failover/FailOver13.out
+ test/tools/javac/failover/FailOver14.java
+ test/tools/javac/failover/FailOver14.out

Changeset: c388fa8c6a43
Author:    ohair
Date:      2010-09-07 15:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c388fa8c6a43

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh

Changeset: 014cf6234586
Author:    sundar
Date:      2010-09-09 09:42 +0530
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/014cf6234586

6900149: IllegalStateException when compiling same files and DiagnosticListener is set.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
+ test/tools/javac/T6900149.java

Changeset: fc73f83cd563
Author:    jjg
Date:      2010-09-09 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/fc73f83cd563

6983239: TreeScanner does not scan default value for method
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/TreeScanner.java
! test/tools/javac/api/T6392782.java
+ test/tools/javac/tree/AbstractTreeScannerTest.java
+ test/tools/javac/tree/JavacTreeScannerTest.java
+ test/tools/javac/tree/SourceTreeScannerTest.java
- test/tools/javac/tree/TreeScannerTest.java

Changeset: 80505c2026e7
Author:    jjg
Date:      2010-09-13 11:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/80505c2026e7

6965264: langtools build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar
Reviewed-by: mcimadamore
Contributed-by: jesse.glick at oracle.com

! make/build.xml

Changeset: e92ae290fb47
Author:    jjg
Date:      2010-09-13 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e92ae290fb47

6978974: [langtools] <findbugs> task should use ${target.java.home}
Reviewed-by: mcimadamore

! make/build.xml

Changeset: 6e2ccba61117
Author:    jjg
Date:      2010-09-16 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6e2ccba61117

6985181: Annotations lost from classfile
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
+ test/tools/javac/T6985181.java

Changeset: bbc9765d9ec6
Author:    jjg
Date:      2010-09-16 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/bbc9765d9ec6

6985115: tests create too much output
Reviewed-by: mcimadamore

! test/tools/javac/T6855236.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/tree/AbstractTreeScannerTest.java
! test/tools/javac/tree/JavacTreeScannerTest.java
! test/tools/javac/tree/SourceTreeScannerTest.java
! test/tools/javap/T6868539.java
! test/tools/javap/T6980017.java

Changeset: c5df455918c4
Author:    lana
Date:      2010-09-16 11:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c5df455918c4

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java

Changeset: fd2579b80b83
Author:    lana
Date:      2010-09-24 16:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/2d/langtools/rev/fd2579b80b83

Merge

- test/tools/javac/T6341023.java
- test/tools/javac/meth/MakeNegTests.sh
- test/tools/javac/quid/MakeNegTests.sh
- test/tools/javac/tree/TreeScannerTest.java



From andrew.brygin at sun.com  Wed Sep 29 07:37:23 2010
From: andrew.brygin at sun.com (andrew.brygin at sun.com)
Date: Wed, 29 Sep 2010 07:37:23 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6735275:
	java.awt.image.SampleModel.getSamples()	methods not allways
	throw ArrayIndexOutOfBoundsException
Message-ID: <20100929073748.C04F947D13@hg.openjdk.java.net>

Changeset: ad17cf689258
Author:    bae
Date:      2010-09-29 10:44 +0400
URL:       http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ad17cf689258

6735275: java.awt.image.SampleModel.getSamples() methods not allways throw ArrayIndexOutOfBoundsException
Reviewed-by: igor, prr

! src/share/classes/java/awt/image/SampleModel.java
+ test/java/awt/image/GetSamplesTest.java



From dlila at redhat.com  Wed Sep 29 16:55:46 2010
From: dlila at redhat.com (Denis Lila)
Date: Wed, 29 Sep 2010 12:55:46 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines;
 STROKE_CONTROL in Pisces
In-Reply-To: <1506430186.954361285779250935.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <414091757.954481285779346260.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>

Hi Jim.

> Then hopefully we can get to something with better memory and CPU costs.

I re-implemented the AA rasterizer twice more, with saving memory in
mind. The first version used a completely different algorithm for computing
crossings: It didn't do it incrementally. It just computed the t value 
where B(t)-CurrentScanline=0 using newton's method, then it computed
the x value at this t, and that's the crossing. Because all our curves
were monotonic in x and y, we could guarantee that there was exaclty one
such t per scanline per curve. The initial x0 in Newton's method was 
(scanline - y0)/(y1-y0) (where y1 and y0 are the y extrema of the curve).
This could be computed incrementally using just one addition per scanline,
and it worked very nicely in minimizing the iterations in Newton's method.
However, there still had to be at least one iteration, which came with at
least one multiplication and one division per scanline, which is much more
expensive than what adaptive forward differencing was doing. However, it
was still a bit faster than the adaptive forward differencing version,
probably since it didn't need to allocate ridiculous amounts of memory.
The memory usage of this was far better than anything we had had until then,
because for storing crossings it only needed 4*n bytes, where n is 
the highest number of crossings on any scanline, as opposed to 
4*numScanlines*n, which is what I had before. Since we store curves, instead
of the lines produced by flattening curves, this storage is also reduced by a lot.

But then I found a way to implement adaptive forward differencing AND save
memory. So, what I have now has the same memory usage described above, but
it's also a little faster (even now, that I haven't optimized it at all).
The webrev containing this isn't up yet (but everything else in the last
webrev link I sent is pretty much the same as what I have now on my machine,
so feel free to look at Stroker.java).

> Can the untransform be eliminated in the case of scaling?  (Whether just 
> for uniform scaling, or maybe even for non-uniform scaling with no 
> rotation or shearing?)

I'm glad you bring this up. I thought a bit about this, and the only thing
that causes problems in Stroker is that for some transformations, if we 
feed Stroker the transformed curve, the width will not be constant throughout
the curve. Therefore we can eliminate the untransforming for every matrix
that keeps these lengths constant. This turns out to be any constant multiples
of orthogonal matrices. So, if the transformation is A=[[a,b],[c,d]], all we
have to do is check for a*b==-c*d && a*a+c*c==b*b+d*d. If this is the case,
we can just make the pathIterator of the shape do the transforming, and we can
forget all about it (which is great, since what's hurting us is the transformation
of our output paths, not the untransformation of the input). 
So, to answer your question, we can't eliminate the untransforming for non
uniform scalings, but we can eliminate it for rotations, uniform transforms,
and even for shears of the form [[1,b],[-b,1]].

> You rock then!  A bug should be filed on closed JDK.  Can you file it or 
> send me your test case and I'll do it?

I filed it. Bug id: 6987950.

> > Thank you,
> 
> Ummm...  Thank *you*.  You're doing all the good work here, I'm just 
> sitting back, throwing out tiny crumbs of past experience and watching
> the ensuing woodchips fly with awe.  I've had on my wish list for some 
> time to be able to eliminate these last few closed source holdouts, but 
> the quality of the Ductus code was so high that I never got motivated to 
> try.  Who knows now...  ;-)

Well, I couldn't have done it without your help, so

Thank you,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 
> On 9/27/2010 7:43 AM, Denis Lila wrote:
> > Hi Jim.
> >> How much faster?  I'm worried about this, especially given our
> tiled
> >> approach to requesting the data.  What was the bottleneck before?
> >> (It's been a while since I visited the code - we weren't computing
> the
> >> crossings for every curve in the path for every tile being
> generated
> >> were we?)
> >
> >      Not much faster. I'm working on someting better.
> 
> >      I'm not sure about the bottleneck, but what we were doing
> before is:
> > 1. Flatten (by subdividing) every curve so that we deal only with
> lines.
> > 2. Add each line to a list sorted by y0. When end_rendering was
> called
> > for each scanline we found the crossings of the scanline and every
> line
> > in our line list, which we used to compute the alpha for that
> scanline's
> > pixel row. All this would be put into RLE encoded temporary storage
> and it
> > would be read back and converted into tile form by
> PiscesTileGenerator.
> >
> >      Speaking of which, would it not be better to get rid of
> PiscesCache and
> > just keep a buffer with the current tile row in Renderer.java. This
> would
> > be possible because the specification for AATileGenerator says the
> iteration
> > is like: for (y...) for (x...);.
> > Why is PiscesCache there? It isn't being used as a cache at all.
> Could it be?
> > Also, why do we output tiles, instead of just pixel rows (which I
> guess would
> > just be nx1 tiles). Is it because we would like to use
> getTypicalAlpha to eliminate
> > completely transparent or completely opaque regions as soon as
> possible (and the
> > longer a tile is the less of a chance it has at being either of
> those two)?
> 
> That was basically "cramming what we had into the interface's box". 
> The 
> cache existed for something that was being done on mobile, but it 
> doesn't have much of a place in our APIs so it was just reused for
> tile 
> generation.  If we have a much more direct way of doing it then it
> would 
> be great to get rid of it.
> 
> I think we can support "ALL1s" and "ALL0s" reasonably without the
> cache.
> 
> >> I can see your points here.  I think there are solutions to avoid
> much
> >> of the untransforming we can consider, but your solution works well
> so
> >> let's get it in and then we can look at optimizations if we feel
> they
> >> are causing a measurable problem later.
> >
> >      I should say this isn't quite as bad as I might have made it
> seem. Firstly,
> > this IO handler class I made elimiinates transformations when
> Dasher
> > communicates with Stroker. More importantly, no untransforming is
> done
> > when the transformation is just a translation or is the identity or
> is singular
> > and when STROKE_CONTROL is off, we only transform the output path.
> That's
> > because the most important reason for handling transforms the way I
> do now
> > is because we can't normalize untransformed paths, otherwise
> coordinate
> > adjustments might be magnified too much. So, we need to transform
> paths
> > before normalization. But we also can't do the stroking and
> widening
> > before the normalization. But if normalization is removed we can
> just pass
> > untransformed paths into Stroker, and transform its output (which is
> still
> > somewhat more expensive than only trasnforming the input path,
> since
> > Stroker produces many 3-7 curves for each input curve).
> 

> 
> >> I'm not sure I understand the reasoning of the control point
> >> calculation.  I'll have to look at the code to register an
> opinion.
> >
> >      I'm sorry, my explanation wasn't very clear. I attached a
> picture that
> > will hopefully clarify things.
> > But, in a way, the computation I use is forced on us. Suppose we
> have a
> > quadratic curve B and we need to compute one of its offsets C.
> C'(0)
> > and C'(1) will be parallel to B'(0) and B'(1) so we need to make
> sure
> > our computed offset has this property too (or it would look weird
> around
> > the endpoints). Now, B'(0) and B'(1) are parallel to p2-p1 and
> p3-p2
> > where p1,p2,p3 are the 3 control points that define B, so if the
> control
> > points of C are q1, q2, q3 then q2-q1 and q3-q2 must be parallel to
> p2-p1
> > and p3-p2 respectively. At this point, we need more constraint,
> since
> > our system is underdetermined. We use the constraints that q1 =
> C(0)
> > and q3 = C(1) (so, the endpoints of the computed offset are equal to
> the
> > endpoints of the ideal offset). All we have left to compute is q2,
> but
> > we know the direction of q2-q1 and the direction of q3-q2, so q2
> must
> > lie on the lines defined by q1+t*(q2-q1) and q3+t*(q3-q2) so q2
> must
> > be the intersection of these lines.
> 
> I agree that if you are creating a parallel curve then intersection is
> 
> the way to go.  I guess what I was potentially confused about was 
> whether there are cases where you need to subdivide at all? 
> Regardless 
> of subdivision, when you get down to the final step of creating the 
> parallel curves then I believe offsetting and finding the intersection
> 
> is correct (though I reserve the possibility that there might still be
> a 
> simpler way - I haven't done any investigation to know if that is
> true).
> 
> >> It sounds like you are correct here.  What does the closed source
> code
> >> draw?
> >
> >      I thought closed source java simply didn't draw the round joins
> in
> > these cases, but I did some more testing and it turns out it does
> for
> > some curves and it doesn't for others. I've included the results of
> a
> > test I wrote that tries to draw paths like:
> moveTo(0,0);p.lineTo(cos,sin);p.lineTo(0,0);
> > where cos and sin are coordinates on a circle (source1.png is the
> output
> > of closed java. Source2.png is my output). As you can see, my
> > version draws the round joins on all tested cases, while closed
> java
> > is inconsistent.
> 
> >      That sounds good. Hopefully by the end of today I'll have a
> > less memory hungry AA implementation that is also faster.
> 
> Yay!
> 

> 
> 			...jim