From dlila at redhat.com Mon Aug 2 14:40:50 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 2 Aug 2010 10:40:50 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <975848464.1469391280760028024.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1471126809.1469491280760050541.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. > I'm guessing the test for "y == boundsMaxY-1" at line 470 could > probably also be deleted now (since it will be handled by the end > test when y reaches maxY)? Indeed it can. I've done this, and also updated a few comments that might have been misleading (they were written before certain changes were made). > It looks fine. Hopefully we can eventually figure out why the sorting > on the fly didn't pan out. Wonderful! So, will it be committed? Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > > Denis Lila wrote: > > Hi Jim. > > > > Thanks for all your suggestions. I fixed the edge array > indexing > > issue, the moveTo bug (not assigning x0), and the double > > initialization issue. I also improved the emission of the last row > > to what you said. The link is the same as the last one I sent. > > > But everything looks in order! > > ...jim From dlila at redhat.com Mon Aug 2 22:17:10 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 2 Aug 2010 18:17:10 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1165692173.1518691280787420867.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1456441756.1518751280787430953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I implemented STROKE_CONTROL today. I used the intermediate NormalizingPathIterator, instead of implementing flattening in pisces, because I wanted to get something working asap, and this would be the easiest way. The webrev is http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ I guess I'm not asking that you take a look at it, because it's probably not the way we're going to end up doing things, but I wrote it, so I'm sending the link just in case anyone wants to see it. The webrev is big because it includes the floating point conversion, but all the STROKE_CONTROL changes are in PiscesRenderingEngine.java. Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > It would be ill-advised to normalize the coordinates after flattening. > > The quality would be really bad. > > Perhaps this is a good reason to start looking at updating Pisces to > take curves and flatten at the lowest level? > > Or, I suppose we could get a non-flattened iterator from the source > path, send it through a "normalizing" filter, and then through a > flattening filter (the way many of the existing objects do flattening > is > to just get their regular iterator and run it through an instance of > FlatteningPathIterator so we could do this manually with an > intervening > "NormalizingPathIterator" if normalization is needed)... > > ...jim > > Denis Lila wrote: > > Hello Jim. > > > > Thanks for that. I'll get to work on implementing it. > > > > One thing though, about normalizing the control points of bezier > > curves: pisces never gets any bezier curves as input. It only gets > > lines that are the product of flattening bezier curves. > > > > Pisces receives its input from flattening path iterators which get > it > > from other path iterators. Of course we can't require these to send > out > > normalized points. In order to normalize the control points we need > to > > be able to look at the bezier curves in Pisces, so we can't just > take > > all the input from the flattener. However, pisces can't handle > curves > > (yet, hopefully), so after the normalization, they must be > flattened, and > > this is the problem. I think it's a pretty good idea to do this by > > storing the input form the iterator into pisces (after > normalization), > > creating a nameless path iterator that just iterates through all > that, > > and using this iterator to create a flattening iterator, which then > > is used as before. > > > > Does anyone have any other ideas? > > > > Thank you, > > Denis. > > > > > > ----- "Jim Graham" wrote: > > > >> For AA this is exactly what we do (round to nearest pixel centers > for > >> > >> strokes). Note that this is done prior to any line widening code > is > >> executed. > >> > >> For non-AA we normalize coordinates to, I believe the (0.25, 0.25) > > >> sub-pixel location. This is so that the transitions between > widening > >> of > >> lines occurs evenly (particularly for horizontal and vertical wide > > >> lines). If you round to pixel edges then you have the following > >> progression (note that the line width grows by half on either side > of > >> > >> the original geometry so you have to consider the "line widths" > where > >> > >> you encounter the pixel centers to your left and right (or above > and > >> below) which govern when that column (or row) of pixels first > turns > >> on): > >> > >> width 0.00 => 0.99 nothing drawn (except we kludge this) > >> width 1.00 => 1.00 1 pixel wide (col to left turns on) > >> width 1.01 => 2.99 2 pixels wide (col to right turns on) > >> width 3.00 => 3.00 3 pixels wide (etc.) > >> width 3.01 => 4.99 4 pixels wide > >> > >> Note that it is nearly impossible to get an odd-width line. You > >> basically have to have exactly an integer width to get an odd-width > > >> line. This is because at the odd widths you reach the "half pixel" > > >> locations on both sides of the line at the same time. Due to the > >> "half-open" insideness rules only one of the pixels will be chosen > to > >> be > >> inside this path. Just below these sizes and you fail to hit > either > >> pixel center. Just at the integer size you reach both pixel > centers > >> at > >> the same time. Just slightly larger than that width and now you've > > >> fully enclosed both pixel centers and the line width has to > increase > >> by > >> nearly 2.0 until you reach the next pixel centers. > >> > >> (The kludge I talk about above is that we set a minimum pen width > so > >> that we never fail to draw a line even if the line width is set to > >> 0.0, > >> but the above table was a theoretical description of the absolute > >> rules.) > >> > >> If we rounded them to pixel centers, then the transitions look > like > >> this: > >> > >> width 0.00 => 0.00 nothing drawn (modulo kludge) > >> width 0.01 => 1.99 1 pixel wide (column you are in turns on) > >> width 2.00 => 2.00 2 pixels wide (column to left turns on) > >> width 2.01 => 3.99 3 pixels wide (column to right turns on) > >> width 4.00 => 4.00 4 pixels wide (etc.) > >> width 4.01 => 5.99 5 pixels wide > >> > >> We have a similar effect as above, but biased towards making even > line > >> > >> widths harder. > >> > >> So, by locating lines at (0.25, 0.25) subpixel location we end up > with > >> a > >> very even progression: > >> > >> width 0.00 => 0.50 nothing drawn (modulo kludge) > >> width 0.51 => 1.50 1 pixel wide (column you are in turns on) > >> width 1.51 => 2.50 2 pixel wide (column to left gets added) > >> width 2.51 => 3.50 3 pixel wide (column to right gets added) > >> width 3.51 => 4.50 4 pixel wide (etc.) > >> > >> This gives us nice even and gradual widening of the lines as we > >> increase > >> the line width by sub-pixel amounts and the line widths are fairly > > >> stable around integer widths. > >> > >> Also, note that we don't say "when stroking" as you might want to > >> normalize both strokes and fills so that they continue to match. I > > >> believe that we normalize both strokes and fills for non-AA and we > >> only > >> normalize strokes for AA (and leave AA fills as "pure"). AA is > less > >> problematic with respect to creating gaps if your stroke and fill > >> normalization are not consistent. > >> > >> The rounding equations are along the lines of: > >> > >> v = Math.floor(v + rval) + aval; > >> > >> For center of pixel you use (rval=0.0, aval=0.5) > >> For 0.25,0.25 rounding use (rval=0.25, aval=0.25) > >> For edge of pixel you use (rval=0.5, aval=0.0) > >> > >> Also, we came up with an interesting way of adjusting the control > >> points > >> of quads and cubics if we adjusted their end points, but I don't > know > >> if > >> what we did was really the best idea. For quads we adjust the > control > >> > >> point by the average of the adjustments that we applied to its 2 > end > >> points. For cubics, we move the first control point by the same > >> amount > >> as we moved the starting endpoint and the second control point by > the > >> > >> amount we moved the final endpoint. The jury is out on whether > that > >> is > >> the most aesthetic technique... > >> > >> ...jim > >> > >> Denis Lila wrote: > >>> Regarding VALUE_STROKE_NORMALIZE the API says: > >>> Stroke normalization control hint value -- > geometry > >> should > >>> be normalized to improve uniformity or spacing of > >> lines and > >>> overall aesthetics. Note that different > >> normalization > >>> algorithms may be more successful than others for > >> given > >>> input paths. > >>> > >>> I can only think of one example where VALUE_STROKE_NORMALIZE makes > a > >> visible > >>> difference between the closed source implementation and OpenJDK: > >>> when drawing anti-aliased horizontal or vertical lines of width > 1, > >> Pisces > >>> draws a 2 pixel wide line with half intensity (because integer > >> coordinates > >>> are between pixels). Sun's jdk with VALUE_SROKE_NORMALIZE turned > on > >> draws > >>> a 1 pixel line with full intensity. This could to achieved by > just > >>> checking for normalization and rounding coordinates to the > nearest > >> half > >>> pixel, but this solution seems too simple, and I'm not sure > whether > >> I'm missing > >>> anything. It would also probably cause problems when drawing > >> anti-aliased > >>> short lines (which is done when drawing any sort of curve) > >>> Unless, of course, this rounding was restricted to just > horizontal > >> and > >>> vertical lines. > >>> > >>> Regards, > >>> Denis. From james.graham at oracle.com Tue Aug 3 23:37:16 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 03 Aug 2010 16:37:16 -0700 Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <1471126809.1469491280760050541.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1471126809.1469491280760050541.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C58A82C.9030107@oracle.com> Hi Denis, I'd need to see a final webrev and approve it and then anyone with an OpenJDK user id can push it. I'll also have to create a bugid for the change set. Are you a registered OpenJDK developer? ...jim Denis Lila wrote: > Hello Jim. > >> I'm guessing the test for "y == boundsMaxY-1" at line 470 could >> probably also be deleted now (since it will be handled by the end >> test when y reaches maxY)? > > Indeed it can. I've done this, and also updated a few comments that > might have been misleading (they were written before certain changes > were made). > >> It looks fine. Hopefully we can eventually figure out why the sorting >> on the fly didn't pan out. > > Wonderful! So, will it be committed? > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> > >> Denis Lila wrote: >>> Hi Jim. >>> >>> Thanks for all your suggestions. I fixed the edge array >> indexing >>> issue, the moveTo bug (not assigning x0), and the double >>> initialization issue. I also improved the emission of the last row >>> to what you said. The link is the same as the last one I sent. > >> But everything looks in order! >> >> ...jim From dlila at redhat.com Wed Aug 4 18:27:11 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 4 Aug 2010 14:27:11 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <1661345407.1711311280946079190.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <140560885.1711771280946431403.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. > I'd need to see a final webrev and approve it and then anyone with an > OpenJDK user id can push it. The final webrev is http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ The only things that have changed since the last one you commented on are the "y == boundsMaxY - 1" check, and a few comments in Renderer.java. > I'll also have to create a bugid for the change set. I've already submitted a bug that this patch would fix. The ID is 6967436. > Are you a registered OpenJDK developer? Not just yet. I will be soon, I think. Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > > ...jim > > Denis Lila wrote: > > Hello Jim. > > > >> I'm guessing the test for "y == boundsMaxY-1" at line 470 could > >> probably also be deleted now (since it will be handled by the end > >> test when y reaches maxY)? > > > > Indeed it can. I've done this, and also updated a few comments that > > might have been misleading (they were written before certain > changes > > were made). > > > >> It looks fine. Hopefully we can eventually figure out why the > sorting > >> on the fly didn't pan out. > > > > Wonderful! So, will it be committed? > > > > Thanks, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> Hi Denis, > >> > > > >> Denis Lila wrote: > >>> Hi Jim. > >>> > >>> Thanks for all your suggestions. I fixed the edge array > >> indexing > >>> issue, the moveTo bug (not assigning x0), and the double > >>> initialization issue. I also improved the emission of the last > row > >>> to what you said. The link is the same as the last one I sent. > > > >> But everything looks in order! > >> > >> ...jim From dlila at redhat.com Wed Aug 4 21:12:46 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 4 Aug 2010 17:12:46 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1138540734.1724921280956199315.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <345295862.1725181280956366292.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. So, I've now implemented both suggestions you had for implementing stroke control: an intermediate normalizing path iterator, and doing flattening in pisces at the lowest level. Respectively, the webrevs are: http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ Again, these include the floating point conversion changes, but all of the changes relevant to this e-mail are in PiscesRenderingEngine.java. As for performance, the version with low level flattening is faster, but this is only noticeable when pisces is run on it's own i.e. not actually drawing anything (by the way, I've included a commented out main method in the second webrev. This allowed me to run pisces on it's own which was useful for debugging and performance testing). However, when drawing stuff, whatever happens after pisces takes up so much time that it's hard to tell the difference. Nevertheless, it might be worth to keep the somewhat ugly, low level version. It might be useful for antialiasing if Stroker moves to outputting curves instead of just lines (because AA still needs to flatten, unless someone comes up with an algorithm to do it without flattening, but I can't think of anything). I'm sorry to ask you specifically for all these reviews - you've already spent a lot of time looking at my work, but no one else has replied to any of my pisces inquiries (except Clemens Eisserer, on this issue). Anyway, I would appreciate it if you, or anyone, could take a look at one or both of the above webrevs. Or maybe we could leave it for when the floating point conversion has been pushed. Then the webrevs would have a lot less clutter. Thanks, Denis. ----- "Denis Lila" wrote: > Hi Jim. > > I implemented STROKE_CONTROL today. I used the intermediate > NormalizingPathIterator, instead of implementing flattening in > pisces, because I wanted to get something working asap, and this > would be the easiest way. > > The webrev is > http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ > > I guess I'm not asking that you take a look at it, because it's > probably > not the way we're going to end up doing things, but I wrote it, so > I'm sending the link just in case anyone wants to see it. > > The webrev is big because it includes the floating point conversion, > but all the > STROKE_CONTROL changes are in PiscesRenderingEngine.java. > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > > > Hi Denis, > > > > It would be ill-advised to normalize the coordinates after > flattening. > > > > The quality would be really bad. > > > > Perhaps this is a good reason to start looking at updating Pisces to > > take curves and flatten at the lowest level? > > > > Or, I suppose we could get a non-flattened iterator from the source > > path, send it through a "normalizing" filter, and then through a > > flattening filter (the way many of the existing objects do > flattening > > is > > to just get their regular iterator and run it through an instance of > > FlatteningPathIterator so we could do this manually with an > > intervening > > "NormalizingPathIterator" if normalization is needed)... > > > > ...jim > > > > Denis Lila wrote: > > > Hello Jim. > > > > > > Thanks for that. I'll get to work on implementing it. > > > > > > One thing though, about normalizing the control points of bezier > > > curves: pisces never gets any bezier curves as input. It only gets > > > lines that are the product of flattening bezier curves. > > > > > > Pisces receives its input from flattening path iterators which get > > it > > > from other path iterators. Of course we can't require these to > send > > out > > > normalized points. In order to normalize the control points we > need > > to > > > be able to look at the bezier curves in Pisces, so we can't just > > take > > > all the input from the flattener. However, pisces can't handle > > curves > > > (yet, hopefully), so after the normalization, they must be > > flattened, and > > > this is the problem. I think it's a pretty good idea to do this by > > > storing the input form the iterator into pisces (after > > normalization), > > > creating a nameless path iterator that just iterates through all > > that, > > > and using this iterator to create a flattening iterator, which > then > > > is used as before. > > > > > > Does anyone have any other ideas? > > > > > > Thank you, > > > Denis. > > > > > > > > > ----- "Jim Graham" wrote: > > > > > >> For AA this is exactly what we do (round to nearest pixel centers > > for > > >> > > >> strokes). Note that this is done prior to any line widening code > > is > > >> executed. > > >> > > >> For non-AA we normalize coordinates to, I believe the (0.25, > 0.25) > > > > >> sub-pixel location. This is so that the transitions between > > widening > > >> of > > >> lines occurs evenly (particularly for horizontal and vertical > wide > > > > >> lines). If you round to pixel edges then you have the following > > >> progression (note that the line width grows by half on either > side > > of > > >> > > >> the original geometry so you have to consider the "line widths" > > where > > >> > > >> you encounter the pixel centers to your left and right (or above > > and > > >> below) which govern when that column (or row) of pixels first > > turns > > >> on): > > >> > > >> width 0.00 => 0.99 nothing drawn (except we kludge this) > > >> width 1.00 => 1.00 1 pixel wide (col to left turns on) > > >> width 1.01 => 2.99 2 pixels wide (col to right turns on) > > >> width 3.00 => 3.00 3 pixels wide (etc.) > > >> width 3.01 => 4.99 4 pixels wide > > >> > > >> Note that it is nearly impossible to get an odd-width line. You > > >> basically have to have exactly an integer width to get an > odd-width > > > > >> line. This is because at the odd widths you reach the "half > pixel" > > > > >> locations on both sides of the line at the same time. Due to the > > >> "half-open" insideness rules only one of the pixels will be > chosen > > to > > >> be > > >> inside this path. Just below these sizes and you fail to hit > > either > > >> pixel center. Just at the integer size you reach both pixel > > centers > > >> at > > >> the same time. Just slightly larger than that width and now > you've > > > > >> fully enclosed both pixel centers and the line width has to > > increase > > >> by > > >> nearly 2.0 until you reach the next pixel centers. > > >> > > >> (The kludge I talk about above is that we set a minimum pen width > > so > > >> that we never fail to draw a line even if the line width is set > to > > >> 0.0, > > >> but the above table was a theoretical description of the absolute > > >> rules.) > > >> > > >> If we rounded them to pixel centers, then the transitions look > > like > > >> this: > > >> > > >> width 0.00 => 0.00 nothing drawn (modulo kludge) > > >> width 0.01 => 1.99 1 pixel wide (column you are in turns on) > > >> width 2.00 => 2.00 2 pixels wide (column to left turns on) > > >> width 2.01 => 3.99 3 pixels wide (column to right turns on) > > >> width 4.00 => 4.00 4 pixels wide (etc.) > > >> width 4.01 => 5.99 5 pixels wide > > >> > > >> We have a similar effect as above, but biased towards making even > > line > > >> > > >> widths harder. > > >> > > >> So, by locating lines at (0.25, 0.25) subpixel location we end up > > with > > >> a > > >> very even progression: > > >> > > >> width 0.00 => 0.50 nothing drawn (modulo kludge) > > >> width 0.51 => 1.50 1 pixel wide (column you are in turns on) > > >> width 1.51 => 2.50 2 pixel wide (column to left gets added) > > >> width 2.51 => 3.50 3 pixel wide (column to right gets added) > > >> width 3.51 => 4.50 4 pixel wide (etc.) > > >> > > >> This gives us nice even and gradual widening of the lines as we > > >> increase > > >> the line width by sub-pixel amounts and the line widths are > fairly > > > > >> stable around integer widths. > > >> > > >> Also, note that we don't say "when stroking" as you might want to > > >> normalize both strokes and fills so that they continue to match. > I > > > > >> believe that we normalize both strokes and fills for non-AA and > we > > >> only > > >> normalize strokes for AA (and leave AA fills as "pure"). AA is > > less > > >> problematic with respect to creating gaps if your stroke and fill > > >> normalization are not consistent. > > >> > > >> The rounding equations are along the lines of: > > >> > > >> v = Math.floor(v + rval) + aval; > > >> > > >> For center of pixel you use (rval=0.0, aval=0.5) > > >> For 0.25,0.25 rounding use (rval=0.25, aval=0.25) > > >> For edge of pixel you use (rval=0.5, aval=0.0) > > >> > > >> Also, we came up with an interesting way of adjusting the control > > >> points > > >> of quads and cubics if we adjusted their end points, but I don't > > know > > >> if > > >> what we did was really the best idea. For quads we adjust the > > control > > >> > > >> point by the average of the adjustments that we applied to its 2 > > end > > >> points. For cubics, we move the first control point by the same > > >> amount > > >> as we moved the starting endpoint and the second control point by > > the > > >> > > >> amount we moved the final endpoint. The jury is out on whether > > that > > >> is > > >> the most aesthetic technique... > > >> > > >> ...jim > > >> > > >> Denis Lila wrote: > > >>> Regarding VALUE_STROKE_NORMALIZE the API says: > > >>> Stroke normalization control hint value -- > > geometry > > >> should > > >>> be normalized to improve uniformity or spacing > of > > >> lines and > > >>> overall aesthetics. Note that different > > >> normalization > > >>> algorithms may be more successful than others > for > > >> given > > >>> input paths. > > >>> > > >>> I can only think of one example where VALUE_STROKE_NORMALIZE > makes > > a > > >> visible > > >>> difference between the closed source implementation and OpenJDK: > > >>> when drawing anti-aliased horizontal or vertical lines of width > > 1, > > >> Pisces > > >>> draws a 2 pixel wide line with half intensity (because integer > > >> coordinates > > >>> are between pixels). Sun's jdk with VALUE_SROKE_NORMALIZE turned > > on > > >> draws > > >>> a 1 pixel line with full intensity. This could to achieved by > > just > > >>> checking for normalization and rounding coordinates to the > > nearest > > >> half > > >>> pixel, but this solution seems too simple, and I'm not sure > > whether > > >> I'm missing > > >>> anything. It would also probably cause problems when drawing > > >> anti-aliased > > >>> short lines (which is done when drawing any sort of curve) > > >>> Unless, of course, this rounding was restricted to just > > horizontal > > >> and > > >>> vertical lines. > > >>> > > >>> Regards, > > >>> Denis. From james.graham at oracle.com Wed Aug 4 22:39:07 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 04 Aug 2010 15:39:07 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <345295862.1725181280956366292.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <345295862.1725181280956366292.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C59EC0B.4040208@oracle.com> Hi Denis, First, comments on the high level normalizer (Normalizing iterator): - If there is no normalization going on, I would use the Shape's own flattening (i.e. getPathIterator(at, flat)). The reason being that some shapes may know how to flatten themselves better, or faster, than a Flattening Iterator. In particular, rectangles and polygons would simply ignore the argument and save themselves the cost of wrapping with an extra iterator. This would probably only be a big issue for very long Polygons. - Line 331 - the initializations to NaN aren't necessary as far as I can tell...? - Rather than saving "mode" in the normalizing iterator, how about saving 2 constants: (0.0, 0.5) for AA and (0.25, 0.25) for non-AA and then simply add those constants in rather than having to have the conditional with the 2 different equations? ...jim From dlila at redhat.com Thu Aug 5 15:06:43 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 5 Aug 2010 11:06:43 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1190661719.1790701281020769564.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <387227588.1790761281020803614.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I made all the suggested changes. Links: http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > First, comments on the high level normalizer (Normalizing iterator): > > - If there is no normalization going on, I would use the Shape's own > flattening (i.e. getPathIterator(at, flat)). The reason being that > some > shapes may know how to flatten themselves better, or faster, than a > Flattening Iterator. In particular, rectangles and polygons would > simply ignore the argument and save themselves the cost of wrapping > with > an extra iterator. This would probably only be a big issue for very > long Polygons. > > - Line 331 - the initializations to NaN aren't necessary as far as I > can > tell...? > > - Rather than saving "mode" in the normalizing iterator, how about > saving 2 constants: (0.0, 0.5) for AA and (0.25, 0.25) for non-AA and > > then simply add those constants in rather than having to have the > conditional with the 2 different equations? > > ...jim From dlila at redhat.com Thu Aug 5 15:08:14 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 5 Aug 2010 11:08:14 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <140560885.1711771280946431403.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1324544227.1790931281020894274.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello. > Are you a registered OpenJDK developer? I am now. Can I go ahead and push it? Regards, Denis. From james.graham at oracle.com Thu Aug 5 18:39:50 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 05 Aug 2010 11:39:50 -0700 Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <1324544227.1790931281020894274.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1324544227.1790931281020894274.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C5B0576.4090804@oracle.com> Hi Denis, That's great! I just did a last minute double-check of your last (final) webrevs to be sure. Have you tested Java2Demo with these changes? I'd also run any regression tests you can find with the changes. If there are no problems there, then you are good to go to push it... ...jim On 8/5/2010 8:08 AM, Denis Lila wrote: > Hello. > >> Are you a registered OpenJDK developer? > I am now. > Can I go ahead and push it? > > Regards, > Denis. From james.graham at oracle.com Thu Aug 5 18:45:04 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 05 Aug 2010 11:45:04 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <387227588.1790761281020803614.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <387227588.1790761281020803614.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C5B06B0.8090104@oracle.com> Hi Denis, I'll wait for some clean webrevs once you get the float stuff in for a final review. I did take a really quick look and thought that a better way to handle "OFF" would be to set rval to -1 and then check "rval < 0" as the (quicker) test for OFF in the currentSegment() method. Does that make sense? In any case, let's wait for cleaner webrevs to go further on this (hopefully in a day or so?)... ...jim On 8/5/2010 8:06 AM, Denis Lila wrote: > Hi Jim. > > I made all the suggested changes. > Links: > http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ > http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> >> First, comments on the high level normalizer (Normalizing iterator): >> >> - If there is no normalization going on, I would use the Shape's own >> flattening (i.e. getPathIterator(at, flat)). The reason being that >> some >> shapes may know how to flatten themselves better, or faster, than a >> Flattening Iterator. In particular, rectangles and polygons would >> simply ignore the argument and save themselves the cost of wrapping >> with >> an extra iterator. This would probably only be a big issue for very >> long Polygons. >> >> - Line 331 - the initializations to NaN aren't necessary as far as I >> can >> tell...? >> >> - Rather than saving "mode" in the normalizing iterator, how about >> saving 2 constants: (0.0, 0.5) for AA and (0.25, 0.25) for non-AA and >> >> then simply add those constants in rather than having to have the >> conditional with the 2 different equations? >> >> ...jim From dlila at redhat.com Thu Aug 5 22:58:41 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 5 Aug 2010 18:58:41 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <1770324094.1828171281048856970.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <481043226.1828291281049121560.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I didn't know about Java2Demo. If I did I would have run it sooner. But I ran it a few hours ago, and everything looked fine (surprisingly high fps too) until I got to the append test. Apparently I introduced a bug when solving the "2 consecutive moveTos bug". Basically, when there's a close() after a horizontal lineTo(), the lineTo in close() won't be executed because it's inside the if (firstOrientation != 0) test. So instead of going back to the starting point, close will stay where it is, which will draw a triangle above the rectangle. I fixed this by introducing a variable that keeps track of the last method called (lineTo, moveTo, or close), and instead of checking for firstOrientation != 0 in close(), I check for (last == LINE_TO). webrev (hopefully final): http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ I'm sorry about this. I wish I had known about Java2Demo sooner. Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > That's great! I just did a last minute double-check of your last > (final) webrevs to be sure. > > Have you tested Java2Demo with these changes? I'd also run any > regression tests you can find with the changes. If there are no > problems there, then you are good to go to push it... > > ...jim > > On 8/5/2010 8:08 AM, Denis Lila wrote: > > Hello. > > > >> Are you a registered OpenJDK developer? > > I am now. > > Can I go ahead and push it? > > > > Regards, > > Denis. From james.graham at oracle.com Fri Aug 6 21:44:00 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 06 Aug 2010 14:44:00 -0700 Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <481043226.1828291281049121560.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <481043226.1828291281049121560.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C5C8220.7090102@oracle.com> Hi Denis, Well, I guess it's a good thing that Java2Demo had a path like that in it - not a very common case, so it's good we found it! The fix looks fine. It still seems like there is way more logic there than is needed - hopefully if we can get rid of flips at some point, much of it will go away. Fixes look good to go to me... ...jim On 8/5/2010 3:58 PM, Denis Lila wrote: > Hi Jim. > > I didn't know about Java2Demo. If I did I would have run it sooner. > But I ran it a few hours ago, and everything looked fine (surprisingly > high fps too) until I got to the append test. > > Apparently I introduced a bug when solving the "2 consecutive moveTos bug". > Basically, when there's a close() after a horizontal lineTo(), the lineTo > in close() won't be executed because it's inside the if (firstOrientation != 0) > test. So instead of going back to the starting point, close will stay where > it is, which will draw a triangle above the rectangle. > > I fixed this by introducing a variable that keeps track of the last method > called (lineTo, moveTo, or close), and instead of checking for firstOrientation != 0 > in close(), I check for (last == LINE_TO). > > webrev (hopefully final): > http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ > > I'm sorry about this. I wish I had known about Java2Demo sooner. > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> >> That's great! I just did a last minute double-check of your last >> (final) webrevs to be sure. >> >> Have you tested Java2Demo with these changes? I'd also run any >> regression tests you can find with the changes. If there are no >> problems there, then you are good to go to push it... >> >> ...jim >> >> On 8/5/2010 8:08 AM, Denis Lila wrote: >>> Hello. >>> >>>> Are you a registered OpenJDK developer? >>> I am now. >>> Can I go ahead and push it? >>> >>> Regards, >>> Denis. From james.graham at oracle.com Sat Aug 7 01:40:30 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 06 Aug 2010 18:40:30 -0700 Subject: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code In-Reply-To: <4C5C8220.7090102@oracle.com> References: <481043226.1828291281049121560.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4C5C8220.7090102@oracle.com> Message-ID: <4C5CB98E.1020304@oracle.com> To the end of getting rid of "flips" - all they are used for is to resize the crossings array, right? This is not a huge array that costs a lot to resize - why not simply use a default array of, say, 30 elements and then resize it if we ever have more crossings than that? Only very complicated paths would have more than 30 crossings to track. The check for array length is only needed once per scanline since we know how many active edges are on each scan line (hi-lo) and you can only have 1 crossing per active edge so with one test per scanline we can keep the crossings array within range... ...jim Jim Graham wrote: > Hi Denis, > > Well, I guess it's a good thing that Java2Demo had a path like that in > it - not a very common case, so it's good we found it! > > The fix looks fine. It still seems like there is way more logic there > than is needed - hopefully if we can get rid of flips at some point, > much of it will go away. > > Fixes look good to go to me... > > ...jim > > On 8/5/2010 3:58 PM, Denis Lila wrote: >> Hi Jim. >> >> I didn't know about Java2Demo. If I did I would have run it sooner. >> But I ran it a few hours ago, and everything looked fine (surprisingly >> high fps too) until I got to the append test. >> >> Apparently I introduced a bug when solving the "2 consecutive moveTos >> bug". >> Basically, when there's a close() after a horizontal lineTo(), the lineTo >> in close() won't be executed because it's inside the if >> (firstOrientation != 0) >> test. So instead of going back to the starting point, close will stay >> where >> it is, which will draw a triangle above the rectangle. >> >> I fixed this by introducing a variable that keeps track of the last >> method >> called (lineTo, moveTo, or close), and instead of checking for >> firstOrientation != 0 >> in close(), I check for (last == LINE_TO). >> >> webrev (hopefully final): >> http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ >> >> I'm sorry about this. I wish I had known about Java2Demo sooner. >> >> Thanks, >> Denis. >> >> ----- "Jim Graham" wrote: >> >>> Hi Denis, >>> >>> That's great! I just did a last minute double-check of your last >>> (final) webrevs to be sure. >>> >>> Have you tested Java2Demo with these changes? I'd also run any >>> regression tests you can find with the changes. If there are no >>> problems there, then you are good to go to push it... >>> >>> ...jim >>> >>> On 8/5/2010 8:08 AM, Denis Lila wrote: >>>> Hello. >>>> >>>>> Are you a registered OpenJDK developer? >>>> I am now. >>>> Can I go ahead and push it? >>>> >>>> Regards, >>>> Denis. From dlila at redhat.com Mon Aug 9 21:03:01 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 9 Aug 2010 17:03:01 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code In-Reply-To: <57146781.2027971281387490361.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1569935843.2028741281387781739.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- Forwarded Message ----- From: "Denis Lila" To: "Jim Graham" Sent: Monday, August 9, 2010 4:58:10 PM GMT -05:00 US/Canada Eastern Subject: Re: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code Hi Jim. Good idea. I've implemented it. I also noticed the quicksort method wasn't very friendly to 0 length arrays. I fixed that. I ran Java2Demo and a few of my tests, and everything looks good. http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ Everything, except the joins demo, that is. The interior of the star's right arm (our left) and left leg is not drawn exactly like in proprietary java or openjdk6. I am not sure if this is a bug since I don't know exactly how the results of a bs.createStrokedShape are supposed to look. However, I am almost certain that this isn't my fault, since I can reproduce the behaviour with an only slightly changed version of openjdk7 with completely different changes than what's in this patch. I'll run it next morning with a fresh build of openjdk7 to be completely sure. Can I push it? Thanks, Denis. ----- "Jim Graham" wrote: > To the end of getting rid of "flips" - all they are used for is to > resize the crossings array, right? This is not a huge array that > costs > a lot to resize - why not simply use a default array of, say, 30 > elements and then resize it if we ever have more crossings than that? > > Only very complicated paths would have more than 30 crossings to > track. > The check for array length is only needed once per scanline since we > > know how many active edges are on each scan line (hi-lo) and you can > only have 1 crossing per active edge so with one test per scanline we > > can keep the crossings array within range... > > ...jim > > Jim Graham wrote: > > Hi Denis, > > > > Well, I guess it's a good thing that Java2Demo had a path like that > in > > it - not a very common case, so it's good we found it! > > > > The fix looks fine. It still seems like there is way more logic > there > > than is needed - hopefully if we can get rid of flips at some point, > > > much of it will go away. > > > > Fixes look good to go to me... > > > > ...jim > > > > On 8/5/2010 3:58 PM, Denis Lila wrote: > >> Hi Jim. > >> > >> I didn't know about Java2Demo. If I did I would have run it > sooner. > >> But I ran it a few hours ago, and everything looked fine > (surprisingly > >> high fps too) until I got to the append test. > >> > >> Apparently I introduced a bug when solving the "2 consecutive > moveTos > >> bug". > >> Basically, when there's a close() after a horizontal lineTo(), the > lineTo > >> in close() won't be executed because it's inside the if > >> (firstOrientation != 0) > >> test. So instead of going back to the starting point, close will > stay > >> where > >> it is, which will draw a triangle above the rectangle. > >> > >> I fixed this by introducing a variable that keeps track of the last > > >> method > >> called (lineTo, moveTo, or close), and instead of checking for > >> firstOrientation != 0 > >> in close(), I check for (last == LINE_TO). > >> > >> webrev (hopefully final): > >> http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ > >> > >> I'm sorry about this. I wish I had known about Java2Demo sooner. > >> > >> Thanks, > >> Denis. > >> > >> ----- "Jim Graham" wrote: > >> > >>> Hi Denis, > >>> > >>> That's great! I just did a last minute double-check of your last > >>> (final) webrevs to be sure. > >>> > >>> Have you tested Java2Demo with these changes? I'd also run any > >>> regression tests you can find with the changes. If there are no > >>> problems there, then you are good to go to push it... > >>> > >>> ...jim > >>> > >>> On 8/5/2010 8:08 AM, Denis Lila wrote: > >>>> Hello. > >>>> > >>>>> Are you a registered OpenJDK developer? > >>>> I am now. > >>>> Can I go ahead and push it? > >>>> > >>>> Regards, > >>>> Denis. From james.graham at oracle.com Tue Aug 10 00:52:54 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 09 Aug 2010 17:52:54 -0700 Subject: [OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code In-Reply-To: <1569935843.2028741281387781739.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1569935843.2028741281387781739.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C60A2E6.2080409@oracle.com> What was the problem - I might have a guess as to the cause if I saw a picture. You should file a bug against it to make sure it doesn't fall through the cracks. But, the webrev you sent looks good to go. If you want some more optimization comments, I'll always have more (I'm evil that way)... ;-) - Testing for y0==y1 in lineTo is redundant. addEdge already ignores the line with a looser test. It does take more processing to reject the edge in that case, though, but that test in lineTo is saving less and less work with every revision. - pix_sxy0 aren't really needed. close() could simply: addEdge(x0, y0, sx0, sy0); this.x0 = sx0; this.y0 = sy0; and bypass what little processing is left in lineTo. - addEdge rejects horizontal edges. It could also reject any of the following classes of edges: - completely above clip - completely below clip - completely to the right of clip since those edges will never contribute to the coverage. The algorithm should skip the above and below edges reasonably quickly, but this would save storage for them. The edges to the right would have to be updated every scanline and waste storage, but that isn't a huge hit. This only helps for corner-case huge paths which aren't common. At least you aren't iterating over miles and miles of irrelevant geometry which would be an important performance hit. But, these 3 are really getting down to the nitty gritty. I'd check it in before I drive you crazy... ;-) ...jim Denis Lila wrote: > ----- Forwarded Message ----- > From: "Denis Lila" > To: "Jim Graham" > Sent: Monday, August 9, 2010 4:58:10 PM GMT -05:00 US/Canada Eastern > Subject: Re: [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code > > Hi Jim. > > Good idea. I've implemented it. I also noticed the quicksort > method wasn't very friendly to 0 length arrays. I fixed that. > I ran Java2Demo and a few of my tests, and everything looks good. > http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ > > Everything, except the joins demo, that is. The interior of the > star's right arm (our left) and left leg is not drawn exactly like > in proprietary java or openjdk6. I am not sure if this is a bug > since I don't know exactly how the results of a bs.createStrokedShape > are supposed to look. However, I am almost certain that this > isn't my fault, since I can reproduce the behaviour with an only > slightly changed version of openjdk7 with completely different > changes than what's in this patch. I'll run it next morning with > a fresh build of openjdk7 to be completely sure. > > Can I push it? > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > >> To the end of getting rid of "flips" - all they are used for is to >> resize the crossings array, right? This is not a huge array that >> costs >> a lot to resize - why not simply use a default array of, say, 30 >> elements and then resize it if we ever have more crossings than that? >> >> Only very complicated paths would have more than 30 crossings to >> track. >> The check for array length is only needed once per scanline since we >> >> know how many active edges are on each scan line (hi-lo) and you can >> only have 1 crossing per active edge so with one test per scanline we >> >> can keep the crossings array within range... >> >> ...jim >> >> Jim Graham wrote: >>> Hi Denis, >>> >>> Well, I guess it's a good thing that Java2Demo had a path like that >> in >>> it - not a very common case, so it's good we found it! >>> >>> The fix looks fine. It still seems like there is way more logic >> there >>> than is needed - hopefully if we can get rid of flips at some point, >>> much of it will go away. >>> >>> Fixes look good to go to me... >>> >>> ...jim >>> >>> On 8/5/2010 3:58 PM, Denis Lila wrote: >>>> Hi Jim. >>>> >>>> I didn't know about Java2Demo. If I did I would have run it >> sooner. >>>> But I ran it a few hours ago, and everything looked fine >> (surprisingly >>>> high fps too) until I got to the append test. >>>> >>>> Apparently I introduced a bug when solving the "2 consecutive >> moveTos >>>> bug". >>>> Basically, when there's a close() after a horizontal lineTo(), the >> lineTo >>>> in close() won't be executed because it's inside the if >>>> (firstOrientation != 0) >>>> test. So instead of going back to the starting point, close will >> stay >>>> where >>>> it is, which will draw a triangle above the rectangle. >>>> >>>> I fixed this by introducing a variable that keeps track of the last >>>> method >>>> called (lineTo, moveTo, or close), and instead of checking for >>>> firstOrientation != 0 >>>> in close(), I check for (last == LINE_TO). >>>> >>>> webrev (hopefully final): >>>> http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ >>>> >>>> I'm sorry about this. I wish I had known about Java2Demo sooner. >>>> >>>> Thanks, >>>> Denis. >>>> >>>> ----- "Jim Graham" wrote: >>>> >>>>> Hi Denis, >>>>> >>>>> That's great! I just did a last minute double-check of your last >>>>> (final) webrevs to be sure. >>>>> >>>>> Have you tested Java2Demo with these changes? I'd also run any >>>>> regression tests you can find with the changes. If there are no >>>>> problems there, then you are good to go to push it... >>>>> >>>>> ...jim >>>>> >>>>> On 8/5/2010 8:08 AM, Denis Lila wrote: >>>>>> Hello. >>>>>> >>>>>>> Are you a registered OpenJDK developer? >>>>>> I am now. >>>>>> Can I go ahead and push it? >>>>>> >>>>>> Regards, >>>>>> Denis. From dlila at redhat.com Tue Aug 10 13:42:29 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 10 Aug 2010 09:42:29 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code In-Reply-To: <429493593.2069571281447731160.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1533151076.2069631281447749299.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > What was the problem - I might have a guess as to the cause if I saw a > picture. You should file a bug against it to make sure it doesn't fall > through the cracks. I can confirm that none of my changes introduced the bug. I just tested it with a truly fresh build of openjdk7. I've attached 3 screenshots with results. > But, these 3 are really getting down to the nitty gritty. I'd check it > in before I drive you crazy... ;-) Good idea :) I'll keep the 3 comments in mind for future work. I actually already implemented something like your third suggestion, but it was along with some other changes and I introduced a bug, so I discarded it because I didn't want to spend too much time debugging. Speaking of which, wouldn't it be a good idea to clip lines (perhaps earlier than Renderer, so that Stroker, Dasher, and Renderer can benefit from it)? We could only do this for lines that are out of bounds vertically, otherwise anti aliasing would break, but for lines that are out of bounds horizontally we could collapse their x coordinate to boundsMinX-1 or boundsMaxX+1 (or bounds +/- lineWidth, if we're doing it before Renderer.java). That would at least reduce their length, and I can't see how it might break anti aliasing. Am I missing anything? Or would this simply not be worth the added processing? Thanks, Denis. ----- "Jim Graham" wrote: > > But, the webrev you sent looks good to go. > > If you want some more optimization comments, I'll always have more > (I'm > evil that way)... ;-) > > - Testing for y0==y1 in lineTo is redundant. addEdge already ignores > > the line with a looser test. It does take more processing to reject > the > edge in that case, though, but that test in lineTo is saving less and > > less work with every revision. > > - pix_sxy0 aren't really needed. close() could simply: > addEdge(x0, y0, sx0, sy0); > this.x0 = sx0; > this.y0 = sy0; > and bypass what little processing is left in lineTo. > > - addEdge rejects horizontal edges. It could also reject any of the > following classes of edges: > - completely above clip > - completely below clip > - completely to the right of clip > since those edges will never contribute to the coverage. The > algorithm > should skip the above and below edges reasonably quickly, but this > would > save storage for them. The edges to the right would have to be > updated > every scanline and waste storage, but that isn't a huge hit. This > only > helps for corner-case huge paths which aren't common. At least you > aren't iterating over miles and miles of irrelevant geometry which > would > be an important performance hit. > > > ...jim > > Denis Lila wrote: > > ----- Forwarded Message ----- > > From: "Denis Lila" > > To: "Jim Graham" > > Sent: Monday, August 9, 2010 4:58:10 PM GMT -05:00 US/Canada > Eastern > > Subject: Re: [OpenJDK 2D-Dev] Various fixes to pisces stroke > widening code > > > > Hi Jim. > > > > Good idea. I've implemented it. I also noticed the quicksort > > method wasn't very friendly to 0 length arrays. I fixed that. > > I ran Java2Demo and a few of my tests, and everything looks good. > > http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ > > > > Everything, except the joins demo, that is. The interior of the > > star's right arm (our left) and left leg is not drawn exactly like > > in proprietary java or openjdk6. I am not sure if this is a bug > > since I don't know exactly how the results of a > bs.createStrokedShape > > are supposed to look. However, I am almost certain that this > > isn't my fault, since I can reproduce the behaviour with an only > > slightly changed version of openjdk7 with completely different > > changes than what's in this patch. I'll run it next morning with > > a fresh build of openjdk7 to be completely sure. > > > > Can I push it? > > > > Thanks, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> To the end of getting rid of "flips" - all they are used for is to > > >> resize the crossings array, right? This is not a huge array that > >> costs > >> a lot to resize - why not simply use a default array of, say, 30 > >> elements and then resize it if we ever have more crossings than > that? > >> > >> Only very complicated paths would have more than 30 crossings to > >> track. > >> The check for array length is only needed once per scanline since > we > >> > >> know how many active edges are on each scan line (hi-lo) and you > can > >> only have 1 crossing per active edge so with one test per scanline > we > >> > >> can keep the crossings array within range... > >> > >> ...jim > >> > >> Jim Graham wrote: > >>> Hi Denis, > >>> > >>> Well, I guess it's a good thing that Java2Demo had a path like > that > >> in > >>> it - not a very common case, so it's good we found it! > >>> > >>> The fix looks fine. It still seems like there is way more logic > >> there > >>> than is needed - hopefully if we can get rid of flips at some > point, > >>> much of it will go away. > >>> > >>> Fixes look good to go to me... > >>> > >>> ...jim > >>> > >>> On 8/5/2010 3:58 PM, Denis Lila wrote: > >>>> Hi Jim. > >>>> > >>>> I didn't know about Java2Demo. If I did I would have run it > >> sooner. > >>>> But I ran it a few hours ago, and everything looked fine > >> (surprisingly > >>>> high fps too) until I got to the append test. > >>>> > >>>> Apparently I introduced a bug when solving the "2 consecutive > >> moveTos > >>>> bug". > >>>> Basically, when there's a close() after a horizontal lineTo(), > the > >> lineTo > >>>> in close() won't be executed because it's inside the if > >>>> (firstOrientation != 0) > >>>> test. So instead of going back to the starting point, close will > >> stay > >>>> where > >>>> it is, which will draw a triangle above the rectangle. > >>>> > >>>> I fixed this by introducing a variable that keeps track of the > last > >>>> method > >>>> called (lineTo, moveTo, or close), and instead of checking for > >>>> firstOrientation != 0 > >>>> in close(), I check for (last == LINE_TO). > >>>> > >>>> webrev (hopefully final): > >>>> http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/ > >>>> > >>>> I'm sorry about this. I wish I had known about Java2Demo sooner. > >>>> > >>>> Thanks, > >>>> Denis. > >>>> > >>>> ----- "Jim Graham" wrote: > >>>> > >>>>> Hi Denis, > >>>>> > >>>>> That's great! I just did a last minute double-check of your > last > >>>>> (final) webrevs to be sure. > >>>>> > >>>>> Have you tested Java2Demo with these changes? I'd also run any > >>>>> regression tests you can find with the changes. If there are > no > >>>>> problems there, then you are good to go to push it... > >>>>> > >>>>> ...jim > >>>>> > >>>>> On 8/5/2010 8:08 AM, Denis Lila wrote: > >>>>>> Hello. > >>>>>> > >>>>>>> Are you a registered OpenJDK developer? > >>>>>> I am now. > >>>>>> Can I go ahead and push it? > >>>>>> > >>>>>> Regards, > >>>>>> Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: triangleOpenJDK7.png Type: image/png Size: 7052 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: triangleGood.png Type: image/png Size: 13970 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Java2DStarOpenJDK7.png Type: image/png Size: 28534 bytes Desc: not available URL: From dlila at redhat.com Tue Aug 10 17:20:35 2010 From: dlila at redhat.com (dlila at redhat.com) Date: Tue, 10 Aug 2010 17:20:35 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6967436: lines longer than 2^15 can fill window.; ... Message-ID: <20100810172044.C1CB44705A@hg.openjdk.java.net> Changeset: d47bd9d94ba4 Author: dlila Date: 2010-08-10 13:19 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d47bd9d94ba4 6967436: lines longer than 2^15 can fill window. 6967433: dashed lines broken when using scaling transforms. Summary: converted pisces to floating point. Also, using better AA algorithm Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/java2d/pisces/PiscesMath.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java - src/share/classes/sun/java2d/pisces/Transform4.java From james.graham at oracle.com Tue Aug 10 20:00:15 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 10 Aug 2010 13:00:15 -0700 Subject: [OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code In-Reply-To: <1533151076.2069631281447749299.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1533151076.2069631281447749299.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C61AFCF.7070307@oracle.com> Hi Denis, WRT the difference in the strokepath - as long as it fills correctly then I don't think it is out of spec as we only specify that BasicStroke returns a path that fills the appropriate pixels. Is their fill area correct? But, it would be a nice thing to have some consistency, and it begs the question - is there some error that this alternate stroking technique might introduce that we just haven't found yet? For instance, is it robust with respect to winding rules if you overlay 2 such stroked objects? Also, it looks like a simple error in choosing which pairs of points to connect when rounding a bend (probably back to the initial moveto?). Clipping geometry outside of a clip is a topic for another discussion. One issue to keep in mind is that floating point clipping equations can sometimes return numbers that are N.49999 or N.50000 or N.50001 and that subtle difference may not matter for AA, but it can cause a pixel to appear or disappear under non-AA rendering which would be bad if it happens when the scene is already rendered and then you have to update a small clipped part of it for some repaint() call and the rendering turns out different during that update due to the clipping math... 8-| So, I typically only cull/clip items when I am down to the bottom level and I can directly know how the equations are going to relate to the final numbers that are used to choose pixels. ...jim On 8/10/2010 6:42 AM, Denis Lila wrote: > Hi Jim. > >> What was the problem - I might have a guess as to the cause if I saw a >> picture. You should file a bug against it to make sure it doesn't fall >> through the cracks. > I can confirm that none of my changes introduced the bug. I just tested it > with a truly fresh build of openjdk7. I've attached 3 screenshots with > results. > >> But, these 3 are really getting down to the nitty gritty. I'd check it >> in before I drive you crazy... ;-) > Good idea :) > I'll keep the 3 comments in mind for future work. I actually already > implemented something like your third suggestion, but it was along with > some other changes and I introduced a bug, so I discarded it because I > didn't want to spend too much time debugging. > Speaking of which, wouldn't it be a good idea to clip lines (perhaps > earlier than Renderer, so that Stroker, Dasher, and Renderer can benefit > from it)? We could only do this for lines that are out of bounds vertically, > otherwise anti aliasing would break, but for lines that are out of bounds > horizontally we could collapse their x coordinate to boundsMinX-1 or boundsMaxX+1 > (or bounds +/- lineWidth, if we're doing it before Renderer.java). > That would at least reduce their length, and I can't see how it might break > anti aliasing. > Am I missing anything? Or would this simply not be worth the added processing? > > Thanks, > Denis. From dlila at redhat.com Tue Aug 10 20:59:14 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 10 Aug 2010 16:59:14 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Fwd: Various fixes to pisces stroke widening code In-Reply-To: <1962957913.2118481281473870890.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <127463181.2118701281473954797.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. > WRT the difference in the strokepath - as long as it fills correctly > then I don't think it is out of spec as we only specify that > BasicStroke returns a path that fills the appropriate pixels. Is > their fill area correct? Ah. That's why I said I wasn't sure this was a bug. If that's what the spec says, then it's not a bug, because the fill areas are the same. > But, it would be a nice thing to have some consistency, and it begs > the question - is there some error that this alternate stroking technique > might introduce that we just haven't found yet? For instance, is it > robust with respect to winding rules if you overlay 2 such stroked > objects? Also, it looks like a simple error in choosing which pairs > of points to connect when rounding a bend (probably back to the initial > moveto?). I was thinking the "problem" was that instead of going to the position of the last moveTo, we were going to the position of the last moveTo + Offset. That would explain the difference in the top left, but not the bottom right. I will have to look at Stroker some more. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > Clipping geometry outside of a clip is a topic for another discussion. > > One issue to keep in mind is that floating point clipping equations > can > sometimes return numbers that are N.49999 or N.50000 or N.50001 and > that > subtle difference may not matter for AA, but it can cause a pixel to > appear or disappear under non-AA rendering which would be bad if it > happens when the scene is already rendered and then you have to update > a > small clipped part of it for some repaint() call and the rendering > turns > out different during that update due to the clipping math... 8-| So, > I > typically only cull/clip items when I am down to the bottom level and > I > can directly know how the equations are going to relate to the final > numbers that are used to choose pixels. > > ...jim > > On 8/10/2010 6:42 AM, Denis Lila wrote: > > Hi Jim. > > > >> What was the problem - I might have a guess as to the cause if I > saw a > >> picture. You should file a bug against it to make sure it doesn't > fall > >> through the cracks. > > I can confirm that none of my changes introduced the bug. I > just tested it > > with a truly fresh build of openjdk7. I've attached 3 screenshots > with > > results. > > > >> But, these 3 are really getting down to the nitty gritty. I'd > check it > >> in before I drive you crazy... ;-) > > Good idea :) > > I'll keep the 3 comments in mind for future work. I actually > already > > implemented something like your third suggestion, but it was along > with > > some other changes and I introduced a bug, so I discarded it because > I > > didn't want to spend too much time debugging. > > Speaking of which, wouldn't it be a good idea to clip lines > (perhaps > > earlier than Renderer, so that Stroker, Dasher, and Renderer can > benefit > > from it)? We could only do this for lines that are out of bounds > vertically, > > otherwise anti aliasing would break, but for lines that are out of > bounds > > horizontally we could collapse their x coordinate to boundsMinX-1 or > boundsMaxX+1 > > (or bounds +/- lineWidth, if we're doing it before Renderer.java). > > That would at least reduce their length, and I can't see how it > might break > > anti aliasing. > > Am I missing anything? Or would this simply not be worth the > added processing? > > > > Thanks, > > Denis. From dlila at redhat.com Tue Aug 10 21:06:05 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 10 Aug 2010 17:06:05 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4C5B06B0.8090104@oracle.com> Message-ID: <688607571.2119221281474365967.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. So, I have the nicer webrevs. FlatteningIterator version: http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ Pisces flattening version: http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ I dealt with the issue of handling OFF by just not accepting it as an input. After all, a normalizing iterator only needs to be created, and is only created if the normalization mode is not OFF. Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > I'll wait for some clean webrevs once you get the float stuff in for a > > final review. I did take a really quick look and thought that a > better > way to handle "OFF" would be to set rval to -1 and then check "rval < > 0" > as the (quicker) test for OFF in the currentSegment() method. Does > that > make sense? > > In any case, let's wait for cleaner webrevs to go further on this > (hopefully in a day or so?)... > > ...jim > > On 8/5/2010 8:06 AM, Denis Lila wrote: > > Hi Jim. > > > > I made all the suggested changes. > > Links: > > > http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ > > > http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ > > > > Thanks, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> Hi Denis, > >> > >> First, comments on the high level normalizer (Normalizing > iterator): > >> > >> - If there is no normalization going on, I would use the Shape's > own > >> flattening (i.e. getPathIterator(at, flat)). The reason being > that > >> some > >> shapes may know how to flatten themselves better, or faster, than > a > >> Flattening Iterator. In particular, rectangles and polygons would > >> simply ignore the argument and save themselves the cost of > wrapping > >> with > >> an extra iterator. This would probably only be a big issue for > very > >> long Polygons. > >> > >> - Line 331 - the initializations to NaN aren't necessary as far as > I > >> can > >> tell...? > >> > >> - Rather than saving "mode" in the normalizing iterator, how about > >> saving 2 constants: (0.0, 0.5) for AA and (0.25, 0.25) for non-AA > and > >> > >> then simply add those constants in rather than having to have the > >> conditional with the 2 different equations? > >> > >> ...jim From james.graham at oracle.com Tue Aug 10 22:39:06 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 10 Aug 2010 15:39:06 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <688607571.2119221281474365967.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <688607571.2119221281474365967.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C61D50A.2000100@oracle.com> Hi Denis, I think the first version is a better choice for now since you said that the performance difference isn't noticeable. I think the lower level flattening might look a little different if we ever decide to upgrade the pipeline to deal with curves. In particular, you are still flattening above the dashing/stroking code and I think the flattening should be done below that code (i.e. in Renderer). So, I'd go with the first one with the following comments: - You indent by 8 spaces in a few places. Is that a tabs vs. spaces issue? We try to stick to 4 space indentations with no tabs for consistentcy. - I'd make the internal error message a little less personal. ;-) "normalization not needed in OFF mode" or something. - lines 362,363 - you don't need to set cur_adjust variables here, they are already being set below. Other than that, it looks good to go... ...jim Denis Lila wrote: > Hi Jim. > > So, I have the nicer webrevs. > FlatteningIterator version: > http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ > > Pisces flattening version: > http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ > > I dealt with the issue of handling OFF by just not accepting it as an input. > After all, a normalizing iterator only needs to be created, and is only created > if the normalization mode is not OFF. > > Thanks, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> >> I'll wait for some clean webrevs once you get the float stuff in for a >> >> final review. I did take a really quick look and thought that a >> better >> way to handle "OFF" would be to set rval to -1 and then check "rval < >> 0" >> as the (quicker) test for OFF in the currentSegment() method. Does >> that >> make sense? >> >> In any case, let's wait for cleaner webrevs to go further on this >> (hopefully in a day or so?)... >> >> ...jim >> >> On 8/5/2010 8:06 AM, Denis Lila wrote: >>> Hi Jim. >>> >>> I made all the suggested changes. >>> Links: >>> >> http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ >> http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ >>> Thanks, >>> Denis. >>> >>> ----- "Jim Graham" wrote: >>> >>>> Hi Denis, >>>> >>>> First, comments on the high level normalizer (Normalizing >> iterator): >>>> - If there is no normalization going on, I would use the Shape's >> own >>>> flattening (i.e. getPathIterator(at, flat)). The reason being >> that >>>> some >>>> shapes may know how to flatten themselves better, or faster, than >> a >>>> Flattening Iterator. In particular, rectangles and polygons would >>>> simply ignore the argument and save themselves the cost of >> wrapping >>>> with >>>> an extra iterator. This would probably only be a big issue for >> very >>>> long Polygons. >>>> >>>> - Line 331 - the initializations to NaN aren't necessary as far as >> I >>>> can >>>> tell...? >>>> >>>> - Rather than saving "mode" in the normalizing iterator, how about >>>> saving 2 constants: (0.0, 0.5) for AA and (0.25, 0.25) for non-AA >> and >>>> then simply add those constants in rather than having to have the >>>> conditional with the 2 different equations? >>>> >>>> ...jim From dlila at redhat.com Wed Aug 11 14:36:51 2010 From: dlila at redhat.com (dlila at redhat.com) Date: Wed, 11 Aug 2010 14:36:51 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6976265: No STROKE_CONTROL Message-ID: <20100811143732.2F0CB4709D@hg.openjdk.java.net> Changeset: 4285edea9ddb Author: dlila Date: 2010-08-11 10:05 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4285edea9ddb 6976265: No STROKE_CONTROL Summary: implemented it in sun.java2d.pisces by adding a PathIterator. Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java From dlila at redhat.com Wed Aug 11 14:43:04 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 11 Aug 2010 10:43:04 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1931358329.2166501281537661629.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <947328609.2166761281537784768.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > I think the first version is a better choice for now since you said that > the performance difference isn't noticeable. I think the lower level > flattening might look a little different if we ever decide to upgrade > the pipeline to deal with curves. In particular, you are still > flattening above the dashing/stroking code and I think the flattening > should be done below that code (i.e. in Renderer). Wouldn't we still need to flatten for dashing? Is there some way to quickly compute the arc length of a bezier curve from t=0 to t=some_number? As far as I can see the function for this computation is the integral of sqrt(polynomial_of_degree_4), and that would be pretty nasty. Or maybe we can get around this somehow? > - You indent by 8 spaces in a few places. Is that a tabs vs. spaces > issue? We try to stick to 4 space indentations with no tabs for > consistentcy. Yes it is. Sorry about this. Eclipse is completely ignoring my "replace tabs with spaces" option. Thanks, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > So, I'd go with the first one with the following comments: > > - I'd make the internal error message a little less personal. ;-) > "normalization not needed in OFF mode" or something. > > - lines 362,363 - you don't need to set cur_adjust variables here, > they are already being set below. > > Other than that, it looks good to go... > > ...jim > > Denis Lila wrote: > > Hi Jim. > > > > So, I have the nicer webrevs. > > FlatteningIterator version: > > > http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ > > > > Pisces flattening version: > > > http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ > > > > I dealt with the issue of handling OFF by just not accepting it as > an input. > > After all, a normalizing iterator only needs to be created, and is > only created > > if the normalization mode is not OFF. > > > > Thanks, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> Hi Denis, > >> > >> I'll wait for some clean webrevs once you get the float stuff in > for a > >> > >> final review. I did take a really quick look and thought that a > >> better > >> way to handle "OFF" would be to set rval to -1 and then check "rval > < > >> 0" > >> as the (quicker) test for OFF in the currentSegment() method. > Does > >> that > >> make sense? > >> > >> In any case, let's wait for cleaner webrevs to go further on this > >> (hopefully in a day or so?)... > >> > >> ...jim > >> > >> On 8/5/2010 8:06 AM, Denis Lila wrote: > >>> Hi Jim. > >>> > >>> I made all the suggested changes. > >>> Links: > >>> > >> > http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/ > >> > http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/ > >>> Thanks, > >>> Denis. > >>> > >>> ----- "Jim Graham" wrote: > >>> > >>>> Hi Denis, > >>>> > >>>> First, comments on the high level normalizer (Normalizing > >> iterator): > >>>> - If there is no normalization going on, I would use the Shape's > >> own > >>>> flattening (i.e. getPathIterator(at, flat)). The reason being > >> that > >>>> some > >>>> shapes may know how to flatten themselves better, or faster, > than > >> a > >>>> Flattening Iterator. In particular, rectangles and polygons > would > >>>> simply ignore the argument and save themselves the cost of > >> wrapping > >>>> with > >>>> an extra iterator. This would probably only be a big issue for > >> very > >>>> long Polygons. > >>>> > >>>> - Line 331 - the initializations to NaN aren't necessary as far > as > >> I > >>>> can > >>>> tell...? > >>>> > >>>> - Rather than saving "mode" in the normalizing iterator, how > about > >>>> saving 2 constants: (0.0, 0.5) for AA and (0.25, 0.25) for > non-AA > >> and > >>>> then simply add those constants in rather than having to have > the > >>>> conditional with the 2 different equations? > >>>> > >>>> ...jim From james.graham at oracle.com Wed Aug 11 21:50:00 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 11 Aug 2010 14:50:00 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <947328609.2166761281537784768.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <947328609.2166761281537784768.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C631B08.2020301@oracle.com> Denis Lila wrote: > Hi Jim. > >> I think the first version is a better choice for now since you said that >> the performance difference isn't noticeable. I think the lower level >> flattening might look a little different if we ever decide to upgrade >> the pipeline to deal with curves. In particular, you are still >> flattening above the dashing/stroking code and I think the flattening >> should be done below that code (i.e. in Renderer). > > Wouldn't we still need to flatten for dashing? Is there some way to > quickly compute the arc length of a bezier curve from t=0 to t=some_number? > As far as I can see the function for this computation is the integral of > sqrt(polynomial_of_degree_4), and that would be pretty nasty. > Or maybe we can get around this somehow? There should be. Google turns up a few hits for "compute arc length for bezier curve" that should be enlightening. BTW, have you looked at a widened dashed curved path with the closed JDK? I'm pretty sure it outputs dashed curves which proves the point. I have also computed these lengths for other projects (the shape morphing used in some JavaOne demos and Java FX) using the following process: - Compute the length of the control polynomial. - Compute the length of the line between the endpoints. - When they are within "epsilon" return the average as the arc length. - Otherwise subdivide and try again. I think you could also do something that looked at the relative angles of all of the control segments and if they are close enough to each other then you can compute the arc length using a simplified equation or simply empirically match this to the "close enough" rule as above. ...jim From lana.steuck at oracle.com Fri Aug 13 05:39:49 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:39:49 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 2 new changesets Message-ID: <20100813053949.6C4854712A@hg.openjdk.java.net> Changeset: f8be576feefc Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/f8be576feefc Added tag jdk7-b103 for changeset be2aedc4e3b1 ! .hgtags Changeset: 9f96a4269d77 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/9f96a4269d77 Added tag jdk7-b104 for changeset f8be576feefc ! .hgtags From lana.steuck at oracle.com Fri Aug 13 05:39:54 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:39:54 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 2 new changesets Message-ID: <20100813053957.CAF864712B@hg.openjdk.java.net> Changeset: 9607213481d4 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/9607213481d4 Added tag jdk7-b103 for changeset 11e7678c3eb1 ! .hgtags Changeset: 6f21b030092f Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/6f21b030092f Added tag jdk7-b104 for changeset 9607213481d4 ! .hgtags From lana.steuck at oracle.com Fri Aug 13 05:44:06 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:44:06 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 2 new changesets Message-ID: <20100813054406.8D45F4712E@hg.openjdk.java.net> Changeset: d42c4acb6424 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/d42c4acb6424 Added tag jdk7-b103 for changeset b7722e878864 ! .hgtags Changeset: 3233b9a4c12e Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/3233b9a4c12e Added tag jdk7-b104 for changeset d42c4acb6424 ! .hgtags From lana.steuck at oracle.com Fri Aug 13 05:44:11 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:44:11 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 2 new changesets Message-ID: <20100813054411.5794B4712F@hg.openjdk.java.net> Changeset: bbc4cce6c20a Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/bbc4cce6c20a Added tag jdk7-b103 for changeset 267386d6b923 ! .hgtags Changeset: 39eb4f3031f4 Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/39eb4f3031f4 Added tag jdk7-b104 for changeset bbc4cce6c20a ! .hgtags From lana.steuck at oracle.com Fri Aug 13 05:45:37 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:45:37 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 44 new changesets Message-ID: <20100813055307.411B947135@hg.openjdk.java.net> Changeset: b839344245a9 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b839344245a9 Added tag jdk7-b103 for changeset 6488b70a23cc ! .hgtags Changeset: 6950da80c75c Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6950da80c75c 6973616: Update minimum boot jdk from 1.5 to 1.6 Reviewed-by: igor, jjg ! make/common/shared/Defs-versions.gmk Changeset: dd48c78218a7 Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dd48c78218a7 6971426: jdk/make/docs docs target does not work on windows Reviewed-by: igor, jjg ! make/docs/Makefile Changeset: f46ec75b1663 Author: ohair Date: 2010-08-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f46ec75b1663 6974239: Correct reference to jdk document site in javadoc Reviewed-by: skannan ! make/docs/Makefile Changeset: 1a92820132a0 Author: cl Date: 2010-08-04 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1a92820132a0 Merge Changeset: d967f8507d9d Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d967f8507d9d Added tag jdk7-b104 for changeset 1a92820132a0 ! .hgtags Changeset: c6f443c3d96a Author: lana Date: 2010-08-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c6f443c3d96a Merge Changeset: c38803ce0560 Author: uta Date: 2010-07-23 18:59 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c38803ce0560 6969851: VM hangs/crashes in FileDialog test (VS2008/2010 build) Reviewed-by: prr, art ! src/windows/native/sun/windows/awt.h Changeset: 9bb8d5c093fc Author: lana Date: 2010-07-29 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9bb8d5c093fc Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 8a72583dc41d Author: lana Date: 2010-08-02 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8a72583dc41d Merge Changeset: 65403b9bcb58 Author: peterz Date: 2010-07-13 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/65403b9bcb58 6462562: InternationalFormatter inserts text incorrectly 6578432: Currency format instance does not work with Swing's NumberFormatter Reviewed-by: rupashka ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/InternationalFormatter.java + test/javax/swing/JFormattedTextField/Test6462562.java Changeset: a0d7b76abcd3 Author: alexp Date: 2010-07-29 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a0d7b76abcd3 4743225: Size of JComboBox list is wrong when list is populated via PopupMenuListener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java + test/javax/swing/JComboBox/4743225/bug4743225.java Changeset: 0e8acbf12695 Author: lana Date: 2010-07-29 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0e8acbf12695 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 951e46d93af0 Author: malenkov Date: 2010-07-30 19:21 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/951e46d93af0 6199676: REGRESSION: ColorChooser loses preview when change LandF in Java5 Reviewed-by: alexp, peterz ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java + test/javax/swing/JColorChooser/Test6199676.java Changeset: f40de306ab66 Author: malenkov Date: 2010-07-30 19:40 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f40de306ab66 6972468: Security manager should be used for tests in java/beans/XMLEncoder Reviewed-by: peterz ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4903007.java ! test/java/beans/XMLEncoder/javax_swing_JLayeredPane.java Changeset: ce1e26600ab7 Author: lana Date: 2010-08-02 19:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ce1e26600ab7 Merge Changeset: 25050030a320 Author: dsamersoff Date: 2010-07-13 15:32 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/25050030a320 6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if java.net.preferIPvStack property set Summary: User can disable ipv6 explicitly, have to check it Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c + test/java/net/NetworkInterface/IPv4Only.java Changeset: f3a4c1947fd1 Author: weijun Date: 2010-07-13 20:27 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f3a4c1947fd1 6670889: Keystore created under Hindi Locale causing ArrayIndexOutOfBoundsException Reviewed-by: chegar ! src/share/classes/sun/security/util/DerOutputStream.java + test/sun/security/util/DerOutputStream/LocaleInTime.java Changeset: ab65f46ae092 Author: darcy Date: 2010-07-15 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ab65f46ae092 6963622: Project Coin: Refinements to suppressed exceptions Reviewed-by: alanb, forax, jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java Changeset: a3747592bdf7 Author: sherman Date: 2010-07-16 16:45 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a3747592bdf7 6964313: Find sun/nio/cs/ext issue with CreateSymbols, then move sun/nio/cs/ext to charset.jar Summary: Removed the duplicate sun.nio.cs.ext entries from rt.jar and moved X11 charsets into charsets.jar Reviewed-by: ohair ! make/common/Release.gmk ! make/sun/nio/cs/Makefile Changeset: 9a1bd20fc71c Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9a1bd20fc71c 6969683: Generify ResolverConfiguration codes Reviewed-by: alanb, chegar ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/sun/net/dns/ResolverConfiguration.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java Changeset: 4022e0c84507 Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4022e0c84507 6969292: make DNS lookup for realm/kdc really work Reviewed-by: alanb, valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: 9d1994d53a67 Author: mullan Date: 2010-07-20 10:41 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9d1994d53a67 6870553: X509Certificate.getSigAlgName method description uses non-standard algorithm name as example Reviewed-by: xuelei ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java Changeset: 58f325ba3e27 Author: chegar Date: 2010-07-21 13:29 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/58f325ba3e27 6969395: TEST_BUG: Tests in java/net sun/net problems Reviewed-by: alanb ! test/ProblemList.txt ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test11.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test6a.java ! test/com/sun/net/httpserver/Test7a.java ! test/com/sun/net/httpserver/Test8a.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/bugs/B6361557.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/java/net/DatagramSocket/DatagramTimeout.java ! test/java/net/DatagramSocket/SendSize.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/SetOutgoingIf.java ! test/java/net/ResponseCache/B6181108.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java - test/java/net/Socket/AccurateTimeout.java ! test/java/net/Socket/CloseAvailable.java ! test/java/net/Socket/DeadlockTest.java ! test/java/net/Socket/LingerTest.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/Socket/ProxyCons.java ! test/java/net/Socket/ReadTimeout.java ! test/java/net/Socket/SetReceiveBufferSize.java ! test/java/net/Socket/SetSoLinger.java ! test/java/net/Socket/ShutdownBoth.java ! test/java/net/Socket/SoTimeout.java ! test/java/net/Socket/Timeout.java ! test/java/net/Socket/UrgentDataTest.java ! test/java/net/Socket/asyncClose/BrokenPipe.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/SocketInputStream/SocketClosedException.java ! test/java/net/SocketInputStream/SocketTimeout.java ! test/java/net/URL/GetContent.java ! test/java/net/URLClassLoader/ClassLoad.java ! test/java/net/URLConnection/DisconnectAfterEOF.java ! test/java/net/URLConnection/HandleContentTypeWithAttrs.java ! test/java/net/URLConnection/HttpContinueStackOverflow.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java ! test/java/net/URLConnection/ResendPostBody.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/net/URLConnection/TimeoutTest.java ! test/java/net/URLConnection/URLConnectionHeaders.java ! test/java/net/URLConnection/ZeroContentLength.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java ! test/sun/net/ftp/FtpGetContent.java ! test/sun/net/ftp/FtpURL.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/HttpClient/MultiThreadTest.java ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java ! test/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java ! test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/protocol/http/DigestTest.java Changeset: f90999d7c404 Author: chegar Date: 2010-07-21 13:52 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f90999d7c404 6970262: TEST_BUG: test/java/net/NetworkInterface/IPv4Only.java has wrong test name in @run tag Reviewed-by: alanb, dsamersoff ! test/java/net/NetworkInterface/IPv4Only.java Changeset: 3902c742b5b1 Author: alanb Date: 2010-07-21 18:08 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3902c742b5b1 6963907: (so) Socket adapter need to implement sendUrgentData Reviewed-by: chegar ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c + test/java/nio/channels/SocketChannel/OutOfBand.java Changeset: d899526a187a Author: dcubed Date: 2010-07-21 16:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d899526a187a 6941287: 4/4 jrunscriptTest.sh test does not work right under Cygwin Summary: Add golden_diff variable for doing proper golden file diffs on Cygwin. Reviewed-by: ohair, dholmes ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh Changeset: 946236dc5c96 Author: dcubed Date: 2010-07-21 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/946236dc5c96 6962804: 4/4 ShellScaffold tests can fail without a specific reason Summary: Add more diagnostics for failures. Only copy target file in grepForString when NL is missing. Reviewed-by: ohair, dholmes ! test/com/sun/jdi/ShellScaffold.sh Changeset: 9cb77130999f Author: dcubed Date: 2010-07-21 17:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9cb77130999f 6964018: 3/4 AnonLoggerWeakRefLeak and LoggerWeakRefLeak can fail in JPRT Summary: Refactor test/sun/tools/common/* code and refactor AnonLoggerWeakRefLeak and LoggerWeakRefLeak to use it. Reviewed-by: ohair, alanb ! test/java/util/logging/AnonLoggerWeakRefLeak.java ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.java ! test/java/util/logging/LoggerWeakRefLeak.sh ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/common/CommonTests.sh ! test/sun/tools/common/ShutdownSimpleApplication.java ! test/sun/tools/common/SimpleApplication.java + test/sun/tools/common/SleeperApplication.java ! test/sun/tools/jhat/ParseTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jstack/Basic.sh Changeset: 748f004aeb5c Author: vinnie Date: 2010-07-23 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/748f004aeb5c 6676075: RegistryContext (com.sun.jndi.url.rmi.rmiURLContext) coding problem Reviewed-by: mullan ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java + test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Changeset: 56217857ccd7 Author: xuelei Date: 2010-07-24 22:59 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/56217857ccd7 6867345: Turkish regional options cause NPE in sun.security.x509.AlgorithmId.algOID Reviewed-by: mullan, weijun ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java + test/sun/security/x509/AlgorithmId/TurkishRegion.java Changeset: 402ff3e81922 Author: weijun Date: 2010-07-26 17:21 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/402ff3e81922 6972005: ConfPlusProp.java test failure when DNS has info for realm Reviewed-by: xuelei ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/confplusprop.conf ! test/sun/security/krb5/confplusprop2.conf Changeset: db21b420d038 Author: martin Date: 2010-07-26 08:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/db21b420d038 6717780: (coll spec) LinkedList api documentation provides the wrong method name Summary: Cleanup by simply making Deque equal status with List Reviewed-by: darcy ! src/share/classes/java/util/LinkedList.java Changeset: 1bfa1c864553 Author: dcubed Date: 2010-07-26 09:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1bfa1c864553 6971847: 4/4 jmap '-histo:live' option is necessary for proper leak detection Summary: Add work around for 6971851. Abort if 'histo:live' option isn't supported. Reviewed-by: alanb, darcy ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 83be262e654c Author: xuelei Date: 2010-07-27 16:07 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/83be262e654c 6870947: 15 sec delay detecting "socket closed" condition when a TCP connection is reset by an LDAP server Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: 5ff8b884a92c Author: vinnie Date: 2010-07-27 11:40 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5ff8b884a92c 6972409: Cease emitting LDAP filter debug messages Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java Changeset: 24741c4bf300 Author: alanb Date: 2010-07-29 13:08 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/24741c4bf300 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated 6799037: (fs) MappedByteBuffer.load crash with unaligned file-mapping (sol) Reviewed-by: chegar, forax ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/windows/native/java/nio/MappedByteBuffer.c ! test/java/nio/MappedByteBuffer/Basic.java + test/java/nio/MappedByteBuffer/Truncate.java Changeset: a8a79f5b669e Author: chegar Date: 2010-07-29 10:02 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a8a79f5b669e 6972374: NetworkInterface.getNetworkInterfaces throws "java.net.SocketException" on Solaris zone Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c Changeset: d82ed433304e Author: chegar Date: 2010-07-29 17:04 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d82ed433304e Merge Changeset: 48e6f4807e5f Author: lana Date: 2010-07-29 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/48e6f4807e5f Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! test/ProblemList.txt Changeset: 4d72d0ec83f5 Author: michaelm Date: 2010-07-30 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4d72d0ec83f5 6510892: com/sun/net/httpserver/bugs/B6361557.java fails Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6361557.java Changeset: 10e7e04d1e96 Author: lana Date: 2010-08-02 19:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/10e7e04d1e96 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 3b0abcb51280 Author: lana Date: 2010-08-09 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3b0abcb51280 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 0576f6cc0463 Author: lana Date: 2010-08-12 19:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0576f6cc0463 Merge - test/java/net/Socket/AccurateTimeout.java From lana.steuck at oracle.com Fri Aug 13 05:54:45 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:54:45 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 24 new changesets Message-ID: <20100813055528.46FF847138@hg.openjdk.java.net> Changeset: fc7219517ec1 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/fc7219517ec1 Added tag jdk7-b103 for changeset bd85271c580c ! .hgtags Changeset: 49489c1d8fae Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/49489c1d8fae Added tag jdk7-b104 for changeset fc7219517ec1 ! .hgtags Changeset: a5454419dd46 Author: jjg Date: 2010-07-13 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a5454419dd46 6966732: replace use of static Log.getLocalizedString with non-static alternative where possible Reviewed-by: darcy ! 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/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: 0e1fab5cffc8 Author: jjg Date: 2010-07-13 19:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0e1fab5cffc8 6968434: test CheckResourceKeys fails on control builds Reviewed-by: darcy ! test/tools/javac/diags/CheckResourceKeys.java Changeset: e57b27703e8b Author: jjg Date: 2010-07-13 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e57b27703e8b 6968789: incorrect text in "diamond not supported" message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: b49b0d72c071 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/b49b0d72c071 6967002: JDK7 b99 javac compilation error (java.lang.AssertionError) Summary: bug in JavacParser related to parsing of type annotations in varargs position Reviewed-by: jjg Contributed-by: mahmood at notnoop.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/typeAnnotations/6967002/T6967002.java + test/tools/javac/typeAnnotations/6967002/T6967002.out Changeset: 472e74211e11 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/472e74211e11 6964669: javac reports error on miranda methods Summary: synthetic name clash check should not apply to miranda methods Reviewed-by: jjg Contributed-by: tomas.zezula at sun.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/miranda/6964669/T6964669.java + test/tools/javac/miranda/6964669/pkg/A.java + test/tools/javac/miranda/6964669/pkg/B.java + test/tools/javac/miranda/6964669/pkg/C.java Changeset: 13354e1abba7 Author: darcy Date: 2010-07-16 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/13354e1abba7 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler 6964740: Project Coin: More tests for ARM compiler changes 6965277: Project Coin: Correctness issues in ARM implementation 6967065: add -Xlint warning category for Automatic Resource Management (ARM) Reviewed-by: jjb, darcy, mcimadamore, jjg, briangoetz Contributed-by: tball at google.com ! make/build.properties ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! 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/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/TryWithResources/ArmLint.java + test/tools/javac/TryWithResources/ArmLint.out + test/tools/javac/TryWithResources/BadTwr.java + test/tools/javac/TryWithResources/BadTwr.out + test/tools/javac/TryWithResources/BadTwrSyntax.java + test/tools/javac/TryWithResources/BadTwrSyntax.out + test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/TryWithResources/ImplicitFinal.java + test/tools/javac/TryWithResources/ImplicitFinal.out + test/tools/javac/TryWithResources/PlainTry.java + test/tools/javac/TryWithResources/PlainTry.out + test/tools/javac/TryWithResources/PlainTry6.out + test/tools/javac/TryWithResources/ResourceOutsideTry.java + test/tools/javac/TryWithResources/ResourceOutsideTry.out + test/tools/javac/TryWithResources/ResourceTypeVar.java + test/tools/javac/TryWithResources/TwrFlow.java + test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/TryWithResources/TwrInference.java + test/tools/javac/TryWithResources/TwrIntersection.java + test/tools/javac/TryWithResources/TwrIntersection02.java + test/tools/javac/TryWithResources/TwrIntersection02.out + test/tools/javac/TryWithResources/TwrMultiCatch.java + test/tools/javac/TryWithResources/TwrOnNonResource.java + test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/TryWithResources/TwrTests.java + test/tools/javac/TryWithResources/WeirdTwr.java + test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: 3640b60bd0f6 Author: jjg Date: 2010-07-22 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/3640b60bd0f6 6968063: provide examples of code that generate diagnostics Reviewed-by: mcimadamore ! make/build.xml + test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/Example.java + test/tools/javac/diags/FileManager.java + test/tools/javac/diags/HTMLWriter.java + test/tools/javac/diags/README.examples.txt + test/tools/javac/diags/RunExamples.java + test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/AbstractCantBeAccessed.java + test/tools/javac/diags/examples/AbstractCantBeInstantiated.java + test/tools/javac/diags/examples/AbstractMethodCantHaveBody.java + test/tools/javac/diags/examples/AlreadyDefined.java + test/tools/javac/diags/examples/AlreadyDefinedImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/diags/examples/AnnoNotApplicable.java + test/tools/javac/diags/examples/AnnoNotValidForType.java + test/tools/javac/diags/examples/AnnoValueMustBeAnnotation.java + test/tools/javac/diags/examples/AnnoValueMustBeClassLiteral.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/AnnosWithoutProcessors.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/processors/AnnoProc.java + test/tools/javac/diags/examples/AnnotationMissingValue.java + test/tools/javac/diags/examples/AnnotationMustBeNameValue.java + test/tools/javac/diags/examples/AnnotationsNotSupported.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoArgs.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoQualForNew.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoTypeArgs.java + test/tools/javac/diags/examples/AnonymousClass.java + test/tools/javac/diags/examples/ArrayAndVarargs.java + test/tools/javac/diags/examples/ArrayDimMissing.java + test/tools/javac/diags/examples/ArrayRequired.java + test/tools/javac/diags/examples/AssertAsIdentifier.java + test/tools/javac/diags/examples/AssertAsIdentifier2.java + test/tools/javac/diags/examples/AttrMustBeConstant.java + test/tools/javac/diags/examples/BadSourceFileHeader/BadSourceFileHeader.java + test/tools/javac/diags/examples/BadSourceFileHeader/sourcepath/p/A.java + test/tools/javac/diags/examples/BreakOutsideSwitchLoop.java + test/tools/javac/diags/examples/CallMustBeFirst.java + test/tools/javac/diags/examples/CannotCreateArrayWithTypeArgs.java + test/tools/javac/diags/examples/CantApplyDiamond.java + test/tools/javac/diags/examples/CantAssignToFinal.java + test/tools/javac/diags/examples/CantDeref.java + test/tools/javac/diags/examples/CantExtendIntfAnno.java + test/tools/javac/diags/examples/CantImplement.java + test/tools/javac/diags/examples/CantInheritDiffArg.java + test/tools/javac/diags/examples/CantRefBeforeConstr.java + test/tools/javac/diags/examples/CantResolve.java + test/tools/javac/diags/examples/CantResolveArgs.java + test/tools/javac/diags/examples/CantResolveArgsParams.java + test/tools/javac/diags/examples/CantResolveLocation.java + test/tools/javac/diags/examples/CantResolveLocationArgs.java + test/tools/javac/diags/examples/CantResolveLocationArgsParams.java + test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/ClashesWith.java + test/tools/javac/diags/examples/ClassCantWrite.java + test/tools/javac/diags/examples/ClassPublicInFile.java + test/tools/javac/diags/examples/ConcreteInheritanceConflict.java + test/tools/javac/diags/examples/ConstExprRequired.java + test/tools/javac/diags/examples/ConstantSVUID.java + test/tools/javac/diags/examples/ContinueOutsideLoop.java + test/tools/javac/diags/examples/CountError.java + test/tools/javac/diags/examples/CountErrorPlural.java + test/tools/javac/diags/examples/CountWarn.java + test/tools/javac/diags/examples/CountWarnPlural.java + test/tools/javac/diags/examples/CyclicAnnoElement.java + test/tools/javac/diags/examples/CyclicInheritance.java + test/tools/javac/diags/examples/DefaultAllowedInIntfAnnotationMember.java + test/tools/javac/diags/examples/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedFilenameAdditional.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPluralAdditional.java + test/tools/javac/diags/examples/DiamondInvalidArg.java + test/tools/javac/diags/examples/DiamondInvalidArgs.java + test/tools/javac/diags/examples/DiamondNotSupported.java + test/tools/javac/diags/examples/DirPathElementNotFound.java + test/tools/javac/diags/examples/DivZero.java + test/tools/javac/diags/examples/DoesNotOverride.java + test/tools/javac/diags/examples/DoesntExist.java + test/tools/javac/diags/examples/DotClassExpected.java + test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationMemberValue.java + test/tools/javac/diags/examples/DuplicateCaseLabel.java + test/tools/javac/diags/examples/DuplicateClass.java + test/tools/javac/diags/examples/DuplicateDefaultLabel.java + test/tools/javac/diags/examples/ElseWithoutIf.java + test/tools/javac/diags/examples/EmptyBytecodeIdent.java + test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/diags/examples/EmptyIf.java + test/tools/javac/diags/examples/EnclClassRequired.java + test/tools/javac/diags/examples/EnumAnnoValueMustBeEnumConst.java + test/tools/javac/diags/examples/EnumAsIdentifier.java + test/tools/javac/diags/examples/EnumAsIdentifier2.java + test/tools/javac/diags/examples/EnumCantBeInstantiated.java + test/tools/javac/diags/examples/EnumConstRequired.java + test/tools/javac/diags/examples/EnumLabelUnqualified.java + test/tools/javac/diags/examples/EnumNoFinalize.java + test/tools/javac/diags/examples/EnumNoSubclassing.java + test/tools/javac/diags/examples/EnumTypesNotExtensible.java + test/tools/javac/diags/examples/EnumsMustBeStatic.java + test/tools/javac/diags/examples/EnumsNotSupported.java + test/tools/javac/diags/examples/ErrProcMessager/ErrProcMessager.java + test/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/ErrSyntheticNameConflict.java + test/tools/javac/diags/examples/Error.java + test/tools/javac/diags/examples/ErrorReadingFile.java + test/tools/javac/diags/examples/ExceptAlreadyCaught.java + test/tools/javac/diags/examples/ExceptNeverThrown.java + test/tools/javac/diags/examples/Expected2.java + test/tools/javac/diags/examples/Expected3.java + test/tools/javac/diags/examples/FinalParamCantBeAssigned.java + test/tools/javac/diags/examples/FinallyCannotComplete.java + test/tools/javac/diags/examples/FinallyWithoutTry.java + test/tools/javac/diags/examples/FloatNumberTooLarge.java + test/tools/javac/diags/examples/FloatNumberTooSmall.java + test/tools/javac/diags/examples/ForeachNotApplicable.java + test/tools/javac/diags/examples/ForeachNotSupported.java + test/tools/javac/diags/examples/GenericArrayCreation.java + test/tools/javac/diags/examples/GenericThrowable.java + test/tools/javac/diags/examples/GenericsNotSupported.java + test/tools/javac/diags/examples/HasBeenDeprecated.java + test/tools/javac/diags/examples/IdentifierExpected.java + test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java + test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/IllegalComboModifiers.java + test/tools/javac/diags/examples/IllegalEnumStaticRef.java + test/tools/javac/diags/examples/IllegalEscapeChar.java + test/tools/javac/diags/examples/IllegalForwardRef.java + test/tools/javac/diags/examples/IllegalInitializer.java + test/tools/javac/diags/examples/IllegalLineEndInCharLit.java + test/tools/javac/diags/examples/IllegalNonAsciiDigit.java + test/tools/javac/diags/examples/IllegalQualNotIcls.java + test/tools/javac/diags/examples/IllegalSelfRef.java + test/tools/javac/diags/examples/IllegalStartOfExpr.java + test/tools/javac/diags/examples/IllegalUnderscore.java + test/tools/javac/diags/examples/IllegalUnicodeEscape.java + test/tools/javac/diags/examples/ImportRequiresCanonical/ImportRequiresCanonical.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/Base.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/ExtendsBase.java + test/tools/javac/diags/examples/ImproperSVUID.java + test/tools/javac/diags/examples/ImproperTypeInnerRawParam.java + test/tools/javac/diags/examples/ImproperTypeParamMissing.java + test/tools/javac/diags/examples/IncomparableTypes.java + test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InconvertibleTypes.java + test/tools/javac/diags/examples/InexactVarargsCall.java + test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InheritFromFinal.java + test/tools/javac/diags/examples/InitializerMustComplete.java + test/tools/javac/diags/examples/InnerClassCantHaveStatic.java + test/tools/javac/diags/examples/IntNumberTooLarge.java + test/tools/javac/diags/examples/InterfaceExpected.java + test/tools/javac/diags/examples/InterfaceNotAllowed.java + test/tools/javac/diags/examples/IntfAnnotationCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfAnnotationMemberClash.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveParams.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfMethodCantHaveBody.java + test/tools/javac/diags/examples/InvalidAnnoMemberType.java + test/tools/javac/diags/examples/InvalidBinaryNumber.java + test/tools/javac/diags/examples/InvalidHexNumber.java + test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/diags/examples/InvalidInstanceof.java + test/tools/javac/diags/examples/InvalidMethodDecl.java + test/tools/javac/diags/examples/KindnameClass.java + test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/KindnameMethod.java + test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/LabelInUse.java + test/tools/javac/diags/examples/LocalEnum.java + test/tools/javac/diags/examples/LocalVarNeedsFinal.java + test/tools/javac/diags/examples/LongSVUID.java + test/tools/javac/diags/examples/MalformedFpLit.java + test/tools/javac/diags/examples/MalformedSupported/MalformedSupported.java + test/tools/javac/diags/examples/MalformedSupported/processors/AnnoProc.java + test/tools/javac/diags/examples/MethodDoesNotOverride.java + test/tools/javac/diags/examples/MightBeAssignedInLoop.java + test/tools/javac/diags/examples/MissingDeprecatedAnnotation.java + test/tools/javac/diags/examples/MissingMethodBody.java + test/tools/javac/diags/examples/MissingReturnStatement.java + test/tools/javac/diags/examples/MissingReturnValue.java + test/tools/javac/diags/examples/MissingSVUID.java + test/tools/javac/diags/examples/ModifierNotAllowed.java + test/tools/javac/diags/examples/MulticatchCantBeAssigned.java + test/tools/javac/diags/examples/MulticatchMustBeFinal.java + test/tools/javac/diags/examples/MulticatchNotSupported.java + test/tools/javac/diags/examples/NameClashSameErasure.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NativeMethodCantHaveBody.java + test/tools/javac/diags/examples/NeitherConditionalSubtype.java + test/tools/javac/diags/examples/NewNotAllowedInAnno.java + test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NoExplicitAnnoProcRequested.java + test/tools/javac/diags/examples/NoInterfaceExpected.java + test/tools/javac/diags/examples/NoInterfaceHere.java + test/tools/javac/diags/examples/NoJavaLang.java + test/tools/javac/diags/examples/NoSuperclass.java + test/tools/javac/diags/examples/NonStaticCantBeRef.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/NotDefAccessClassIntfCantAccess.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/p/C.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/NotDefPublicCantAccess.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/p/C.java + test/tools/javac/diags/examples/NotEnclClass.java + test/tools/javac/diags/examples/NotLoopLabel.java + test/tools/javac/diags/examples/NotWithinBounds.java + test/tools/javac/diags/examples/Note.java + test/tools/javac/diags/examples/NoteProcMessager/NoteProcMessager.java + test/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/Orphaned.java + test/tools/javac/diags/examples/OverrideDoesntThrow.java + test/tools/javac/diags/examples/OverrideIncompatibleReturn.java + test/tools/javac/diags/examples/OverrideMeth.java + test/tools/javac/diags/examples/OverrideStatic.java + test/tools/javac/diags/examples/OverrideUncheckedReturn.java + test/tools/javac/diags/examples/OverrideUncheckedThrown.java + test/tools/javac/diags/examples/OverrideVarargsExtra.java + test/tools/javac/diags/examples/OverrideVarargsMissing.java + test/tools/javac/diags/examples/OverrideWeakerAccess.java + test/tools/javac/diags/examples/PackageAnnos.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/p/package-info.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/package-info.java + test/tools/javac/diags/examples/PathElementNotFound.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q/C.java + test/tools/javac/diags/examples/PossibleFallThrough.java + test/tools/javac/diags/examples/PossibleLossPrecision.java + test/tools/javac/diags/examples/PrematureEOF.java + test/tools/javac/diags/examples/PrintProcessorInfo/PrintProcessorInfo.java + test/tools/javac/diags/examples/PrintProcessorInfo/processors/AnnoProc.java + test/tools/javac/diags/examples/PrintRounds/PrintRounds.java + test/tools/javac/diags/examples/PrintRounds/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcCantFindClass/ProcCantFindClass.java + test/tools/javac/diags/examples/ProcCantFindClass/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcFileReopening/ProcFileReopening.java + test/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIllegalFileName/ProcIllegalFileName.java + test/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/ProcIncompatibleSourceVersion.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcOnlyNoProcs.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/ProcPackageDoesNotExist.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcTypeRecreate/ProcTypeRecreate.java + test/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/ProcUnclosedTypeFiles.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/ProcUseImplicit.java + test/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/ProcUseProcOrImplicit.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/ProcessorCantInstantiate.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcessorNotFound.java + test/tools/javac/diags/examples/ProcessorWrongType/ProcessorWrongType.java + test/tools/javac/diags/examples/ProcessorWrongType/processors/AnnoProc.java + test/tools/javac/diags/examples/QualifiedNewStaticClass.java + test/tools/javac/diags/examples/RawClassUse.java + test/tools/javac/diags/examples/RecursiveConstrInvocation.java + test/tools/javac/diags/examples/RedundantCast.java + test/tools/javac/diags/examples/RefAmbiguous.java + test/tools/javac/diags/examples/RepeatedAnnotationTarget.java + test/tools/javac/diags/examples/RepeatedInterface.java + test/tools/javac/diags/examples/RepeatedModifier.java + test/tools/javac/diags/examples/ReportAccess.java + test/tools/javac/diags/examples/ResourceClosed.java + test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java + test/tools/javac/diags/examples/ResourceNotApplicableToType.java + test/tools/javac/diags/examples/ResourceNotReferenced.java + test/tools/javac/diags/examples/ReturnOutsideMethod.java + test/tools/javac/diags/examples/StaticImportNotSupported.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/Other.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java + test/tools/javac/diags/examples/StaticNotQualifiedByType.java + test/tools/javac/diags/examples/StringConstRequired.java + test/tools/javac/diags/examples/StringSwitchNotSupported.java + test/tools/javac/diags/examples/SunApiFilename.java + test/tools/javac/diags/examples/SunApiFilenameAdditional.java + test/tools/javac/diags/examples/SunApiPlural/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPlural/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPluralAdditional.java + test/tools/javac/diags/examples/SunProprietary.java + test/tools/javac/diags/examples/SuperNotAllowedInEnum.java + test/tools/javac/diags/examples/ThrowsNotAllowedInAnno.java + test/tools/javac/diags/examples/TryResourceNotSupported.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinallyOrResource.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java + test/tools/javac/diags/examples/TypeFoundRequired.java + test/tools/javac/diags/examples/TypeNoParams.java + test/tools/javac/diags/examples/TypeReqClassArray.java + test/tools/javac/diags/examples/TypeReqRef.java + test/tools/javac/diags/examples/TypeVarCantBeDeref.java + test/tools/javac/diags/examples/TypeVarMayNotBeFollowedByOtherBounds.java + test/tools/javac/diags/examples/TypesIncompatible.java + test/tools/javac/diags/examples/UncheckedAssign.java + test/tools/javac/diags/examples/UncheckedAssignToVar.java + test/tools/javac/diags/examples/UncheckedCall.java + test/tools/javac/diags/examples/UncheckedCast.java + test/tools/javac/diags/examples/UncheckedClash.java + test/tools/javac/diags/examples/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedFilenameAdditional.java + test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java + test/tools/javac/diags/examples/UncheckedImplement.java + test/tools/javac/diags/examples/UncheckedMethodInvocation.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedPlural.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename1.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename2.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedPluralAdditional.java + test/tools/javac/diags/examples/UnclosedBytecodeIdent.java + test/tools/javac/diags/examples/UnclosedCharLiteral.java + test/tools/javac/diags/examples/UnclosedComment.java + test/tools/javac/diags/examples/UnclosedStringLiteral.java + test/tools/javac/diags/examples/UndefinedLabel.java + test/tools/javac/diags/examples/UndeterminedType1.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/UnmatchedProcessorOptions.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/processors/AnnoProc.java + test/tools/javac/diags/examples/UnnamedPackage.java + test/tools/javac/diags/examples/UnreachableStatement.java + test/tools/javac/diags/examples/UnreportedException.java + test/tools/javac/diags/examples/UnreportedExceptionDefaultConstructor.java + test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java + test/tools/javac/diags/examples/UnsupportedEncoding.java + test/tools/javac/diags/examples/UnsupportedFpLit.java + test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java + test/tools/javac/diags/examples/VarMightAlreadyBeAssigned.java + test/tools/javac/diags/examples/VarMightNotHaveBeenInitialized.java + test/tools/javac/diags/examples/VarargsClash.java + test/tools/javac/diags/examples/VarargsFilename.java + test/tools/javac/diags/examples/VarargsFilenameAdditional.java + test/tools/javac/diags/examples/VarargsImplement.java + test/tools/javac/diags/examples/VarargsNonReifiableType.java + test/tools/javac/diags/examples/VarargsNotSupported.java + test/tools/javac/diags/examples/VarargsOverride.java + test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java + test/tools/javac/diags/examples/Verbose.java + test/tools/javac/diags/examples/VoidNotAllowed.java + test/tools/javac/diags/examples/WarnForwardRef.java + test/tools/javac/diags/examples/WarnProcMessager/WarnProcMessager.java + test/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/WarnSelfRef.java + test/tools/javac/diags/examples/WarnSyntheticNameConflict.java + test/tools/javac/diags/examples/WarningAndWerror.java + test/tools/javac/diags/examples/WhereCaptured.java + test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereIntersection.java + test/tools/javac/diags/examples/WhereTypeVar.java + test/tools/javac/diags/examples/WrongNumberTypeArgs.java Changeset: 4172cfff05f0 Author: jjg Date: 2010-07-26 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4172cfff05f0 6971882: Remove -XDstdout from javac test Reviewed-by: darcy ! test/tools/javac/4980495/static/Test.java ! test/tools/javac/4980495/std/Test.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6330920/T6330920.java ! test/tools/javac/6491592/T6491592.java ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/CyclicInheritance.java ! test/tools/javac/Digits.java ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendsAccess/ExtendsAccess.java ! test/tools/javac/FloatingPointChanges/BadConstructorModifiers.java ! test/tools/javac/IllegalAnnotation.java ! test/tools/javac/InnerNamedConstant_2.java ! test/tools/javac/InterfaceMemberClassModifiers.java ! test/tools/javac/LocalClasses_2.java ! test/tools/javac/NameCollision.java ! test/tools/javac/NestedInnerClassNames.java ! test/tools/javac/NonStaticFieldExpr1.java ! test/tools/javac/NonStaticFieldExpr2.java ! test/tools/javac/NonStaticFieldExpr3.java ! test/tools/javac/OverridePosition.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_1.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_2.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_3.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.java ! test/tools/javac/StringsInSwitch/NonConstantLabel.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels1.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels2.java ! test/tools/javac/SynchronizedClass.java ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4906100.java ! test/tools/javac/T4994049/T4994049.java ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5024091/T5024091.java ! test/tools/javac/T5048776.java ! test/tools/javac/T6214885.java ! test/tools/javac/T6224167.java ! test/tools/javac/T6227617.java ! test/tools/javac/T6230128.java ! test/tools/javac/T6231847.java ! test/tools/javac/T6241723.java ! test/tools/javac/T6245591.java ! test/tools/javac/T6247324.java ! test/tools/javac/T6394563.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depDocComment/DeprecatedDocComment.java ! test/tools/javac/depDocComment/SuppressDeprecation.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/annotation/Test3.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/depOverrides/doccomment/Test3.java ! test/tools/javac/enum/6384542/T6384542.java ! test/tools/javac/enum/6384542/T6384542a.java ! test/tools/javac/enum/forwardRef/T6425594.java ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/6207386/T6207386.java ! test/tools/javac/generics/6359951/T6359951.java ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/wildcards/6437894/T6437894.java ! test/tools/javac/lint/NoWarn.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/positions/T6253161.java ! test/tools/javac/positions/T6253161a.java ! test/tools/javac/positions/T6264029.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java ! test/tools/javac/rawDiags/Error.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/rawDiags/Warning.java ! test/tools/javac/unicode/UnicodeNewline.java ! test/tools/javac/warnings/Deprecation.java ! test/tools/javac/warnings/DivZero.java ! test/tools/javac/warnings/FallThrough.java ! test/tools/javac/warnings/Unchecked.java Changeset: d1bd93028447 Author: jjg Date: 2010-07-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d1bd93028447 6957438: improve code for generating warning messages containing option names Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! test/tools/javac/diags/examples/CountWarn.java ! test/tools/javac/diags/examples/CountWarnPlural.java ! test/tools/javac/diags/examples/Error.java Changeset: b29160d1b3e0 Author: jjg Date: 2010-07-27 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/b29160d1b3e0 6972327: JCTree.pos incorrect for annotations without modifiers and package Reviewed-by: mcimadamore Contributed-by: jan.lahoda at sun.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T6972327.java Changeset: ed354a00f76b Author: jjg Date: 2010-07-27 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ed354a00f76b 6403456: -Werror should work with annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/werror/WError1.java + test/tools/javac/processing/werror/WError1.out + test/tools/javac/processing/werror/WErrorGen.java + test/tools/javac/processing/werror/WErrorGen.out + test/tools/javac/processing/werror/WErrorLast.java + test/tools/javac/processing/werror/WErrorLast.out Changeset: 36c4ec4525b4 Author: mcimadamore Date: 2010-07-29 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/36c4ec4525b4 6938454: Unable to determine generic type in program that compiles under Java 6 Summary: a redundant dubtyping check causes spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6938454/T6938454a.java + test/tools/javac/generics/inference/6938454/T6938454b.java Changeset: e79e8efe1b3e Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e79e8efe1b3e 6972747: CheckExamples fail when assertions are enabled Summary: The test calls the wrong version of JavacMessage constructor Reviewed-by: jjg ! test/tools/javac/diags/Example.java Changeset: 62f3f07002ea Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/62f3f07002ea 6970833: Try-with-resource implementation throws an NPE during Flow analysis Summary: Updated logic not to rely upon Symbol.implementation (which check in superinterfaces) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/TryWithResources/ResourceInterface.java + test/tools/javac/TryWithResources/ResourceInterface.out Changeset: 4a7979c3ce15 Author: jjg Date: 2010-07-29 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4a7979c3ce15 6972556: warning for using a file name instead of a binary name for Filer.createSourceFile Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ProcSuspiciousClassName/ProcSuspiciousClassName.java + test/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java Changeset: 8a5c98a695ae Author: jjg Date: 2010-07-29 19:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/8a5c98a695ae 6340549: javax.tools.JavaCompilerTool.getStandardFileManager().list() includes directories Reviewed-by: darcy + test/tools/javac/T6340549.java Changeset: 2cf925ad67ab Author: jjg Date: 2010-07-29 19:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2cf925ad67ab 6966604: JavacFiler not correctly notified of lastRound Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ProcFileCreateLastRound/ProcFileCreateLastRound.java + test/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java + test/tools/javac/processing/filer/TestLastRound.java + test/tools/javac/processing/filer/TestLastRound.out ! test/tools/javac/processing/werror/WErrorGen.java Changeset: 077eb94c912d Author: lana Date: 2010-07-29 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/077eb94c912d Merge Changeset: 38e2c23309f1 Author: darcy Date: 2010-08-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/38e2c23309f1 6971877: Project Coin: improve semantics of suppressed exceptions in try-with-resources Reviewed-by: jjb + test/tools/javac/TryWithResources/TwrSuppression.java Changeset: 6318230cdb82 Author: jjg Date: 2010-08-02 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6318230cdb82 6973626: test/tools/javac/processing/* tests fail with assertions enabled Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 186feb2042f0 Author: lana Date: 2010-08-02 19:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/186feb2042f0 Merge Changeset: aaecac256d39 Author: lana Date: 2010-08-09 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/aaecac256d39 Merge From lana.steuck at oracle.com Fri Aug 13 05:42:14 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:42:14 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 20 new changesets Message-ID: <20100813054254.01D874712C@hg.openjdk.java.net> Changeset: efd4401fab1d Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/efd4401fab1d Added tag jdk7-b103 for changeset cb4250ef73b2 ! .hgtags Changeset: e7ec8cd4dd8a Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e7ec8cd4dd8a 6962569: assembler_sparc.cpp:1969: assert(false) failed: error Summary: array_overlap_test() fails when the address range crosses the MSB boundary. Thanks to Tom and Vladimir for their help on this one. Reviewed-by: kvn, never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 4e5661ba9d98 Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4e5661ba9d98 6944166: G1: explicit GCs are not always handled correctly Summary: G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset. Reviewed-by: iveresov, ysr, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! 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/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/runtime/mutexLocker.cpp Changeset: 1a1ce2076047 Author: ysr Date: 2010-07-16 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1a1ce2076047 Merge Changeset: ad7e433e2730 Author: ysr Date: 2010-07-20 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ad7e433e2730 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/runtime/vtune.hpp Changeset: 131ed9a23d48 Author: ysr Date: 2010-07-21 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/131ed9a23d48 Merge Changeset: 083fde3b838e Author: jrose Date: 2010-07-15 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/083fde3b838e 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs. Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 01b172b8cd7c Author: never Date: 2010-07-16 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/01b172b8cd7c Merge Changeset: e0ba4e04c839 Author: jrose Date: 2010-07-16 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e0ba4e04c839 6969574: invokedynamic call sites deoptimize instead of executing Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 7139e81efd2d Author: never Date: 2010-07-22 15:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7139e81efd2d 6970566: runThese fails with SIGSEGV Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp Changeset: 5063ce716349 Author: never Date: 2010-07-23 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5063ce716349 Merge Changeset: a93a9eda13f7 Author: jcoomes Date: 2010-07-16 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a93a9eda13f7 6962947: shared TaskQueue statistics Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.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/psTasks.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 5cbac8938c4c Author: johnc Date: 2010-07-19 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5cbac8938c4c 6956639: G1: assert(cached_ptr != card_ptr) failed: shouldn't be, concurrentG1Refine.cpp:307 Summary: During concurrent refinment, filter cards in young regions after it has been determined that the region has been allocated from and the young type of the region has been set. Reviewed-by: iveresov, tonyp, jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 4f1fffe08c63 Author: ysr Date: 2010-07-21 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4f1fffe08c63 Merge Changeset: 1890dc9151da Author: ysr Date: 2010-07-23 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1890dc9151da Merge Changeset: cc3fdfeb54b0 Author: trims Date: 2010-07-29 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/cc3fdfeb54b0 Merge Changeset: fd2645290e89 Author: trims Date: 2010-07-30 06:56 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fd2645290e89 6973381: Bump the HS19 build number to 05 Summary: Update the HS19 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 28abe3f6a5f6 Author: trims Date: 2010-08-03 19:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/28abe3f6a5f6 Merge Changeset: b4acf10eb134 Author: trims Date: 2010-08-05 02:48 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b4acf10eb134 Added tag hs19-b04 for changeset e55900b5c1b8 ! .hgtags Changeset: 6709c14587c2 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6709c14587c2 Added tag jdk7-b104 for changeset b4acf10eb134 ! .hgtags From linuxhippy at gmail.com Mon Aug 16 15:51:41 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 16 Aug 2010 17:51:41 +0200 Subject: [OpenJDK 2D-Dev] CR 6974985 Redispatched, P3 java/classes_2d Jave2Demo threw exceptions when xrender enabled in OEL5.5 In-Reply-To: References: <4C5CA334.2090400@oracle.com> Message-ID: Hi Phil, I was able to get rid of the problem by avoiding double-freeing Pictures, but I am not sure if it was really the cause or it just hides the symthoms. Setting sun.awt.noisyerrorhandler I got reports about invalid picture parameters passed to XRenderFreePicture(), and there are only two locations where I call these methods: - In X11SurfaceData dispose() - In XRenderBackendNative freePicture() when called by the pipeline itself. When I set xrPic = None in X11SurfaceData.dispose() to avoid double-frees I don't get any XErrors anymore: if(xsdo->xrPic != None) { XRenderFreePicture(awt_display, xsdo->xrPic); xsdo->xrPic = None; // Free pictures only once } However I added some debug code which really confuses me (without the "Free pictures only once"-line, running Java2Demo). Actually there was not a single case where dispose() was called twice, so I don't have an explanation why setting xrPic=None changes things. *1. This picture is created, and freed only once - and still I get an XError:* picture 52000aa created picture 52000aa freed in dispose Xerror RenderBadPicture (invalid Picture parameter), XID 52000aa, ser# 1836 - Major opcode 147 (Unknown) - Minor opcode 7 *2. This picture has no X11SDOps, it was created by the pipeline itself for pipeline-internal use:* Xerror RenderBadPicture (invalid Picture parameter), XID 52000b8, ser# 5069- Major opcode 147 (Unknown) - Minor opcode 7 ..... picture 52001b8 freed in freePicture So the double-free check doesn't change anything here, still with the check in X11SurfaceData.dispose() I don't get any errors. * 3. This picture was never freed, but I get a BadPicture for a Free Request:* picture 52001dc created Xerror RenderBadPicture (invalid Picture parameter), XID 52001dc, ser# 37176 - Major opcode 147 (Unknown) - Minor opcode 7 Do you have any idea whats going on here? Or why those XErrors could have influenced setting the DND property? Could it be that xcb's error reporting struggles with multiple threads? Thanks, Clemens -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulli at netcorner.org Mon Aug 23 15:48:54 2010 From: ulli at netcorner.org (Thorsten Jungblut) Date: Mon, 23 Aug 2010 17:48:54 +0200 (CEST) Subject: [OpenJDK 2D-Dev] Concurrent execution of SunLayoutEngine.getEngine(..) may cause corrupt HashMap Message-ID: Hi, if java.awt.font.TextLayout is used concurrently within multiple threads, threads can become stuck in an endless loop caused by a corrupt HashMap. This problem seems to caused by calls to sun.font.SunLayoutEngine.getEngine(LayoutEngineKey key) during initilization of TextLayout at java.awt.font.TextLayout(String string, Font font, FontRenderContext frc) SunLayoutEngine.getEngine(LayoutEngineKey) accesses a SoftReference and a HashMap without proper synchronisation. This may lead to the HashMap being corrupted. Any subsequent call to this method causes an endless loop. Imho the problem is solved by synchronize access to the used SoftReference and HashMap. I created a patch (using latest OpenJDK7 sources from mercurial): diff -r fd28003bc1d6 src/share/classes/sun/font/SunLayoutEngine.java --- a/src/share/classes/sun/font/SunLayoutEngine.java Mon Aug 23 14:35:22 2010 +0100 +++ b/src/share/classes/sun/font/SunLayoutEngine.java Mon Aug 23 17:38:59 2010 +0200 @@ -128,7 +128,7 @@ } // !!! don't need this unless we have more than one sun layout engine... - public LayoutEngine getEngine(LayoutEngineKey key) { + public synchronized LayoutEngine getEngine(LayoutEngineKey key) { HashMap cache = (HashMap)cacheref.get(); if (cache == null) { cache = new HashMap(); This will cause access to the hole method to be synchronized so that neither 'cache' nor 'cacheref' are accessed concurrently and so nothing can get corrupted. Any comments are welcome. Best regards Thorsten From dlila at redhat.com Mon Aug 23 23:18:37 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 23 Aug 2010 19:18:37 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1518357418.3084571282605284912.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1952577154.3084621282605517278.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello. So, I've been working on removing flattening from pisces (except for AA). The following compiles and sort of works: http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ The changes to the AA renderer are small, and for dashing I used the algorithm in your last e-mail. That has worked well so far. Actually, dashing is a bit more complicated, since that algorithm computes the arc length given the parameter t. For dashing we needed the inverse of this function. Nevertheless, I found something and dashing seems to work. For now I would like someone to take a look at just Stroker. 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. Thanks, Denis. ----- "Jim Graham" wrote: > Denis Lila wrote: > > Hi Jim. > > > >> I think the first version is a better choice for now since you said > that > >> the performance difference isn't noticeable. I think the lower > level > >> flattening might look a little different if we ever decide to > upgrade > >> the pipeline to deal with curves. In particular, you are still > >> flattening above the dashing/stroking code and I think the > flattening > >> should be done below that code (i.e. in Renderer). > > > > Wouldn't we still need to flatten for dashing? Is there some way > to > > quickly compute the arc length of a bezier curve from t=0 to > t=some_number? > > As far as I can see the function for this computation is the > integral of > > sqrt(polynomial_of_degree_4), and that would be pretty nasty. > > Or maybe we can get around this somehow? > > There should be. Google turns up a few hits for "compute arc length > for > bezier curve" that should be enlightening. > > BTW, have you looked at a widened dashed curved path with the closed > JDK? I'm pretty sure it outputs dashed curves which proves the > point. > > I have also computed these lengths for other projects (the shape > morphing used in some JavaOne demos and Java FX) using the following > process: > > - Compute the length of the control polynomial. > - Compute the length of the line between the endpoints. > - When they are within "epsilon" return the average as the arc > length. > - Otherwise subdivide and try again. > > I think you could also do something that looked at the relative angles > > of all of the control segments and if they are close enough to each > other then you can compute the arc length using a simplified equation > or > simply empirically match this to the "close enough" rule as above. > > ...jim From dlila at redhat.com Tue Aug 24 10:26:49 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 24 Aug 2010 06:26:49 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <672227012.3104261282645579089.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1398307037.3104281282645609057.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello again. > 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. I implemented another version that detects where either dx/dt or dy/dt is 0, and splits the curve there. This works pretty well for all the curves I've tested (except ones containing "cusps", or something close to a cusp, like p.moveTo(0,0); p.curveTo(100,100,0,100,100,0);). Best of all, this: > For example, the curve p.moveTo(0,0),p.curveTo(84.0, 62.0, 32.0, 34.0, 28.0, 5.0) is no longer a problem. There is another problem with this method (other than the cusps, which can probably be handled easily as a special case): it is axis-dependent. Ideally, it shouldn't be because the optimal subdivisions of a curve are at values of t that do not change under rotations and translations, but with this method, the t values at which I split the curve do change. A better way would take into account curve flatness instead of changes in x or y direction. Thanks, Denis. From james.graham at oracle.com Tue Aug 24 22:35:34 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Aug 2010 15:35:34 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1952577154.3084621282605517278.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1952577154.3084621282605517278.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C744936.9070405@oracle.com> 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. 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. 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 Tue Aug 24 22:52:20 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Aug 2010 15:52:20 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4C744936.9070405@oracle.com> References: <1952577154.3084621282605517278.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4C744936.9070405@oracle.com> Message-ID: <4C744D24.8060301@oracle.com> Hi Denis, On 8/24/2010 3:35 PM, Jim Graham wrote: > 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 Just to provide a basic overview... You can iterate a line with a constant delta-T using: x += dx; y += dy; Similarly, you can iterate a quad curve with a constant delta-T using: dx += ddx; x += dx; dy += ddy; y += dy; and a cubic using: ddx += dddx; dx += ddx; x += dx; ddy += dddy; dy += ddy; y += dy; There are then techniques to apply to evaluate the dd[d]x and dd[d]y to see if the curve is "flat enough" for your particular needs. If it isn't flat enough, then some simple math performed on the d* variables can double or halve the sampling rate for a localized portion of the curve. Once you pass the curvy section, you can then reduce the sampling rate again by examining the d* variables. Done right, this could probably be integrated at the innermost loop of the renderer to reduce its storage requirements for curves, but that would mean the inner loop would have to switch on the curve type to determine which sampling equations apply (though you could simply have quads have ddd[xy] = 0 and lines have dd[d][xy] = 0 and use a single set of code perhaps without too much performance impact). Otherwise, this could simply be used to flatten and produce edges with less intermediate storage (and faster hopefully)... ...jim From dalibor.topic at oracle.com Wed Aug 25 13:57:48 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 25 Aug 2010 15:57:48 +0200 Subject: [OpenJDK 2D-Dev] Concurrent execution of SunLayoutEngine.getEngine(..) may cause corrupt HashMap In-Reply-To: References: Message-ID: <4C75215C.8020706@oracle.com> On 8/23/10 5:48 PM, Thorsten Jungblut wrote: > I created a patch (using latest OpenJDK7 sources from mercurial): Hi Thorsten, I couldn't find your name on the SCA signatories list. Please see http://openjdk.java.net/contribute/, in particular step 0. In order to avoid having your patch get lost in mail meanwhile, please file it in the OpenJDK bugzilla at bugs.openjdk.java.net. Thanks! cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dlila at redhat.com Wed Aug 25 21:36:47 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 25 Aug 2010 17:36:47 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <677906335.3446671282771712293.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1942447815.3447401282772207430.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> 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" 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 Wed Aug 25 23:49:15 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 25 Aug 2010 16:49:15 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1942447815.3447401282772207430.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1942447815.3447401282772207430.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C75ABFB.7040804@oracle.com> 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. 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. 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. 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... ...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" 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 philip.race at oracle.com Thu Aug 26 21:18:49 2010 From: philip.race at oracle.com (Phil Race) Date: Thu, 26 Aug 2010 14:18:49 -0700 Subject: [OpenJDK 2D-Dev] CR 6974985 Redispatched, P3 java/classes_2d Jave2Demo threw exceptions when xrender enabled in OEL5.5 In-Reply-To: References: <4C5CA334.2090400@oracle.com> Message-ID: <4C76DA39.8080500@oracle.com> Been on vacation ... just catching up .. So my reading of your debugging is that you have instrumented all the locations you call XRenderCreatePicture and XRenderFreePicture so you can track these .. although I don't see (2) logging that creation. Looking at (3) the alternatives that come to mind are : - as you suggest the error reporting is questionable - XRenderCreatePicture looks like it succeeded but didn't - some code stomped on the Picture's client-side memory - some other code is doing X11 protocol on another thread without the lock Its not at all clear which it is from the evidence but since XRenderCreatePicture is aysnchronous you may not find out that it didn't work until later. How about inserting a call to XSynchronize(True) so which may give you a more timely errors. Or maybe run your Xserver in sync mode "X --sync ..." but that'll make everything painfully slow. -phil. On 8/16/2010 8:51 AM, Clemens Eisserer wrote: > Hi Phil, > > I was able to get rid of the problem by avoiding double-freeing > Pictures, but I am not sure if it was really the cause or it just > hides the symthoms. > > Setting sun.awt.noisyerrorhandler I got reports about invalid picture > parameters passed to XRenderFreePicture(), and there are only two > locations where I call these methods: > - In X11SurfaceData dispose() > - In XRenderBackendNative freePicture() when called by the pipeline > itself. > > > When I set xrPic = None in X11SurfaceData.dispose() to avoid > double-frees I don't get any XErrors anymore: > if(xsdo->xrPic != None) { > XRenderFreePicture(awt_display, xsdo->xrPic); > xsdo->xrPic = None; // Free pictures only once > } > > > However I added some debug code which really confuses me (without the > "Free pictures only once"-line, running Java2Demo). > Actually there was not a single case where dispose() was called twice, > so I don't have an explanation why setting xrPic=None changes things. > > *1. This picture is created, and freed only once - and still I get an > XError:* > picture 52000aa created > picture 52000aa freed in dispose > Xerror RenderBadPicture (invalid Picture parameter), XID 52000aa, > ser# 1836 - Major opcode 147 (Unknown) - Minor opcode 7 > > > *2. This picture has no X11SDOps, it was created by the pipeline > itself for pipeline-internal use:* > Xerror RenderBadPicture (invalid Picture parameter), XID 52000b8, > ser# 5069- Major opcode 147 (Unknown) - Minor opcode 7 > ..... > picture 52001b8 freed in freePicture > > So the double-free check doesn't change anything here, still with the > check in X11SurfaceData.dispose() I don't get any errors. > * > 3. This picture was never freed, but I get a BadPicture for a Free > Request:* > picture 52001dc created > Xerror RenderBadPicture (invalid Picture parameter), XID 52001dc, ser# > 37176 - Major opcode 147 (Unknown) - Minor opcode 7 > > > Do you have any idea whats going on here? Or why those XErrors could > have influenced setting the DND property? > Could it be that xcb's error reporting struggles with multiple threads? > > Thanks, Clemens -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Fri Aug 27 20:07:10 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 27 Aug 2010 22:07:10 +0200 Subject: [OpenJDK 2D-Dev] CR 6974985 Redispatched, P3 java/classes_2d Jave2Demo threw exceptions when xrender enabled in OEL5.5 In-Reply-To: <4C76DA39.8080500@oracle.com> References: <4C5CA334.2090400@oracle.com> <4C76DA39.8080500@oracle.com> Message-ID: Hi Phil, The root of all those Errors seems to be that on XDetroyWindow all Pictures associated with that Window are freed automatically, however the same is not true for Pixmaps. So I may only call XRenderFreePicture for Pixmaps, because it seems X11SurfaceData.dispose is called after XDestroyWindow. However I would like to make sure first this is really the intended behaviour, it seems quite strange and inconsistent to me and I don't want to depend on it if possible. I don't know how those XErrors can cause the DnD exception, but when I comment the XRenderFreePicture call, I don't get the DnD exception anymore. > Looking at (3) the alternatives that come to mind are : > - as you suggest the error reporting is questionable Yes, the XID reported is bogous, no idea why. Its even there in the XEventError structure passed to Java's custom error handler, even in synchrnous mode. > - some other code is doing X11 protocol on another thread without the lock I went over all sections and didn't find anything. Thanks, Clemens From linuxhippy at gmail.com Fri Aug 27 20:25:59 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 27 Aug 2010 22:25:59 +0200 Subject: [OpenJDK 2D-Dev] Another Xrender bug .. In-Reply-To: <4C76F39D.7020206@oracle.com> References: <4C76F39D.7020206@oracle.com> Message-ID: Hi again, > ?Any thoughts on this one that just got submitted a few minutes ago? > I'm guessing you don't have a SPARC System with OpenSolaris handy > so I'm just asking for ideas here. The only thing I can think of is the copy code which copies/converts the GlyphInfo image-data into the stream submitted to X, in XRGlyphCacheEntry.writePixelData(). I guess the pixel-data I get from the GlyphInfo structure is the same, maybe access using Unsafe is somehow broken or shifted by a byte? For now I assume a fixed oder when uploading the glyph-data (didn't find any docs about it), could it be different on that machine? Thanks, Clemens > -phil. > > *Change Request ID*: 6980378 > *Synopsis*: LCD subpixel text has yellow background with Xrender enabled in > jdk1.7.0-ea-b106 on SPARC. > > === *Description* > ============================================================ > Java Version: 1.7.0-ea-b106 > Platform: OpenSolaris 5.11 snv_146 > > Problems: > When launch Java2Demo/SwingSet2 with Xrender=True or true in b106, you can > see all letters or fonts are marked with yellow color or yellow background, > but disable xrender, it looks normal, no yellow background, please see > attached files for xrender enabled and disabled screen shots for details. > > File this bug to make sure that this is not a problem caused by xrender > enabled. > > It can be reproducible as alway by the following command: > bin/java -jar -Dsun.java2d.xrender=True demo/jfc/Java2D/*.jar > > We have a OpenSolaris 5.11 snv_146 newly installed in lab, the host name is > listed in comments if you want to reproduce it. > > The framebuffer in the machine is XVR-100. > > *** (#1 of 1): 2010-08-26 21:55:21 GMT+00:00 tao.t.zhang at oracle.com > *** Last Edit: 2010-08-26 22:46:10 GMT+00:00 tao.t.zhang at oracle.com > > === *Evaluation* > ============================================================= > The background that is yellow follows the rectangular shape of the > individual glyphs. Otherwise everything appears correct. > Seeing this only on SPARC. At this time there's only one system > here with the right hardware/software combination to run XRender > on SPARC so it could be an Xserver side problem. > > Its not been seen on Solaris on Intel and it also doesn't occur > on software buffered images, only on XRender surfaces. > > > From ahughes at redhat.com Fri Aug 27 20:43:07 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 27 Aug 2010 21:43:07 +0100 Subject: [OpenJDK 2D-Dev] Another Xrender bug .. In-Reply-To: References: <4C76F39D.7020206@oracle.com> Message-ID: On 27 August 2010 21:25, Clemens Eisserer wrote: > Hi again, > >> ?Any thoughts on this one that just got submitted a few minutes ago? >> I'm guessing you don't have a SPARC System with OpenSolaris handy >> so I'm just asking for ideas here. > > The only thing I can think of is the copy code which copies/converts > the GlyphInfo image-data into the stream submitted to X, in > XRGlyphCacheEntry.writePixelData(). > > I guess the pixel-data I get from the GlyphInfo structure is the same, > maybe access using Unsafe is somehow broken or shifted by a byte? > For now I assume a fixed oder when uploading the glyph-data (didn't > find any docs about it), could it be different on that machine? > FWIW, SPARCs are big-endian. Specifically, 'The 32-bit SPARC V8 architecture is purely big-endian. The 64-bit SPARC V9 architecture utilizes big-endian instructions, but can access data in either big-endian or little-endian byte order, chosen either at the application instruction (load/store) level or at the memory page level (via an MMU setting). The latter is often used for accessing data from inherently little-endian devices, such as those on PCI buses.' -- http://en.wikipedia.org/wiki/SPARC > Thanks, Clemens > > >> -phil. >> >> *Change Request ID*: 6980378 >> *Synopsis*: LCD subpixel text has yellow background with Xrender enabled in >> jdk1.7.0-ea-b106 on SPARC. >> >> === *Description* >> ============================================================ >> Java Version: 1.7.0-ea-b106 >> Platform: OpenSolaris 5.11 snv_146 >> >> Problems: >> When launch Java2Demo/SwingSet2 with Xrender=True or true in b106, you can >> see all letters or fonts are marked with yellow color or yellow background, >> but disable xrender, it looks normal, no yellow background, please see >> attached files for xrender enabled and disabled screen shots for details. >> >> File this bug to make sure that this is not a problem caused by xrender >> enabled. >> >> It can be reproducible as alway by the following command: >> bin/java -jar -Dsun.java2d.xrender=True demo/jfc/Java2D/*.jar >> >> We have a OpenSolaris 5.11 snv_146 newly installed in lab, the host name is >> listed in comments if you want to reproduce it. >> >> The framebuffer in the machine is XVR-100. >> >> *** (#1 of 1): 2010-08-26 21:55:21 GMT+00:00 tao.t.zhang at oracle.com >> *** Last Edit: 2010-08-26 22:46:10 GMT+00:00 tao.t.zhang at oracle.com >> >> === *Evaluation* >> ============================================================= >> The background that is yellow follows the rectangular shape of the >> individual glyphs. Otherwise everything appears correct. >> Seeing this only on SPARC. At this time there's only one system >> here with the right hardware/software combination to run XRender >> on SPARC so it could be an Xserver side problem. >> >> Its not been seen on Solaris on Intel and it also doesn't occur >> on software buffered images, only on XRender surfaces. >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA? 7927 142C 2591 94EF D9D8 From philip.race at oracle.com Fri Aug 27 23:32:48 2010 From: philip.race at oracle.com (Phil Race) Date: Fri, 27 Aug 2010 16:32:48 -0700 Subject: [OpenJDK 2D-Dev] Another Xrender bug .. In-Reply-To: References: <4C76F39D.7020206@oracle.com> Message-ID: <4C784B20.4070702@oracle.com> Whilst SPARC is big-endian the glyph image data is all accessed as bytes so I don't think that can be the problem. But it could be the image format isn't right. Like ARGB is being used and the server expects RGB ? -phil. On 8/27/2010 1:43 PM, Dr Andrew John Hughes wrote: > On 27 August 2010 21:25, Clemens Eisserer wrote: >> Hi again, >> >>> Any thoughts on this one that just got submitted a few minutes ago? >>> I'm guessing you don't have a SPARC System with OpenSolaris handy >>> so I'm just asking for ideas here. >> The only thing I can think of is the copy code which copies/converts >> the GlyphInfo image-data into the stream submitted to X, in >> XRGlyphCacheEntry.writePixelData(). >> >> I guess the pixel-data I get from the GlyphInfo structure is the same, >> maybe access using Unsafe is somehow broken or shifted by a byte? >> For now I assume a fixed oder when uploading the glyph-data (didn't >> find any docs about it), could it be different on that machine? >> > FWIW, SPARCs are big-endian. Specifically, > > 'The 32-bit SPARC V8 architecture is purely big-endian. The 64-bit > SPARC V9 architecture utilizes big-endian instructions, but can access > data in either big-endian or little-endian byte order, chosen either > at the application instruction (load/store) level or at the memory > page level (via an MMU setting). The latter is often used for > accessing data from inherently little-endian devices, such as those on > PCI buses.' -- http://en.wikipedia.org/wiki/SPARC > >> Thanks, Clemens >> >> >>> -phil. >>> >>> *Change Request ID*: 6980378 >>> *Synopsis*: LCD subpixel text has yellow background with Xrender enabled in >>> jdk1.7.0-ea-b106 on SPARC. >>> >>> === *Description* >>> ============================================================ >>> Java Version: 1.7.0-ea-b106 >>> Platform: OpenSolaris 5.11 snv_146 >>> >>> Problems: >>> When launch Java2Demo/SwingSet2 with Xrender=True or true in b106, you can >>> see all letters or fonts are marked with yellow color or yellow background, >>> but disable xrender, it looks normal, no yellow background, please see >>> attached files for xrender enabled and disabled screen shots for details. >>> >>> File this bug to make sure that this is not a problem caused by xrender >>> enabled. >>> >>> It can be reproducible as alway by the following command: >>> bin/java -jar -Dsun.java2d.xrender=True demo/jfc/Java2D/*.jar >>> >>> We have a OpenSolaris 5.11 snv_146 newly installed in lab, the host name is >>> listed in comments if you want to reproduce it. >>> >>> The framebuffer in the machine is XVR-100. >>> >>> *** (#1 of 1): 2010-08-26 21:55:21 GMT+00:00 tao.t.zhang at oracle.com >>> *** Last Edit: 2010-08-26 22:46:10 GMT+00:00 tao.t.zhang at oracle.com >>> >>> === *Evaluation* >>> ============================================================= >>> The background that is yellow follows the rectangular shape of the >>> individual glyphs. Otherwise everything appears correct. >>> Seeing this only on SPARC. At this time there's only one system >>> here with the right hardware/software combination to run XRender >>> on SPARC so it could be an Xserver side problem. >>> >>> Its not been seen on Solaris on Intel and it also doesn't occur >>> on software buffered images, only on XRender surfaces. >>> >>> >>> > > From linuxhippy at gmail.com Mon Aug 30 08:11:50 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 30 Aug 2010 10:11:50 +0200 Subject: [OpenJDK 2D-Dev] CR 6974985 Redispatched, P3 java/classes_2d Jave2Demo threw exceptions when xrender enabled in OEL5.5 In-Reply-To: References: <4C5CA334.2090400@oracle.com> <4C76DA39.8080500@oracle.com> Message-ID: Hello again, I got confirmation that indeed Pictures are automatically freed on XWindowDestroy but not so for XFreePixmap. The best solution would be to call XrenderFreePicture before calling XDestroyWindows, however unlike pixmaps, windows aren't destroyed in the dispose-code - so this probably would require some refactoring. Do you know why windows are destroyed immediatly, instead of just beeing unmapped and destroyed by the dispose-code? The ugly/easy solution would be to check wether the drawable was a pixmap, and only then free the pictures associated with it. However this relies on an implementation detail of the XOrg implementation. Thanks, Clemens From dlila at redhat.com Mon Aug 30 22:03:23 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 30 Aug 2010 18:03:23 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <2069290062.3780291283205706762.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1668885088.3780321283205803039.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> 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" 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" 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 Tue Aug 31 11:32:06 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 31 Aug 2010 04:32:06 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1668885088.3780321283205803039.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1668885088.3780321283205803039.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4C7CE836.7090200@oracle.com> 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" 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" 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 Tue Aug 31 22:13:58 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 31 Aug 2010 18:13:58 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1998355219.3886111283292430972.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <979263116.3886571283292838724.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> 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. 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. Very well. I've convinced myself. I'll implement the latter. Thanks, Denis. ----- "Jim Graham" 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" 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" 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Stroker.java Type: text/x-java Size: 41611 bytes Desc: not available URL: