From andrew.brygin at sun.com Mon Oct 4 06:20:24 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Mon, 04 Oct 2010 06:20:24 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6988213: lcms build failure on windows-amd64 Message-ID: <20101004062109.DBB9D47EBA@hg.openjdk.java.net> Changeset: 160f7ffc3d14 Author: bae Date: 2010-10-02 12:41 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/160f7ffc3d14 6988213: lcms build failure on windows-amd64 Reviewed-by: igor, prr ! make/sun/cmm/lcms/Makefile From ptisnovs at redhat.com Mon Oct 4 11:14:36 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 04 Oct 2010 13:14:36 +0200 Subject: [OpenJDK 2D-Dev] [Fwd: Need reviewer for change in freetypeScaler.c] Message-ID: <4CA9B71C.4070503@redhat.com> Hi, can someone please review a patch (see attachment) which I posted about two weeks before? This mail was probably lost due to JavaOne ;-) Thank you in advance Pavel -------------- next part -------------- An embedded message was scrubbed... From: Pavel Tisnovsky Subject: [OpenJDK 2D-Dev] Need reviewer for change in freetypeScaler.c Date: Thu, 16 Sep 2010 18:31:27 +0200 Size: 4228 URL: From philip.race at oracle.com Mon Oct 4 17:47:00 2010 From: philip.race at oracle.com (Phil Race) Date: Mon, 04 Oct 2010 10:47:00 -0700 Subject: [OpenJDK 2D-Dev] [Fwd: Need reviewer for change in freetypeScaler.c] In-Reply-To: <4CA9B71C.4070503@redhat.com> References: <4CA9B71C.4070503@redhat.com> Message-ID: <4CAA1314.6080704@oracle.com> Whilst the fix looks reasonable I'm a bit confused since you say the referenced regression test for 6703377 fails and yet it passes for me on a 6open build .. which is what I'd hoped would happen for a test specifically designed to test that bug. Note that this fix would need to be pushed under a new bug id, and either the regression test would need to be updated to reference the new bug (in addition to the old one), or if it can't reproduce the problem, you'd need to update it or provide a new one. -phil. On 10/4/2010 4:14 AM, Pavel Tisnovsky wrote: > Hi, > > can someone please review a patch (see attachment) which I posted about > two weeks before? This mail was probably lost due to JavaOne ;-) > > Thank you in advance > Pavel From andrew.brygin at sun.com Tue Oct 5 06:46:44 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Tue, 05 Oct 2010 06:46:44 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6976076: sun/java2d/pipe/MutableColorTest/MutableColorTest.java failed Message-ID: <20101005064705.2392D47EF8@hg.openjdk.java.net> Changeset: b96e6b8761bc Author: bae Date: 2010-10-05 10:23 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b96e6b8761bc 6976076: sun/java2d/pipe/MutableColorTest/MutableColorTest.java failed Reviewed-by: igor, prr ! test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java From ptisnovs at redhat.com Tue Oct 5 09:33:54 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 05 Oct 2010 11:33:54 +0200 Subject: [OpenJDK 2D-Dev] [Fwd: Need reviewer for change in freetypeScaler.c] In-Reply-To: <4CAA1314.6080704@oracle.com> References: <4CA9B71C.4070503@redhat.com> <4CAA1314.6080704@oracle.com> Message-ID: <4CAAF102.1080806@redhat.com> Phil Race wrote: > > Whilst the fix looks reasonable I'm a bit confused since you say the > referenced regression test for > 6703377 fails and yet it passes for me on a 6open build .. which is what > I'd hoped would happen > for a test specifically designed to test that bug. Hi Phil, thank you very much for your comments. I'm going to create regression test targeted only to this issue based on java/awt/Graphics2D/DrawString/RotTransText.java. Could you please create a new bug id for this issue or do I have to create reg.test first? Pavel > > Note that this fix would need to be pushed under a new bug id, and > either the regression test > would need to be updated to reference the new bug (in addition to the > old one), or if it can't > reproduce the problem, you'd need to update it or provide a new one. > > -phil. > > On 10/4/2010 4:14 AM, Pavel Tisnovsky wrote: >> Hi, >> >> can someone please review a patch (see attachment) which I posted about >> two weeks before? This mail was probably lost due to JavaOne ;-) >> >> Thank you in advance >> Pavel > From philip.race at oracle.com Tue Oct 5 16:26:11 2010 From: philip.race at oracle.com (Phil Race) Date: Tue, 05 Oct 2010 09:26:11 -0700 Subject: [OpenJDK 2D-Dev] [Fwd: Need reviewer for change in freetypeScaler.c] In-Reply-To: <4CAAF102.1080806@redhat.com> References: <4CA9B71C.4070503@redhat.com> <4CAA1314.6080704@oracle.com> <4CAAF102.1080806@redhat.com> Message-ID: <4CAB51A3.3000508@oracle.com> It might be best if you provided the regression test first as pasting that into the bug description as the test case there would make it more apparent what the user impact is. Then the evaluation will be what you found as the cause. -phil. On 10/5/2010 2:33 AM, Pavel Tisnovsky wrote: > Phil Race wrote: >> Whilst the fix looks reasonable I'm a bit confused since you say the >> referenced regression test for >> 6703377 fails and yet it passes for me on a 6open build .. which is what >> I'd hoped would happen >> for a test specifically designed to test that bug. > Hi Phil, > > thank you very much for your comments. I'm going to create regression > test targeted only to this issue based on > java/awt/Graphics2D/DrawString/RotTransText.java. > > Could you please create a new bug id for this issue or do I have to > create reg.test first? > > Pavel > >> Note that this fix would need to be pushed under a new bug id, and >> either the regression test >> would need to be updated to reference the new bug (in addition to the >> old one), or if it can't >> reproduce the problem, you'd need to update it or provide a new one. >> >> -phil. >> >> On 10/4/2010 4:14 AM, Pavel Tisnovsky wrote: >>> Hi, >>> >>> can someone please review a patch (see attachment) which I posted about >>> two weeks before? This mail was probably lost due to JavaOne ;-) >>> >>> Thank you in advance >>> Pavel From andrew.brygin at sun.com Wed Oct 6 08:45:14 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Wed, 06 Oct 2010 08:45:14 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6853488: REGRESSION : A black background is seen for a transparent animated gif image for splash screen Message-ID: <20101006084538.857EE47F3C@hg.openjdk.java.net> Changeset: 93d0daa9aa7a Author: bae Date: 2010-10-06 12:19 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/93d0daa9aa7a 6853488: REGRESSION : A black background is seen for a transparent animated gif image for splash screen Reviewed-by: igor, prr ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c From dlila at redhat.com Wed Oct 6 20:36:38 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 6 Oct 2010 16:36:38 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <601834408.1550211286396932164.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. In the last week I have been implementing various optimizations, in particular to anti-aliasing. I tried to remove PiscesCache, and I did, but the code ended up being a mess, and it was actually slower, so I scrapped it. Most of the motivation for removing PiscesCache was so that getTypicalAlpha would be easier to implement. So, I tried to implement this without removing PiscesCache. Quite a few changes had to be made, but it is done and it speeds up rendering of mostly full or mostly empty shapes pretty dramatically. The curves animation in Java2Ddemo is about 80% faster on my machine than when using java6. Somewhat disappointingly, its fps is only about 0.7 times that of proprietary java. When rendering single frames of very complex paths it's only half as fast as closed java. Still it is considerably faster than what we have now, so I shouldn't complain. webrev: http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ This is how I implemented getTypicalAlpha: I added an int array A[numHorizTiles][numVertTiles] such that Aij contains the added alpha of every pixel in tile ij. This array starts with every entry being 0, and I increase its elements as RLE pairs are added to the "cache". I also made the cache store its data in an int[][] where the run lengths for row i are stored in the ith subarray (before, the run lengths were all put in the same array, and an offset array was kept along with another accounting array to make sense of it). I did this for clarity and because it helped with the implementation of getTypicalAlpha. I am not sure how the latter is true anymore, but it is done, it works, and its fast, so I think we should leave it, even if it's not completely necessary. I also implemented the optimization of removing all the untransforming if the transformation is a multiple of an orthogonal transformation. I implemented another optimization where Renderer's constructor takes a boolean argument that indicates whether its input is monotonic in x and y, and I gave Stroker an argument that indicates whether antialiasing is being done. These allow Stroker to skip the rotation it does of its input curves before subdividing them, and just subdivide the curves into monotonic x and y pieces. These are then fed to Renderer, which knows that all its input is monotonic, so it doesn't try to make its input monotonic (which normally is required, otherwise it wouldn't be able to keep track of the smallest and largest x and y coordinates). A minor change: Renderer's constructor no longer requires a cache argument. It creates its own now. I think that's it. For the first time, the renderer is at a point where I have no major concerns about it, and would be pretty comfortable with pushing it, although, of course, I would appreciate any suggestions, in particular comments on how to improve performance (especially AA performance - I must admit I was expecting larger improvements). Thank you Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 9/27/2010 7:43 AM, Denis Lila wrote: > > Hi Jim. > >> How much faster? I'm worried about this, especially given our > tiled > >> approach to requesting the data. What was the bottleneck before? > >> (It's been a while since I visited the code - we weren't computing > the > >> crossings for every curve in the path for every tile being > generated > >> were we?) > > > > Not much faster. I'm working on someting better. > > Then hopefully we can get to something with better memory and CPU > costs. > > > I'm not sure about the bottleneck, but what we were doing > before is: > > 1. Flatten (by subdividing) every curve so that we deal only with > lines. > > 2. Add each line to a list sorted by y0. When end_rendering was > called > > for each scanline we found the crossings of the scanline and every > line > > in our line list, which we used to compute the alpha for that > scanline's > > pixel row. All this would be put into RLE encoded temporary storage > and it > > would be read back and converted into tile form by > PiscesTileGenerator. > > > > Speaking of which, would it not be better to get rid of > PiscesCache and > > just keep a buffer with the current tile row in Renderer.java. This > would > > be possible because the specification for AATileGenerator says the > iteration > > is like: for (y...) for (x...);. > > Why is PiscesCache there? It isn't being used as a cache at all. > Could it be? > > Also, why do we output tiles, instead of just pixel rows (which I > guess would > > just be nx1 tiles). Is it because we would like to use > getTypicalAlpha to eliminate > > completely transparent or completely opaque regions as soon as > possible (and the > > longer a tile is the less of a chance it has at being either of > those two)? > > That was basically "cramming what we had into the interface's box". > The > cache existed for something that was being done on mobile, but it > doesn't have much of a place in our APIs so it was just reused for > tile > generation. If we have a much more direct way of doing it then it > would > be great to get rid of it. > > I think we can support "ALL1s" and "ALL0s" reasonably without the > cache. > > >> I can see your points here. I think there are solutions to avoid > much > >> of the untransforming we can consider, but your solution works well > so > >> let's get it in and then we can look at optimizations if we feel > they > >> are causing a measurable problem later. > > > > I should say this isn't quite as bad as I might have made it > seem. Firstly, > > this IO handler class I made elimiinates transformations when > Dasher > > communicates with Stroker. More importantly, no untransforming is > done > > when the transformation is just a translation or is the identity or > is singular > > and when STROKE_CONTROL is off, we only transform the output path. > That's > > because the most important reason for handling transforms the way I > do now > > is because we can't normalize untransformed paths, otherwise > coordinate > > adjustments might be magnified too much. So, we need to transform > paths > > before normalization. But we also can't do the stroking and > widening > > before the normalization. But if normalization is removed we can > just pass > > untransformed paths into Stroker, and transform its output (which is > still > > somewhat more expensive than only trasnforming the input path, > since > > Stroker produces many 3-7 curves for each input curve). > > Can the untransform be eliminated in the case of scaling? (Whether > just > for uniform scaling, or maybe even for non-uniform scaling with no > rotation or shearing?) > > >> I'm not sure I understand the reasoning of the control point > >> calculation. I'll have to look at the code to register an > opinion. > > > > I'm sorry, my explanation wasn't very clear. I attached a > picture that > > will hopefully clarify things. > > But, in a way, the computation I use is forced on us. Suppose we > have a > > quadratic curve B and we need to compute one of its offsets C. > C'(0) > > and C'(1) will be parallel to B'(0) and B'(1) so we need to make > sure > > our computed offset has this property too (or it would look weird > around > > the endpoints). Now, B'(0) and B'(1) are parallel to p2-p1 and > p3-p2 > > where p1,p2,p3 are the 3 control points that define B, so if the > control > > points of C are q1, q2, q3 then q2-q1 and q3-q2 must be parallel to > p2-p1 > > and p3-p2 respectively. At this point, we need more constraint, > since > > our system is underdetermined. We use the constraints that q1 = > C(0) > > and q3 = C(1) (so, the endpoints of the computed offset are equal to > the > > endpoints of the ideal offset). All we have left to compute is q2, > but > > we know the direction of q2-q1 and the direction of q3-q2, so q2 > must > > lie on the lines defined by q1+t*(q2-q1) and q3+t*(q3-q2) so q2 > must > > be the intersection of these lines. > > I agree that if you are creating a parallel curve then intersection is > > the way to go. I guess what I was potentially confused about was > whether there are cases where you need to subdivide at all? > Regardless > of subdivision, when you get down to the final step of creating the > parallel curves then I believe offsetting and finding the intersection > > is correct (though I reserve the possibility that there might still be > a > simpler way - I haven't done any investigation to know if that is > true). > > >> It sounds like you are correct here. What does the closed source > code > >> draw? > > > > I thought closed source java simply didn't draw the round joins > in > > these cases, but I did some more testing and it turns out it does > for > > some curves and it doesn't for others. I've included the results of > a > > test I wrote that tries to draw paths like: > moveTo(0,0);p.lineTo(cos,sin);p.lineTo(0,0); > > where cos and sin are coordinates on a circle (source1.png is the > output > > of closed java. Source2.png is my output). As you can see, my > > version draws the round joins on all tested cases, while closed > java > > is inconsistent. > > You rock then! A bug should be filed on closed JDK. Can you file it > or > send me your test case and I'll do it? > > > That sounds good. Hopefully by the end of today I'll have a > > less memory hungry AA implementation that is also faster. > > Yay! > > > Thank you, > > Ummm... Thank *you*. You're doing all the good work here, I'm just > sitting back, throwing out tiny crumbs of past experience and watching > > the ensuing woodchips fly with awe. I've had on my wish list for some > > time to be able to eliminate these last few closed source holdouts, > but > the quality of the Ductus code was so high that I never got motivated > to > try. Who knows now... ;-) > > ...jim From andrew.brygin at sun.com Thu Oct 7 09:22:18 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Thu, 07 Oct 2010 09:22:18 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6975884: sun/java2d/SunGraphics2D/DrawImageBilinear.java failed Message-ID: <20101007092245.5C7C447F7A@hg.openjdk.java.net> Changeset: 6cb79067ea7a Author: bae Date: 2010-10-07 12:25 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6cb79067ea7a 6975884: sun/java2d/SunGraphics2D/DrawImageBilinear.java failed Reviewed-by: prr ! test/sun/java2d/SunGraphics2D/DrawImageBilinear.java From ptisnovs at redhat.com Thu Oct 7 12:16:47 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Thu, 07 Oct 2010 14:16:47 +0200 Subject: [OpenJDK 2D-Dev] [Fwd: Need reviewer for change in freetypeScaler.c] In-Reply-To: <4CAB51A3.3000508@oracle.com> References: <4CA9B71C.4070503@redhat.com> <4CAA1314.6080704@oracle.com> <4CAAF102.1080806@redhat.com> <4CAB51A3.3000508@oracle.com> Message-ID: <4CADBA2F.7010001@redhat.com> Phil Race wrote: > It might be best if you provided the regression test first as pasting > that into the > bug description as the test case there would make it more apparent what > the user impact is. > Then the evaluation will be what you found as the cause. I've created webrew with new regression test, it is available here: http://cr.openjdk.java.net/~ptisnovs/TextOutlineBug/ I've also included correct test images (rendered by Sun JDK 6 and IBM Java) and incorrectly rendered images. Phil, could you please review this regression test? Please note that I didn't include bug ID, so this test probably could not be run from JTreg harness but "only" from CLI. Thanks in advance Pavel > > -phil. > > On 10/5/2010 2:33 AM, Pavel Tisnovsky wrote: >> Phil Race wrote: >>> Whilst the fix looks reasonable I'm a bit confused since you say the >>> referenced regression test for >>> 6703377 fails and yet it passes for me on a 6open build .. which is what >>> I'd hoped would happen >>> for a test specifically designed to test that bug. >> Hi Phil, >> >> thank you very much for your comments. I'm going to create regression >> test targeted only to this issue based on >> java/awt/Graphics2D/DrawString/RotTransText.java. >> >> Could you please create a new bug id for this issue or do I have to >> create reg.test first? >> >> Pavel >> >>> Note that this fix would need to be pushed under a new bug id, and >>> either the regression test >>> would need to be updated to reference the new bug (in addition to the >>> old one), or if it can't >>> reproduce the problem, you'd need to update it or provide a new one. >>> >>> -phil. >>> >>> On 10/4/2010 4:14 AM, Pavel Tisnovsky wrote: >>>> Hi, >>>> >>>> can someone please review a patch (see attachment) which I posted about >>>> two weeks before? This mail was probably lost due to JavaOne ;-) >>>> >>>> Thank you in advance >>>> Pavel > From philip.race at oracle.com Thu Oct 7 17:38:00 2010 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Oct 2010 10:38:00 -0700 Subject: [OpenJDK 2D-Dev] [Fwd: Need reviewer for change in freetypeScaler.c] In-Reply-To: <4CADBA2F.7010001@redhat.com> References: <4CA9B71C.4070503@redhat.com> <4CAA1314.6080704@oracle.com> <4CAAF102.1080806@redhat.com> <4CAB51A3.3000508@oracle.com> <4CADBA2F.7010001@redhat.com> Message-ID: <4CAE0578.6040902@oracle.com> I suggest that the test only create the output files if some command line argument is supplied. In the test harness I am not sure where those would end up. The current working directory is not necessarily the same as either where the source files or the class files are. Also this test passes for me with the latest 6 open on Redhat 5.5, solaris 10 (sparc) and windows 7 even without your changes!? I find that very puzzling. My build is not using the system freetype (ie even in the RH 5.5 case) so maybe that's it but I can't see how .. -phil. On 10/7/2010 5:16 AM, Pavel Tisnovsky wrote: > Phil Race wrote: >> It might be best if you provided the regression test first as pasting >> that into the >> bug description as the test case there would make it more apparent what >> the user impact is. >> Then the evaluation will be what you found as the cause. > I've created webrew with new regression test, it is available here: > http://cr.openjdk.java.net/~ptisnovs/TextOutlineBug/ > > I've also included correct test images (rendered by Sun JDK 6 and IBM > Java) and incorrectly rendered images. > > Phil, could you please review this regression test? Please note that I > didn't include bug ID, so this test probably could not be run from JTreg > harness but "only" from CLI. > > Thanks in advance > Pavel > >> -phil. >> >> On 10/5/2010 2:33 AM, Pavel Tisnovsky wrote: >>> Phil Race wrote: >>>> Whilst the fix looks reasonable I'm a bit confused since you say the >>>> referenced regression test for >>>> 6703377 fails and yet it passes for me on a 6open build .. which is what >>>> I'd hoped would happen >>>> for a test specifically designed to test that bug. >>> Hi Phil, >>> >>> thank you very much for your comments. I'm going to create regression >>> test targeted only to this issue based on >>> java/awt/Graphics2D/DrawString/RotTransText.java. >>> >>> Could you please create a new bug id for this issue or do I have to >>> create reg.test first? >>> >>> Pavel >>> >>>> Note that this fix would need to be pushed under a new bug id, and >>>> either the regression test >>>> would need to be updated to reference the new bug (in addition to the >>>> old one), or if it can't >>>> reproduce the problem, you'd need to update it or provide a new one. >>>> >>>> -phil. >>>> >>>> On 10/4/2010 4:14 AM, Pavel Tisnovsky wrote: >>>>> Hi, >>>>> >>>>> can someone please review a patch (see attachment) which I posted about >>>>> two weeks before? This mail was probably lost due to JavaOne ;-) >>>>> >>>>> Thank you in advance >>>>> Pavel From philip.race at oracle.com Thu Oct 7 18:16:08 2010 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Oct 2010 11:16:08 -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> <4C76DA39.8080500@oracle.com> <4C9A90DB.9010907@oracle.com> Message-ID: <4CAE0E68.70705@oracle.com> Sorry for the delay. I briefly read then forgot about this email. I'm OK with this patch going in as is, since I cannot (at least offhand) think of a better way than doing the cast. I suppose could add an empty "freeSDResources" method to the SurfaceData class and have the XRSurfaceData be the only one that does anything with it but its really just window dressing. >PS: Is there some java-side equivalent in SurfaceData for X11SD_Dispose? >I have a GC on the java side with no references on the native side and >if possible would like to free it at dispose time without writing C >code. I don't see how you free any X11 XID without dropping into native somewhere but are you looking for something like the existing static method XlibWrapper.XFreeGC(long display, long gc)" ? -phil. On 9/24/2010 2:55 PM, Clemens Eisserer wrote: > Hi Phil, > > >> It doesn't sound right to me that this behaviour is an implementation detail of X.org. >> Developers need to know that either it does or it doesn't. Were you given a >> good rationale? > The explanation was that Pixmaps are reference counted, and therefor > stay alive if a XRender-picture points to it. A window is not > reference counted, and therefor all its resources are destroyed > immediatly. GC's are not affected because they are not bound to a > drawable, thats why it hasn't been a problem for the JDK to free GCs > later than the Window. > I find this explanation fishy, but the general recommendation was to > free Pictures before the drawable in any case. > > The patch attached does free the picture before destroying the window, > however casting surfaceData to XRSurfaceData in XWindow.java is ugly - > and the patch assumes nobody calls XDestroyWindow for a > SurfaceData-Drawable except destroy(). Suggestions welcome ;) > > With that patch I get rid of all XErrors and also can't reproduce the > XDnD-Exception anymore. > >> I don't see how that helped on its own. If the Picture is implicitly freed >> by XDestroyWindow then >> xsdo->xrPic is still going to be != None .. or am I overlooking something? > My initial analysis was wrong - somehow I thought the problem is > solved, but it wasn't. > > Thanks Clemens > > PS: Is there some java-side equivalent in SurfaceData for X11SD_Dispose? > I have a GC on the java side with no references on the native side and > if possible would like to free it at dispose time without writing C > code. From dlila at redhat.com Fri Oct 8 15:53:43 2010 From: dlila at redhat.com (Denis Lila) Date: Fri, 8 Oct 2010 11:53:43 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CA121AD.3010303@oracle.com> Message-ID: <1525642683.1780651286553223375.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. Sorry for all the e-mails, but I made a couple of other notable changes I should mention. 1. The optimization I described in one of my other e-mails that allowed Renderer to skip subdivision of curves into monotonic pieces if the curves came from Stroker is gone. There was a bug with round joins and caps (the curves composing them would not be monotonic). I could have fixed this, but there's also the problem that the rest of Stroker's output curves can only be guaranteed to be monotonic in x and y if we can find all points in the non-offset curve where the radius of curvature == linewidth. My algorithm that tries to find these points does so pretty well, but it doesn't always find them all. 2. I changed how the alpha map is managed in PiscesTileGenerator to something that's a bit clearer and uses less memory (the latter comes from changing the +300 in the alpha tile allocation to +1. If there was a good reason for using 300, please tell me). That's all. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 9/27/2010 7:43 AM, Denis Lila wrote: > > Hi Jim. > >> How much faster? I'm worried about this, especially given our > tiled > >> approach to requesting the data. What was the bottleneck before? > >> (It's been a while since I visited the code - we weren't computing > the > >> crossings for every curve in the path for every tile being > generated > >> were we?) > > > > Not much faster. I'm working on someting better. > > Then hopefully we can get to something with better memory and CPU > costs. > > > I'm not sure about the bottleneck, but what we were doing > before is: > > 1. Flatten (by subdividing) every curve so that we deal only with > lines. > > 2. Add each line to a list sorted by y0. When end_rendering was > called > > for each scanline we found the crossings of the scanline and every > line > > in our line list, which we used to compute the alpha for that > scanline's > > pixel row. All this would be put into RLE encoded temporary storage > and it > > would be read back and converted into tile form by > PiscesTileGenerator. > > > > Speaking of which, would it not be better to get rid of > PiscesCache and > > just keep a buffer with the current tile row in Renderer.java. This > would > > be possible because the specification for AATileGenerator says the > iteration > > is like: for (y...) for (x...);. > > Why is PiscesCache there? It isn't being used as a cache at all. > Could it be? > > Also, why do we output tiles, instead of just pixel rows (which I > guess would > > just be nx1 tiles). Is it because we would like to use > getTypicalAlpha to eliminate > > completely transparent or completely opaque regions as soon as > possible (and the > > longer a tile is the less of a chance it has at being either of > those two)? > > That was basically "cramming what we had into the interface's box". > The > cache existed for something that was being done on mobile, but it > doesn't have much of a place in our APIs so it was just reused for > tile > generation. If we have a much more direct way of doing it then it > would > be great to get rid of it. > > I think we can support "ALL1s" and "ALL0s" reasonably without the > cache. > > >> I can see your points here. I think there are solutions to avoid > much > >> of the untransforming we can consider, but your solution works well > so > >> let's get it in and then we can look at optimizations if we feel > they > >> are causing a measurable problem later. > > > > I should say this isn't quite as bad as I might have made it > seem. Firstly, > > this IO handler class I made elimiinates transformations when > Dasher > > communicates with Stroker. More importantly, no untransforming is > done > > when the transformation is just a translation or is the identity or > is singular > > and when STROKE_CONTROL is off, we only transform the output path. > That's > > because the most important reason for handling transforms the way I > do now > > is because we can't normalize untransformed paths, otherwise > coordinate > > adjustments might be magnified too much. So, we need to transform > paths > > before normalization. But we also can't do the stroking and > widening > > before the normalization. But if normalization is removed we can > just pass > > untransformed paths into Stroker, and transform its output (which is > still > > somewhat more expensive than only trasnforming the input path, > since > > Stroker produces many 3-7 curves for each input curve). > > Can the untransform be eliminated in the case of scaling? (Whether > just > for uniform scaling, or maybe even for non-uniform scaling with no > rotation or shearing?) > > >> I'm not sure I understand the reasoning of the control point > >> calculation. I'll have to look at the code to register an > opinion. > > > > I'm sorry, my explanation wasn't very clear. I attached a > picture that > > will hopefully clarify things. > > But, in a way, the computation I use is forced on us. Suppose we > have a > > quadratic curve B and we need to compute one of its offsets C. > C'(0) > > and C'(1) will be parallel to B'(0) and B'(1) so we need to make > sure > > our computed offset has this property too (or it would look weird > around > > the endpoints). Now, B'(0) and B'(1) are parallel to p2-p1 and > p3-p2 > > where p1,p2,p3 are the 3 control points that define B, so if the > control > > points of C are q1, q2, q3 then q2-q1 and q3-q2 must be parallel to > p2-p1 > > and p3-p2 respectively. At this point, we need more constraint, > since > > our system is underdetermined. We use the constraints that q1 = > C(0) > > and q3 = C(1) (so, the endpoints of the computed offset are equal to > the > > endpoints of the ideal offset). All we have left to compute is q2, > but > > we know the direction of q2-q1 and the direction of q3-q2, so q2 > must > > lie on the lines defined by q1+t*(q2-q1) and q3+t*(q3-q2) so q2 > must > > be the intersection of these lines. > > I agree that if you are creating a parallel curve then intersection is > > the way to go. I guess what I was potentially confused about was > whether there are cases where you need to subdivide at all? > Regardless > of subdivision, when you get down to the final step of creating the > parallel curves then I believe offsetting and finding the intersection > > is correct (though I reserve the possibility that there might still be > a > simpler way - I haven't done any investigation to know if that is > true). > > >> It sounds like you are correct here. What does the closed source > code > >> draw? > > > > I thought closed source java simply didn't draw the round joins > in > > these cases, but I did some more testing and it turns out it does > for > > some curves and it doesn't for others. I've included the results of > a > > test I wrote that tries to draw paths like: > moveTo(0,0);p.lineTo(cos,sin);p.lineTo(0,0); > > where cos and sin are coordinates on a circle (source1.png is the > output > > of closed java. Source2.png is my output). As you can see, my > > version draws the round joins on all tested cases, while closed > java > > is inconsistent. > > You rock then! A bug should be filed on closed JDK. Can you file it > or > send me your test case and I'll do it? > > > That sounds good. Hopefully by the end of today I'll have a > > less memory hungry AA implementation that is also faster. > > Yay! > > > Thank you, > > Ummm... Thank *you*. You're doing all the good work here, I'm just > sitting back, throwing out tiny crumbs of past experience and watching > > the ensuing woodchips fly with awe. I've had on my wish list for some > > time to be able to eliminate these last few closed source holdouts, > but > the quality of the Ductus code was so high that I never got motivated > to > try. Who knows now... ;-) > > ...jim From james.graham at oracle.com Fri Oct 8 23:47:02 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 08 Oct 2010 16:47:02 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1525642683.1780651286553223375.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1525642683.1780651286553223375.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CAFAD76.2010608@oracle.com> Hi Denis, On 10/8/2010 8:53 AM, Denis Lila wrote: > 2. I changed how the alpha map is managed in PiscesTileGenerator to > something that's a bit clearer and uses less memory (the latter comes > from changing the +300 in the alpha tile allocation to +1. If there was > a good reason for using 300, please tell me). Did I do that? Wow. I wish I knew. There were probably some bugs in the alpha accumulation at some point. Since it was indexed by a byte, I find it hard to believe that it would need 300 entries of padding. One thing - will we ever need more than one alpha map in practice? I don't believe we will since it depends on the maxalpha from the Renderer which is a fixed value. So, the hashmap cache is probably overkill compared to just seeing if the existing one is the right size, no? ...jim From dlila at redhat.com Tue Oct 12 13:01:08 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Oct 2010 09:01:08 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1438453603.223471286888451740.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <931162845.223531286888468767.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > > 2. I changed how the alpha map is managed in PiscesTileGenerator to > > something that's a bit clearer and uses less memory (the latter comes > > from changing the +300 in the alpha tile allocation to +1. If there was > > a good reason for using 300, please tell me). > > Did I do that? Wow. I wish I knew. There were probably some bugs in > the alpha accumulation at some point. Since it was indexed by a byte, I > find it hard to believe that it would need 300 entries of padding. I don't know who did it. I didn't mean to imply I thought it was you. In hindsight, the wording of "If there was a good reason for using 300, please tell me" was pretty terrible. I only asked because 300 seemed like a very out of place number and I thought it was a bugfix, but I couldn't see for what bug, so I thought you might know since you've helped me out in this sort of situation before (i.e. sx0, sy0 in Dasher). > One thing - will we ever need more than one alpha map in practice? I > don't believe we will since it depends on the maxalpha from the Renderer > which is a fixed value. So, the hashmap cache is probably overkill > compared to just seeing if the existing one is the right size, no? Right now, it's true that there will never be more than one alpha map, so you might say the HashMap is overkill, but I don't think this is a problem because performance wise it costs nearly nothing and I think the code is easier to read now. But it's not a big deal, I can change it back if you want. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 10/8/2010 8:53 AM, Denis Lila wrote: > > ...jim From james.graham at oracle.com Wed Oct 13 06:34:41 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Oct 2010 23:34:41 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <931162845.223531286888468767.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <931162845.223531286888468767.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CB55301.5010402@oracle.com> Hi Denis, On 10/12/2010 6:01 AM, Denis Lila wrote: > Hi Jim. > >>> 2. I changed how the alpha map is managed in PiscesTileGenerator to >>> something that's a bit clearer and uses less memory (the latter comes >>> from changing the +300 in the alpha tile allocation to +1. If there was >>> a good reason for using 300, please tell me). >> >> Did I do that? Wow. I wish I knew. There were probably some bugs in >> the alpha accumulation at some point. Since it was indexed by a byte, I >> find it hard to believe that it would need 300 entries of padding. > > I don't know who did it. I didn't mean to imply I thought it was you. > In hindsight, the wording of "If there was a good reason for using 300, > please tell me" was pretty terrible. I only asked because 300 seemed like a > very out of place number and I thought it was a bugfix, but I couldn't see > for what bug, so I thought you might know since you've helped me out in > this sort of situation before (i.e. sx0, sy0 in Dasher). It was most likely me since this code hasn't been touched much since I hacked it together. I wasn't put out by your comment, I was simply making a public showing of confusion to cover my embarrassment. ;-) >> One thing - will we ever need more than one alpha map in practice? I >> don't believe we will since it depends on the maxalpha from the Renderer >> which is a fixed value. So, the hashmap cache is probably overkill >> compared to just seeing if the existing one is the right size, no? > > Right now, it's true that there will never be more than one alpha map, so > you might say the HashMap is overkill, but I don't think this is a problem > because performance wise it costs nearly nothing and I think the code is easier > to read now. > But it's not a big deal, I can change it back if you want. No, I think it's OK if it doesn't show up on any benchmarks... ...jim From james.graham at oracle.com Wed Oct 13 22:40:04 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 13 Oct 2010 15:40:04 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CB63544.4020208@oracle.com> HI Denis, I'm just now getting down to the nitty gritty of your webrevs (sigh). On 10/6/2010 1:36 PM, Denis Lila wrote: > > webrev: > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ PiscesRenderingEngine.java: line 278 - the det calculation is missing "b". line 296 - is there an "epsilon" that we can use? "==" with floating point often fails with calculations. line 308 - miterlimit is a ratio of lengths and should not need to be scaled. line 332 - I think you can use a null transform for the same result. line 338 - null here too TransformingPolyIOHelper should be in its own file - we consider more than one class per file to be bad form these days, especially if the class is used outside of that file. I'm a little troubled by how the PolyIOHelper fits into the design. It's odd to talk to the same object for both input and output. I have some ideas there, but I think I'll leave it for a followon email and effort. Dasher.java: lines 110,111 - shouldn't you check if there are any "first segments" before writing the extra move? lines 150-152 - starting should be left true until you reach the end of the dash, no? Otherwise you only hold back the starting segments up until the first "piece" of a curve. Everything should be held back until you reach an "off" piece. I don't think the logic for these variables is right yet. Here is what I see: boolean needsMoveto; in moveTo and pathDone: if (firstSegBuf is not empty) { output moveto(sx,sy) output firstSegs } needsMoveto = true; // not needed in pathDone in goTo() { if (ON) { if (starting) { store it in firstSegBuf } else { if (needsMoveto) { output moveto(x0,y0); needsMoveto = false; } send it to output } } else { starting = false; needsMoveto = true; // nothing goes to output } } and in ClosePath: lineToImpl(sx, sy, LINE); if (firstSegBuf is not empty) { if (!ON) { // Or "if (needsMoveto)" output moveTo(sx, sy) } output firstSegs } I don't see a need for firstDashOn or fullCurve line 228 - Lazy allocate lc? Polygons, rectangles, and lines won't need it to be dashed (though dashing is already expensive enough it might not be noticeable, still waste is waste and there is only one piece of code that uses lc so it is easy to protect with a lazy allocation) line 235 - is there a reason to output a curve of 0 length? lines of 0 length are omitted... line 257 - shouldn't the left and right indices always be at 0 and type-curCurveoff? It looks like after the first time through this loop you are storing the right half on top of the left half (see line 262)? That would output odd values if any curve gets subdivided more than once, though, right? line 289 - LenComputer always allocates maxcurves segements which is 8*1024 words (32K) + object overhead * 1024 + 2 more arrays of 1025 words. That's a lot of memory for the worst case scenario. It might be nice to come back to this and have it be more dynamic (and it is more of a push to have the "lc" variable be lazily allocated above). Also, if you are clever enough, you never need storage for more than about 10 (maybe 11) curves even if you produce 1024 t's and len's - due to the recursive nature of the subdivision that leaves one half dormant while the other half is explored. line 347,352 - it might be cleaner to have the calling function keep track of how far into the curve you are and communicate this to the method so it doesn't have to clobber its data based on an assumption of how the calling function is structured. But, this arrangement works fine for the current purposes and you do have a "TODO" comment in there about this. Stroker.java: line 129 - proof that miterLimit does not need to be scaled... ;-) I'm going to send this buffer of comments off now and continue on with Stroker.java in a future email... ...jim From james.graham at oracle.com Wed Oct 13 23:20:29 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 13 Oct 2010 16:20:29 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CB63EBD.6070808@oracle.com> Hi Denis, I took a little break from code reviewing to write up this concept which might help simplify the PolyIOHelper stuff in your code (later). My concept was that the attached "transforming PathConsumer" classes would be potentially more efficient than putting the coordinates into a buffer and then calling a method on AffineTransform. With the PolyIOHelper stuff we have the following flow: src calls pc.fooTo() pc calls io.readFoo() io stores to buffer conditionally: io calls at.transform() at loads values at computes values at stores values With these classes, if there is a transform: src calls tpc.fooTo(x,y) tpc computes values tpc calls pc.fooTo(x',y') pc stores to buffer as needed And if the transform was null or identity: src calls pc.fooTo() pc stores to buffer as needed And something similar on the output. The buffering is then entirely at the discretion of the eventual consumer (Dasher/Stroker) and the information flow is more direct whether or not there is a transform. There are optimal "TPC" implementations of translate, scale+translate, and full transform. AT further optimizes the cases of scale without translate and shears without scales (and/or translates), but I don't think those cases happen often enough to worry about spending too much to optimize, especially since these classes already win by inlining the transform calculations...? Note that these compile, but I haven't tested them (the implementation was pretty straightforward, though)... ...jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TransformingPathConsumer2D.java URL: From james.graham at oracle.com Thu Oct 14 03:09:14 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 13 Oct 2010 20:09:14 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CB63544.4020208@oracle.com> References: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CB63544.4020208@oracle.com> Message-ID: <4CB6745A.2040005@oracle.com> Round 2 On 10/13/2010 3:40 PM, Jim Graham wrote: > HI Denis, > > I'm just now getting down to the nitty gritty of your webrevs (sigh). > > On 10/6/2010 1:36 PM, Denis Lila wrote: >> >> webrev: >> http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ Stroker.java: Are you happy with the current variable names? You're doing the bulk of the work now so if they make sense to you now then it might be best to leave them alone, but they give me headaches trying to figure them out. I think you are right that it might help to create some "vector" helper classes. I eventually got used to the naming by the time I was done with the file, but yikes - this will hurt the next guy that comes along to maintain the code. The sx0,sy0,sdx,sdy variables are (reasonably) well named. The x0,y0,pdx,pdy variables aren't consistent. Perhaps cx0,cy0,cdx,cdy for "current" would make more sense? The mx0,my0,omx,omy variables are even further from the prior naming conventions, what about smx,smy,cmx,cmy? I would combine the emit*To methods into just the one version that takes a boolean. The number of times you call them without the boolean are few and far between and the versions that don't take the boolean are so few lines of code that inlining them into the boolean versions of the methods will still make for nice and tight code. line 208 - isn't this just "side = false" since side is either 0 or 1? Also, side is only ever 1 for an end cap in which case we need exactly 2 90 degree beziers which are very simple to compute and could be hard coded. Was there a reason not to just have a special "roundCap" function which would be 2 hardcoded and fast emitCurveTo calls? The code would be something like: curveTo(/*x+mx, y+my,*/ x+mx-C*my, y+my+C*mx, x-my+C*mx, y+mx+C*my, x-my, y+mx); curveTo(/*x-my, y+mx,*/ x-my-C*mx, y+mx-C*my, x-mx-C*my, y-my+C*mx, x-mx, y-my); where C = 0.5522847498307933; // Computed btan constant for 90 degree arcs (rest of drawRoundJoin method - it may take some doing, but eventually this method should simplify based on: there will only ever be 1 or 2 curves, Math.sin(Math.atan2()) cancels out as does Math.cos(Math.atan2()) though to do so requires Math.hypot() which is a simpler calculation than any of the transcendentals. So, if there was an easy test for "acute/obtuse angle" and a way to find the center of an angle (both I'm sure we could find on the net), then we could eliminate the transcendentals from this method). line 283 - doesn't this simplify to?: t = x10p*(y0-y0p) - y10p*(x0-x0p) (source: http://local.wasp.uwa.edu.au/~pbourke/geometry/lineline2d/) then calculating: t = (...)/den; can amortize the dividend from the following 2 calculations. line 337 - shouldn't this just return? I don't think that empty lines should modify the path at all. If this is a case of "moveto(x,y); lineto(x,y)" then the finish() code should deal with the "path that never went anywhere - i.e. drawing a dot", shouldn't it? The only problem is that moveTo never set up omx,omy so finish will likely draw something random. Perhaps if moveto (and closepath) simply set up omx,omy to w,0 (or 0,-w if you prefer) then finish would do a reasonable thing for empty paths? line 374 - why is this moveto here? Doesn't this break the joined path into 2 separate paths? Should this be a lineto? (Also, sx0==x0 and sy0==y0 at this point). line 389 - The test here is different from closePath. What if they were both "prev == DRAWING_OP_TO"? line 394 - or prev = CLOSE to match the initial state? (I guess it shouldn't really matter unless an upstream feeder has a bug.) line 486 - this leaves the current point in a different place than line 510, does that matter? My head started spinning when evaluating the parallel curve methods so I'll stop here for now... ...jim From james.graham at oracle.com Thu Oct 14 23:49:48 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 14 Oct 2010 16:49:48 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CB7971C.2060702@oracle.com> Round 3... On 10/6/2010 1:36 PM, Denis Lila wrote: > > webrev: > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ I'm going to set the rest of Stroker.java aside for a moment and focus on other areas where I have some better knowledge... Renderer.java: lines 83, 91, 99: can't these be folded into the prior loops? You can update their Y while searching for the [eqc]hi value. lines 178,192: indent to the preceding "("? (Also, I'm a big fan of moving the "{" to a line by itself if an conditional or argument list was wrapped to more than 1 line - the 2D team tends to use that style everywhere in the 2D code...) line 193: add fieldForCmp here instead of every time in the loop? (The compiler will probably/hopefully do that anyway) line 238: If X0,Y0,XL,COUNT were bumped up by 1 then you could just reuse "SLOPE" from the linear indices - just a thought. lines 521,527,533: Why are these executed twice? You call these methods again after the "initialize common fields" code. That seems like double the work just to maybe save 4 lines of shared code? Maybe put the 4 lines of shared code in a helper function that all of the init() methods call? line 574: indentation? line 566: shouldn't horizontal lines be ignored? they don't affect rasterization. line 612: delete? Or will this be making a comeback sometime? lines 624,626: indentation? lines 724,725: doesn't the assert false omit these? I usually throw an InternalError in cases like this with a description of what went wrong. I've read up through the use of the cache in emitRow(). I'll continue with reviewing the cache in the next set, meanwhile I also took a look at the helper classes... Helpers.java: line 37: If it can't be instantiated, why does it take arguments? getTransformedPoints isn't used? getUntransformedPoints isn't used? fillWithIndxes(float) isn't used? evalQuad isn't used? (Though it does provide symmetry with evalCubic which is used) getFlatness* aren't used? ptSegDistSq isn't used? line 105: There is a closed form solution to cubic roots. I unfortunately used a bad version in CubicCurve2D.solveCubic and I don't remember if I ever went back and fixed it (it may even have been "Cardano's method" for all I know). There are versions out there which do work better. The problem with the one in CC2D was that I copied it out of Numerical Recipes in C and apparently the author somehow assumed that all cubics would have 1 or 3 roots, but a cubic of the form (x-a)(x-a)(x-b) has 2 roots. D'oh! While I did find other implementations out there on the net, in the end fixing the closed form solution seemed wrought with issues since many of the tests would use radically different approaches depending on tiny changes in one of the intermediate results and so I worried about FP error even in doubles possibly skewing the results. I think you should leave your code in there, but I wanted to fill you in on other possibities. BezCurve.java: Didn't you get a complaint that this class is defined in a file of the wrong name? Maybe the compiler doesn't complain because the class isn't public, but one of the names should change to match. line 59: I'd throw an internal error and the compiler would be appeased. line 35: If you make this a "create" factory then it can leverage the code in the existing constructors - just a thought. I'll stop here and hit send - not much left after this round... ...jim From andrew.brygin at sun.com Fri Oct 15 07:18:22 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 15 Oct 2010 07:18:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6725821: Compiler warnings in medialib code Message-ID: <20101015071902.D88F54716D@hg.openjdk.java.net> Changeset: 4a50631c9910 Author: bae Date: 2010-10-15 10:42 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4a50631c9910 6725821: Compiler warnings in medialib code Reviewed-by: igor, prr ! make/sun/image/generic/Makefile ! src/share/native/sun/awt/medialib/mlib_ImageLookUp_64.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32U16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32U16Func.c From andrew.brygin at sun.com Fri Oct 15 08:08:26 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 15 Oct 2010 08:08:26 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6773022: java.awt.image.SampleModel.getDataElements() does't throw ArrayIndexOutOfBoundsEx for Integer.MAX_V Message-ID: <20101015080836.6FACA47170@hg.openjdk.java.net> Changeset: 37df0a178978 Author: bae Date: 2010-10-15 11:26 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/37df0a178978 6773022: java.awt.image.SampleModel.getDataElements() does't throw ArrayIndexOutOfBoundsEx for Integer.MAX_V Reviewed-by: igor, prr ! src/share/classes/java/awt/image/SampleModel.java + test/java/awt/image/GetDataElementsTest.java From andrew.brygin at sun.com Fri Oct 15 08:39:19 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 15 Oct 2010 08:39:19 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6984033: imageio vendor references need to change (jdk7 only) Message-ID: <20101015083929.0D5D447180@hg.openjdk.java.net> Changeset: a7cdcd3541d4 Author: bae Date: 2010-10-15 12:02 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a7cdcd3541d4 6984033: imageio vendor references need to change (jdk7 only) Reviewed-by: prr, ohair ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/InputStreamImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/OutputStreamImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageOutputStreamSpi.java From jennifer.godinez at sun.com Fri Oct 15 18:40:56 2010 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Fri, 15 Oct 2010 18:40:56 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6804454: RFE: Provide a way to control the printing dpi resolution from MSIE browser print. See also 6801859 Message-ID: <20101015184118.74D694719A@hg.openjdk.java.net> Changeset: 0a53abebf6e9 Author: jgodinez Date: 2010-10-15 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0a53abebf6e9 6804454: RFE: Provide a way to control the printing dpi resolution from MSIE browser print. See also 6801859 Reviewed-by: igor, prr ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java From james.graham at oracle.com Sat Oct 16 01:11:58 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 15 Oct 2010 18:11:58 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1733589840.1551881286397398825.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CB8FBDE.5050703@oracle.com> Round 4... On 10/6/2010 1:36 PM, Denis Lila wrote: > > webrev: > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ BezCurve.java: I'd add some "set()" methods to BezCurve/Curve and then use a scratch instance in Renderer (and other places?) to reuse those calculations, such as: Curve constructors (obviously) Renderer.curveOrQuadTo() Renderer.initQuad() Renderer.initCurve() Stroker.findSubdivPoints() lines 179,182 - using your d* variables, wouldn't these be: a = 2*(dax*dax + day*day) b = 3*(dax*dbx + day*dby) c = 2*(dax*cx + day*cy) + dbx*dbx + dby*dby d = dbx*cx + dby*cy It has fewer multiplies and more of the multipliers are powers of 2 which are faster than non-power-of-2 multiplies. line 206,210 - a nit - it didn't really confuse me, but halfway through reading this it occurs to me that these are really t0 and t1, right? line 212 - if x0 (t0?) is 0 then you don't need to include it in the roots, no? line 249,257 - these corrections are exponential compared to the sample code on the wikipedia page - was that the "slight modification" that you mentioned in the comments? line 303 - isn't it enough to just look at the previous T value (or keep a running "prevt" variable) rather than update every T value in the array? Isn't this enough? int prevt = 0; /* field in Iterator */ next() { curt = Ts[next]; split = (curt - prevt) / (1 - prevt); prevt = curt; } ROCsq - I looked at the wikipedia article and it wasn't clear how it directly related to your function since the article is dealing with the curvature of a function graphed against its own t, but you are dealing with 2 parametric equations combined and graphed against each other. I think I'm going to have to just trust you on this one for now. :-( Done with BezCurve.java... Stroker.java: lines 558 (et al) - create a helper function for all of these (degenerates to a line) cases? lines 621-626 and 643-646 - I'm not sure what the derivation of these lines are. I tried to do my own equations, but I seem to be heading in a different direction than you used and it didn't seem like I was going to converge. What equations did you set up to solve to get these calculations? From what I can see we have: - new p1,p4 are calculated - new p(0.5) is calculated - the corresponding dx,dy at t=0,0.5,1 (gives slopes) - slopes at t=0, 0.5 and 1 should be the same for all curves and what you are trying to compute are two scaling constants c1 and c2 that represent how much to scale the dx1,dy1 and dx4,dy4 values to get a curve that interpolates both position and slope at t=0.5. A comment might help here... :-( line 687 - dup? line 856 - use a scratch Curve instance and set methods to reduce GC? line 857 - this is true if the first vector is parallel to either axis, but the comment after it says only "parallel to the x axis" - is that a problem? Also, if both are 0 then no parallel constraint is applied even if it does start out parallel. I imagine that this is all OK because the "both 0" case should be rare/non-existant and the y-axis case will also benefit from the same optimization...? lines 861-863: sin/cos and atan2 cancel each other out. It is faster to compute the hypotenuse and then divide the x and y by the hypotenuse to get the cos and sin. (cos = x/hypot; sin = y/hypot;) Cache and TileGenerator look ok... I think I'm done at this point except for not understanding the "parallel cubic" equations I mentioned above and the ROCsq method... ...jim From dlila at redhat.com Mon Oct 18 21:19:21 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 18 Oct 2010 17:19:21 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <329772581.845441287436747457.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <765647625.845461287436761968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > I'm just now getting down to the nitty gritty of your webrevs (sigh). Thanks. I hope it's not too bad. > PiscesRenderingEngine.java: > line 278 - the det calculation is missing "b". > > line 296 - is there an "epsilon" that we can use? "==" with floating > point often fails with calculations. > > line 308 - miterlimit is a ratio of lengths and should not need to be > scaled. > > line 332 - I think you can use a null transform for the same result. > > line 338 - null here too I fixed these. > lines 110,111 - shouldn't you check if there are any "first segments" > before writing the extra move? I suppose I should. I didn't because I don't think it affects what is drawn. It doesn't, does it? > lines 150-152 - starting should be left true until you reach the end > of the dash, no? Otherwise you only hold back the starting segments up > until the first "piece" of a curve. Everything should be held back > until you reach an "off" piece. I don't think the logic for these > variables is right yet. Here is what I see: That's right, it should stay true until the end of the first dash is reached. I'm pretty sure that's what it does. This is what fullCurve is used for. It is a hint from the caller that indicates whether the input curve has been subdivided. If it hasn't, that means the first dash isn't over yet so starting will remain true (lines 150-152). Admittedly, this is a bit clunky so I've implemented your solution. > line 228 - Lazy allocate lc? Polygons, rectangles, and lines won't > need it to be dashed (though dashing is already expensive enough it might > not be noticeable, still waste is waste and there is only one piece of > code that uses lc so it is easy to protect with a lazy allocation) Done. > line 257 - shouldn't the left and right indices always be at 0 and > type-curCurveoff? It looks like after the first time through this > loop you are storing the right half on top of the left half (see line 262)? > That would output odd values if any curve gets subdivided more than > once, though, right? What is happening is that at any time there is a "current curve" - the one to be emitted in goTo, and the rest of the curve. The current curve gets bounced around between 0 and type-curCurveoff. So, suppose type==8 and the curve needs to be subdivided twice. Then on the second iteration, the subdivision will put the left half at curCurvepts, which is 8 and the right half will go to 0. Then goTo will be called with an offset of curCurveoff+2, which is 10, which is correct since that's where the current curve starts in relative coordinates. For some reason, when writing this, I was under the impression that this would let us move fewer coordinates around in the coordinate array, but of course, the subdivision routine will need to write to 2*type array elements anyway. So, I changed this to the more straightforward implementation (I also changed BezCurve.breakPtsAtTs, since it was doing the same thing). > line 347,352 - it might be cleaner to have the calling function keep > track of how far into the curve you are and communicate this to the > method so it doesn't have to clobber its data based on an assumption > of how the calling function is structured. But, this arrangement works > fine for the current purposes and you do have a "TODO" comment in > there about this. > line 289 - LenComputer always allocates maxcurves segements which is > 8*1024 words (32K) + object overhead * 1024 + 2 more arrays of 1025 > words. That's a lot of memory for the worst case scenario. It might > be nice to come back to this and have it be more dynamic (and it is more > of a push to have the "lc" variable be lazily allocated above). Also, if > you are clever enough, you never need storage for more than about 10 > (maybe 11) curves even if you produce 1024 t's and len's - due to the > recursive nature of the subdivision that leaves one half dormant while > the other half is explored. I turned LengthComputer into an iterator. I think it's much cleaner now. There's no longer any of that "scale every t in the array so that they become valid parameters of the right subdivided curve". It also uses less memory - just limit+1 curves. I guess I am clever enough ;) (though unfortunately not clever enough to have thought of the idea myself). I found a problem with Dashing though. Curves like moveTo(0,0); curveTo(498,498,499,499,500,500); are not handled well at all. http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ is the link with the new webrev. I have fixed this problem by doing binary search on the results of the flattening. I really don't like this solution because it does *a lot* more subdivisions than just flattening. Regards, Denis. ----- "Jim Graham" wrote: > HI Denis, > > On 10/6/2010 1:36 PM, Denis Lila wrote: > > > > webrev: > > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ > > TransformingPolyIOHelper should be in its own file - we consider more > than one class per file to be bad form these days, especially if the > class is used outside of that file. > > I'm a little troubled by how the PolyIOHelper fits into the design. > It's odd to talk to the same object for both input and output. I have > some ideas there, but I think I'll leave it for a followon email and > effort. > > Dasher.java: > > > boolean needsMoveto; > > in moveTo and pathDone: > if (firstSegBuf is not empty) { > output moveto(sx,sy) > output firstSegs > } > needsMoveto = true; // not needed in pathDone > > in goTo() { > if (ON) { > if (starting) { > store it in firstSegBuf > } else { > if (needsMoveto) { > output moveto(x0,y0); > needsMoveto = false; > } > send it to output > } > } else { > starting = false; > needsMoveto = true; > // nothing goes to output > } > } > > and in ClosePath: > lineToImpl(sx, sy, LINE); > if (firstSegBuf is not empty) { > if (!ON) { // Or "if (needsMoveto)" > output moveTo(sx, sy) > } > output firstSegs > } > > I don't see a need for firstDashOn or fullCurve > > > Stroker.java: > > line 129 - proof that miterLimit does not need to be scaled... ;-) > > I'm going to send this buffer of comments off now and continue on with > > Stroker.java in a future email... > > ...jim From dlila at redhat.com Mon Oct 18 21:21:33 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 18 Oct 2010 17:21:33 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <2128739898.656791287167837262.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Are you happy with the current variable names? Not really. The names you suggested are much better. I'm using them now. As for making a vector class, I think we should push this and then decide. It's absence has already done most of the damage it could possibly do, so it's not an urgent matter. And besides, pushing a good version of this first will make it easier to determine the performance impact of the vector class. > line 208 - isn't this just "side = false" since side is either 0 or > 1? > Also, side is only ever 1 for an end cap in which case we need exactly > 2 90 degree beziers which are very simple to compute and could be hard > coded. Was there a reason not to just have a special "roundCap" > function which would be 2 hardcoded and fast emitCurveTo calls? The > code would be something like: > curveTo(/*x+mx, y+my,*/ > x+mx-C*my, y+my+C*mx, > x-my+C*mx, y+mx+C*my, > x-my, y+mx); > curveTo(/*x-my, y+mx,*/ > x-my-C*mx, y+mx-C*my, > x-mx-C*my, y-my+C*mx, > x-mx, y-my); > where C = 0.5522847498307933; > // Computed btan constant for 90 degree arcs > > (rest of drawRoundJoin method - it may take some doing, but eventually > this method should simplify based on: there will only ever be 1 or 2 > curves, Math.sin(Math.atan2()) cancels out as does > Math.cos(Math.atan2()) though to do so requires Math.hypot() which is > a simpler calculation than any of the transcendentals. So, if there was > an easy test for "acute/obtuse angle" and a way to find the center of > an angle (both I'm sure we could find on the net), then we could > eliminate the transcendentals from this method). I introduced a drawRoundCap method. This eliminated the side argument from the round join drawing, which made it easier to eliminate the trig function calls. I did this by using dot products to compute cosines (which was possible because now Stroker takes only untransformed paths, and all lineWidths are the same), and I used the double angle identities to compute any sines. I came up with my own ways of detecting acute/obtuse angles and finding the centres of angles ("my own" meaning I didn't look at any websites), and they consist of: 1. if (omx * mx + omy * my) >= 0 then the angle is acute (line 200). 2. I explain this in a comment in the file (line 208). > I would combine the emit*To methods into just the one version that > takes a boolean. The number of times you call them without the boolean are > few and far between and the versions that don't take the boolean are > so few lines of code that inlining them into the boolean versions of the > methods will still make for nice and tight code. I was tempted to do this. I didn't because the boolean versions will need absolute coordinates, while the non boolean ones require relative ones. So if the non boolean versions need to be called and all we have are the boolean ones, 2 dummy arguments need to be supplied. However, I've looked at the code more closesly, and it turns out that we only use the non boolean versions from inside the boolean versions, so I've followed your suggestion (except on emitLineTo, since the non boolean version of that is used quite a bit). > line 374 - why is this moveto here? Doesn't this break the joined > path into 2 separate paths? Should this be a lineto? It does break it into 2 separate paths, but that's the correct behaviour in this case. Mathematically speaking, the 2 offset curves are spearate curves (despite any intersections). This changes when we use caps, but when using closePath(), caps aren't drawn so we should have 2 separate paths. This is also the behaviour of oracle's closed source java (which can be seen in one of the Java2Ddemo demos - the one that draws the offset curves of a star with a vertical slider controlling the line width). > (Also, sx0==x0 and sy0==y0 at this point). I am now using s*0 instead of *0, since the expressions involve sdx and sdy, so it's a bit clearer. > line 389 - The test here is different from closePath. What if they > were both "prev == DRAWING_OP_TO"? I am now using prev!=DRAWING_OP_TO (not ==, since it is supposed to execute finish() if no nonzero length lines have been fed to Stroker yet). In fact I have removed the "started" variable since it's equivalent to prev==DRAWING_OP_TO. > line 337 - shouldn't this just return? I don't think that empty lines > should modify the path at all. If this is a case of "moveto(x,y); > lineto(x,y)" then the finish() code should deal with the "path that > never went anywhere - i.e. drawing a dot", shouldn't it? The only > problem is that moveTo never set up omx,omy so finish will likely draw > something random. Perhaps if moveto (and closepath) simply set up > omx,omy to w,0 (or 0,-w if you prefer) then finish would do a > reasonable thing for empty paths? The reason I made it the way it is is to match what proprietary java does. If one tries to draw a path like moveTo(0,0);lineTo(100,-100); lineTo(100,-100);lineTo(0,-200); instead of ignoring the second lineTo(100,-100) it will instead behave as if it were something like lineTo(100.00001,-100.00001), and it will draw the join. Of course, just because proprietary java does it, it doesn't mean it's the right thing to do. So, should I still make it ignore segments of 0 length? > line 486 - this leaves the current point in a different place than > line 510, does that matter? No. 486 sets the first point of the consumer we're feeding to the first point of one of the offset curves. Line 510 makes sure the inner offsets of non parallel, consecutive segments join together nicely. 486 and 510 aren't really closely related. I don't even think 510 is necessary to generate correct fill volumes, but it makes outlines look nicer. I've attached 2 screenshots of the star Java2DDemo that show what 510 does. > line 283 - doesn't this simplify to?: > t = x10p*(y0-y0p) - y10p*(x0-x0p) > (source: http://local.wasp.uwa.edu.au/~pbourke/geometry/lineline2d/) > then calculating: > t = (...)/den; > can amortize the dividend from the following 2 calculations. I am using this t calculation now. I don't see how what I had simplified into this though. This is makes me think we were using a wrong equation, which is puzzling since I didn't notice any problems with drawing miters or quadratic beziers. Well, maybe I just made some mistake in trying to show they're equivalent. It doesn't matter. > My head started spinning when evaluating the parallel curve methods so > I'll stop here for now... Sorry about that. Is there anything I can do to make it easier? Thanks, Denis. ----- "Jim Graham" wrote: > Round 2 > > On 10/13/2010 3:40 PM, Jim Graham wrote: > > HI Denis, > > > > I'm just now getting down to the nitty gritty of your webrevs > (sigh). > > > > On 10/6/2010 1:36 PM, Denis Lila wrote: > >> > >> webrev: > >> http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ > > Stroker.java: > > You're doing the bulk > of > the work now so if they make sense to you now then it might be best to > > leave them alone, but they give me headaches trying to figure them > out. > I think you are right that it might help to create some "vector" > helper classes. I eventually got used to the naming by the time I was > > done with the file, but yikes - this will hurt the next guy that comes > > along to maintain the code. > The sx0,sy0,sdx,sdy variables are (reasonably) well named. > The x0,y0,pdx,pdy variables aren't consistent. Perhaps > cx0,cy0,cdx,cdy > for "current" would make more sense? > The mx0,my0,omx,omy variables are even further from the prior naming > conventions, what about smx,smy,cmx,cmy? > > line 394 - or prev = CLOSE to match the initial state? (I guess it > shouldn't really matter unless an upstream feeder has a bug.) > > ...jim -------------- next part -------------- A non-text attachment was scrubbed... Name: with510.png Type: image/png Size: 5209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: without510.png Type: image/png Size: 5181 bytes Desc: not available URL: From james.graham at oracle.com Tue Oct 19 00:31:20 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 18 Oct 2010 17:31:20 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <765647625.845461287436761968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <765647625.845461287436761968.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBCE6D8.4070206@oracle.com> Hi Denis, Looks like some great new work here! I'll try to keep the "pie in the sky" suggestions down now so we can get this in soon... On 10/18/2010 2:19 PM, Denis Lila wrote: > Hi Jim. > >> I'm just now getting down to the nitty gritty of your webrevs (sigh). > > Thanks. I hope it's not too bad. The code was great - what sucked was all of the cobwebs on my trig and curve math neurons. >> PiscesRenderingEngine.java: >> line 296 - is there an "epsilon" that we can use? "==" with floating >> point often fails with calculations. I was thinking maybe something more like the ULP stuff you did in one of the other files. I don't think 2 non-equal fp values can be subtracted and produce a value that is as small as MIN_VALUE unless you are subtracting 2 extremely tiny numbers. >> line 338 - null here too If this is now line 341 you still use "at" which might be a non-null identity transform. I'd just use "null" as some shapes might try to do some work if they get a non-null identity transform, but null pretty much tells them "it's identity". > I turned LengthComputer into an iterator. I think it's much cleaner now. > There's no longer any of that "scale every t in the array so that they become > valid parameters of the right subdivided curve". > It also uses less memory - just limit+1 curves. I guess I am clever enough ;) > (though unfortunately not clever enough to have thought of the idea myself). Interesting solution. I like it. line 248,251 - I thought it was a bug that you used 2 when I thought you should use 0, but it turns out that it doesn't matter because the last point of left is the first point of right. So, I'm not sure why you use 2, but it isn't a bug. However... You only need the array to be 8+6 if you take advantage of that shared point and store the 2 halves at "0..type" and "type-2 .. 2*type-2". Just a thought. No real bug here. > I found a problem with Dashing though. Curves like moveTo(0,0); > curveTo(498,498,499,499,500,500); are not handled well at all. > http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ is the link > with the new webrev. I have fixed this problem by doing binary search on > the results of the flattening. I really don't like this solution because > it does *a lot* more subdivisions than just flattening. Ah, I get it now. Hmmm. We can leave it for now, but I'm pretty sure we can detect cases like this because the sides of the control polygon are not relatively equal and only do the recursion if the control polygon indicates some amount of acceleration is happening. Leave it for now and make a mental note of this for later. Also, if there is acceleration then I think you could just solve either the X or the Y cubic for the necessary point (xs = interp(x0,x1,len/leafLen), solve for xs). One simplification to your binary search - since we know the length is relatively close to chord length, just compute the point on the curve at t and then use the distance formula to the start point to compute the arc length - no subdividing needed, just an eval and a linelen, and bsBuf goes away... ...jim > Regards, > Denis. > > ----- "Jim Graham" wrote: > >> HI Denis, >> >> On 10/6/2010 1:36 PM, Denis Lila wrote: >>> >>> webrev: >>> http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ >> >> TransformingPolyIOHelper should be in its own file - we consider more >> than one class per file to be bad form these days, especially if the >> class is used outside of that file. >> >> I'm a little troubled by how the PolyIOHelper fits into the design. >> It's odd to talk to the same object for both input and output. I have >> some ideas there, but I think I'll leave it for a followon email and >> effort. >> >> Dasher.java: >> > >> >> boolean needsMoveto; >> >> in moveTo and pathDone: >> if (firstSegBuf is not empty) { >> output moveto(sx,sy) >> output firstSegs >> } >> needsMoveto = true; // not needed in pathDone >> >> in goTo() { >> if (ON) { >> if (starting) { >> store it in firstSegBuf >> } else { >> if (needsMoveto) { >> output moveto(x0,y0); >> needsMoveto = false; >> } >> send it to output >> } >> } else { >> starting = false; >> needsMoveto = true; >> // nothing goes to output >> } >> } >> >> and in ClosePath: >> lineToImpl(sx, sy, LINE); >> if (firstSegBuf is not empty) { >> if (!ON) { // Or "if (needsMoveto)" >> output moveTo(sx, sy) >> } >> output firstSegs >> } >> >> I don't see a need for firstDashOn or fullCurve >> >> >> Stroker.java: >> >> line 129 - proof that miterLimit does not need to be scaled... ;-) >> >> I'm going to send this buffer of comments off now and continue on with >> >> Stroker.java in a future email... >> >> ...jim From james.graham at oracle.com Tue Oct 19 00:48:26 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 18 Oct 2010 17:48:26 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBCEADA.2040303@oracle.com> Hi Denis, On 10/18/2010 2:21 PM, Denis Lila wrote: >> Are you happy with the current variable names? > > Not really. The names you suggested are much better. I'm using them now. > As for making a vector class, I think we should push this and then decide. > It's absence has already done most of the damage it could possibly do, so > it's not an urgent matter. And besides, pushing a good version of this first > will make it easier to determine the performance impact of the vector class. Woohoo! Note comment needs updating at line 90. > I introduced a drawRoundCap method. This eliminated the side argument from > the round join drawing, which made it easier to eliminate the trig function > calls. I did this by using dot products to compute cosines (which was possible > because now Stroker takes only untransformed paths, and all lineWidths are the > same), and I used the double angle identities to compute any sines. > I came up with my own ways of detecting acute/obtuse angles and finding the centres > of angles ("my own" meaning I didn't look at any websites), and they consist of: > 1. if (omx * mx + omy * my)>= 0 then the angle is acute (line 200). > 2. I explain this in a comment in the file (line 208). Yay. And I can't believe you got that much mileage out of that one change. Cool! I'll verify the math tomorrow (it doesn't look hard, but I'm almost out of here). > I was tempted to do this. I didn't because the boolean versions will need > absolute coordinates, while the non boolean ones require relative ones. So > if the non boolean versions need to be called and all we have are the boolean > ones, 2 dummy arguments need to be supplied. However, I've looked at the code > more closesly, and it turns out that we only use the non boolean versions > from inside the boolean versions, so I've followed your suggestion (except > on emitLineTo, since the non boolean version of that is used quite a bit). OK, no problem. >> line 374 - why is this moveto here? Doesn't this break the joined >> path into 2 separate paths? Should this be a lineto? > > It does break it into 2 separate paths, but that's the correct behaviour > in this case. Mathematically speaking, the 2 offset curves are spearate > curves (despite any intersections). This changes when we use caps, but > when using closePath(), caps aren't drawn so weshould have 2 separate > paths. This is also the behaviour of oracle's closed source java (which > can be seen in one of the Java2Ddemo demos - the one that draws the offset > curves of a star with a vertical slider controlling the line width). Oh, duh! I get it. I had been looking at Dasher all day before that and so I was thinking of this in terms of "connecting the last dash to the first" which would, of course, be one continuous path, but this is Stroker so if you get a close then it has an inner and outer path. Sorry for the distraction. >> line 389 - The test here is different from closePath. What if they >> were both "prev == DRAWING_OP_TO"? > > I am now using prev!=DRAWING_OP_TO (not ==, since it is supposed to execute > finish() if no nonzero length lines have been fed to Stroker yet). In fact > I have removed the "started" variable since it's equivalent to prev==DRAWING_OP_TO. Interesting. I'll have to trace this later, but it sounds good. >> line 337 - shouldn't this just return? I don't think that empty lines >> should modify the path at all. If this is a case of "moveto(x,y); >> lineto(x,y)" then the finish() code should deal with the "path that >> never went anywhere - i.e. drawing a dot", shouldn't it? The only >> problem is that moveTo never set up omx,omy so finish will likely draw >> something random. Perhaps if moveto (and closepath) simply set up >> omx,omy to w,0 (or 0,-w if you prefer) then finish would do a >> reasonable thing for empty paths? > > The reason I made it the way it is is to match what proprietary java > does. If one tries to draw a path like moveTo(0,0);lineTo(100,-100); > lineTo(100,-100);lineTo(0,-200); instead of ignoring the second lineTo(100,-100) > it will instead behave as if it were something like lineTo(100.00001,-100.00001), > and it will draw the join. Of course, just because proprietary java does it, it > doesn't mean it's the right thing to do. So, should I still make it ignore segments > of 0 length? No, let me think about this some more. Compatible is a good default for now until we understand it fully so let's not derail for that. >> line 283 - doesn't this simplify to?: >> t = x10p*(y0-y0p) - y10p*(x0-x0p) >> (source: http://local.wasp.uwa.edu.au/~pbourke/geometry/lineline2d/) >> then calculating: >> t = (...)/den; >> can amortize the dividend from the following 2 calculations. > > I am using this t calculation now. I don't see how what I had simplified > into this though. This is makes me think we were using a wrong equation, which is > puzzling since I didn't notice any problems with drawing miters or quadratic beziers. > Well, maybe I just made some mistake in trying to show they're equivalent. It doesn't > matter. No, actually they are identical. If you expand it out, they are the same value - one just does more calculations. The only reason I noted it was that I googled for the formula and found this form and had to verify that the one that was there was the same - at which point I noted that the google version had fewer operations. >> My head started spinning when evaluating the parallel curve methods so >> I'll stop here for now... > > Sorry about that. Is there anything I can do to make it easier? No, I eventually muddled through it (in later emails...) ...jim From lana.steuck at oracle.com Tue Oct 19 03:14:47 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:14:47 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 8 new changesets Message-ID: <20101019031447.D580647261@hg.openjdk.java.net> Changeset: c1df968c4527 Author: cl Date: 2010-10-01 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/c1df968c4527 Added tag jdk7-b112 for changeset b852103caf73 ! .hgtags Changeset: aaf7fab2e8e4 Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/aaf7fab2e8e4 Added tag jdk7-b113 for changeset c1df968c4527 ! .hgtags Changeset: ed13debe9a5e Author: ohair Date: 2010-09-24 14:03 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/ed13debe9a5e 6987114: Fix top level "test" Makefile logic, add jdk/make/Makefile test target Reviewed-by: mchung ! Makefile Changeset: 27d945094f81 Author: ohair Date: 2010-09-24 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/27d945094f81 6987117: Add jprt test sets Reviewed-by: mchung ! make/jprt.properties Changeset: befdbb69155b Author: lana Date: 2010-09-25 10:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/befdbb69155b Merge Changeset: db9fe730f305 Author: lana Date: 2010-10-04 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/db9fe730f305 Merge Changeset: 27985a5c6e52 Author: lana Date: 2010-10-12 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/27985a5c6e52 Merge Changeset: 73c9023ae9b0 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/73c9023ae9b0 Added tag jdk7-b114 for changeset 27985a5c6e52 ! .hgtags From lana.steuck at oracle.com Tue Oct 19 03:14:52 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:14:52 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 3 new changesets Message-ID: <20101019031454.E286447262@hg.openjdk.java.net> Changeset: a89a6c5be9d1 Author: cl Date: 2010-10-01 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/a89a6c5be9d1 Added tag jdk7-b112 for changeset cc67fdc4fee9 ! .hgtags Changeset: 88fddb73c5c4 Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/88fddb73c5c4 Added tag jdk7-b113 for changeset a89a6c5be9d1 ! .hgtags Changeset: da7561d479e0 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/da7561d479e0 Added tag jdk7-b114 for changeset 88fddb73c5c4 ! .hgtags From lana.steuck at oracle.com Tue Oct 19 03:15:42 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:15:42 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 68 new changesets Message-ID: <20101019031743.0558F47263@hg.openjdk.java.net> Changeset: f8c5d1bdaad4 Author: ptisnovs Date: 2010-08-19 14:23 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f8c5d1bdaad4 6885308: The incorrect -XX:StackRedPages, -XX:StackShadowPages, -XX:StackYellowPages could cause VM crash Summary: Test minimal stack sizes given (also fixed linux compilation error) Reviewed-by: never, phh, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: ebfb7c68865e Author: dcubed Date: 2010-08-23 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ebfb7c68865e Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 4b29a725c43c Author: jrose Date: 2010-08-20 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4b29a725c43c 6912064: type profiles need to be exploited more for dynamic language support Reviewed-by: kvn ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/globals.hpp Changeset: 53dbe853fb3a Author: kvn Date: 2010-08-23 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/53dbe853fb3a 6896381: CTW fails share/vm/ci/bcEscapeAnalyzer.cpp:99, assert(_stack_height < _max_stack,"stack overflow") Summary: Check constant Tag type instead of calling get_constant(). Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 3e8fbc61cee8 Author: twisti Date: 2010-08-25 05:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3e8fbc61cee8 6978355: renaming for 6961697 Summary: This is the renaming part of 6961697 to keep the actual changes small for review. Reviewed-by: kvn, never ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/c1/Runtime1.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FindInCodeCachePanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/icache.cpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b4099f5786da Author: never Date: 2010-08-25 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b4099f5786da Merge ! src/share/vm/runtime/globals.hpp Changeset: c7004d700b49 Author: dholmes Date: 2010-08-25 21:29 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c7004d700b49 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Summary: Disable stack bounds checks in product mode other than for the initial thread Reviewed-by: coleenp, jcoomes, aph ! src/os/linux/vm/os_linux.cpp Changeset: 2528b5bd749c Author: kamg Date: 2010-08-27 15:05 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2528b5bd749c 6980262: Memory leak when exception is thrown in static initializer Summary: Use resource memory instead of c-heap for the exception message Reviewed-by: phh, jmasa ! src/share/vm/oops/instanceKlass.cpp Changeset: 8397081c7ac1 Author: dcubed Date: 2010-08-27 21:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8397081c7ac1 Merge Changeset: bba76f745fe6 Author: ysr Date: 2010-08-23 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/bba76f745fe6 6910183: CMS: assert(_index < capacity(),"_index out of bounds") Summary: Weakened a too-strong, off-by-one assert; added code to keep track of and report any overflows at appropriate level of verbosity. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: e967bad2a9ab Author: tonyp Date: 2010-08-25 08:44 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e967bad2a9ab 6941275: G1: The MemoryPools are incorrectly supported for G1 Summary: The way we were caluclating the max value meant that it might fluctuate during the run and this broke some assumptions inside the MBeans framework. This change sets the max value of each pool to -1, which means undefined according to the spec. Reviewed-by: mchung, johnc ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 8e5955ddf8e4 Author: jcoomes Date: 2010-08-25 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8e5955ddf8e4 6978300: G1: debug builds crash if ParallelGCThreads==0 Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 21c29458b334 Author: kevinw Date: 2010-08-27 16:57 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/21c29458b334 6980392: TEST_BUG: gc/6581734/Test6581734.java has typo Summary: simple correction in testcase Reviewed-by: mchung ! test/gc/6581734/Test6581734.java Changeset: 1c63587d925b Author: tonyp Date: 2010-08-27 13:34 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1c63587d925b 6980206: G1: assert(has_undefined_max_size, "Undefined max size"); Summary: An assert in the management.cpp is too strong and assumes the max size is always defined on memory pools, even when we don't need to use it. Reviewed-by: mchung, johnc ! src/share/vm/services/management.cpp Changeset: af586a7893cf Author: tonyp Date: 2010-08-27 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/af586a7893cf Merge Changeset: 75107ee8712f Author: tonyp Date: 2010-08-30 13:00 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/75107ee8712f Merge Changeset: f208bf19192d Author: tonyp Date: 2010-08-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f208bf19192d Merge Changeset: 14b92b91f460 Author: kvn Date: 2010-08-26 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/14b92b91f460 6976400: "Meet Not Symmetric" Summary: Use NULL as klass for TypeAryPtr::RANGE. Add klass verification into TypeAryPtr ctor. Reviewed-by: never ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 0878d7bae69f Author: twisti Date: 2010-08-27 01:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0878d7bae69f 6961697: move nmethod constants section before instruction section Summary: This is a preparation for 6961690. Reviewed-by: kvn, never ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: d6f45b55c972 Author: never Date: 2010-08-27 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d6f45b55c972 4809552: Optimize Arrays.fill(...) Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 14197af1010e Author: never Date: 2010-08-27 17:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/14197af1010e Merge ! src/share/vm/includeDB_compiler2 ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp Changeset: 114e6b93e9e1 Author: kvn Date: 2010-08-30 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/114e6b93e9e1 6980978: assert(mt == t->xmeet(this)) failed: meet not commutative Summary: Fix code in TypeAryPtr::xmeet() for constant array. Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 02f0a9b6f654 Author: never Date: 2010-08-30 17:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/02f0a9b6f654 6969586: OptimizeStringConcat: SIGSEGV in LoadNode::Value() Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: dee553c74493 Author: never Date: 2010-09-01 00:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/dee553c74493 Merge Changeset: 6ee479178066 Author: ikrylov Date: 2010-08-31 03:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6ee479178066 6979444: add command line option to print command line flags descriptions Summary: Implementation of a nonproduct boolean flag XX:PrintFlagsWithComments Reviewed-by: kamg, dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/macros.hpp Changeset: 1ab9e2cbfa0e Author: kamg Date: 2010-09-03 14:47 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1ab9e2cbfa0e 6870851: Bad frame_chop in StackMapTable crashes JVM Summary: Must check locals for null when processing chop frame Reviewed-by: dholmes, dcubed ! src/share/vm/classfile/stackMapTable.cpp Changeset: 40d7b43b6fe0 Author: kamg Date: 2010-09-07 11:38 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/40d7b43b6fe0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 07551f490c76 Author: kamg Date: 2010-09-07 11:50 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/07551f490c76 6982851: Add b107 machine classifications to jprt.properties file. Summary: See synopsis Reviewed-by: ohair ! make/jprt.properties Changeset: 40b1534a1dab Author: trims Date: 2010-09-08 18:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/40b1534a1dab Merge Changeset: 93193e632121 Author: trims Date: 2010-09-08 18:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/93193e632121 6983320: Fork HS19 to HS20 - renumber Major and build numbers of JVM Summary: Update the Major and Build numbers for HS20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ea175c1b79ce Author: dcubed Date: 2010-09-08 08:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ea175c1b79ce 6561870: 3/3 Long javac compile lines fail due to command line length issues (agent compiles?) Summary: Use javac's @filename construct to avoid long compile lines Reviewed-by: ohair, twisti, never Contributed-by: doko at ubuntu.com ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make Changeset: 30f67acf635d Author: thurka Date: 2010-09-11 08:18 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/30f67acf635d 6765718: Indicate which thread throwing OOME when generating the heap dump at OOME Summary: Emit a fake frame that makes it look like the thread is in the OutOfMemoryError zero-parameter constructor Reviewed-by: dcubed ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/utilities/debug.cpp Changeset: 8a8a7a014a12 Author: kamg Date: 2010-09-13 07:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8a8a7a014a12 Merge Changeset: 179464550c7d Author: ysr Date: 2010-09-10 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/179464550c7d 6983930: CMS: Various small cleanups ca September 2010 Summary: Fixed comment/documentation typos; converted some guarantee()s to assert()s. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/runtime/globals.hpp Changeset: eeade8e89248 Author: ysr Date: 2010-09-11 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/eeade8e89248 Merge ! src/share/vm/runtime/globals.hpp Changeset: 6eddcbe17c83 Author: johnc Date: 2010-09-13 10:00 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6eddcbe17c83 6981746: G1: SEGV with -XX:+TraceGen0Time Summary: Pass correct value for length to NumberSeq constructor. Guard dereferences of "body_summary" pointer with a NULL check. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 432d823638f7 Author: jcoomes Date: 2010-09-15 10:39 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/432d823638f7 6985022: update make/jprt.properties for new jdk7 tools Reviewed-by: ohair, kvn ! make/jprt.properties Changeset: 97fbf5beff7b Author: johnc Date: 2010-09-16 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/97fbf5beff7b Merge Changeset: f353275af40e Author: never Date: 2010-09-02 11:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f353275af40e 6981773: incorrect fill value with OptimizeFill Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: d5d065957597 Author: iveresov Date: 2010-09-03 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d5d065957597 6953144: Tiered compilation Summary: Infrastructure for tiered compilation support (interpreter + c1 + c2) for 32 and 64 bit. Simple tiered policy implementation. Reviewed-by: kvn, never, phh, twisti ! make/linux/Makefile ! make/solaris/Makefile + make/solaris/makefiles/reorder_TIERED_sparcv9 ! make/windows/build.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp + src/share/vm/runtime/simpleThresholdPolicy.cpp + src/share/vm/runtime/simpleThresholdPolicy.hpp + src/share/vm/runtime/simpleThresholdPolicy.inline.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp Changeset: ac4f710073ed Author: iveresov Date: 2010-09-07 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ac4f710073ed 6982921: assert(_entry_bci != InvocationEntryBci) failed: wrong kind of nmethod Summary: Assertion fails during print compilation because nmethod::print_on() calls osr_entry_bci() without checking that the method is an osr method. The fix adds an appropriate check. Reviewed-by: never, twisti ! src/share/vm/code/nmethod.cpp Changeset: 5e4f03302987 Author: never Date: 2010-09-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5e4f03302987 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: f9883ee8ce39 Author: never Date: 2010-09-08 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f9883ee8ce39 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp Changeset: 84713fd87632 Author: twisti Date: 2010-09-08 04:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/84713fd87632 6983073: fix compiler error with GCC 4.4 or newer on SPARC Reviewed-by: twisti Contributed-by: Matthias Klose ! src/cpu/sparc/vm/frame_sparc.hpp Changeset: 33a54060190d Author: twisti Date: 2010-09-09 01:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/33a54060190d Merge Changeset: a83b0246bb77 Author: twisti Date: 2010-09-09 05:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a83b0246bb77 6934483: GCC 4.5 errors "suggest parentheses around something..." when compiling with -Werror and -Wall Summary: These are minor changes fixing compile failure when -Wall -Werror flags are used under gcc 4.5. Reviewed-by: twisti, kvn, rasbold Contributed-by: Pavel Tisnovsky ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 7f9553bedfd5 Author: iveresov Date: 2010-09-11 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7f9553bedfd5 6984056: C1: incorrect code for integer constant addition on x64 Summary: Fix add/sub of constants to ints on x64 Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 3a294e483abc Author: iveresov Date: 2010-09-13 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3a294e483abc 6919069: client compiler needs to capture more profile information for tiered work Summary: Added profiling of instanceof and aastore. Reviewed-by: kvn, jrose, never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp Changeset: d20603ee9e10 Author: kvn Date: 2010-09-13 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d20603ee9e10 6984346: Remove development code in type.hpp Summary: Remove code which use UseNewCode in type.hpp Reviewed-by: never ! src/share/vm/opto/type.hpp Changeset: d257356e35f0 Author: jrose Date: 2010-09-13 23:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d257356e35f0 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Reviewed-by: never ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 065dd1ca3ab6 Author: never Date: 2010-09-14 14:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/065dd1ca3ab6 6982370: SIGBUS in jbyte_fill Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp + test/compiler/6982370/Test6982370.java Changeset: a8b66e00933b Author: kvn Date: 2010-09-14 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a8b66e00933b 6984368: Large default heap size does not allow to use zero based compressed oops Summary: take into account HeapBaseMinAddress and round down MaxPermSize Reviewed-by: never ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 18c378513575 Author: kvn Date: 2010-09-16 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/18c378513575 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/macros.hpp Changeset: 883a82d6d41d Author: acorn Date: 2010-09-10 12:36 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/883a82d6d41d 6942092: Loader-constraint test is failing Summary: Fix test string compare to match source update Reviewed-by: dcubed, phh ! test/runtime/6626217/Test6626217.sh Changeset: 6cde0ed1b568 Author: acorn Date: 2010-09-14 10:15 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6cde0ed1b568 Merge Changeset: 4094f07967ca Author: kamg Date: 2010-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/4094f07967ca 6974813: JVM needs to use demand loading for its DTrace probes Summary: Pass -xlazyload to the 'dtrace -G' invocation Reviewed-by: phh, ysr ! make/solaris/makefiles/dtrace.make Changeset: 728a287f6c20 Author: zgu Date: 2010-09-17 09:45 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/728a287f6c20 6981753: Rebrand vm vendor property settings Summary: Uses JDK_Version to determinate to set vm vendor to "Oracle Corporation" for JDK7 and later. Reviewed-by: kamg, ohair, coleenp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vm_version.cpp Changeset: 51640ecd89f8 Author: zgu Date: 2010-09-17 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/51640ecd89f8 Merge Changeset: 3babdb042f25 Author: kamg Date: 2010-09-17 19:45 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3babdb042f25 Merge Changeset: 60f88489896f Author: kamg Date: 2010-09-20 15:38 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/60f88489896f 6975210: java.lang.VerifyError in some of JCK tests Summary: Naked oop in verificationType::is_reference_assignable_from() Reviewed-by: never, kvn, coleenp ! src/share/vm/classfile/verificationType.cpp Changeset: 2966dab85b3e Author: dcubed Date: 2010-09-21 06:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2966dab85b3e 6985848: 3/4 fix for 6561870 causes sa-jdi.jar to be rebuilt every time Summary: Refine fix for 6561870 to only rebuild sa-jdi.jar when needed Reviewed-by: never, ohair, coleenp ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make Changeset: a25394352030 Author: kamg Date: 2010-09-22 12:54 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a25394352030 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9bdbd693dbaa Author: trims Date: 2010-09-24 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9bdbd693dbaa Merge Changeset: b2045e0af26e Author: trims Date: 2010-09-24 00:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b2045e0af26e 6987149: Fix incorrect Oracle copyright header in make/templates files Summary: Minor fix to first line of template copyright files Reviewed-by: ohair ! make/templates/bsd-header ! make/templates/gpl-cp-header ! make/templates/gpl-header Changeset: 5511edd5d719 Author: iveresov Date: 2010-09-30 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5511edd5d719 6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler Summary: The workaround changes the scope of the variable Reviewed-by: phh, ysr, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: beef35b96b81 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/beef35b96b81 Added tag jdk7-b112 for changeset 5511edd5d719 ! .hgtags Changeset: 68d6141ea19d Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/68d6141ea19d Added tag jdk7-b113 for changeset beef35b96b81 ! .hgtags Changeset: 477faa484f91 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/477faa484f91 Added tag jdk7-b114 for changeset 68d6141ea19d ! .hgtags From lana.steuck at oracle.com Tue Oct 19 03:18:17 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:18:17 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 3 new changesets Message-ID: <20101019031817.CB2E147264@hg.openjdk.java.net> Changeset: bc0c84ce54c3 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/bc0c84ce54c3 Added tag jdk7-b112 for changeset 1b0525424288 ! .hgtags Changeset: d57197d22c2b Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/d57197d22c2b Added tag jdk7-b113 for changeset bc0c84ce54c3 ! .hgtags Changeset: dc1612e1d3ac Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/dc1612e1d3ac Added tag jdk7-b114 for changeset d57197d22c2b ! .hgtags From lana.steuck at oracle.com Tue Oct 19 03:18:22 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:18:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 3 new changesets Message-ID: <20101019031822.D07D147265@hg.openjdk.java.net> Changeset: d35c94fd2236 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/d35c94fd2236 Added tag jdk7-b112 for changeset 8e0f0054817f ! .hgtags Changeset: 400f494c81c5 Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/400f494c81c5 Added tag jdk7-b113 for changeset d35c94fd2236 ! .hgtags Changeset: 824cc44bd6eb Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/824cc44bd6eb Added tag jdk7-b114 for changeset 400f494c81c5 ! .hgtags From lana.steuck at oracle.com Tue Oct 19 03:20:17 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:20:17 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 72 new changesets Message-ID: <20101019033223.9216147266@hg.openjdk.java.net> Changeset: 61d3b9fbb26b Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/61d3b9fbb26b Added tag jdk7-b112 for changeset b53f226b1d91 ! .hgtags Changeset: 621be994f8d9 Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/621be994f8d9 Added tag jdk7-b113 for changeset 61d3b9fbb26b ! .hgtags Changeset: d0cfe52db29e Author: lana Date: 2010-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d0cfe52db29e Merge Changeset: d32203d5a47c Author: ant Date: 2010-09-27 16:11 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d32203d5a47c 6505819: Provide traverseIn method for sun.awt.EmbeddedFrame Reviewed-by: dcherepanov, art ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: d21c9804c512 Author: ant Date: 2010-09-27 17:38 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d21c9804c512 6886678: Clicking on parent JFrame's client area does not switch focus from JWindow to JFrame on Windows Reviewed-by: dcherepanov, art ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java Changeset: 40fa33254fc6 Author: art Date: 2010-09-28 14:57 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/40fa33254fc6 6987896: Modal dialogs resumes the calling thread before it's hidden Reviewed-by: anthony ! src/share/classes/java/awt/Dialog.java Changeset: 6994facc6a8b Author: omajid Date: 2010-09-28 10:16 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6994facc6a8b 6987945: XDecoratedPeer shouldn't allow to resize a frame to zero size Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java Changeset: a601a6711ef8 Author: lana Date: 2010-09-28 00:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a601a6711ef8 Merge - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/tools/launcher/VerifyExceptions.java Changeset: 8936ad6b154e Author: lana Date: 2010-09-28 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8936ad6b154e Merge Changeset: 3caf15616f46 Author: dav Date: 2010-09-30 14:50 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3caf15616f46 6694729: obsolete link in ActionEvent javadoc Reviewed-by: art ! src/share/classes/java/awt/event/ActionEvent.java Changeset: 8afd49c55619 Author: art Date: 2010-09-30 21:06 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8afd49c55619 6860270: JVM crash is occuring when verifying whether Browse action is supported on WinVista 64 bit Reviewed-by: anthony, uta ! src/windows/native/sun/windows/awt_Desktop.cpp Changeset: b0d1ef182650 Author: dav Date: 2010-10-01 15:10 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b0d1ef182650 6829267: Regression test java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java fails in RHEL5 Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java Changeset: 70a73fc061d9 Author: dav Date: 2010-10-04 11:40 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/70a73fc061d9 6847155: test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java fails Reviewed-by: denis ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java Changeset: a014255d826c Author: anthony Date: 2010-10-04 16:12 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a014255d826c 6987233: FileDialog.getDirectory() should add a trainling slash when GTK FileDialog is used Summary: Add the trailing slash if it's absent Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: d147113a36fd Author: anthony Date: 2010-10-04 16:21 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d147113a36fd 6982279: java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed due to NPE Summary: Rely on the WWindowPeer.getTranslucentGraphics()'s return value Reviewed-by: art, dcherepanov ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 63b6059eebd0 Author: lana Date: 2010-10-04 14:36 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/63b6059eebd0 Merge Changeset: e2050786c3ce Author: alexp Date: 2010-09-17 22:50 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e2050786c3ce 6982661: Complete JLayer component Reviewed-by: malenkov ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: a463040967f2 Author: alexp Date: 2010-09-17 23:00 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a463040967f2 6606019: NPE and IAE are interchanged in specification for GroupLayout.Group class Reviewed-by: rupashka ! src/share/classes/javax/swing/GroupLayout.java Changeset: cdd64925de04 Author: alexp Date: 2010-09-17 23:09 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cdd64925de04 6632953: MetalComboBoxUI.getBaseline(JComponent, int, int) throws IAE for valid width/height Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java + test/javax/swing/JComboBox/6632953/bug6632953.java Changeset: a8ec7a461254 Author: alexp Date: 2010-09-17 23:16 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a8ec7a461254 6576054: NullPointerException when closing tooltip by pressing esc Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java Changeset: e753db9c4416 Author: alexp Date: 2010-09-17 23:21 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e753db9c4416 4330950: Lost newly entered data in the cell when resizing column width Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java Changeset: 76b39a4964fa Author: alexp Date: 2010-09-17 23:34 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/76b39a4964fa 6542335: different behavior on knob of scroll bar between 1.4.2 and 5.0 Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java + test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: 002495e6aecb Author: peterz Date: 2010-09-21 10:03 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/002495e6aecb 6960126: With GTK L&F JDesktopPane substitutes set desktop manager Reviewed-by: malenkov ! src/share/classes/javax/swing/JDesktopPane.java Changeset: c650dd9e6be2 Author: peterz Date: 2010-09-21 10:04 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c650dd9e6be2 6978052: No appropriate CCC request for listed JDK 7 changes in javax.swing.plaf.synth package (b84) Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: 39351e11b8f9 Author: naoto Date: 2010-09-23 20:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/39351e11b8f9 6986612: pit jdk7 b112: java.util.Locale getDisplayVariant() sqe test getDisplayVariantTests.java fails Reviewed-by: dougfelt Contributed-by: Yoshito Umaoka ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/BaseLocale.java Changeset: b57ca6031a35 Author: lana Date: 2010-09-26 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b57ca6031a35 Merge - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/tools/launcher/VerifyExceptions.java Changeset: 278c8daa3075 Author: malenkov Date: 2010-09-27 13:38 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/278c8daa3075 6976577: JCK7 api/java_beans/EventSetDescriptor/descriptions.html#Ctor1 fails since jdk7 b102 Reviewed-by: peterz ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/6976577/Test6976577.java + test/java/beans/Introspector/6976577/test/Accessor.java Changeset: bbadb9484f53 Author: omajid Date: 2010-09-27 11:30 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/bbadb9484f53 6986968: Crash on XIM server restart Summary: Free XIM data structures on DestroyXIMCallback Reviewed-by: naoto ! src/solaris/native/sun/awt/awt_InputMethod.c Changeset: 0ca4ae74cf44 Author: malenkov Date: 2010-09-27 21:07 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0ca4ae74cf44 6986450: javax/swing/JTable/Test6888156.java test is failing against jdk7 just on windows Reviewed-by: alexp ! test/javax/swing/JTable/Test6888156.java Changeset: 75a0f7b47024 Author: naoto Date: 2010-09-28 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/75a0f7b47024 6915621: (rb) ResourceBundle.getBundle() deadlock when called inside a synchronized thread Reviewed-by: okutsu ! src/share/classes/java/util/ResourceBundle.java Changeset: 990bbd005f28 Author: malenkov Date: 2010-09-30 20:21 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/990bbd005f28 6982753: javax/swing/JTextArea/6940863/bug6940863.java should be modified Reviewed-by: alexp ! test/javax/swing/JTextArea/6940863/bug6940863.java Changeset: 76edcef04379 Author: okutsu Date: 2010-10-04 13:05 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/76edcef04379 6955776: (tz) Windows-only: tzmappings needs update for KB981793 6929185: (tz) Windows-only: tzmappings needs update for KB979306 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: b210ae2a8e74 Author: lana Date: 2010-10-04 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b210ae2a8e74 Merge Changeset: 7794d718ffe2 Author: lancea Date: 2010-09-17 13:23 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7794d718ffe2 6983452: SyncProvider issue for JoinRowSet implementation Reviewed-by: darcy, ohair ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java Changeset: 1cb444a3d5cd Author: lancea Date: 2010-09-17 13:26 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1cb444a3d5cd 6984864: Exception when running acceptChanges with custom SyncProvider Reviewed-by: darcy, ohair ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java Changeset: 095a5e5a025a Author: lancea Date: 2010-09-17 13:30 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/095a5e5a025a 6985400: DatabaseMetaData.generatedKeyAlwaysReturned, "indexe(s)" should be "index(es)" Reviewed-by: darcy, ohair ! src/share/classes/java/sql/DatabaseMetaData.java Changeset: 291a5c52f9d0 Author: lancea Date: 2010-09-17 13:33 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/291a5c52f9d0 6985725: RowSetProvider has typo for the property javax.sql.rowset.RowSetFactory in the javadoc Reviewed-by: darcy, ohair ! src/share/classes/javax/sql/rowset/RowSetProvider.java Changeset: 605b327f4830 Author: mchung Date: 2010-09-17 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/605b327f4830 6888546: restore System.initializeSystemClasses Summary: restore System.initializeSystemClasses prior to fix for 6797688 Reviewed-by: alanb ! src/share/classes/java/lang/System.java Changeset: 48d7f8c4cd60 Author: martin Date: 2010-09-17 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/48d7f8c4cd60 6981138: (process) Process.waitFor() may hang if subprocess has live descendants (lnx) Summary: Do exit status handling before trying to close streams Reviewed-by: alanb, dholmes ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! test/java/lang/ProcessBuilder/Basic.java Changeset: b5d37597c815 Author: martin Date: 2010-09-17 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b5d37597c815 6981157: Improve UnknownHostException with EAI error details and other cleanups Summary: generify; remove compiler warnings, typos, casts; return status information via gai_strerror when getaddrinfo fails; show full stack of native failures Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h Changeset: 0d78b3eedecc Author: lancea Date: 2010-09-18 06:09 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0d78b3eedecc 6984044: RowSet source needs to rebrand vendor references Reviewed-by: darcy, ohair ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java ! src/share/classes/com/sun/rowset/providers/RIXMLProvider.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/rowset.properties ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/sql/rowset/spi/package.html Changeset: 902486a8e414 Author: dl Date: 2010-09-20 18:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/902486a8e414 6981113: Add ConcurrentLinkedDeque Summary: Extend techniques developed for ConcurrentLinkedQueue and LinkedTransferQueue to implement a non-blocking concurrent Deque with interior removes. Reviewed-by: martin, dholmes, chegar ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/IteratorAtEnd.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/Deque/ChorusLine.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java Changeset: cd4aad589b3f Author: chegar Date: 2010-09-21 15:58 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cd4aad589b3f 6672144: HttpURLConnection.getInputStream sends POST request after failed chunked Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpClient/StreamingRetry.java Changeset: f5d25402ed53 Author: dl Date: 2010-09-21 16:06 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f5d25402ed53 6986050: Small clarifications and fixes for ForkJoin Summary: Clarify FJ.get on throw InterruptedException, propagate ThreadFactory, shutdown transition Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/RecursiveAction.java Changeset: 4927d1319b2f Author: dcubed Date: 2010-09-22 07:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4927d1319b2f 6949710: 3/3 the GC'able nature of Logging objects needs to be made brutally clear Summary: Add words in more places to make it clear that Logger objects are GC'able unless there is a strong reference. Reviewed-by: dholmes, andrew ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java Changeset: 4db5c4867a78 Author: ohair Date: 2010-09-22 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4db5c4867a78 6946527: rebranding system properties per Oracle Requirements (vendor) Summary: Changes from "Sun Microsystems, Inc." to "Oracle Corporation" in the java.vendor, java.specification.vendor and java.vendor.url Java system properties. Also change of Windows COMPANY file property from "Oracle" to "Oracle Corporation". Reviewed-by: lancea, flar ! make/common/shared/Defs.gmk ! src/share/native/java/lang/System.c Changeset: 378ea143ff5f Author: ohair Date: 2010-09-22 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/378ea143ff5f Merge Changeset: ca630e91d473 Author: weijun Date: 2010-09-23 10:46 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ca630e91d473 6982971: TEST failure: com/sun/security/sasl/ntlm/NTLMTest.java Reviewed-by: wetmore ! test/com/sun/security/sasl/ntlm/NTLMTest.java Changeset: 60cff062f66d Author: mchung Date: 2010-09-22 21:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/60cff062f66d 6984036: servicetag vendor rebranding issues Summary: Update product_vendor field to use java.vendor system property Reviewed-by: ohair ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/RegistrationData.java ! src/share/classes/com/sun/servicetag/Registry.java ! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/Util.java ! test/com/sun/servicetag/environ.properties ! test/com/sun/servicetag/missing-environ-field.xml ! test/com/sun/servicetag/newer-registry-version.xml ! test/com/sun/servicetag/registration.xml ! test/com/sun/servicetag/servicetag1.properties ! test/com/sun/servicetag/servicetag2.properties ! test/com/sun/servicetag/servicetag3.properties ! test/com/sun/servicetag/servicetag4.properties ! test/com/sun/servicetag/servicetag5.properties Changeset: 9a837f410672 Author: ohair Date: 2010-09-24 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9a837f410672 6987117: Add jprt test sets Reviewed-by: mchung ! make/jprt.properties Changeset: 8503c7f3a354 Author: ohair Date: 2010-09-24 14:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8503c7f3a354 6987114: Fix top level "test" Makefile logic, add jdk/make/Makefile test target 6987113: Remove SCCS logic from makefiles Reviewed-by: mchung ! make/Makefile ! make/common/Cscope.gmk ! make/common/Defs.gmk - make/common/Rules-SCCS.gmk ! make/common/shared/Defs-utils.gmk ! test/ProblemList.txt Changeset: 9eb9485ec45b Author: weijun Date: 2010-09-25 10:21 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9eb9485ec45b 6986868: TEST failure: sun/security/tools/jarsigner/crl.sh Reviewed-by: ohair ! test/sun/security/tools/jarsigner/crl.sh Changeset: 4b0fdb9f7cfe Author: lana Date: 2010-09-25 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4b0fdb9f7cfe Merge ! make/java/java/FILES_java.gmk - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java ! src/share/native/java/lang/System.c - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp Changeset: 7b2b0131fa61 Author: lancea Date: 2010-09-27 18:05 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7b2b0131fa61 6987638: javadoc update to RowSetProvider and Statement Reviewed-by: darcy, alanb ! src/share/classes/java/sql/Statement.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java Changeset: b3a4add96d45 Author: michaelm Date: 2010-09-28 11:59 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b3a4add96d45 6550798: Using InputStream.skip with ResponseCache will cause partial data to be cached Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/6550798/TestCache.java + test/sun/net/www/protocol/http/6550798/test.java Changeset: 4b637d890b6c Author: michaelm Date: 2010-09-28 12:04 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4b637d890b6c Merge Changeset: a43232b264cb Author: michaelm Date: 2010-09-28 14:36 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a43232b264cb 6987927: can't use -Dfile.encoding=Cp037 in net test Reviewed-by: chegar - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 26c6ee936f63 Author: weijun Date: 2010-09-29 15:26 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/26c6ee936f63 6988163: sun.security.util.Resources dup and a keytool doc typo Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java Changeset: 570f825ad872 Author: chegar Date: 2010-09-29 17:33 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/570f825ad872 6987461: Handle leak when enabling java.net.useSystemProxies Summary: Release the registry key handle if ProxyEnable is 0 Reviewed-by: michaelm ! src/windows/native/sun/net/spi/DefaultProxySelector.c Changeset: 04d9b09dbef9 Author: alanb Date: 2010-09-30 14:48 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/04d9b09dbef9 6988037: fileClose prints debug message is close fails Reviewed-by: kevinw, forax ! src/solaris/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.c Changeset: 1fe397df4aaa Author: alanb Date: 2010-09-30 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1fe397df4aaa Merge - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 9a8022905f6a Author: lancea Date: 2010-10-01 14:36 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9a8022905f6a 6988993: Address Findbugs warnings for the use of String Constructor Reviewed-by: ohair ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: f439d8b1e84a Author: alanb Date: 2010-10-02 12:59 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f439d8b1e84a 6979526: (file) java/nio/file/FileStore/Basic.java fails if the same file system is mounted more than once Reviewed-by: kevinw, forax ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: a6591c8b046d Author: alanb Date: 2010-10-02 12:59 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a6591c8b046d Merge Changeset: 81b0c1e3d5a7 Author: alanb Date: 2010-10-03 19:39 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/81b0c1e3d5a7 6907737: (file) FileVisitor and Files.walkFileTree issues Reviewed-by: sherman + src/share/classes/java/nio/file/FileSystemLoopException.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitOption.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/WatchDir.java + test/java/nio/file/Files/MaxDepth.java ! test/java/nio/file/Files/Misc.java ! test/java/nio/file/Files/PrintFileTree.java ! test/java/nio/file/Files/SkipSiblings.java ! test/java/nio/file/Files/TerminateWalk.java ! test/java/nio/file/Files/WalkWithSecurity.java ! test/java/nio/file/Files/walk_file_tree.sh ! test/java/nio/file/TestUtil.java Changeset: b8af3bab5dbf Author: alanb Date: 2010-10-04 14:17 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b8af3bab5dbf 6989190: SO_SNDBUF/SO_RCVBUF limits should only be checked when setsockopt fails (sol) Reviewed-by: chegar, michaelm ! src/solaris/native/java/net/net_util_md.c ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java Changeset: ffaf6a35b895 Author: lancea Date: 2010-10-04 13:04 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ffaf6a35b895 6989139: Address JDBC Findbugs where Number type Constructor are used Reviewed-by: ohair ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java Changeset: d5fc514976fa Author: lana Date: 2010-10-04 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d5fc514976fa Merge - make/common/Rules-SCCS.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 4a513df0df12 Author: sherman Date: 2010-10-08 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4a513df0df12 6990846: Demo: NIO.2 filesystem provider for zip/jar archives Summary: The first drop of the zip filesystem provider, as a separate demo Reviewed-by: alanb ! make/mkdemo/Makefile + make/mkdemo/nio/Makefile + make/mkdemo/nio/zipfs/Makefile + src/share/demo/nio/zipfs/Demo.java + src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider + src/share/demo/nio/zipfs/README.txt + src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java + src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java + test/demo/zipfs/Basic.java + test/demo/zipfs/PathOps.java + test/demo/zipfs/ZipFSTester.java + test/demo/zipfs/basic.sh Changeset: e250cef36ea0 Author: lana Date: 2010-10-12 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e250cef36ea0 Merge - make/common/Rules-SCCS.gmk - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh Changeset: 0613978371d8 Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0613978371d8 Added tag jdk7-b114 for changeset e250cef36ea0 ! .hgtags Changeset: b9c24a76093d Author: lana Date: 2010-10-18 12:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b9c24a76093d Merge - make/common/Rules-SCCS.gmk ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh From lana.steuck at oracle.com Tue Oct 19 03:34:15 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 19 Oct 2010 03:34:15 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 19 new changesets Message-ID: <20101019033455.3EF0E47267@hg.openjdk.java.net> Changeset: 6dbd2d869b05 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6dbd2d869b05 Added tag jdk7-b112 for changeset fd2579b80b83 ! .hgtags Changeset: cd3235a96b6c Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/cd3235a96b6c Added tag jdk7-b113 for changeset 6dbd2d869b05 ! .hgtags Changeset: 50f9ac2f4730 Author: mcimadamore Date: 2010-09-18 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/50f9ac2f4730 6980862: too aggressive compiler optimization causes stale results of Types.implementation() Summary: use a scope counter in order to determine when/if the implementation cache entries are stale Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: 77cc34d5e548 Author: mcimadamore Date: 2010-09-18 09:56 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/77cc34d5e548 5088624: cannot find symbol message should be more intelligent Summary: Resolve.java should keep track of all candidates found during a method resolution sweep to generate more meaningful diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/T6326754.out ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java + test/tools/javac/diags/examples/InapplicableSymbols.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InferArgsLengthMismatch.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out Changeset: 0c1ef2af7a8e Author: mcimadamore Date: 2010-09-18 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0c1ef2af7a8e 6863465: javac doesn't detect circular subclass dependencies via qualified names Summary: class inheritance circularity check should look at trees, not just symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/6863465/T6863465a.java + test/tools/javac/6863465/T6863465a.out + test/tools/javac/6863465/T6863465b.java + test/tools/javac/6863465/T6863465b.out + test/tools/javac/6863465/T6863465c.java + test/tools/javac/6863465/T6863465c.out + test/tools/javac/6863465/T6863465d.java + test/tools/javac/6863465/T6863465d.out + test/tools/javac/6863465/TestCircularClassfile.java ! test/tools/javac/CyclicInheritance.out ! test/tools/javac/NameCollision.out Changeset: da7ca56d092c Author: sundar Date: 2010-09-22 20:53 +0530 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/da7ca56d092c 6587674: NoClassdefFound when anonymously extending a class. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6587674.java Changeset: 3eea38ce151c Author: jjg Date: 2010-09-22 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/3eea38ce151c 6986772: langtools netbeans build should use ${ant.core.lib} instead of ${ant.home}/lib/ant.jar Reviewed-by: ohair ! make/netbeans/langtools/build.xml Changeset: 827d87221959 Author: lana Date: 2010-09-25 12:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/827d87221959 Merge Changeset: f6fe12839a8a Author: jjg Date: 2010-09-27 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f6fe12839a8a 6890226: javah -version is broken Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties + src/share/classes/com/sun/tools/javah/resources/version.properties-template + test/tools/javah/VersionTest.java Changeset: 3c9b64e55c5d Author: jjg Date: 2010-09-27 14:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/3c9b64e55c5d 6877202: Elements.getDocComment() is not getting JavaDocComments 6861094: javac -Xprint does not print comments 6985205: access to tree positions and doc comments may be lost across annotation processing rounds Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java + src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/6302184/T6302184.out ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/api/TestJavacTaskScanner.java - test/tools/javac/processing/Xprint.java + test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java + test/tools/javac/processing/model/util/elements/doccomments/a/First.java + test/tools/javac/processing/model/util/elements/doccomments/z/Last.java + test/tools/javac/processing/options/Xprint.java + test/tools/javac/processing/options/XprintDocComments.java + test/tools/javac/processing/options/XprintDocComments.out + test/tools/javac/tree/TreePosRoundsTest.java Changeset: d4df3b6ee729 Author: jjg Date: 2010-09-27 17:28 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d4df3b6ee729 6986246: Trees object is round-specific Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java ! test/tools/javac/tree/TreePosRoundsTest.java Changeset: 28b021bb889f Author: sundar Date: 2010-09-28 22:46 +0530 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/28b021bb889f 6967842: Element not returned from tree API for ARM resource variables. Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: f94af0667151 Author: jjg Date: 2010-09-29 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f94af0667151 6502392: Invalid relative names for Filer.createResource and Filer.getResource Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/processing/filer/TestInvalidRelativeNames.java Changeset: d2aaaec153e8 Author: darcy Date: 2010-09-29 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d2aaaec153e8 6983738: Use a JavacTestingAbstractProcessor Reviewed-by: jjg + test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6365040/ProcBar.java ! test/tools/javac/processing/6365040/ProcFoo.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6511613/DummyProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestGetResource2.java ! test/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/tools/javac/processing/filer/TestLastRound.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestAnonSourceNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/processing/werror/WError1.java ! test/tools/javac/processing/werror/WErrorGen.java ! test/tools/javac/processing/werror/WErrorLast.java Changeset: 7b413ac1a720 Author: jjg Date: 2010-09-30 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/7b413ac1a720 6988436: Cleanup javac option handling Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Source.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/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/Options.java Changeset: 232919708730 Author: alanb Date: 2010-10-03 19:40 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/232919708730 6907737: (file) FileVisitor and Files.walkFileTree issues Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java Changeset: 2c321dcb1edc Author: lana Date: 2010-10-04 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2c321dcb1edc Merge - test/tools/javac/processing/Xprint.java Changeset: e4e7408cdc5b Author: lana Date: 2010-10-12 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/e4e7408cdc5b Merge - test/tools/javac/processing/Xprint.java Changeset: 01e8ac5fbefd Author: cl Date: 2010-10-14 19:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/01e8ac5fbefd Added tag jdk7-b114 for changeset e4e7408cdc5b ! .hgtags From dlila at redhat.com Tue Oct 19 17:38:21 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 19 Oct 2010 13:38:21 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1041772591.938081287509897553.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <717863655.938101287509901743.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. If I haven't replied to a suggestion, that means I've implemented and I thought it was a good idea, so I don't have anything to say about it. > line 238: If X0,Y0,XL,COUNT were bumped up by 1 then you could just > reuse "SLOPE" from the linear indices - just a thought. True, but I would like to preserve the naming differences. CURSLOPE makes it clear that the slope will change. > lines 521,527,533: Why are these executed twice? You call these > methods again after the "initialize common fields" code. That seems like > double the work just to maybe save 4 lines of shared code? Maybe put the 4 > lines of shared code in a helper function that all of the init() > methods call? Wow, I can't believe these slipped past me. What happened was that I used to initialize the type specific fields first, to avoid having 2 switch statements. However, that didn't work out (for reasons explained in the comment), so I needed 2 switches after all. I guess I just forgot to delete the init* calls in the first one. I'm pretty sure that the init* calls in the first switch can just be deleted. In fact, it might be a bug to leave them there, since init* calls the AFD iteration function. If we have 2 init calls, the AFD function will be called twice, so this is probably a bug. > line 37: If it can't be instantiated, why does it take arguments? Another mistake when cutting, pasting, and modifying old code. > getTransformedPoints isn't used? > getUntransformedPoints isn't used? > fillWithIndxes(float) isn't used? > evalQuad isn't used? (Though it does provide symmetry with evalCubic > which is used) > getFlatness* aren't used? > ptSegDistSq isn't used? Should I get rid of these? I wanted to do it, but I wanted to wait until just before pushing because I was afraid I'd start needing them again at some point in the future. > line 105: There is a closed form solution to cubic roots. I > unfortunately used a bad version in CubicCurve2D.solveCubic and I > don't remember if I ever went back and fixed it (it may even have been > "Cardano's method" for all I know). There are versions out there > which do work better. The problem with the one in CC2D was that I copied it > out of Numerical Recipes in C and apparently the author somehow > assumed that all cubics would have 1 or 3 roots, but a cubic of the form > (x-a)(x-a)(x-b) has 2 roots. D'oh! While I did find other > implementations out there on the net, in the end fixing the closed > form solution seemed wrought with issues since many of the tests would use > radically different approaches depending on tiny changes in one of the > intermediate results and so I worried about FP error even in doubles > possibly skewing the results. I think you should leave your code in > there, but I wanted to fill you in on other possibities. I looked around for a closed form solution but I only found variations of the one on wikipedia. I decided not to implement it because it looked like I was going to have to deal with complex numbers and I didn't want to do that. It also didn't seem like it would be a lot faster than Newton's method which actually does very few iterations (4-6 if I remember correctly). But I'll keep this in mind, and if I find a good implementation of a closed form formula, I'll use it. > line 566: shouldn't horizontal lines be ignored? they don't affect > rasterization. They don't, but it's important to always update the current position, otherwise, if we get something like: moveto(0,0),lineTo(100,0), lineTo(100,100), instead of recording a vertical line from 100,0 to 100,100 we would record a diagonal line from 0,0 to 100,100. The actual ignoring is done in the six lines following these two. The link is still http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ I thoroughly tested it yet, but Java2DDemo looks good. Thanks, Denis. ----- "Jim Graham" wrote: > Round 3... > > On 10/6/2010 1:36 PM, Denis Lila wrote: > > > > webrev: > > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ > > I'm going to set the rest of Stroker.java aside for a moment and focus > > on other areas where I have some better knowledge... > > Renderer.java: > > lines 83, 91, 99: can't these be folded into the prior loops? You can > > update their Y while searching for the [eqc]hi value. > > lines 178,192: indent to the preceding "("? (Also, I'm a big fan of > moving the "{" to a line by itself if an conditional or argument list > > was wrapped to more than 1 line - the 2D team tends to use that style > > everywhere in the 2D code...) > > line 193: add fieldForCmp here instead of every time in the loop? > (The > compiler will probably/hopefully do that anyway) > > line 574: indentation? > > line 612: delete? Or will this be making a comeback sometime? > > lines 624,626: indentation? > > lines 724,725: doesn't the assert false omit these? I usually throw > an > InternalError in cases like this with a description of what went > wrong. > > I've read up through the use of the cache in emitRow(). I'll continue > > with reviewing the cache in the next set, meanwhile I also took a look > > at the helper classes... > > Helpers.java: > > BezCurve.java: > > Didn't you get a complaint that this class is defined in a file of the > > wrong name? Maybe the compiler doesn't complain because the class > isn't > public, but one of the names should change to match. > > line 59: I'd throw an internal error and the compiler would be > appeased. > > line 35: If you make this a "create" factory then it can leverage the > > code in the existing constructors - just a thought. > > I'll stop here and hit send - not much left after this round... > > ...jim From dlila at redhat.com Tue Oct 19 17:40:05 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 19 Oct 2010 13:40:05 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1226603888.934581287508081666.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <241845924.938501287510005312.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > line 249,257 - these corrections are exponential compared to the > sample code on the wikipedia page - was that the "slight modification" that > you mentioned in the comments? That's right. This turned out to be necessary because a lot of the numbers dealt with in this code are very large. Increasing the scaling factor exponentially makes it a lot faster and it doesn't behave much differently when it gets close to the root since by that point side tends to change sign so it never becomes larger than 2 or 3. > ROCsq - I looked at the wikipedia article and it wasn't clear how it > directly related to your function since the article is dealing with > the curvature of a function graphed against its own t, but you are dealing > with 2 parametric equations combined and graphed against each other. > I think I'm going to have to just trust you on this one for now. :-( http://en.wikipedia.org/wiki/Radius_of_curvature_%28applications%29 Did you look at the above wikipedia article? When researching I came across 2 of them, and one of them only mentions natural parameterizations, but the above has the general equation for a R->Rn function, then below that they have the special case where n=2, x(t)=t, and y(t)=f(t). I used the first equation on that page. Actually, I wrote a simple program to make sure the radius of curvature function was correct. I have attached it. It's not a proof, but I think it is convincing. Just hold down the mouse button and move it horizontally. This will change the t value on the curve and the circle drawn will have radius equal to Math.sqrt(ROCsq). You can also change the control points of the curve. There's a bug where when you run it the window is really tiny, so you have to manually resize it and maximize it. > lines 621-626 and 643-646 - I'm not sure what the derivation of these > lines are. I tried to do my own equations, but I seem to be heading > in a different direction than you used and it didn't seem like I was > going to converge. What equations did you set up to solve to get these > calculations? From what I can see we have: > - new p1,p4 are calculated > - new p(0.5) is calculated > - the corresponding dx,dy at t=0,0.5,1 (gives slopes) > - slopes at t=0, 0.5 and 1 should be the same for all curves > and what you are trying to compute are two scaling constants c1 and c2 > that represent how much to scale the dx1,dy1 and dx4,dy4 values to get > a curve that interpolates both position and slope at t=0.5. A comment > might help here... :-( I see how (dxm,dym) was confusing. The only reason for computing the slope at t=0.5 is to get the point of the offset curve at t=0.5. We don't make the computed curve and the input curve have equal slopes at t=0.5 because this would give us an overdetermined system. What we're trying to do in this function is to approximate an ideal offset curve (call it I) of the input curve B using a bezier curve Bp. The constraints I use to get the equations are: 1. The computed curve Bp should go through I(0) and I(1). These are computed in lines 661,662,665,666. This gives us p1p and p4p. We still need to find 4 variables: the x and y components of p2p and p3p (i.e. x2p, y2p, x3p, y3p). 2. Bp should have slope equal in absolute value to I at the endpoints. So, (by the way, "v1 || v2" below, means "vector v1 is parallel to vector v2") I'(0) || Bp'(0) and I'(1) || Bp'(1). Obviously, I'(0) || B'(0) and I'(1) || B'(1); therefore, Bp'(0) || B'(0) and Bp'(1) || B'(1). We know that Bp'(0) || (p2p-p1p) and Bp'(1) || (p4p-p3p) and the same is true for any bezier curve; therefore, we get the equations (1) p2p = c1 * (p2-p1) + p1p (2) p3p = c2 * (p4-p3) + p4p We know p1p, p4p, p2, p1, p3, and p4; therefore, this reduces the number of unknowns from 4 to 2 (i.e. just c1 and c2). To eliminate these 2 unknowns we use the following constraint: 3. Bp(0.5) == I(0.5). I(0.5) is computed in lines 663,664, and I should note that this is *the only* reason for computing dxm,dym. This gives us (3) Bp(0.5) = (p1p + 3 * (p2p + p3p) + p4p)/8, which is equivalent to (4) p2p + p3p = (Bp(0.5)*8 - p1p - p4p) / 3 We can substitute (1) and (2) from above into (4) and we get: (5) c1*(p2-p1) + c2*(p4-p3) = (Bp(0.5)*8 - p1p - p4p)/3 - p1p - p4p which is equivalent to (6) c1*(p2-p1) + c2*(p4-p3) = (4/3) * (Bp(0.5) * 2 - p1p - p4p) The right side of this is a 2D vector, and we know I(0.5), which gives us Bp(0.5), which gives us the value of the right side. The left side is just a matrix vector multiplication in disguise. It is [x2-x1, x4-x3][c1] [y2-y1, y4-y3][c2] which, in Stroker, is equal to [dx1, dx4][c1] [dy1, dy4][c2] At this point we are left with a simple linear system and we solve it by getting the inverse of the matrix above. Then we use [c1,c2] to compute p2p and p3p. I think using Bp'(0.5) || I'(0.5) instead of Bp(0.5)==I(0.5) only eliminates 1 variable and leaves us with 1 unknown. This brings up the interesting possibility of replacing constraint 3 with: Bp'(1/3) || I'(1/3) and B'(2/3) || I'(2/3). I guess this is something to implement sometime in the future just to compare with the current equations. But what we have now works pretty well, so I'm in no rush. I've implemented everything else you suggested. Regards, Denis. ----- "Jim Graham" wrote: > Round 4... > > On 10/6/2010 1:36 PM, Denis Lila wrote: > > > > webrev: > > http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ > > BezCurve.java: > > I'd add some "set()" methods to BezCurve/Curve and then use a scratch > > instance in Renderer (and other places?) to reuse those calculations, > > such as: > > Curve constructors (obviously) > Renderer.curveOrQuadTo() > Renderer.initQuad() > Renderer.initCurve() > Stroker.findSubdivPoints() > > lines 179,182 - using your d* variables, wouldn't these be: > a = 2*(dax*dax + day*day) > b = 3*(dax*dbx + day*dby) > c = 2*(dax*cx + day*cy) + dbx*dbx + dby*dby > d = dbx*cx + dby*cy > It has fewer multiplies and more of the multipliers are powers of 2 > which are faster than non-power-of-2 multiplies. > > line 206,210 - a nit - it didn't really confuse me, but halfway > through > reading this it occurs to me that these are really t0 and t1, right? > > line 212 - if x0 (t0?) is 0 then you don't need to include it in the > roots, no? > > line 303 - isn't it enough to just look at the previous T value (or > keep > a running "prevt" variable) rather than update every T value in the > array? Isn't this enough? > int prevt = 0; /* field in Iterator */ > next() { > curt = Ts[next]; > split = (curt - prevt) / (1 - prevt); > prevt = curt; > } > > Done with BezCurve.java... > > Stroker.java: > > lines 558 (et al) - create a helper function for all of these > (degenerates to a line) cases? > > line 687 - dup? > > line 856 - use a scratch Curve instance and set methods to reduce GC? > > line 857 - this is true if the first vector is parallel to either > axis, > but the comment after it says only "parallel to the x axis" - is that > a > problem? Also, if both are 0 then no parallel constraint is applied > even if it does start out parallel. I imagine that this is all OK > because the "both 0" case should be rare/non-existant and the y-axis > case will also benefit from the same optimization...? > > lines 861-863: sin/cos and atan2 cancel each other out. It is faster > > to compute the hypotenuse and then divide the x and y by the > hypotenuse > to get the cos and sin. (cos = x/hypot; sin = y/hypot;) > > Cache and TileGenerator look ok... > > I think I'm done at this point except for not understanding the > "parallel cubic" equations I mentioned above and the ROCsq method... > > ...jim -------------- next part -------------- A non-text attachment was scrubbed... Name: ROCDemo.jar Type: application/x-java-archive Size: 22198 bytes Desc: not available URL: From james.graham at oracle.com Tue Oct 19 23:18:28 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 19 Oct 2010 16:18:28 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <717863655.938101287509901743.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <717863655.938101287509901743.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBE2744.2030908@oracle.com> On 10/19/2010 10:38 AM, Denis Lila wrote: > Hi Jim. > > If I haven't replied to a suggestion, that means I've implemented and > I thought it was a good idea, so I don't have anything to say about it. That's mostly true too for me, but there are a couple that I might go back to - I'll let you know when I think I've reached a 100% coverage (getting close). >> getTransformedPoints isn't used? >> getUntransformedPoints isn't used? >> fillWithIndxes(float) isn't used? >> evalQuad isn't used? (Though it does provide symmetry with evalCubic >> which is used) >> getFlatness* aren't used? >> ptSegDistSq isn't used? > > Should I get rid of these? I wanted to do it, but I wanted to wait until > just before pushing because I was afraid I'd start needing them again at > some point in the future. OK, use your best judgment. If they are small and they add to symmetry of services (like evalQuad) or they might be used later, then it isn't a big deal, but dead code in private APIs shouldn't be just left laying around if we can help it. ...jim From james.graham at oracle.com Wed Oct 20 00:13:00 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 19 Oct 2010 17:13:00 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <241845924.938501287510005312.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <241845924.938501287510005312.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBE340C.1060904@oracle.com> Hi Denis, On 10/19/2010 10:40 AM, Denis Lila wrote: >> ROCsq - I looked at the wikipedia article and it wasn't clear how it >> directly related to your function since the article is dealing with >> the curvature of a function graphed against its own t, but you are dealing >> with 2 parametric equations combined and graphed against each other. >> I think I'm going to have to just trust you on this one for now. :-( > > http://en.wikipedia.org/wiki/Radius_of_curvature_%28applications%29 > Did you look at the above wikipedia article? When researching I came across > 2 of them, and one of them only mentions natural parameterizations, but > the above has the general equation for a R->Rn function, then below that > they have the special case where n=2, x(t)=t, and y(t)=f(t). I used the > first equation on that page. > Actually, I wrote a simple program to make sure the radius of curvature > function was correct. I have attached it. It's not a proof, but I think > it is convincing. Just hold down the mouse button and move it horizontally. > This will change the t value on the curve and the circle drawn will have > radius equal to Math.sqrt(ROCsq). You can also change the control points of > the curve. There's a bug where when you run it the window is really tiny, so > you have to manually resize it and maximize it. I actually did read that article, but I wasn't seeing the fact that it was a multiple parametric equation and that the || were distance calculations rather than simply absolute values. Now I see it. Plugging those concepts in to the first equation the mapping is very direct. One thing that confused me when I was proof-reading it was that the numerator seemed to be dx2dy2 squared when it should be cubed. Then I spotted the final "*dx2dy2" term at the end which makes it cubed. I wasn't sure why you isolated that term out there instead of just grouping it with the rest of the numerator - is there a danger of overflow if you multiply it before you do the division? If so, then that is fine since it doesn't actually affect the number of fp ops so it should be the same performance. >> lines 621-626 and 643-646 - I'm not sure what the derivation of these >> lines are. I tried to do my own equations, but I seem to be heading >> in a different direction than you used and it didn't seem like I was >> going to converge. What equations did you set up to solve to get these >> calculations? From what I can see we have: >> - new p1,p4 are calculated >> - new p(0.5) is calculated >> - the corresponding dx,dy at t=0,0.5,1 (gives slopes) >> - slopes at t=0, 0.5 and 1 should be the same for all curves >> and what you are trying to compute are two scaling constants c1 and c2 >> that represent how much to scale the dx1,dy1 and dx4,dy4 values to get >> a curve that interpolates both position and slope at t=0.5. A comment >> might help here... :-( > > I see how (dxm,dym) was confusing. The only reason for computing the slope > at t=0.5 is to get the point of the offset curve at t=0.5. We don't make > the computed curve and the input curve have equal slopes at t=0.5 because > this would give us an overdetermined system. What we're trying to do in this > function is to approximate an ideal offset curve (call it I) of the input > curve B using a bezier curve Bp. The constraints I use to get the equations are: It does help *a lot*, though, so thank you for writing it up. I would move it closer to the code in question since the function has such a long preamble that separates the comment from the code that implements it (also method comments are usually reserved for API documentation purposes). lines 544,559 - I'd remove the line numbers from the comment. They are already wrong and they won't survive any more edits any better. ;-) In #2, you have a bunch of "I'() || B'()" which I read as "the slope of the derivative (i.e. acceleration) is equal", don't you really mean "I() || B()" which would mean the original curves should be parallel? Otherwise you could say "I'() == B'()", but I think you want to show parallels because that shows how you can use the dxy1,dxy4 values as the parallel equivalents. I would rename det43 to invdet43 to indicate that it is the inverse of the determinant. I kept looking at it and thinking "he has the determinant in the wrong side" until I noticed that it was in the denominator of det43 (which is hard to read in parenthesized C-math). One side note. At first glance I would have thought that the final equations would have subtracted the c2*dxy4 terms rather than adding them (since dxy4 represent p4-p3, not p3-p4 and so the linear interpolation equation "looks" backwards), but that isn't true because you did all of your math looking to find the c2 that belongs in this equation (as "backwards" as it seems) and so you got that answer. Interestingly if you look at the effect on the results if you calculate the dxy4 terms the other way around, they are simply negated and the impact would be that c1 would be unaffected (both num and denom are negated) and c2 would be negated (only det43 is negated), so it works out the same either way. Fun... > I think using Bp'(0.5) || I'(0.5) instead of Bp(0.5)==I(0.5) only eliminates > 1 variable and leaves us with 1 unknown. This brings up the interesting possibility > of replacing constraint 3 with: Bp'(1/3) || I'(1/3) and B'(2/3) || I'(2/3). I guess > this is something to implement sometime in the future just to compare with the > current equations. But what we have now works pretty well, so I'm in no rush. No, the existing stuff is clean and works fine so let's leave it - for now at the very least... ...jim From james.graham at oracle.com Wed Oct 20 00:15:44 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 19 Oct 2010 17:15:44 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <241845924.938501287510005312.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <241845924.938501287510005312.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBE34B0.3070809@oracle.com> Hi Denis, On 10/19/2010 10:40 AM, Denis Lila wrote: > Actually, I wrote a simple program to make sure the radius of curvature > function was correct. I have attached it. It's not a proof, but I think > it is convincing. Just hold down the mouse button and move it horizontally. > This will change the t value on the curve and the circle drawn will have > radius equal to Math.sqrt(ROCsq). You can also change the control points of > the curve. There's a bug where when you run it the window is really tiny, so > you have to manually resize it and maximize it. I'm assuming that the huge printout of "Roc roots=[]" is meant to be a reassuring indication that the error of the approximation is small? ...jim From james.graham at oracle.com Wed Oct 20 00:52:07 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 19 Oct 2010 17:52:07 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBE3D37.1040707@oracle.com> Hi Denis, On 10/18/2010 2:21 PM, Denis Lila wrote: > I introduced a drawRoundCap method. This eliminated the side argument from > the round join drawing, which made it easier to eliminate the trig function > calls. I did this by using dot products to compute cosines (which was possible > because now Stroker takes only untransformed paths, and all lineWidths are the > same), and I used the double angle identities to compute any sines. > I came up with my own ways of detecting acute/obtuse angles and finding the centres > of angles ("my own" meaning I didn't look at any websites), and they consist of: > 1. if (omx * mx + omy * my)>= 0 then the angle is acute (line 200). > 2. I explain this in a comment in the file (line 208). The new trig-less round join code looks great! I don't see any errors, but a couple of nit comments: One comment on the comment. Isn't the upper bound on the ratio equal to sqrt(2)/2? The radius (lineWidth2) is never greater than this chord length for any angle >90. When would the isCW test trigger? Does it track "rev"? What happens at 180 degrees (is that test reliable for the randomization that might happen when omxy are directly opposite mxy)? The only reason I ask is because I think the sign of mmxy is probably controllable by understanding the input conditions, but this test should be safe (modulo if it really works at 180 degrees). If it has failure modes at 180 degrees then reworking the math to produce the right sign in the first place may be more robust for that case. A test for this is to render "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate it through 360 degrees and see if the round caps invert at various angles. Also, line 256 - does that track "rev"? >> My head started spinning when evaluating the parallel curve methods so >> I'll stop here for now... > > Sorry about that. Is there anything I can do to make it easier? Actually I think I'm up to speed on all the math now. I mainly have to double check the bookkeeping stuff a second time. Can you let me know when you reach the end of my comment queue and I'll start the hopefully final proofread? ...jim From dlila at redhat.com Wed Oct 20 14:11:09 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Oct 2010 10:11:09 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <122166979.1020121287583773446.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1062837976.1020401287583869906.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > One comment on the comment. Isn't the upper bound on the ratio equal > to sqrt(2)/2? The radius (lineWidth2) is never greater than this chord > length for any angle >90. You're right. > When would the isCW test trigger? Does it track "rev"? What happens > at 180 degrees (is that test reliable for the randomization that might > happen when omxy are directly opposite mxy)? isCw is used for computing the arc bisector by testing whether the computed point is on the side it should be (and multiplying by -1 if not), it is used to compute the sign of cv in drawBezApproxForArc, and for computing rev. > The only reason I ask is > because I think the sign of mmxy is probably controllable by > understanding the input conditions, but this test should be safe > (modulo if it really works at 180 degrees). If it has failure modes at 180 > degrees then reworking the math to produce the right sign in the first > place may be more robust for that case. A test for this is to render > "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate it through > 360 degrees and see if the round caps invert at various angles. I already did that. I drew 100 lines like the one you describe. I attached the results. It never fails. It is still possible that there could be some case where it fails, but this does prove that such a case would be very rare. > Also, line 256 - does that track "rev"? It does. I changed the test to if(rev). > when you reach the end of my comment queue and I'll start the > hopefully final proofread? I made the change you suggested to the dasher binary search, so I'm almost done. I still have to run some tests, but I should be done by today. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 10/18/2010 2:21 PM, Denis Lila wrote: > > I introduced a drawRoundCap method. This eliminated the side > argument from > > the round join drawing, which made it easier to eliminate the trig > function > > calls. I did this by using dot products to compute cosines (which > was possible > > because now Stroker takes only untransformed paths, and all > lineWidths are the > > same), and I used the double angle identities to compute any sines. > > I came up with my own ways of detecting acute/obtuse angles and > finding the centres > > of angles ("my own" meaning I didn't look at any websites), and they > consist of: > > 1. if (omx * mx + omy * my)>= 0 then the angle is acute (line 200). > > 2. I explain this in a comment in the file (line 208). > > The new trig-less round join code looks great! I don't see any > errors, > but a couple of nit comments: > > >> My head started spinning when evaluating the parallel curve methods > so > >> I'll stop here for now... > > > > Sorry about that. Is there anything I can do to make it easier? > > Actually I think I'm up to speed on all the math now. I mainly have > to > double check the bookkeeping stuff a second time. Can you let me know > > ...jim From dlila at redhat.com Wed Oct 20 14:25:30 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Oct 2010 10:25:30 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CBE34B0.3070809@oracle.com> Message-ID: <1362566009.1023421287584730715.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. > I'm assuming that the huge printout of "Roc roots=[ 0's>]" is meant to be a reassuring indication that the error of the > approximation is small? That's something that should be completely ignored. To be honest, I don't remember exactly what it was supposed to print, but I think I somehow used it to convince myself that using points where acceleration dot velocity == 0 as the endpoints for the false position algorithm would be a good way to find roots of ROC(t) - w. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 10/19/2010 10:40 AM, Denis Lila wrote: > > Actually, I wrote a simple program to make sure the radius of > curvature > > function was correct. I have attached it. It's not a proof, but I > think > > it is convincing. Just hold down the mouse button and move it > horizontally. > > This will change the t value on the curve and the circle drawn will > have > > radius equal to Math.sqrt(ROCsq). You can also change the control > points of > > the curve. There's a bug where when you run it the window is really > tiny, so > > you have to manually resize it and maximize it. > > ...jim From dlila at redhat.com Wed Oct 20 14:54:52 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Oct 2010 10:54:52 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1927760378.1029631287586448595.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <980101885.1029741287586492007.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > I wasn't sure why you isolated that term out there instead of just > grouping it with the rest of the numerator - is there a danger of > overflow if you multiply it before you do the division? If so, then > that is fine since it doesn't actually affect the number of fp ops so > it should be the same performance. I'm not sure if there's a danger of overflow, but the numbers there do tend to be large, so I wanted to be safe. > In #2, you have a bunch of "I'() || B'()" which I read as "the slope > of the derivative (i.e. acceleration) is equal", don't you really mean > "I() || B()" which would mean the original curves should be parallel? > Otherwise you could say "I'() == B'()", but I think you want to show > parallels because that shows how you can use the dxy1,dxy4 values as > the parallel equivalents. Not really. I've updated the comment explaining what || does, and it should be clearer now. Basically, A(t) || B(t) means that vectors A(t) and B(t) are parallel (i.e. A(t) = c*B(t), for some nonzero t), not that curves A and B are parallel at t. > so it works out the same either way. Fun... Yeah - if one is consistent with one's definitions and if the algebra is followed mechanically the signs take care of themselves. > No, the existing stuff is clean and works fine so let's leave it - for > now at the very least... Sure. I just meant that when I have some free time in the future I'll implement this other idea just to satisfy my curiosity. I doubt it will work better than what we have though (or work at all). Regards, Denis. From james.graham at oracle.com Wed Oct 20 17:14:13 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 20 Oct 2010 10:14:13 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1062837976.1020401287583869906.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1062837976.1020401287583869906.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBF2365.4080601@oracle.com> Hi Denis, One clarification: On 10/20/10 7:11 AM, Denis Lila wrote: >> When would the isCW test trigger? Does it track "rev"? What happens >> at 180 degrees (is that test reliable for the randomization that might >> happen when omxy are directly opposite mxy)? > > isCw is used for computing the arc bisector by testing whether the computed > point is on the side it should be (and multiplying by -1 if not), it is used > to compute the sign of cv in drawBezApproxForArc, and for computing rev. > >> The only reason I ask is >> because I think the sign of mmxy is probably controllable by >> understanding the input conditions, but this test should be safe >> (modulo if it really works at 180 degrees). If it has failure modes at 180 >> degrees then reworking the math to produce the right sign in the first >> place may be more robust for that case. A test for this is to render >> "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate it through >> 360 degrees and see if the round caps invert at various angles. > > I already did that. I drew 100 lines like the one you describe. I attached > the results. It never fails. It is still possible that there could be some > case where it fails, but this does prove that such a case would be very rare. > >> Also, line 256 - does that track "rev"? > > It does. I changed the test to if(rev). Cool, but above I was also asking the same question about line 231, and you provided a lot of information about line 231 (and a test to verify it), but didn't answer if the test in line 231 also tracks rev the same way...? ...jim From james.graham at oracle.com Wed Oct 20 17:20:18 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 20 Oct 2010 10:20:18 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <980101885.1029741287586492007.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <980101885.1029741287586492007.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBF24D2.9090206@oracle.com> On 10/20/10 7:54 AM, Denis Lila wrote: >> In #2, you have a bunch of "I'() || B'()" which I read as "the slope >> of the derivative (i.e. acceleration) is equal", don't you really mean >> "I() || B()" which would mean the original curves should be parallel? >> Otherwise you could say "I'() == B'()", but I think you want to show >> parallels because that shows how you can use the dxy1,dxy4 values as >> the parallel equivalents. > > Not really. I've updated the comment explaining what || does, and > it should be clearer now. Basically, A(t) || B(t) means that vectors > A(t) and B(t) are parallel (i.e. A(t) = c*B(t), for some nonzero t), > not that curves A and B are parallel at t. I'm not sure we are on the same page here. I'() is usually the symbol indicating the "derivative" of I(). My issue is not with the || operator, but with the fact that you are applying it to the I'() instead of I(). Also, how is A(t) and B(t) are parallel not the same as "the curves A and B are parallel at t"? Also, A(t) = c*B(t) is always true for all A and B and all t if you take a sample in isolation. Parallel means something like "A(t) = c*B(t) with the same value of c for some interval around t", not that the values at t can be expressed as a multiple. Again, I'() || B'() says to me that the derivative curves are parallel, not that the original curves are parallel... ...jim From dlila at redhat.com Wed Oct 20 17:29:45 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Oct 2010 13:29:45 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CBF2365.4080601@oracle.com> Message-ID: <1827973700.1048901287595785606.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Cool, but above I was also asking the same question about line 231, > and you provided a lot of information about line 231 (and a test to verify > it), but didn't answer if the test in line 231 also tracks rev the > same way...? Oh, no, line 231 isn't mean to be related to rev at all. It just checks to see on which side of the (omx,omy),(mx,my) chord the computed (mmx, mmy) is. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > One clarification: > > On 10/20/10 7:11 AM, Denis Lila wrote: > >> When would the isCW test trigger? Does it track "rev"? What > happens > >> at 180 degrees (is that test reliable for the randomization that > might > >> happen when omxy are directly opposite mxy)? > > > > isCw is used for computing the arc bisector by testing whether the > computed > > point is on the side it should be (and multiplying by -1 if not), it > is used > > to compute the sign of cv in drawBezApproxForArc, and for computing > rev. > > > >> The only reason I ask is > >> because I think the sign of mmxy is probably controllable by > >> understanding the input conditions, but this test should be safe > >> (modulo if it really works at 180 degrees). If it has failure > modes at 180 > >> degrees then reworking the math to produce the right sign in the > first > >> place may be more robust for that case. A test for this is to > render > >> "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate it > through > >> 360 degrees and see if the round caps invert at various angles. > > > > I already did that. I drew 100 lines like the one you describe. I > attached > > the results. It never fails. It is still possible that there could > be some > > case where it fails, but this does prove that such a case would be > very rare. > > > >> Also, line 256 - does that track "rev"? > > > > It does. I changed the test to if(rev). > > ...jim From dlila at redhat.com Wed Oct 20 17:48:36 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Oct 2010 13:48:36 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1461972011.1051821287596735100.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1694532168.1052091287596916602.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Also, how is A(t) and B(t) are parallel not the same as "the curves A > and B are parallel at t"? Well, suppose A and B are lines with endpoints (0,0), (2,0) for A and (0,1),(2,1) for B. Obviously, for all t, A and B are parallel at t. However let t = 0.5. Then A(t) = (1,0) and B(t) = (1, 1). The vectors (1,0) and (1,1) are not parallel, so saying A(t) || B(t) is the same as saying that there exists c such that (1,0) = c*(1,1), which isn't true. However, A'(t)=(2,0) and B'(t)=(2,0), and the vectors (2,0) and (2,0) are parallel. Does this make more sense? Regards, Denis. ----- "Jim Graham" wrote: > On 10/20/10 7:54 AM, Denis Lila wrote: > >> In #2, you have a bunch of "I'() || B'()" which I read as "the > slope > >> of the derivative (i.e. acceleration) is equal", don't you really > mean > >> "I() || B()" which would mean the original curves should be > parallel? > >> Otherwise you could say "I'() == B'()", but I think you want to > show > >> parallels because that shows how you can use the dxy1,dxy4 values > as > >> the parallel equivalents. > > > > Not really. I've updated the comment explaining what || does, and > > it should be clearer now. Basically, A(t) || B(t) means that > vectors > > A(t) and B(t) are parallel (i.e. A(t) = c*B(t), for some nonzero > t), > > not that curves A and B are parallel at t. > > I'm not sure we are on the same page here. > > I'() is usually the symbol indicating the "derivative" of I(). My > issue > is not with the || operator, but with the fact that you are applying > it > to the I'() instead of I(). > > Also, A(t) = c*B(t) is always true for all A and B and all t if you > take > a sample in isolation. Parallel means something like "A(t) = c*B(t) > with the same value of c for some interval around t", not that the > values at t can be expressed as a multiple. > > Again, I'() || B'() says to me that the derivative curves are > parallel, > not that the original curves are parallel... > > ...jim From james.graham at oracle.com Wed Oct 20 17:56:46 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 20 Oct 2010 10:56:46 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1827973700.1048901287595785606.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1827973700.1048901287595785606.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBF2D5E.6020404@oracle.com> Right, but it seemed to me that if omxy was the "from" vector and mxy was the "to" vector, that the computed mmxy should always be predictably on the same side of it, no? If it was on the wrong side then it wouldn't be a random occurence, it must be related to the input data. So either it is always on the right side, always on the wrong side (i.e. just reverse the rotation in the math), or always on the right/wrong side depending on the CWness of the join angle - which would be reflected in rev... No? ...jim On 10/20/10 10:29 AM, Denis Lila wrote: >> Cool, but above I was also asking the same question about line 231, >> and you provided a lot of information about line 231 (and a test to verify >> it), but didn't answer if the test in line 231 also tracks rev the >> same way...? > > Oh, no, line 231 isn't mean to be related to rev at all. It just checks > to see on which side of the (omx,omy),(mx,my) chord the computed (mmx, mmy) > is. > > Regards, > Denis. > > ----- "Jim Graham" wrote: > >> Hi Denis, >> >> One clarification: >> >> On 10/20/10 7:11 AM, Denis Lila wrote: >>>> When would the isCW test trigger? Does it track "rev"? What >> happens >>>> at 180 degrees (is that test reliable for the randomization that >> might >>>> happen when omxy are directly opposite mxy)? >>> >>> isCw is used for computing the arc bisector by testing whether the >> computed >>> point is on the side it should be (and multiplying by -1 if not), it >> is used >>> to compute the sign of cv in drawBezApproxForArc, and for computing >> rev. >>> >>>> The only reason I ask is >>>> because I think the sign of mmxy is probably controllable by >>>> understanding the input conditions, but this test should be safe >>>> (modulo if it really works at 180 degrees). If it has failure >> modes at 180 >>>> degrees then reworking the math to produce the right sign in the >> first >>>> place may be more robust for that case. A test for this is to >> render >>>> "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate it >> through >>>> 360 degrees and see if the round caps invert at various angles. >>> >>> I already did that. I drew 100 lines like the one you describe. I >> attached >>> the results. It never fails. It is still possible that there could >> be some >>> case where it fails, but this does prove that such a case would be >> very rare. >>> >>>> Also, line 256 - does that track "rev"? >>> >>> It does. I changed the test to if(rev). >> >> ...jim From james.graham at oracle.com Wed Oct 20 18:11:59 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 20 Oct 2010 11:11:59 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1694532168.1052091287596916602.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1694532168.1052091287596916602.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CBF30EF.8060304@oracle.com> OK, I can see how your terminology works now, but it seems odd to me. I never consider re-expressing the coordinates on a curve as a vector and basing geometric properties on those constructed vectors. I either consider the points on the curve, or its tangent or its normal - none of which is the value you are expressing. You are, essentially, operating on tangent vectors, but you aren't calling them that, you are calling them something like "the vector of the derivative" which is a relative (direction only) version of the tangent vector (which has location and direction). When one talks about curves and being parallel, my mind tends to think of the tangents of the curves being parallel and tangents are directed by the first derivative. Also, if you are going to use your definition of "vector" then parallel is an odd term to use for values that originate from the same point (points considered as a vector are taken to originate from 0,0) - really you want those "vectors" to be collinear, not (just) parallel. So, either || means "the coordinates of the curves expressed as vectors are collinear" or it means "the curves (i.e. the tangents of the curve at the indicated point) are parallel". Saying "vector I() is parallel to vector B()" didn't really have meaning to me based on the above biases. So, I get your comment now and all of the math makes sense, but the terminology seemed foreign to me... ...jim On 10/20/10 10:48 AM, Denis Lila wrote: >> Also, how is A(t) and B(t) are parallel not the same as "the curves A >> and B are parallel at t"? > > Well, suppose A and B are lines with endpoints (0,0), (2,0) for A > and (0,1),(2,1) for B. Obviously, for all t, A and B are parallel at t. > However let t = 0.5. Then A(t) = (1,0) and B(t) = (1, 1). The vectors > (1,0) and (1,1) are not parallel, so saying A(t) || B(t) is the same > as saying that there exists c such that (1,0) = c*(1,1), which isn't true. > > However, A'(t)=(2,0) and B'(t)=(2,0), and the vectors > (2,0) and (2,0) are parallel. > > Does this make more sense? > > Regards, > Denis. > > ----- "Jim Graham" wrote: > >> On 10/20/10 7:54 AM, Denis Lila wrote: >>>> In #2, you have a bunch of "I'() || B'()" which I read as "the >> slope >>>> of the derivative (i.e. acceleration) is equal", don't you really >> mean >>>> "I() || B()" which would mean the original curves should be >> parallel? >>>> Otherwise you could say "I'() == B'()", but I think you want to >> show >>>> parallels because that shows how you can use the dxy1,dxy4 values >> as >>>> the parallel equivalents. >>> >>> Not really. I've updated the comment explaining what || does, and >>> it should be clearer now. Basically, A(t) || B(t) means that >> vectors >>> A(t) and B(t) are parallel (i.e. A(t) = c*B(t), for some nonzero >> t), >>> not that curves A and B are parallel at t. >> >> I'm not sure we are on the same page here. >> >> I'() is usually the symbol indicating the "derivative" of I(). My >> issue >> is not with the || operator, but with the fact that you are applying >> it >> to the I'() instead of I(). >> >> Also, A(t) = c*B(t) is always true for all A and B and all t if you >> take >> a sample in isolation. Parallel means something like "A(t) = c*B(t) >> with the same value of c for some interval around t", not that the >> values at t can be expressed as a multiple. >> >> Again, I'() || B'() says to me that the derivative curves are >> parallel, >> not that the original curves are parallel... >> >> ...jim From dlila at redhat.com Thu Oct 21 13:26:40 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 21 Oct 2010 09:26:40 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <794804650.1149921287667533331.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <427368863.1150131287667600926.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello Jim. > So either it is always on the right side, always on the wrong side > (i.e. just reverse the rotation in the math), or always on the right/wrong > side depending on the CWness of the join angle - which would be > reflected in rev... No? That's a good point. I've changed the test to simply if(rev) because the normal we compute is on the left of the original vector (omx,omy)-(mx,my). So, if the arc was counter clockwise no adjustment was needed. Regards, Denis. ----- "Jim Graham" wrote: > Right, but it seemed to me that if omxy was the "from" vector and mxy > > was the "to" vector, that the computed mmxy should always be > predictably > on the same side of it, no? If it was on the wrong side then it > wouldn't be a random occurence, it must be related to the input data. > > ...jim > > On 10/20/10 10:29 AM, Denis Lila wrote: > >> Cool, but above I was also asking the same question about line > 231, > >> and you provided a lot of information about line 231 (and a test to > verify > >> it), but didn't answer if the test in line 231 also tracks rev the > >> same way...? > > > > Oh, no, line 231 isn't mean to be related to rev at all. It just > checks > > to see on which side of the (omx,omy),(mx,my) chord the computed > (mmx, mmy) > > is. > > > > Regards, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> Hi Denis, > >> > >> One clarification: > >> > >> On 10/20/10 7:11 AM, Denis Lila wrote: > >>>> When would the isCW test trigger? Does it track "rev"? What > >> happens > >>>> at 180 degrees (is that test reliable for the randomization that > >> might > >>>> happen when omxy are directly opposite mxy)? > >>> > >>> isCw is used for computing the arc bisector by testing whether > the > >> computed > >>> point is on the side it should be (and multiplying by -1 if not), > it > >> is used > >>> to compute the sign of cv in drawBezApproxForArc, and for > computing > >> rev. > >>> > >>>> The only reason I ask is > >>>> because I think the sign of mmxy is probably controllable by > >>>> understanding the input conditions, but this test should be safe > >>>> (modulo if it really works at 180 degrees). If it has failure > >> modes at 180 > >>>> degrees then reworking the math to produce the right sign in the > >> first > >>>> place may be more robust for that case. A test for this is to > >> render > >>>> "(0,0) -> (100,0) -> (0,0)" with round caps and then rotate > it > >> through > >>>> 360 degrees and see if the round caps invert at various angles. > >>> > >>> I already did that. I drew 100 lines like the one you describe. I > >> attached > >>> the results. It never fails. It is still possible that there > could > >> be some > >>> case where it fails, but this does prove that such a case would > be > >> very rare. > >>> > >>>> Also, line 256 - does that track "rev"? > >>> > >>> It does. I changed the test to if(rev). > >> > >> ...jim From dlila at redhat.com Thu Oct 21 19:27:03 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 21 Oct 2010 15:27:03 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1146689114.1193771287688903086.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <577702805.1194121287689223461.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > When one talks about curves and being parallel, my mind > tends to think of the tangents of the curves being parallel and > tangents are directed by the first derivative. That's what I was trying to express. The tangents of curves A and B at t are parallel if and only if there's some c such that A'(t) = c*B'(t), which is what I defined || to mean, although perhaps I didn't make this clear enough. > Also, if you are going to use your definition of "vector" then > parallel is an odd term to use I agree. I was never comfortable with using "parallel" but I couldn't find a better word. How about "aligned"? Anyway, I've changed the comments to something that hopefully will avoid this sort of confusion in the future. Other than this, I think I've followed all your other suggestions (putting some of the degenerate curve handling in separate functions, fixing the style issues, removing unused methods, etc). I also fixed a bug in Renderer.edgeSetCurY where I was using edges[idx+MINY] instead of edges[idx+CURY] (which produced visible artifacts on nearly horizontal lines). I am also now using your TransformingPathConsumer2D class, which simplified things quite a bit where ever it was used. Good to push? http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ Regards, Denis. ----- "Jim Graham" wrote: > OK, I can see how your terminology works now, but it seems odd to me. > I > never consider re-expressing the coordinates on a curve as a vector > and > basing geometric properties on those constructed vectors. I either > consider the points on the curve, or its tangent or its normal - none > of > which is the value you are expressing. You are, essentially, > operating > on tangent vectors, but you aren't calling them that, you are calling > > them something like "the vector of the derivative" which is a relative > > (direction only) version of the tangent vector (which has location and > > direction). > for values that originate from the same point > (points considered as a vector are taken to originate from 0,0) - > really > you want those "vectors" to be collinear, not (just) parallel. > > So, either || means "the coordinates of the curves expressed as > vectors > are collinear" or it means "the curves (i.e. the tangents of the curve > > at the indicated point) are parallel". Saying "vector I() is parallel > > to vector B()" didn't really have meaning to me based on the above > biases. > > So, I get your comment now and all of the math makes sense, but the > terminology seemed foreign to me... > > ...jim > > On 10/20/10 10:48 AM, Denis Lila wrote: > >> Also, how is A(t) and B(t) are parallel not the same as "the curves > A > >> and B are parallel at t"? > > > > Well, suppose A and B are lines with endpoints (0,0), (2,0) for A > > and (0,1),(2,1) for B. Obviously, for all t, A and B are parallel at > t. > > However let t = 0.5. Then A(t) = (1,0) and B(t) = (1, 1). The > vectors > > (1,0) and (1,1) are not parallel, so saying A(t) || B(t) is the > same > > as saying that there exists c such that (1,0) = c*(1,1), which isn't > true. > > > > However, A'(t)=(2,0) and B'(t)=(2,0), and the vectors > > (2,0) and (2,0) are parallel. > > > > Does this make more sense? > > > > Regards, > > Denis. > > > > ----- "Jim Graham" wrote: > > > >> On 10/20/10 7:54 AM, Denis Lila wrote: > >>>> In #2, you have a bunch of "I'() || B'()" which I read as "the > >> slope > >>>> of the derivative (i.e. acceleration) is equal", don't you > really > >> mean > >>>> "I() || B()" which would mean the original curves should be > >> parallel? > >>>> Otherwise you could say "I'() == B'()", but I think you want to > >> show > >>>> parallels because that shows how you can use the dxy1,dxy4 > values > >> as > >>>> the parallel equivalents. > >>> > >>> Not really. I've updated the comment explaining what || does, and > >>> it should be clearer now. Basically, A(t) || B(t) means that > >> vectors > >>> A(t) and B(t) are parallel (i.e. A(t) = c*B(t), for some nonzero > >> t), > >>> not that curves A and B are parallel at t. > >> > >> I'm not sure we are on the same page here. > >> > >> I'() is usually the symbol indicating the "derivative" of I(). My > >> issue > >> is not with the || operator, but with the fact that you are > applying > >> it > >> to the I'() instead of I(). > >> > >> Also, A(t) = c*B(t) is always true for all A and B and all t if > you > >> take > >> a sample in isolation. Parallel means something like "A(t) = > c*B(t) > >> with the same value of c for some interval around t", not that the > >> values at t can be expressed as a multiple. > >> > >> Again, I'() || B'() says to me that the derivative curves are > >> parallel, > >> not that the original curves are parallel... > >> > >> ...jim From james.graham at oracle.com Thu Oct 21 20:52:32 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Oct 2010 13:52:32 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <577702805.1194121287689223461.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <577702805.1194121287689223461.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC0A810.1080402@oracle.com> Hi Denis, I'll be focusing on this later today, just a last proofread. In the meantime, can you outline the tests that you ran? Also, have you used J2DBench at all? I know you ran some of your own benchmarks, but didn't know if you were familiar with this tool: {OpenJDK}/src/share/demo/java2d/J2DBench/ ...jim On 10/21/2010 12:27 PM, Denis Lila wrote: > Good to push? > > http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ From dlila at redhat.com Fri Oct 22 00:32:18 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 21 Oct 2010 20:32:18 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <409774995.1214281287707474731.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1048982578.1214301287707538296.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > In the meantime, can you outline the tests that you ran? I ran Java2D without any problems. There's also been an icedtea bug http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=450 related to a look and feel (tinylaf: http://www.muntjak.de/hans/java/tinylaf/tinylaf-1_4_0.zip to run a demo, download, extract and run tinycp.jar) that wasn't being painted properly. Now it looks good (I think there's no LCD text antialiasing, but that's a different story). I also wrote rendered at least 50000 random cubic curves. I didn't inspect these too closely - this test was just to find any obvious errors. There weren't any. Most importantly, I also ran this test suite: http://icedtea.classpath.org/hg/gfx-test/ It generates a lot of images using a reference java implementation and an implementation to be tested. I used closed source java as a reference, and I ran it using a fresh checkout of the 2d branch of openjdk7: http://icedtea.classpath.org/~dlila/prevPiscesSungfx/results/ and a fresh checkout of the 2d branch with my patch applied: http://icedtea.classpath.org/~dlila/latestPiscesSungfx/ As you can see, the number of images that are the same as the reference implementation has increased subtantially. It has also increased consistenly across all categories. I've gone through most of the images, and the ones that are different aren't dramatically different. The differences are barely noticeable. The improvement is even greater when compared to openjdk6 which produces some pretty scary test results, especially in the scaled rectangles category (but I haven't uploaded these tests so you'll just have to trust me on this ;-) ) NOTE: the webrev has changed slightly since the last e-mail I sent. The gfx test suite revealed a bug in the drawing of dashed rectangles, so to fix it I have changed a line in Dasher.closePath from "if(needsMoveTo) {" to "if(needsMoveTo || !dashOn) {" > Also, have you used J2DBench at all? I know you ran some of your own > benchmarks, but didn't know if you were familiar with this tool: > > {OpenJDK}/src/share/demo/java2d/J2DBench/ I was going to run these today, but fixing the dashing bug above and rerunning the tests took a while and it's already 8:30 pm here and I have to go home. I'll run them tomorrow morning. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > I'll be focusing on this later today, just a last proofread. > > > ...jim > > On 10/21/2010 12:27 PM, Denis Lila wrote: > > Good to push? > > > > http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ From james.graham at oracle.com Fri Oct 22 01:10:26 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Oct 2010 18:10:26 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC0E482.2040209@oracle.com> Hi Denis, I saw something in the latest webrev that reminded me of an earlier comment. On 10/18/2010 2:21 PM, Denis Lila wrote: >> line 389 - The test here is different from closePath. What if they >> were both "prev == DRAWING_OP_TO"? > > I am now using prev!=DRAWING_OP_TO (not ==, since it is supposed to execute > finish() if no nonzero length lines have been fed to Stroker yet). In fact > I have removed the "started" variable since it's equivalent to prev==DRAWING_OP_TO. It looks like closePath still uses a different test than moveTo and pathDone. They all test for DRAWING_OP_TO, but closepath uses != whereas the others use ==. Is that right? ...jim From james.graham at oracle.com Fri Oct 22 02:14:36 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Oct 2010 19:14:36 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CC0E482.2040209@oracle.com> References: <36028779.845541287436893510.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CC0E482.2040209@oracle.com> Message-ID: <4CC0F38C.9080106@oracle.com> This comment may make more sense if I explain that the condition for when finish() is executed in closePath is the reverse of the condition in move and done. I agree that it should return if prev!=OP_TO, but I'm not so sure about doing a finish(). Does closed JDK emit something on moveto,close? (Or close,close?) ...jim On 10/21/2010 6:10 PM, Jim Graham wrote: > Hi Denis, > > I saw something in the latest webrev that reminded me of an earlier > comment. > > On 10/18/2010 2:21 PM, Denis Lila wrote: >>> line 389 - The test here is different from closePath. What if they >>> were both "prev == DRAWING_OP_TO"? >> >> I am now using prev!=DRAWING_OP_TO (not ==, since it is supposed to >> execute >> finish() if no nonzero length lines have been fed to Stroker yet). In >> fact >> I have removed the "started" variable since it's equivalent to >> prev==DRAWING_OP_TO. > > It looks like closePath still uses a different test than moveTo and > pathDone. They all test for DRAWING_OP_TO, but closepath uses != whereas > the others use ==. Is that right? > > ...jim From james.graham at oracle.com Fri Oct 22 02:16:06 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 21 Oct 2010 19:16:06 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <4CC0A810.1080402@oracle.com> References: <577702805.1194121287689223461.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CC0A810.1080402@oracle.com> Message-ID: <4CC0F3E6.9090303@oracle.com> Hi Denis, This should be the last batch of comments, most of which may require a 10 second answer. Most of them could just be ignored as they are minor optimizations. There are only a couple where I think something is "off"... PiscesRenderingEngine.java: lines 279 and 303 - maybe add Helpers.nearZero(v, nulp) for these? For one thing, you compute the same values twice - hopefully the compiler will notice that. line 303 - could use either within or nearZero, same comment about the value being computed twice. Also, aa+cc gets computed later, not sure if the compiler is smart enough to deal with that. line 325 - you don't need to clone at. "outat = at" should be enough. A note for next revision - you don't need to include the translation in outat and inat, it would be enough to use just the abcd part of the transform. Right now, the TransformingPathConsumer implementations tend to assume translation, but we could create variants for the non-translating cases and maybe save some work. Dasher.java: lines 98-101 - somewhere in the confusion moveToImpl became redundant with moveTo. lines 174-175 - lineToImpl now redundant too. line 368 - does this cause a problem if t==1 because lastSegLen will now return the wrong value? Maybe move this into an else clause on the "t>=1" test? line 405 - I didn't understand why you use "2*err*(len+leftLen)" as the termination condition, why not just err? Stroker.java: lines 200,236 - for the most part, aren't these redundant? lines 358-361 - lineToImpl redundant now? line 390 - should finish() really be done here? That would mean that moveTo,close would try to emit something and close,close would as well. Is that right? line 800 - technically, this could be [0] and [1] since all points on the curve are the same. ;-) line 805,810 - abs()? line 821,824 - you add 1 to nCurves just to subtract 1 later? Maybe rename it to nSplits and skip the +/-1? ...jim On 10/21/2010 1:52 PM, Jim Graham wrote: > Hi Denis, > > I'll be focusing on this later today, just a last proofread. > > In the meantime, can you outline the tests that you ran? > > Also, have you used J2DBench at all? I know you ran some of your own > benchmarks, but didn't know if you were familiar with this tool: > > {OpenJDK}/src/share/demo/java2d/J2DBench/ > > ...jim > > On 10/21/2010 12:27 PM, Denis Lila wrote: >> Good to push? >> >> http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ From andrew.brygin at sun.com Fri Oct 22 13:32:24 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 22 Oct 2010 13:32:24 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6663447: D3D: excessive surface data replacements Message-ID: <20101022133251.3F62D47358@hg.openjdk.java.net> Changeset: 12b65e7ee3e4 Author: bae Date: 2010-10-22 16:57 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/12b65e7ee3e4 6663447: D3D: excessive surface data replacements Reviewed-by: prr, art ! src/windows/classes/sun/awt/windows/WWindowPeer.java From dlila at redhat.com Fri Oct 22 18:31:06 2010 From: dlila at redhat.com (Denis Lila) Date: Fri, 22 Oct 2010 14:31:06 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <522490658.1310471287772259610.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1176134236.1310521287772266261.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > Does closed JDK emit something on moveto,close? (Or close,close?) Surprisingly, it does. On moveto,close it draws caps just as if a 0 length line had been drawn. Isn't this a bug? It doesn't make much sense to me that something should be drawn because of a moveTo. So, if we want to replicate closed jdk's behaviour, the finish() call there is correct, but it alone isn't enough. An emitMoveTo needs to be issued, otherwise the last point of the last drawing command will be connected to the cap drawn at the last moveTo position. Regards, Denis. ----- "Jim Graham" wrote: > This comment may make more sense if I explain that the condition for > when finish() is executed in closePath is the reverse of the condition > > in move and done. I agree that it should return if prev!=OP_TO, but > I'm > not so sure about doing a finish(). > > ...jim > > On 10/21/2010 6:10 PM, Jim Graham wrote: > > Hi Denis, > > > > I saw something in the latest webrev that reminded me of an earlier > > comment. > > > > On 10/18/2010 2:21 PM, Denis Lila wrote: > >>> line 389 - The test here is different from closePath. What if > they > >>> were both "prev == DRAWING_OP_TO"? > >> > >> I am now using prev!=DRAWING_OP_TO (not ==, since it is supposed > to > >> execute > >> finish() if no nonzero length lines have been fed to Stroker yet). > In > >> fact > >> I have removed the "started" variable since it's equivalent to > >> prev==DRAWING_OP_TO. > > > > It looks like closePath still uses a different test than moveTo and > > pathDone. They all test for DRAWING_OP_TO, but closepath uses != > whereas > > the others use ==. Is that right? > > > > ...jim From dlila at redhat.com Fri Oct 22 19:22:41 2010 From: dlila at redhat.com (Denis Lila) Date: Fri, 22 Oct 2010 15:22:41 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <404877525.1311221287772663687.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <2114042183.1314951287775361647.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. >>> http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ > lines 279 and 303 - maybe add Helpers.nearZero(v, nulp) for these? I've introduced this method and am using it in 303. However, I think line 279 is good as it is, since we're comparing Float.MIN_VALUE and a double. > line 303 - could use either within or nearZero, same comment about the > value being computed twice. Also, aa+cc gets computed later, not sure > if the compiler is smart enough to deal with that. I think caching aa+cc would be a bit overkill. However, I've declared the variables as final and hopefully that will help the compiler to not recompute them. > line 405 - I didn't understand why you use "2*err*(len+leftLen)" as > the termination condition, why not just err? Because the error is meant to be relative. What I use is supposed to be equivalent to difference/AverageOfCorrectValueAndApproximation < err, where, in our case, AverageOfCorrectValueAndApproximation=(len+leafLen)/2, so that multiplication by 2 should have been a division. Should I use the less fancy differece/CorrectValue < err and skip a division by 2? > lines 200,236 - for the most part, aren't these redundant? I think so. When I first implemented the bezier round joins they were necessary, but I'm not sure why. All I know is when I tested it without them, joins weren't drawn properly. However, I can't reproduce the problem now, so I've removed them. > lines 98-101 - somewhere in the confusion moveToImpl became redundant > with moveTo. I thought I'd leave these in because they're interface methods, and it's usually not a great idea to call these from private methods. I've removed them anyway, because you said so and because I suppose if ever we need to do something to the user input that shouldn't be done to input coming from private methods in the class (such as the scaling of the input coordinates done in Renderer) we can always easily reintroduce them. > lines 358-361 - lineToImpl redundant now? > line 390 - should finish() really be done here? That would mean that > moveTo,close would try to emit something and close,close would as > well. > Is that right? That's right. I don't think it's what should happen, but it's what closed jre does, so I've left it in (with some changes to make it actually replicate the behaviour of closed java, since it was buggy - the moveTo was missing). I don't draw anything on the second close in the close,close case, since that would look horrible with round joins and square caps. However, the way path2D's are implemented this safeguard will not be activated since a closePath() following another closePath() is ignored. I also now initialize the *dxy *mxy variables in moveTo. This should be an inconsequential change, but I've put it in just so the state of Stroker after a moveTo is well defined. > line 368 - does this cause a problem if t==1 because lastSegLen will > now return the wrong value? Maybe move this into an else clause on the > "t>=1" test? It does cause a problem. I've fixed it by adding a variable that keeps track of the length of the last returned segment. The way it was being done was a dirty hack because it assumed that if the method didn't return in the loop, done would remain false. I made one more change in dasher: in somethingTo I removed the long comment near the end, and I handle the case where phase == dash[idx] immediately. I do this for consistency with lineTo. The only instances where this makes a difference is when we have a path that starts with a dash, ends at exactly the end of a dash, and has a closePath. So something like move(100,0), line(0,0),line(0,50),line(100,50),line(100,0),close() with a dash pattern {60,60}. In closed jdk (and also in openjdk with my patch), no join would be drawn at 100,0 on this path with this dash pattern. Whether that's correct behaviour is arguable, imho. On one hand, if we don't do it , but I think it is because if it isn't done certain dashed rectangles start looking weird at the top left. Now, consider a path like move(100,0),line(0,0),curve(0,100,100,100,100,0),close() with a dash pattern of {60,60}. The length of the curve in this is exactly 200 (I have not proven this, but it seems clear since the more I increase precision, the closer to 200 the computed length becomes. Also, if you render it with a dash pattern of {10,10} in closed jdk, exactly 10 full dashes are drawn). So, this path has exactly the same length as the above path. However, if this path is rendered with closed jdk a join will be drawn at (100,0). This behaviour is inconsistent with the line only path For this reason, I think this is a bug in closed jdk since dashing should depend only on the path's length, not on the kind of segments in a path. Handling the case where phase==dash[idx] immediately fixes this problem. I also moved the second if statement in the loop of lineTo inside the first if for symmetry with how this case is handled in somethingTo. The logic is the same. I reran all the gfx tests. Nothing has changed. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > This should be the last batch of comments, most of which may require a > > 10 second answer. Most of them could just be ignored as they are > minor > optimizations. There are only a couple where I think something is > "off"... > > PiscesRenderingEngine.java: > > > line 325 - you don't need to clone at. "outat = at" should be > enough. > > A note for next revision - you don't need to include the translation > in > outat and inat, it would be enough to use just the abcd part of the > transform. Right now, the TransformingPathConsumer implementations > tend > to assume translation, but we could create variants for the > non-translating cases and maybe save some work. > > Dasher.java: > > lines 174-175 - lineToImpl now redundant too. > > Stroker.java: > > line 800 - technically, this could be [0] and [1] since all points on > > the curve are the same. ;-) > > line 805,810 - abs()? > > line 821,824 - you add 1 to nCurves just to subtract 1 later? Maybe > rename it to nSplits and skip the +/-1? > > ...jim > > On 10/21/2010 1:52 PM, Jim Graham wrote: > > Hi Denis, > > > > I'll be focusing on this later today, just a last proofread. > > > > In the meantime, can you outline the tests that you ran? > > > > Also, have you used J2DBench at all? I know you ran some of your > own > > benchmarks, but didn't know if you were familiar with this tool: > > > > {OpenJDK}/src/share/demo/java2d/J2DBench/ > > > > ...jim > > > > On 10/21/2010 12:27 PM, Denis Lila wrote: > >> Good to push? > >> > >> http://icedtea.classpath.org/~dlila/webrevs/noflatten2/webrev/ From dlila at redhat.com Fri Oct 22 21:25:01 2010 From: dlila at redhat.com (Denis Lila) Date: Fri, 22 Oct 2010 17:25:01 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <316493882.1325411287782482930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <876716550.1325651287782701630.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > I was going to run these today, but fixing the dashing bug above and > rerunning the tests took a while and it's already 8:30 pm here and I > have to go home. I'll run them tomorrow morning. I ran the benchmarks. I've attached the options file. I ran benchmarks of my icedtea installation, closed source java, openjdk7 without the webrev, and openjdk7 with the webrev. The results files are at http://icedtea.classpath.org/~dlila/benchResults/ I think the names are pretty self explanatory. The html comparisons are: jdk6 vs latest work: http://icedtea.classpath.org/~dlila/benchResults/JDK6vsLatest_html/Summary_Report.html closed source vs latest work: http://icedtea.classpath.org/~dlila/benchResults/SUNvsLatest_html/Summary_Report.html and most importantly: previous version of pisces in openjdk7 vs latest work: http://icedtea.classpath.org/~dlila/benchResults/PrevVsLatest_html/Summary_Report.html The improvements are significant. Running J2DAnalyzer on all the results files with jdk6Bench.res as the basis produces the following summary: Summary: jdk6Bench: Number of tests: 104 Overall average: 311110.7986576862 Best spread: 0.0% variance Worst spread: 10.96% variance (Basis for results comparison) sunBench: Number of tests: 104 Overall average: 276654.4443479696 Best spread: 0.25% variance Worst spread: 19.28% variance Comparison to basis: Best result: 6488.34% of basis Worst result: 43.74% of basis Number of wins: 80 Number of ties: 2 Number of losses: 22 prevPisces: Number of tests: 104 Overall average: 221539.3516605794 Best spread: 0.08% variance Worst spread: 5.54% variance Comparison to basis: Best result: 350.33% of basis Worst result: 55.0% of basis Number of wins: 57 Number of ties: 10 Number of losses: 37 latestPisces: Number of tests: 104 Overall average: 226762.64157611743 Best spread: 0.0% variance Worst spread: 3.03% variance Comparison to basis: Best result: 501.86% of basis Worst result: 26.23% of basis Number of wins: 72 Number of ties: 4 Number of losses: 28 But unfortunately, if you look at the individual test cases in the html reports there are also some stepbacks, most notably in the dashing of anything that isn't a straight line. In fact, the results of drawOval show a 50%-500% improvement in non dashed drawing, and a 50%-25% deterioration in dashed drawing. I was expecting this, after the binary search algorithm. I've been thinking it might be better if we just go with the old algorithm and simply use Dasher.LengthIterator to flatten the curves and feed the lines to lineTo. Or we could just go with what we have and hope we find a better algorithm. Regards, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: piscesBench.opt Type: application/octet-stream Size: 9492 bytes Desc: not available URL: From james.graham at oracle.com Sat Oct 23 05:35:06 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 22 Oct 2010 22:35:06 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <876716550.1325651287782701630.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <876716550.1325651287782701630.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC2740A.3070903@oracle.com> Hi Denis, Interesting results. Note that sun-jdk7 is already showing some regressions so the more intesting results are the old-to-new pisces comparisons. It's interesting to note that non-AA dashed ovals took a much bigger hit than AA dashed ovals so we need to see which code is fielding those and see what its issue is. I'd stick with the new algorithm and lets look for ways to make dashed curves go faster. I know there are better "curve length" algorithms we could incorporate, but let's get a stake in the ground before we consider going back to flattening... ...jim On 10/22/2010 2:25 PM, Denis Lila wrote: > Hi Jim. > >> I was going to run these today, but fixing the dashing bug above and >> rerunning the tests took a while and it's already 8:30 pm here and I >> have to go home. I'll run them tomorrow morning. > > I ran the benchmarks. I've attached the options file. I ran benchmarks > of my icedtea installation, closed source java, openjdk7 without the > webrev, and openjdk7 with the webrev. > > The results files are at http://icedtea.classpath.org/~dlila/benchResults/ > I think the names are pretty self explanatory. > > The html comparisons are: > jdk6 vs latest work: > http://icedtea.classpath.org/~dlila/benchResults/JDK6vsLatest_html/Summary_Report.html > > closed source vs latest work: > http://icedtea.classpath.org/~dlila/benchResults/SUNvsLatest_html/Summary_Report.html > > and most importantly: > previous version of pisces in openjdk7 vs latest work: > http://icedtea.classpath.org/~dlila/benchResults/PrevVsLatest_html/Summary_Report.html > > The improvements are significant. Running J2DAnalyzer on all the results files with > jdk6Bench.res as the basis produces the following summary: > > Summary: > jdk6Bench: > Number of tests: 104 > Overall average: 311110.7986576862 > Best spread: 0.0% variance > Worst spread: 10.96% variance > (Basis for results comparison) > > sunBench: > Number of tests: 104 > Overall average: 276654.4443479696 > Best spread: 0.25% variance > Worst spread: 19.28% variance > Comparison to basis: > Best result: 6488.34% of basis > Worst result: 43.74% of basis > Number of wins: 80 > Number of ties: 2 > Number of losses: 22 > > prevPisces: > Number of tests: 104 > Overall average: 221539.3516605794 > Best spread: 0.08% variance > Worst spread: 5.54% variance > Comparison to basis: > Best result: 350.33% of basis > Worst result: 55.0% of basis > Number of wins: 57 > Number of ties: 10 > Number of losses: 37 > > latestPisces: > Number of tests: 104 > Overall average: 226762.64157611743 > Best spread: 0.0% variance > Worst spread: 3.03% variance > Comparison to basis: > Best result: 501.86% of basis > Worst result: 26.23% of basis > Number of wins: 72 > Number of ties: 4 > Number of losses: 28 > > > But unfortunately, if you look at the individual test cases in the html > reports there are also some stepbacks, most notably in the dashing of > anything that isn't a straight line. In fact, the results of drawOval > show a 50%-500% improvement in non dashed drawing, and a 50%-25% deterioration > in dashed drawing. I was expecting this, after the binary search algorithm. > I've been thinking it might be better if we just go with the old algorithm > and simply use Dasher.LengthIterator to flatten the curves and feed the lines > to lineTo. Or we could just go with what we have and hope we find a better > algorithm. > > Regards, > Denis. From james.graham at oracle.com Fri Oct 22 23:05:11 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 22 Oct 2010 16:05:11 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <2114042183.1314951287775361647.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <2114042183.1314951287775361647.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC218A7.4010209@oracle.com> On 10/22/2010 12:22 PM, Denis Lila wrote: > Because the error is meant to be relative. What I use is supposed to be > equivalent to difference/AverageOfCorrectValueAndApproximation< err, > where, in our case, AverageOfCorrectValueAndApproximation=(len+leafLen)/2, > so that multiplication by 2 should have been a division. > Should I use the less fancy differece/CorrectValue< err and skip > a division by 2? If it is relative, then shouldn't it be relative to the desired length? Why does the computed approximation factor in to the size of the error you are looking for? If you use the average then the amount of error that you will "accept" will be larger if your estimate is wronger. I don't think the "wrongness" of your approximation should have any effect on your error. How about this: (Math.abs(len-leftLen) < err*len) (noting that err*len can be calculated outside of the loop). >> lines 98-101 - somewhere in the confusion moveToImpl became redundant >> with moveTo. > > I thought I'd leave these in because they're interface methods, > and it's usually not a great idea to call these from private methods. I've > removed them anyway, because you said so and because I suppose > if ever we need to do something to the user input that shouldn't be done > to input coming from private methods in the class (such as the scaling > of the input coordinates done in Renderer) we can always easily > reintroduce them. I actually thought about the interface concept after I sent that and was at peace with them, but I'm also at peace with them being gone. ;-) > That's right. I don't think it's what should happen, but it's what closed > jre does, so I've left it in (with some changes to make it actually > replicate the behaviour of closed java, since it was buggy - the moveTo > was missing). I don't draw anything on the second close in the close,close > case, since that would look horrible with round joins and square caps. > However, the way path2D's are implemented this safeguard will not be > activated since a closePath() following another closePath() is ignored. Note that a custom shape can send segments in any order that it wants so close,close can happen from a custom shape even if Path2D won't do it. > I also now initialize the *dxy *mxy variables in moveTo. This should be an > inconsequential change, but I've put it in just so the state of > Stroker after a moveTo is well defined. New code looks good (even if we think it's a silly side effect of closed JDK to have to implement). >> line 368 - does this cause a problem if t==1 because lastSegLen will >> now return the wrong value? Maybe move this into an else clause on the >> "t>=1" test? > > It does cause a problem. I've fixed it by adding a variable that keeps track > of the length of the last returned segment. The way it was being done was > a dirty hack because it assumed that if the method didn't return in the loop, > done would remain false. Woohoo! I was actually bothered by the side-effecting in the old code - this is a better approach. > I made one more change in dasher: in somethingTo I removed the long comment > near the end, and I handle the case where phase == dash[idx] immediately. > I do this for consistency with lineTo. The only instances where this makes > a difference is when we have a path that starts with a dash, ends at exactly > the end of a dash, and has a closePath. So something like move(100,0), > line(0,0),line(0,50),line(100,50),line(100,0),close() with a dash pattern {60,60}. > In closed jdk (and also in openjdk with my patch), no join would be drawn > at 100,0 on this path with this dash pattern. > Whether that's correct behaviour is arguable, imho. On one hand, if we don't do it > , but I think it is because if > it isn't done certain dashed rectangles start looking weird at the top left. I think it probably should not have a join since we don't join two segments if one of the "OFF" lengths is 0. We should probably only save the first dash if it starts in the middle of a dash. Perhaps the closed JDK is wrong here. > Now, consider a path like move(100,0),line(0,0),curve(0,100,100,100,100,0),close() > with a dash pattern of {60,60}. The length of the curve in this is exactly 200 (I > have not proven this, but it seems clear since the more I increase precision, the > closer to 200 the computed length becomes. Also, if you render it with a dash pattern > of {10,10} in closed jdk, exactly 10 full dashes are drawn). So, this path has exactly the same > length as the above path. However, if this path is rendered with closed jdk a join > will be drawn at (100,0). This behaviour is inconsistent with the line only path > For this reason, I think this is a bug in closed jdk since dashing > should depend only on the path's length, not on the kind of segments in a path. Note that curve length is imperfect so their behavior may differ because the above path had exact lengths that didn't rely on fp calculations with errors to get it right, but the curved case had a lot of computations. Even if they believe the last dash had .000000001 left on it, they would close, even though they believed the length of the curve to be "about 200". > Handling the case where phase==dash[idx] immediately fixes this problem. Good point. > I also moved the second if statement in the loop of lineTo inside the first if > for symmetry with how this case is handled in somethingTo. The logic is the same. Looks good. I was going to say that, but figured it was too "nitty" to even mention (perhaps you're getting the hint that I'm a bit OCD about code... ;-) > I reran all the gfx tests. Nothing has changed. Woohoo! There is only one question on the board from my perspective - the question about dash length errors at the start of this message. Depending on how you feel about that I think we're ready to go (and I have some ideas on further optimizations to consider if you are still game after this goes in)... ...jim From dlila at redhat.com Mon Oct 25 14:12:42 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 25 Oct 2010 10:12:42 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1974242359.1416041288015711723.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1584100192.1416651288015962269.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > It's interesting to note that non-AA dashed ovals took a > much bigger hit than AA dashed ovals so we need to see which code is > fielding those and see what its issue is. I think that's because when AA is used the tests take more time, so a smaller proportion of time is being spent in Dasher so all that is needed for us to see this pattern is for AA to not have gotten too much worse (which it hasn't - it's faster in fact). Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > Interesting results. Note that sun-jdk7 is already showing some > regressions so the more intesting results are the old-to-new pisces > comparisons. > > I'd stick with the new algorithm and lets look for ways to make dashed > > curves go faster. I know there are better "curve length" algorithms > we > could incorporate, but let's get a stake in the ground before we > consider going back to flattening... > > ...jim > > On 10/22/2010 2:25 PM, Denis Lila wrote: > > Hi Jim. > > > >> I was going to run these today, but fixing the dashing bug above > and > >> rerunning the tests took a while and it's already 8:30 pm here and > I > >> have to go home. I'll run them tomorrow morning. > > > > I ran the benchmarks. I've attached the options file. I ran > benchmarks > > of my icedtea installation, closed source java, openjdk7 without > the > > webrev, and openjdk7 with the webrev. > > > > The results files are at > http://icedtea.classpath.org/~dlila/benchResults/ > > I think the names are pretty self explanatory. > > > > The html comparisons are: > > jdk6 vs latest work: > > > http://icedtea.classpath.org/~dlila/benchResults/JDK6vsLatest_html/Summary_Report.html > > > > closed source vs latest work: > > > http://icedtea.classpath.org/~dlila/benchResults/SUNvsLatest_html/Summary_Report.html > > > > and most importantly: > > previous version of pisces in openjdk7 vs latest work: > > > http://icedtea.classpath.org/~dlila/benchResults/PrevVsLatest_html/Summary_Report.html > > > > The improvements are significant. Running J2DAnalyzer on all the > results files with > > jdk6Bench.res as the basis produces the following summary: > > > > Summary: > > jdk6Bench: > > Number of tests: 104 > > Overall average: 311110.7986576862 > > Best spread: 0.0% variance > > Worst spread: 10.96% variance > > (Basis for results comparison) > > > > sunBench: > > Number of tests: 104 > > Overall average: 276654.4443479696 > > Best spread: 0.25% variance > > Worst spread: 19.28% variance > > Comparison to basis: > > Best result: 6488.34% of basis > > Worst result: 43.74% of basis > > Number of wins: 80 > > Number of ties: 2 > > Number of losses: 22 > > > > prevPisces: > > Number of tests: 104 > > Overall average: 221539.3516605794 > > Best spread: 0.08% variance > > Worst spread: 5.54% variance > > Comparison to basis: > > Best result: 350.33% of basis > > Worst result: 55.0% of basis > > Number of wins: 57 > > Number of ties: 10 > > Number of losses: 37 > > > > latestPisces: > > Number of tests: 104 > > Overall average: 226762.64157611743 > > Best spread: 0.0% variance > > Worst spread: 3.03% variance > > Comparison to basis: > > Best result: 501.86% of basis > > Worst result: 26.23% of basis > > Number of wins: 72 > > Number of ties: 4 > > Number of losses: 28 > > > > > > But unfortunately, if you look at the individual test cases in the > html > > reports there are also some stepbacks, most notably in the dashing > of > > anything that isn't a straight line. In fact, the results of > drawOval > > show a 50%-500% improvement in non dashed drawing, and a 50%-25% > deterioration > > in dashed drawing. I was expecting this, after the binary search > algorithm. > > I've been thinking it might be better if we just go with the old > algorithm > > and simply use Dasher.LengthIterator to flatten the curves and feed > the lines > > to lineTo. Or we could just go with what we have and hope we find a > better > > algorithm. > > > > Regards, > > Denis. From dlila at redhat.com Mon Oct 25 14:34:54 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 25 Oct 2010 10:34:54 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <564505631.1419881288017012010.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1213329260.1420741288017294932.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > How about this: > > (Math.abs(len-leftLen) < err*len) > > (noting that err*len can be calculated outside of the loop). This is what I use now. > Note that a custom shape can send segments in any order that it wants > so close,close can happen from a custom shape even if Path2D won't do > it. Right, of course. For some reason I only considered the test case I was using. Sorry for slip up. > There is only one question on the board from my perspective - the > question about dash length errors at the start of this message. I'm ok with the accuracy of dash length computations. My main concerns right now are dashing performance and AA rendering performance. The latter has improved, but not by as much as I was expecting. Also, it was bothering me that when I removed PiscesCache 1-2 weeks ago performance got worse. It would also be nice to find a method that is guaranteed to find all offset curve cusps. > Depending on how you feel about that I think we're ready to go That's great. I will be pushing today. > (and I have some ideas on further optimizations to consider if you are still > game after this goes in)... I'd love to hear what they are. Thank you for all your time, Denis. ----- "Jim Graham" wrote: > On 10/22/2010 12:22 PM, Denis Lila wrote: > > Because the error is meant to be relative. What I use is supposed to > be > > equivalent to difference/AverageOfCorrectValueAndApproximation< > err, > > where, in our case, > AverageOfCorrectValueAndApproximation=(len+leafLen)/2, > > so that multiplication by 2 should have been a division. > > Should I use the less fancy differece/CorrectValue< err and skip > > a division by 2? > > If it is relative, then shouldn't it be relative to the desired > length? > Why does the computed approximation factor in to the size of the > error > you are looking for? If you use the average then the amount of error > > that you will "accept" will be larger if your estimate is wronger. I > > don't think the "wrongness" of your approximation should have any > effect > on your error. > > >> lines 98-101 - somewhere in the confusion moveToImpl became > redundant > >> with moveTo. > > > > I thought I'd leave these in because they're interface methods, > > and it's usually not a great idea to call these from private > methods. I've > > removed them anyway, because you said so and because I suppose > > if ever we need to do something to the user input that shouldn't be > done > > to input coming from private methods in the class (such as the > scaling > > of the input coordinates done in Renderer) we can always easily > > reintroduce them. > > I actually thought about the interface concept after I sent that and > was > at peace with them, but I'm also at peace with them being gone. ;-) > > > That's right. I don't think it's what should happen, but it's what > closed > > jre does, so I've left it in (with some changes to make it actually > > replicate the behaviour of closed java, since it was buggy - the > moveTo > > was missing). I don't draw anything on the second close in the > close,close > > case, since that would look horrible with round joins and square > caps. > > However, the way path2D's are implemented this safeguard will not > be > > activated since a closePath() following another closePath() is > ignored. > > > I also now initialize the *dxy *mxy variables in moveTo. This should > be an > > inconsequential change, but I've put it in just so the state of > > Stroker after a moveTo is well defined. > > New code looks good (even if we think it's a silly side effect of > closed > JDK to have to implement). > > >> line 368 - does this cause a problem if t==1 because lastSegLen > will > >> now return the wrong value? Maybe move this into an else clause on > the > >> "t>=1" test? > > > > It does cause a problem. I've fixed it by adding a variable that > keeps track > > of the length of the last returned segment. The way it was being > done was > > a dirty hack because it assumed that if the method didn't return in > the loop, > > done would remain false. > > Woohoo! I was actually bothered by the side-effecting in the old code > - > this is a better approach. > > > I made one more change in dasher: in somethingTo I removed the long > comment > > near the end, and I handle the case where phase == dash[idx] > immediately. > > I do this for consistency with lineTo. The only instances where this > makes > > a difference is when we have a path that starts with a dash, ends at > exactly > > the end of a dash, and has a closePath. So something like > move(100,0), > > line(0,0),line(0,50),line(100,50),line(100,0),close() with a dash > pattern {60,60}. > > In closed jdk (and also in openjdk with my patch), no join would be > drawn > > at 100,0 on this path with this dash pattern. > > Whether that's correct behaviour is arguable, imho. On one hand, if > we don't do it > > , but I think it is because if > > it isn't done certain dashed rectangles start looking weird at the > top left. > > I think it probably should not have a join since we don't join two > segments if one of the "OFF" lengths is 0. We should probably only > save > the first dash if it starts in the middle of a dash. > > Perhaps the closed JDK is wrong here. > > > Now, consider a path like > move(100,0),line(0,0),curve(0,100,100,100,100,0),close() > > with a dash pattern of {60,60}. The length of the curve in this is > exactly 200 (I > > have not proven this, but it seems clear since the more I increase > precision, the > > closer to 200 the computed length becomes. Also, if you render it > with a dash pattern > > of {10,10} in closed jdk, exactly 10 full dashes are drawn). So, > this path has exactly the same > > length as the above path. However, if this path is rendered with > closed jdk a join > > will be drawn at (100,0). This behaviour is inconsistent with the > line only path > > For this reason, I think this is a bug in closed jdk since dashing > > should depend only on the path's length, not on the kind of segments > in a path. > > Note that curve length is imperfect so their behavior may differ > because > the above path had exact lengths that didn't rely on fp calculations > with errors to get it right, but the curved case had a lot of > computations. Even if they believe the last dash had .000000001 left > on > it, they would close, even though they believed the length of the > curve > to be "about 200". > > > Handling the case where phase==dash[idx] immediately fixes this > problem. > > Good point. > > > I also moved the second if statement in the loop of lineTo inside > the first if > > for symmetry with how this case is handled in somethingTo. The logic > is the same. > > Looks good. I was going to say that, but figured it was too "nitty" > to > even mention (perhaps you're getting the hint that I'm a bit OCD about > > code... ;-) > > > I reran all the gfx tests. Nothing has changed. > > Woohoo! > > > ...jim From dlila at redhat.com Mon Oct 25 15:17:25 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 25 Oct 2010 11:17:25 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1213329260.1420741288017294932.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1341776311.1427881288019845895.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > That's great. I will be pushing today. About that: you wrote the TransformingPathConsumer2D file, so how should you be given credit? Should I put your name in "Contributed-by"? Should I put an @author tag in the file? Or does the "reviewed-by" suffice? Regards, Denis. ----- "Denis Lila" wrote: > Hi Jim. > > > How about this: > > > > (Math.abs(len-leftLen) < err*len) > > > > (noting that err*len can be calculated outside of the loop). > > This is what I use now. > > > Note that a custom shape can send segments in any order that it > wants > > so close,close can happen from a custom shape even if Path2D won't > do > > it. > > Right, of course. For some reason I only considered the test case I > was > using. Sorry for slip up. > > > There is only one question on the board from my perspective - the > > question about dash length errors at the start of this message. > > I'm ok with the accuracy of dash length computations. My main > concerns > right now are dashing performance and AA rendering performance. The > latter has improved, but not by as much as I was expecting. Also, it > was > bothering me that when I removed PiscesCache 1-2 weeks ago > performance > got worse. > It would also be nice to find a method that is guaranteed to find > all offset curve cusps. > > > Depending on how you feel about that I think we're ready to go > > That's great. I will be pushing today. > > > (and I have some ideas on further optimizations to consider if you > are still > > game after this goes in)... > > I'd love to hear what they are. > > Thank you for all your time, > Denis. > > ----- "Jim Graham" wrote: > > > On 10/22/2010 12:22 PM, Denis Lila wrote: > > > Because the error is meant to be relative. What I use is supposed > to > > be > > > equivalent to difference/AverageOfCorrectValueAndApproximation< > > err, > > > where, in our case, > > AverageOfCorrectValueAndApproximation=(len+leafLen)/2, > > > so that multiplication by 2 should have been a division. > > > Should I use the less fancy differece/CorrectValue< err and skip > > > a division by 2? > > > > If it is relative, then shouldn't it be relative to the desired > > length? > > Why does the computed approximation factor in to the size of the > > error > > you are looking for? If you use the average then the amount of > error > > > > that you will "accept" will be larger if your estimate is wronger. > I > > > > don't think the "wrongness" of your approximation should have any > > effect > > on your error. > > > > >> lines 98-101 - somewhere in the confusion moveToImpl became > > redundant > > >> with moveTo. > > > > > > I thought I'd leave these in because they're interface methods, > > > and it's usually not a great idea to call these from private > > methods. I've > > > removed them anyway, because you said so and because I suppose > > > if ever we need to do something to the user input that shouldn't > be > > done > > > to input coming from private methods in the class (such as the > > scaling > > > of the input coordinates done in Renderer) we can always easily > > > reintroduce them. > > > > I actually thought about the interface concept after I sent that > and > > was > > at peace with them, but I'm also at peace with them being gone. ;-) > > > > > That's right. I don't think it's what should happen, but it's > what > > closed > > > jre does, so I've left it in (with some changes to make it > actually > > > replicate the behaviour of closed java, since it was buggy - the > > moveTo > > > was missing). I don't draw anything on the second close in the > > close,close > > > case, since that would look horrible with round joins and square > > caps. > > > However, the way path2D's are implemented this safeguard will not > > be > > > activated since a closePath() following another closePath() is > > ignored. > > > > > I also now initialize the *dxy *mxy variables in moveTo. This > should > > be an > > > inconsequential change, but I've put it in just so the state of > > > Stroker after a moveTo is well defined. > > > > New code looks good (even if we think it's a silly side effect of > > closed > > JDK to have to implement). > > > > >> line 368 - does this cause a problem if t==1 because lastSegLen > > will > > >> now return the wrong value? Maybe move this into an else clause > on > > the > > >> "t>=1" test? > > > > > > It does cause a problem. I've fixed it by adding a variable that > > keeps track > > > of the length of the last returned segment. The way it was being > > done was > > > a dirty hack because it assumed that if the method didn't return > in > > the loop, > > > done would remain false. > > > > Woohoo! I was actually bothered by the side-effecting in the old > code > > - > > this is a better approach. > > > > > I made one more change in dasher: in somethingTo I removed the > long > > comment > > > near the end, and I handle the case where phase == dash[idx] > > immediately. > > > I do this for consistency with lineTo. The only instances where > this > > makes > > > a difference is when we have a path that starts with a dash, ends > at > > exactly > > > the end of a dash, and has a closePath. So something like > > move(100,0), > > > line(0,0),line(0,50),line(100,50),line(100,0),close() with a dash > > pattern {60,60}. > > > In closed jdk (and also in openjdk with my patch), no join would > be > > drawn > > > at 100,0 on this path with this dash pattern. > > > Whether that's correct behaviour is arguable, imho. On one hand, > if > > we don't do it > > > , but I think it is because if > > > it isn't done certain dashed rectangles start looking weird at > the > > top left. > > > > I think it probably should not have a join since we don't join two > > segments if one of the "OFF" lengths is 0. We should probably only > > save > > the first dash if it starts in the middle of a dash. > > > > Perhaps the closed JDK is wrong here. > > > > > Now, consider a path like > > move(100,0),line(0,0),curve(0,100,100,100,100,0),close() > > > with a dash pattern of {60,60}. The length of the curve in this > is > > exactly 200 (I > > > have not proven this, but it seems clear since the more I > increase > > precision, the > > > closer to 200 the computed length becomes. Also, if you render it > > with a dash pattern > > > of {10,10} in closed jdk, exactly 10 full dashes are drawn). So, > > this path has exactly the same > > > length as the above path. However, if this path is rendered with > > closed jdk a join > > > will be drawn at (100,0). This behaviour is inconsistent with the > > line only path > > > For this reason, I think this is a bug in closed jdk since > dashing > > > should depend only on the path's length, not on the kind of > segments > > in a path. > > > > Note that curve length is imperfect so their behavior may differ > > because > > the above path had exact lengths that didn't rely on fp calculations > > > with errors to get it right, but the curved case had a lot of > > computations. Even if they believe the last dash had .000000001 > left > > on > > it, they would close, even though they believed the length of the > > curve > > to be "about 200". > > > > > Handling the case where phase==dash[idx] immediately fixes this > > problem. > > > > Good point. > > > > > I also moved the second if statement in the loop of lineTo inside > > the first if > > > for symmetry with how this case is handled in somethingTo. The > logic > > is the same. > > > > Looks good. I was going to say that, but figured it was too > "nitty" > > to > > even mention (perhaps you're getting the hint that I'm a bit OCD > about > > > > code... ;-) > > > > > I reran all the gfx tests. Nothing has changed. > > > > Woohoo! > > > > > > ...jim From james.graham at oracle.com Mon Oct 25 19:47:02 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 25 Oct 2010 12:47:02 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1213329260.1420741288017294932.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1213329260.1420741288017294932.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC5DEB6.3090708@oracle.com> Hi Denis, On 10/25/2010 7:34 AM, Denis Lila wrote: >> (and I have some ideas on further optimizations to consider if you are still >> game after this goes in)... > > I'd love to hear what they are. Here are my thoughts: - Currently Renderer has more stages than we probably should have: for (each full pixel row) { for (each subpixel row) { for (each curve on subpixel row) { convert curve into crossing crossing is (subpixelx:31 + dir:1) } sort crossings for subpixel row apply wind rule and convert crossings into alpha deltas } convert alpha deltas into run lengths } for (each tile) { convert run lengths into alphas } I'm thinking we should be able to get rid of a couple of those stages... - One alternate process would be: (all work is done in the tail end of the cache itself) for (each full pixel row) { for (each curve on full pixel row) { convert curve into N subpixel crossings (subpixelx:28 + subpixelfracty:3 + dir:1) } } sort all crossings for entire pixel row maybe collapse raw crossings into modified accumulated crossings record start of row in index array for (each tile) { convert raw or collapsed crossings directly into alphas } Note that we could simply leave the raw crossings in the cache and then process them in the tile generator, but that would require more storage in the cache since a given path would tend to have 8 different entries as it crossed every subpixel row. If we collapse them, then we can sum the entries for a given x coordinate into a single entry and store: (pixelx:25 + coveragedelta:7) where the coverage delta is a signed quantity up to N_SUBPIX^2 so it uses the same storage we needed for the subpixel parts of both X and Y plus the direction bit. It likely needs a paired value in the next x pixel location just like our current "alpha deltas" needs as well. If we wanted to optimize that then we could devote one more bit to "the next pixel will consume all of the remainder of the N^2 coverage", but there would be cases where that would not be true (such as if the pixel row has only partial vertical coverage by the path). It's probably simpler to just have deltas for every pixel. The storage here would likely be similar to the storage used for the current cache since the current RLE cache uses 2 full ints to store a coverage and a count. And in cases where we have one pixel taking up partial coverage and the following pixel taking up the remainder of the full coverage then we have 4 ints, but the "crossing delta" system would only have 2 ints. Other thoughts... - Create a curve class and store an array of those so you don't have to iterate 3 different arrays of values and use array accesses to grab the data (each array access is checked for index OOB exceptions). - Or perform AFD on curves as they come into Renderer, but only save line segment edges in the edges array. This would use more storage, but the iterations of the AFD would happen in a tight loop as the data comes in rather than having to store all of their AFD data back in the quads and curves arrays and then reload the data for every sub-pixel step. Renderer still takes curves, it just breaks them down immediately rather than on the fly. If there are only a small number of edges per curve then the storage might not be that much worse because the quad and curve arrays already store more values than the edge array. - Convert to native. Note that we use a native version of the pisces that you started with to do some rendering in FX. I tried porting to use your new (Java) renderer in FX and performance went down even though you show it to be faster than what was there before. So, your Java renderer compares favorably to the old Java pisces, but both compare unfavorably to the old native pisces. Maybe we should convert your code to native and see if that gives us a performance boost. It's nice to use pure Java, but there is a lot of "shoehorning" of data going on here that could be done much more easily and naturally in native code. How is that for "food for thought"? ...jim From dlila at redhat.com Mon Oct 25 22:30:25 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 25 Oct 2010 18:30:25 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1042542373.1473241288045700188.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <460590212.1473431288045825422.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > - Create a curve class and store an array of those so you don't have > to iterate 3 different arrays of values and use array accesses to grab > the data (each array access is checked for index OOB exceptions). I actually implemented something like this in my first draft of the current version of renderer. I didn't stick with it because it was a slower than even what we have in openjdk6. Granted, my implementation was a bit more high level than simply making 3 classes to represent lines quads and cubics, but it seemed pretty hopeless, so I didn't spend any time figuring out exactly what it was that made it slower. > - Or perform AFD on curves as they come into Renderer, but only save > line segment edges in the edges array. This would use more storage, > but the iterations of the AFD would happen in a tight loop as the data > comes in rather than having to store all of their AFD data back in the quads I considered this before abandoning the high level version I mention above. I didn't go with it because, while I am not worried about the higher memory consumption, I was afraid of the impact that having this many edges would have on the qsort call and on lines 99-113 and 140-148 in next(). How about this: we change the format of the edges array to be an array of sequences of edges. So, right now the edges array has this format: E* where E represents 6 consecutive floats {ymin,ymax,curx,cury,or,slope}. I am proposing we change it to {n,or}({ymin,ymax,curx,cury,slope})^n. lineTo's would add an edge sequence with n=1 to the edges array. If a call to quadTo or curveTo produced N curves, it would simply put N,or at the end of the edges array, and then append the data for the N produced edges. I think this would give us the best of both worlds, in that we can do all the AFD iterations in a tight loop close to the input methods and it doesn't present any problems with respect to sorting or managing the active list. It can probably be implemented completely transparently with respect to ScanlineIterator. The details of the implementation involve an interesting speed/memory trade off, but we can discuss that later. > - Convert to native. Note that we use a native version of the pisces > that you started with to do some rendering in FX. I tried porting to > use your new (Java) renderer in FX and performance went down even > though you show it to be faster than what was there before. So, your Java > renderer compares favorably to the old Java pisces, but both compare > unfavorably to the old native pisces. Maybe we should convert your > code to native and see if that gives us a performance boost. It's nice to > use pure Java, but there is a lot of "shoehorning" of data going on > here that could be done much more easily and naturally in native code. I've been wanting to do this for a very long time. C and C++ are more convenient for this type of work. I didn't because I've never used the JNI before. I guess this is as good a time to learn as any. I'd still like to keep the debugging of native code to a minimum, so we should implement as much as possible in java before starting on this. I still need to think some more about your other suggestion. I'll reply to it tomorrow. > How is that for "food for thought"? Delicious :) Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 10/25/2010 7:34 AM, Denis Lila wrote: > >> (and I have some ideas on further optimizations to consider if you > are still > >> game after this goes in)... > > > > I'd love to hear what they are. > > Here are my thoughts: > > - Currently Renderer has more stages than we probably should have: > for (each full pixel row) { > for (each subpixel row) { > for (each curve on subpixel row) { > convert curve into crossing > crossing is (subpixelx:31 + dir:1) > } > sort crossings for subpixel row > apply wind rule and convert crossings into alpha deltas > } > convert alpha deltas into run lengths > } > for (each tile) { > convert run lengths into alphas > } > I'm thinking we should be able to get rid of a couple of those > stages... > > - One alternate process would be: > (all work is done in the tail end of the cache itself) > for (each full pixel row) { > for (each curve on full pixel row) { > convert curve into N subpixel crossings > (subpixelx:28 + subpixelfracty:3 + dir:1) > } > } > sort all crossings for entire pixel row > maybe collapse raw crossings into modified accumulated crossings > record start of row in index array > for (each tile) { > convert raw or collapsed crossings directly into alphas > } > Note that we could simply leave the raw crossings in the cache and > then > process them in the tile generator, but that would require more > storage > in the cache since a given path would tend to have 8 different entries > > as it crossed every subpixel row. If we collapse them, then we can > sum > the entries for a given x coordinate into a single entry and store: > (pixelx:25 + coveragedelta:7) > where the coverage delta is a signed quantity up to N_SUBPIX^2 so it > uses the same storage we needed for the subpixel parts of both X and Y > > plus the direction bit. It likely needs a paired value in the next x > > pixel location just like our current "alpha deltas" needs as well. If > > we wanted to optimize that then we could devote one more bit to "the > next pixel will consume all of the remainder of the N^2 coverage", but > > there would be cases where that would not be true (such as if the > pixel > row has only partial vertical coverage by the path). It's probably > simpler to just have deltas for every pixel. > > The storage here would likely be similar to the storage used for the > current cache since the current RLE cache uses 2 full ints to store a > > coverage and a count. And in cases where we have one pixel taking up > > partial coverage and the following pixel taking up the remainder of > the > full coverage then we have 4 ints, but the "crossing delta" system > would > only have 2 ints. > > Other thoughts... > > and curves arrays and then reload the data for every sub-pixel step. > Renderer still takes curves, it just breaks them down immediately > rather > than on the fly. If there are only a small number of edges per curve > > then the storage might not be that much worse because the quad and > curve > arrays already store more values than the edge array. > > ...jim From james.graham at oracle.com Tue Oct 26 00:54:31 2010 From: james.graham at oracle.com (Jim Graham) Date: Mon, 25 Oct 2010 17:54:31 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <460590212.1473431288045825422.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <460590212.1473431288045825422.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC626C7.3010908@oracle.com> Hi Denis, Just to be certain - you are still planning on putting the existing stuff back and we're talking about future work, right? I'd love to get a stake in the ground here. On 10/25/2010 3:30 PM, Denis Lila wrote: >> - Create a curve class and store an array of those so you don't have >> to iterate 3 different arrays of values and use array accesses to grab >> the data (each array access is checked for index OOB exceptions). > > I actually implemented something like this in my first draft of the current > version of renderer. I didn't stick with it because it was a slower than > even what we have in openjdk6. Granted, my implementation was a bit more > high level than simply making 3 classes to represent lines quads and cubics, > but it seemed pretty hopeless, so I didn't spend any time figuring out > exactly what it was that made it slower. Hmmm... Perhaps object allocation overhead was biting us there. In native code you could cobble this up with batch allocation of space and pseudo-object/struct allocation out of the batches. >> - Or perform AFD on curves as they come into Renderer, but only save >> line segment edges in the edges array. This would use more storage, >> but the iterations of the AFD would happen in a tight loop as the data >> comes in rather than having to store all of their AFD data back in the quads > > I considered this before abandoning the high level version I mention above. > I didn't go with it because, while I am not worried about the higher memory > consumption, I was afraid of the impact that having this many edges would > have on the qsort call and on lines 99-113 and 140-148 in next(). I can see worrying about qsort, but I think one qsort would be inherently faster than 3 qsorts which you have anyway so the difference would get lost in the noise. Also, I'm not sure how the 99 to 113 and 140 to 148 would be affected. The path will have the same number of crossings per sample row regardless of whether the curves have been flattened or not. You might be adding and deleting edges from the active list more often, though (in other words, 99 would dump more curves and 140 would take in more curves), but the number of edges or curves at any given point would not be affected by flattening. Also, the way you've written the loops at 99, they have to copy every edge/quad/curve that *doesn't* expire so a skipped curve is actually less work for that loop. The loops at 140 would have to occasionally do more processing, but it is made up for in the fact that 99 does less work and the "nextY" processing is simpler. > How about this: we change the format of the edges array to be an array of > sequences of edges. So, right now the edges array has this format: > E* where E represents 6 consecutive floats {ymin,ymax,curx,cury,or,slope}. > I am proposing we change it to {n,or}({ymin,ymax,curx,cury,slope})^n. > lineTo's would add an edge sequence with n=1 to the edges array. If a call > to quadTo or curveTo produced N curves, it would simply put N,or at the > end of the edges array, and then append the data for the N produced edges. > I think this would give us the best of both worlds, in that we can do all > the AFD iterations in a tight loop close to the input methods and it > doesn't present any problems with respect to sorting or managing the > active list. It can probably be implemented completely transparently with > respect to ScanlineIterator. The details of > the implementation involve an interesting speed/memory trade off, but we > can discuss that later. I think this might be overkill since sorts tend to have logN behavior so doubling the number of edges would not double the time taken in the sort. Also, I would think that the sort would be a small amount of time compared to the rest of the processing, wasn't it? If we are really worried about the y-sort, then how about creating a bunch of buckets and doing a bucket sort of the edges? As they are added to the list of segments, we accumulate their indices in a row list based on their startY so that each step of the "next()" simply moves to the next Y and adds the edges mentioned in the list there. Some work would have to be done on how to manage the storage simply (like a "rownext" field in the edge structure so that they are linked in a linked list), but then there would be no qsort at all for the cost of new int[N_ROWS] and an extra field in every edge. >> - Convert to native. Note that we use a native version of the pisces >> that you started with to do some rendering in FX. I tried porting to >> use your new (Java) renderer in FX and performance went down even >> though you show it to be faster than what was there before. So, your Java >> renderer compares favorably to the old Java pisces, but both compare >> unfavorably to the old native pisces. Maybe we should convert your >> code to native and see if that gives us a performance boost. It's nice to >> use pure Java, but there is a lot of "shoehorning" of data going on >> here that could be done much more easily and naturally in native code. > > I've been wanting to do this for a very long time. C and C++ are more > convenient for this type of work. I didn't because I've never used the JNI > before. I guess this is as good a time to learn as any. I'd still like to > keep the debugging of native code to a minimum, so we should implement > as much as possible in java before starting on this. Perhaps we should work on the algorithms a little more then (I'm talking about the numeric stuff, not the memory management stuff since the memory management techniques will differ quite a lot in C code, but better math helps at either level)? >> How is that for "food for thought"? > Delicious :) Here's another idea: 90% (guesstimate) of the time edges do not cross each other, thus if you sort the crossings without reordering the active edges then you just end up doing the same sorting work (same swaps) on the next scanline. My SpanShapeIterator code actually reordered the edges on every sample line to match their current X coordinates in a way that involved 1 compare per edge that was processed and only occasionally a swap of 2 edge pointers. It would basically eliminate the sort at line 149 at the cost of only doing a compare in the nextY processing for the very very common case. And another non-idea: I tried inlining all of the work that lineTo did and it ended up slower than what you do where you turn it into a generic curve of length 4 in a points array. I scratched my head, but didn't pursue why that would be slower. It might have been because I had a large chunk of nearly duplicate code in both halves of an "if (y0 < y1)" conditional rather than simply swapping the coordinates and using common code - maybe it was an instruction cache thing. The test case I was using to test performance was only using polygons so the curve stuff didn't even come into play... ...jim From dlila at redhat.com Tue Oct 26 13:58:21 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 26 Oct 2010 09:58:21 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1443171120.1518831288101370965.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1333733575.1519201288101501519.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. > Just to be certain - you are still planning on putting the existing > stuff back and we're talking about future work, right? ?I'd love to > get a stake in the ground here. Yes, I'll push today. > If we are really worried about the y-sort, then how about creating a > bunch of buckets and doing a bucket sort of the edges? ?As they are > added to the list of segments, we accumulate their indices in a row > list based on their startY so that each step of the "next()" simply moves > to the next Y and adds the edges mentioned in the list there. ?Some work > would have to be done on how to manage the storage simply (like a > "rownext" field in the edge structure so that they are linked in a > linked list), but then there would be no qsort at all for the cost of > new int[N_ROWS] and an extra field in every edge. I like this. > Perhaps we should work on the algorithms a little more then (I'm > talking about the numeric stuff, not the memory management stuff since the > memory management techniques will differ quite a lot in C code, but > better math helps at either level)? Indeed - especially the dashing. > 90% (guesstimate) of the time edges do not cross each other, thus if > you sort the crossings without reordering the active edges then you just > end up doing the same sorting work (same swaps) on the next scanline. ?My > SpanShapeIterator code actually reordered the edges on every sample > line to match their current X coordinates in a way that involved 1 compare > per edge that was processed and only occasionally a swap of 2 edge > pointers. ?It would basically eliminate the sort at line 149 at the > cost of only doing a compare in the nextY processing for the very very > common case. I also implemented this some time ago. I didn't keep it because it slowed things down a bit. However, I only tested it with very complex and large paths, and in hindsight, I shouldn't have based my decision on that, so I will re-implement it. Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 10/25/2010 3:30 PM, Denis Lila wrote: > >> - Create a curve class and store an array of those so you don't > have > >> to iterate 3 different arrays of values and use array accesses to > grab > >> the data (each array access is checked for index OOB exceptions). > > > > I actually implemented something like this in my first draft of the > current > > version of renderer. I didn't stick with it because it was a slower > than > > even what we have in openjdk6. Granted, my implementation was a bit > more > > high level than simply making 3 classes to represent lines quads and > cubics, > > but it seemed pretty hopeless, so I didn't spend any time figuring > out > > exactly what it was that made it slower. > > Hmmm... ?Perhaps object allocation overhead was biting us there. ?In > native code you could cobble this up with batch allocation of space > and > pseudo-object/struct allocation out of the batches. > > >> - Or perform AFD on curves as they come into Renderer, but only > save > >> line segment edges in the edges array. ?This would use more > storage, > >> but the iterations of the AFD would happen in a tight loop as the > data > >> comes in rather than having to store all of their AFD data back in > the quads > > > > I considered this before abandoning the high level version I mention > above. > > I didn't go with it because, while I am not worried about the higher > memory > > consumption, I was afraid of the impact that having this many edges > would > > have on the qsort call and on lines 99-113 and 140-148 in next(). > > I can see worrying about qsort, but I think one qsort would be > inherently faster than 3 qsorts which you have anyway so the > difference > would get lost in the noise. ?Also, I'm not sure how the 99 to 113 and > > 140 to 148 would be affected. ?The path will have the same number of > crossings per sample row regardless of whether the curves have been > flattened or not. ?You might be adding and deleting edges from the > active list more often, though (in other words, 99 would dump more > curves and 140 would take in more curves), but the number of edges or > > curves at any given point would not be affected by flattening. ?Also, > > the way you've written the loops at 99, they have to copy every > edge/quad/curve that *doesn't* expire so a skipped curve is actually > less work for that loop. ?The loops at 140 would have to occasionally > do > more processing, but it is made up for in the fact that 99 does less > work and the "nextY" processing is simpler. > > > How about this: we change the format of the edges array to be an > array of > > sequences of edges. So, right now the edges array has this format: > > E* where E represents 6 consecutive floats > {ymin,ymax,curx,cury,or,slope}. > > I am proposing we change it to > {n,or}({ymin,ymax,curx,cury,slope})^n. > > lineTo's would add an edge sequence with n=1 to the edges array. If > a call > > to quadTo or curveTo produced N curves, it would simply put N,or at > the > > end of the edges array, and then append the data for the N produced > edges. > > I think this would give us the best of both worlds, in that we can > do all > > the AFD iterations in a tight loop close to the input methods and > it > > doesn't present any problems with respect to sorting or managing > the > > active list. It can probably be implemented completely transparently > with > > respect to ScanlineIterator. The details of > > the implementation involve an interesting speed/memory trade off, > but we > > can discuss that later. > > I think this might be overkill since sorts tend to have logN behavior > so > doubling the number of edges would not double the time taken in the > sort. ?Also, I would think that the sort would be a small amount of > time > compared to the rest of the processing, wasn't it? > > >> - Convert to native. ?Note that we use a native version of the > pisces > >> that you started with to do some rendering in FX. ?I tried porting > to > >> use your new (Java) renderer in FX and performance went down even > >> though you show it to be faster than what was there before. ?So, > your Java > >> renderer compares favorably to the old Java pisces, but both > compare > >> unfavorably to the old native pisces. ?Maybe we should convert > your > >> code to native and see if that gives us a performance boost. ?It's > nice to > >> use pure Java, but there is a lot of "shoehorning" of data going > on > >> here that could be done much more easily and naturally in native > code. > > > > I've been wanting to do this for a very long time. C and C++ are > more > > convenient for this type of work. I didn't because I've never used > the JNI > > before. I guess this is as good a time to learn as any. I'd still > like to > > keep the debugging of native code to a minimum, so we should > implement > > as much as possible in java before starting on this. > > >> How is that for "food for thought"? > > Delicious :) > > > > Here's another idea: > > And another non-idea: > > I tried inlining all of the work that lineTo did and it ended up > slower > than what you do where you turn it into a generic curve of length 4 in > a > points array. ?I scratched my head, but didn't pursue why that would > be > slower. ?It might have been because I had a large chunk of nearly > duplicate code in both halves of an "if (y0 < y1)" conditional rather > > than simply swapping the coordinates and using common code - maybe it > > was an instruction cache thing. > > The test case I was using to test performance was only using polygons > so > the curve stuff didn't even come into play... > > ????????????????????????...jim From dlila at redhat.com Tue Oct 26 15:18:41 2010 From: dlila at redhat.com (dlila at redhat.com) Date: Tue, 26 Oct 2010 15:18:41 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6967434: Round joins/caps of scaled up lines have poor quality. Message-ID: <20101026151904.EF5994743D@hg.openjdk.java.net> Changeset: 065e6c5a8027 Author: dlila Date: 2010-10-26 10:39 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/065e6c5a8027 6967434: Round joins/caps of scaled up lines have poor quality. Summary: eliminated flattening from the rendering engine. Reviewed-by: flar + src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java + src/share/classes/sun/java2d/pisces/Helpers.java - src/share/classes/sun/java2d/pisces/LineSink.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java + src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java From james.graham at oracle.com Tue Oct 26 20:55:42 2010 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Oct 2010 13:55:42 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1333733575.1519201288101501519.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1333733575.1519201288101501519.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC7404E.2020802@oracle.com> On 10/26/2010 6:58 AM, Denis Lila wrote: >> If we are really worried about the y-sort, then how about creating a >> bunch of buckets and doing a bucket sort of the edges? As they are >> added to the list of segments, we accumulate their indices in a row >> list based on their startY so that each step of the "next()" simply moves >> to the next Y and adds the edges mentioned in the list there. Some work >> would have to be done on how to manage the storage simply (like a >> "rownext" field in the edge structure so that they are linked in a >> linked list), but then there would be no qsort at all for the cost of >> new int[N_ROWS] and an extra field in every edge. > > I like this. It's even more frugal if combined with my idea that an entire full pixel row could be processed in one batch rather than processing each sub-pixel row separately. >> 90% (guesstimate) of the time edges do not cross each other, thus if >> you sort the crossings without reordering the active edges then you just >> end up doing the same sorting work (same swaps) on the next scanline. My >> SpanShapeIterator code actually reordered the edges on every sample >> line to match their current X coordinates in a way that involved 1 compare >> per edge that was processed and only occasionally a swap of 2 edge >> pointers. It would basically eliminate the sort at line 149 at the >> cost of only doing a compare in the nextY processing for the very very >> common case. > > I also implemented this some time ago. I didn't keep it because it slowed > things down a bit. However, I only tested it with very complex and large > paths, and in hindsight, I shouldn't have based my decision on that, so I > will re-implement it. First, this is less helpful if we process the edges/quads/curves in 3 separate batches because you'd still have 3 sets of crossings to interweave and so some sorting would still be necessary, but keeping each of the 3 sets sorted amongst themselves might still help with reducing the swapping work of the sorting step. This technique would work best if all of the edge types were processed from one list. Also, be sure to test with both clockwise and couterclockwise versions of the test paths just in case. The (constantly re)sorting hit will be more expensive with one than the other since one of them will have the edges already in the sorted order and the other would require maximum swaps. I'd check: Simple CW rectangle Simple CCW rectangle CW and CCW rectangles with 500(?) zig-zags along top edge CW and CCW rectangles with 500(?) zig-zags along both top and bottom And a note related to another suggestion I'd made, I think if we did something like "process an entire pixel row at once" it would complicate the "auto-edge sorting" a bit. If every curve is iterated to the bottom of the pixel in turn before moving to the next edge then its crossings may swap with another edge's crossings, but that next edge would not be processed yet and then there may be a mish-mosh of N subpixel values from the two edges to interweave. If it was done by processing each subpixel row in turn then the edges could be kept sorted as the subpixel rows were iterated, but it would reduce the savings on the overhead of swapping between edges. The best compromise might be to process every curve fully, verify its sorted position in the edge array using its X coordinate at the bottom of the pixel, still sort the whole pixel row's worth of crossing values, but hopefully the sorting would have very little work to do if the original values were "mostly sorted" by having kept the edges in order at pixel boundaries (a "mostly sorted" friendly sort algorithm, like insertion sort, might be needed). ...jim From linuxhippy at gmail.com Wed Oct 27 19:35:19 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 27 Oct 2010 21:35:19 +0200 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha Message-ID: Hi, While playing arround with the SRC composition rule I found what seems to be a bug. When rendering text with an AlphaComposite(SRC, EA) I get garbage when enabling subpixel antialising: g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC, 0.01f)); g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_VBGR); g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON); g2d.setColor(Color.black); g2d.drawString("This text is painted with black color", 50, 50); If I comment out the KEY_ANTIALIASING hint, which shouldn't have any effect on text rendering, extra alpha is ignored but the text is rendered correctly. Should I file a but? Thanks, Clemens From dlila at redhat.com Wed Oct 27 21:06:15 2010 From: dlila at redhat.com (Denis Lila) Date: Wed, 27 Oct 2010 17:06:15 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <1317786050.1685001288213425891.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Clemens. It's interesting to note that this doesn't happen on OpenJDK, and on closed java the subpixel hint is not necessary to reproduce this. Simply using VALUE_ANTIALIAS_ON and the SRC composite is enough. Regards, Denis. ----- "Clemens Eisserer" wrote: > Hi, > > While playing arround with the SRC composition rule I found what > seems > to be a bug. > When rendering text with an AlphaComposite(SRC, EA) I get garbage > when > enabling subpixel antialising: > > g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC, > 0.01f)); > g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, > RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_VBGR); > > g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON); > > g2d.setColor(Color.black); > g2d.drawString("This text is painted with black color", 50, > 50); > > If I comment out the KEY_ANTIALIASING hint, which shouldn't have any > effect on text rendering, extra alpha is ignored but the text is > rendered correctly. > > Should I file a but? > > Thanks, Clemens From linuxhippy at gmail.com Wed Oct 27 22:27:43 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 28 Oct 2010 00:27:43 +0200 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1317786050.1685001288213425891.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Hi Denis, > It's interesting to note that this doesn't happen on OpenJDK, and > on closed java the subpixel hint is not necessary to reproduce this. > Simply using VALUE_ANTIALIAS_ON and the SRC composite is enough. I have to enable lcd text antialising to get the described result, however I see it with OpenJDK6 and JDKb99 from oracle. Another thing which looks odd when I disable LCD antialiasing is pixels that lay on straight lines seem to ignore extra alpha as shown in the screenshot attached. - Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: textaa.png Type: image/png Size: 1133 bytes Desc: not available URL: From philip.race at oracle.com Wed Oct 27 23:27:22 2010 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Oct 2010 16:27:22 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC8B55A.3090504@oracle.com> With the composite we theoretically back off the LCD text anyway, so modulo pipe selection bugs both hints ought to end up in the grayscale path which is showing the poor rendering - on some builds. I'm not sure of the details of why its so poor or if in fact its semi-reasonable for that composite but it doesn't occur in current JDK 7 builds - not since b17 - when back in those early days of JDK 7 (Summer 2007), I fixed 6263951: Java does not use fast AA text loops when regular AA hint is set That is presumably what cures this garbage although I'm not sure we should be using the regular loops in this case, ie its not so much fixed as incorrectly masked. As for why its not happening in OpenJDK, in either case, if you are talking about 6 open, or the current jdk 7 source, since openjdk6 forked off jdk7 b23, it inherited the fix. Anyway, here's a (full) program that for me on jdk6u22 and jdk7 b115 looks exactly as bad as you report and you'll notice its not really text rendering at all. Just filling a path. import javax.swing.*; import java.awt.*; import java.awt.font.*; import static java.awt.RenderingHints.*; public class SRC_EA extends Component { public static void main(String[] args) { JFrame f = new JFrame(); f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); f.add("Center", new SRC_EA()); f.pack(); f.setVisible(true); } public Dimension getPreferredSize() { return new Dimension(100,100); } public void paint(Graphics g) { Font f = new Font("Dialog", Font.PLAIN, 12); g.setFont(f); g.setColor(Color.white); g.fillRect(0,0,400,300); g.setColor(Color.black); Graphics2D g2 = (Graphics2D)g; g2.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC, 0.01f)); g2.setRenderingHint(KEY_ANTIALIASING, VALUE_ANTIALIAS_ON); FontRenderContext frc = g2.getFontRenderContext(); GlyphVector gv = f.createGlyphVector(frc, "ABCDEFGHIJKL"); Shape s = gv.getOutline(20,20); g2.fill(s); } } -phil. On 10/27/2010 2:06 PM, Denis Lila wrote: > Hi Clemens. > > It's interesting to note that this doesn't happen on OpenJDK, and > on closed java the subpixel hint is not necessary to reproduce this. > Simply using VALUE_ANTIALIAS_ON and the SRC composite is enough. > > Regards, > Denis. > > ----- "Clemens Eisserer" wrote: > >> Hi, >> >> While playing arround with the SRC composition rule I found what >> seems >> to be a bug. >> When rendering text with an AlphaComposite(SRC, EA) I get garbage >> when >> enabling subpixel antialising: >> >> g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC, >> 0.01f)); >> g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, >> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_VBGR); >> >> g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON); >> >> g2d.setColor(Color.black); >> g2d.drawString("This text is painted with black color", 50, >> 50); >> >> If I comment out the KEY_ANTIALIASING hint, which shouldn't have any >> effect on text rendering, extra alpha is ignored but the text is >> rendered correctly. >> >> Should I file a but? >> >> Thanks, Clemens From philip.race at oracle.com Wed Oct 27 23:28:45 2010 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Oct 2010 16:28:45 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: References: <1317786050.1685001288213425891.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC8B5AD.6040300@oracle.com> This is getting a bit puzzling .. what I see sounds more like what Denis is seeing. Are you using the X11 pipeline or Xrender ? I'm using X11. -phil. On 10/27/2010 3:27 PM, Clemens Eisserer wrote: > Hi Denis, > >> It's interesting to note that this doesn't happen on OpenJDK, and >> on closed java the subpixel hint is not necessary to reproduce this. >> Simply using VALUE_ANTIALIAS_ON and the SRC composite is enough. > I have to enable lcd text antialising to get the described result, > however I see it with OpenJDK6 and JDKb99 from oracle. > > Another thing which looks odd when I disable LCD antialiasing is > pixels that lay on straight lines seem to ignore extra alpha as shown > in the screenshot attached. > > - Clemens From james.graham at oracle.com Thu Oct 28 01:37:57 2010 From: james.graham at oracle.com (Jim Graham) Date: Wed, 27 Oct 2010 18:37:57 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1333733575.1519201288101501519.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1333733575.1519201288101501519.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CC8D3F5.7090905@oracle.com> Hi Denis, On 10/26/2010 6:58 AM, Denis Lila wrote: >> 90% (guesstimate) of the time edges do not cross each other, thus if >> you sort the crossings without reordering the active edges then you just >> end up doing the same sorting work (same swaps) on the next scanline. My >> SpanShapeIterator code actually reordered the edges on every sample >> line to match their current X coordinates in a way that involved 1 compare >> per edge that was processed and only occasionally a swap of 2 edge >> pointers. It would basically eliminate the sort at line 149 at the >> cost of only doing a compare in the nextY processing for the very very >> common case. > > I also implemented this some time ago. I didn't keep it because it slowed > things down a bit. However, I only tested it with very complex and large > paths, and in hindsight, I shouldn't have based my decision on that, so I > will re-implement it. I tried using this new rasterizer in FX and I had a test case which had a few shapes that were essentially zig-zaggy shapes on the top and bottom and fills between the zigzags (kind of like a seismic chart with fills between the pen squiggles). When I added a simple sort of the linear edges the performance nearly doubled in speed. Here is the code I replaced your quad-next-edge loop with: for (int i = elo; i < ehi; i++) { int ptr = edgePtrs[i]; int cross = ((int) edges[ptr+CURX]) << 1; if (edges[ptr+OR] > 0) { cross |= 1; } edges[ptr+CURY] += 1; edges[ptr+CURX] += edges[ptr+SLOPE]; int j = crossingIdx; while (--j >= 0) { int jcross = crossings[j]; if (cross >= jcross) { break; } crossings[j+1] = jcross; edgePtrs[elo+j+1] = edgePtrs[elo+j]; } crossings[j+1] = cross; edgePtrs[elo+j+1] = ptr; crossingIdx++; } I then did a conditional sort, moved to right after the qlo->qhi and clo->chi loops: for (int i = qlo; i < qhi; i++) { // same stuff } for (int i = clo; i < chi; i++) { // same stuff } if (qhi > qlo || chi > clo) { Arrays.sort(crossings, 0, crossingIdx); } In the case of my test case where I only had a polygon to fill, the performance doubled. Obviously I didn't do much for the case where there were curves because this was just a quick hack to see the value of sorting the edges. If we moved to a Curve class or some other way to consolidate the 3 lists (may be easier in native code), this might win in more cases... ...jim From linuxhippy at gmail.com Thu Oct 28 08:40:09 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 28 Oct 2010 10:40:09 +0200 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <4CC8B5AD.6040300@oracle.com> References: <1317786050.1685001288213425891.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CC8B5AD.6040300@oracle.com> Message-ID: Hi Phil, > Are you using the X11 pipeline or Xrender ? I'm using X11. Sorry I didn't mention - I was rendering to an BufferedImage INT/RGB. - Clemens From linuxhippy at gmail.com Thu Oct 28 08:46:56 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 28 Oct 2010 10:46:56 +0200 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: References: <1317786050.1685001288213425891.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <936443304.1685231288213575354.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CC8B5AD.6040300@oracle.com> Message-ID: Hi again, Attached is the sample program as well as the output I get on jdk7b99, when running the sample program attached. - Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: FontTest.java Type: application/octet-stream Size: 1748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcd_text_broken.png Type: image/png Size: 1078 bytes Desc: not available URL: From dlila at redhat.com Thu Oct 28 18:49:37 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Oct 2010 14:49:37 -0400 (EDT) Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <851608329.1760711288291700611.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello. After noticing some weird things I made some modifications to Clemens' test. I've attached the results and the tester. The most interesting results are the first 18 lines in each image, all of which are produced by rendering to INT_RBG type buffered images. The first 6 lines have both AA_ON and subpixel aa. Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. In each group of 6, the only thing that changes is the order in which the hints, the composite, and the colour are set. Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). The only thing they have in common is that the AA hint is on. Lines 7-12 look ok - they only have LCD AA. We can see that the order doesn't matter. On openJDK7 (with a build of a fresh clone of the 2d tree) lines 1-3 look like what Clemens is seeing, but the next 3 don't look bad, even though all of the first 6 lines are supposed to be drawn with a black colour, SRC compositing, and both AA_ON and LCD AA. The same goes for lines 13-15. What lines 1-3 and 13-15 have in common is that the colour is set after the composite. Lines 7-12 still look ok, but they are a bit different from what closed java produces, even though subpixel antialiasing is clearly used in both. That's it for my observations. Regards, Denis. ----- "Clemens Eisserer" wrote: > Hi again, > > Attached is the sample program as well as the output I get on > jdk7b99, > when running the sample program attached. > > - Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: FontTestJDK7.png Type: image/png Size: 33846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FontTestSUNJDK.png Type: image/png Size: 26772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FontTest.java Type: text/x-java Size: 24365 bytes Desc: not available URL: From dlila at redhat.com Thu Oct 28 22:27:32 2010 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Oct 2010 18:27:32 -0400 (EDT) Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <1364844244.1779801288304716180.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <749269859.1779881288304852674.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Jim. I removed the cubic and quadratic lists and am now flattening everything as it comes in, like you suggested. I ran some AA benchmarks and the curves test was about 15% faster. Then I started using your insertion sort in the only edges version and re ran the benchmarks. Curves improved from 15% better to 20-22% and lines improved from nothing to 2-20%, depending on how vertical the lines were. I didn't expect that the sorting would make this much difference. But, it does, so I think it is worth it to work more on it; therefore, next I will implement the bucket sort you suggested. > If we moved to a Curve class or some other way to > consolidate the 3 lists (may be easier in native code), this might win > in more cases... Does that mean you no longer think we should flatten every curve as soon as we get it? Regards, Denis. ----- "Jim Graham" wrote: > Hi Denis, > > On 10/26/2010 6:58 AM, Denis Lila wrote: > >> 90% (guesstimate) of the time edges do not cross each other, thus > if > >> you sort the crossings without reordering the active edges then you > just > >> end up doing the same sorting work (same swaps) on the next > scanline. My > >> SpanShapeIterator code actually reordered the edges on every > sample > >> line to match their current X coordinates in a way that involved 1 > compare > >> per edge that was processed and only occasionally a swap of 2 edge > >> pointers. It would basically eliminate the sort at line 149 at > the > >> cost of only doing a compare in the nextY processing for the very > very > >> common case. > > > > I also implemented this some time ago. I didn't keep it because it > slowed > > things down a bit. However, I only tested it with very complex and > large > > paths, and in hindsight, I shouldn't have based my decision on that, > so I > > will re-implement it. > > I tried using this new rasterizer in FX and I had a test case which > had > a few shapes that were essentially zig-zaggy shapes on the top and > bottom and fills between the zigzags (kind of like a seismic chart > with > fills between the pen squiggles). > > When I added a simple sort of the linear edges the performance nearly > > doubled in speed. Here is the code I replaced your quad-next-edge > loop > with: > > for (int i = elo; i < ehi; i++) { > int ptr = edgePtrs[i]; > int cross = ((int) edges[ptr+CURX]) << 1; > if (edges[ptr+OR] > 0) { > cross |= 1; > } > edges[ptr+CURY] += 1; > edges[ptr+CURX] += edges[ptr+SLOPE]; > int j = crossingIdx; > while (--j >= 0) { > int jcross = crossings[j]; > if (cross >= jcross) { > break; > } > crossings[j+1] = jcross; > edgePtrs[elo+j+1] = edgePtrs[elo+j]; > } > crossings[j+1] = cross; > edgePtrs[elo+j+1] = ptr; > crossingIdx++; > } > > I then did a conditional sort, moved to right after the qlo->qhi and > clo->chi loops: > > for (int i = qlo; i < qhi; i++) { > // same stuff > } > for (int i = clo; i < chi; i++) { > // same stuff > } > if (qhi > qlo || chi > clo) { > Arrays.sort(crossings, 0, crossingIdx); > } > > In the case of my test case where I only had a polygon to fill, the > performance doubled. Obviously I didn't do much for the case where > there were curves because this was just a quick hack to see the value > of sorting the edges. > > ...jim From james.graham at oracle.com Thu Oct 28 23:59:41 2010 From: james.graham at oracle.com (Jim Graham) Date: Thu, 28 Oct 2010 16:59:41 -0700 Subject: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces In-Reply-To: <749269859.1779881288304852674.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <749269859.1779881288304852674.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CCA0E6D.30901@oracle.com> Hi Denis, Good news! On 10/28/2010 3:27 PM, Denis Lila wrote: >> If we moved to a Curve class or some other way to >> consolidate the 3 lists (may be easier in native code), this might win >> in more cases... > > Does that mean you no longer think we should flatten every curve as soon > as we get it? No, I was just discussion the feasibility of that one suggestion in the context of all of the possibilities of whether or not we took the other choices. If you think that flattening will pay off then we don't have to worry about the 3 lists. It was just that when I hacked it in, I still had your 3 lists and so the pros and cons of horizontal edge sorting were relative to that version of the renderer... ...jim From andrew.brygin at sun.com Fri Oct 29 08:22:51 2010 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 29 Oct 2010 08:22:51 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6670881: Phantom lines appear when rendering polygons & ellipses with antialiasing OFF Message-ID: <20101029082318.0635747503@hg.openjdk.java.net> Changeset: d9890d8a8159 Author: bae Date: 2010-10-29 11:49 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d9890d8a8159 6670881: Phantom lines appear when rendering polygons & ellipses with antialiasing OFF Reviewed-by: prr, bae ! src/share/native/sun/java2d/loops/ProcessPath.c From linuxhippy at gmail.com Fri Oct 29 19:06:07 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 29 Oct 2010 21:06:07 +0200 Subject: [OpenJDK 2D-Dev] Java's definition of the SRC operator Message-ID: Hi, Some users reported problems with the IntelliJ Idea's editor when running with xrender enabled. It turned out that there are some differences between how Java and xrender interpret the SRC operator. Is the general rule, that SRC behaves like SRC_OVER when antialiasing is enabled? Are there some special cases that need to be taken care of? Thanks, Clemens From james.graham at oracle.com Fri Oct 29 19:23:22 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 29 Oct 2010 12:23:22 -0700 Subject: [OpenJDK 2D-Dev] Java's definition of the SRC operator In-Reply-To: References: Message-ID: <4CCB1F2A.8070701@oracle.com> SRC behaves like SRC, but AA is another part of the equation. It works like this (for any rule): blendresult = PORTER_DUFF(rule, rendercolor, dstcolor, extraalpha) // For SRC, blendresult = rendercolor modulated by extra alpha storedresult = INTERP(dstcolor, blendresult, aacoverage) // For full aa coverage, storedresult = blendresult The only part of this that could possibly be interpreted as "behaving like SRC_OVER" would be the second INTERP and it depends on the aa coverage, not on the alpha of the colors involved. Is that what they were talking about? But, the interior of shapes should all have full aa coverage and so should just store the blendresult (which, in the case of SRC is rendercolor)... ...jim On 10/29/10 12:06 PM, Clemens Eisserer wrote: > Hi, > > Some users reported problems with the IntelliJ Idea's editor when > running with xrender enabled. > It turned out that there are some differences between how Java and > xrender interpret the SRC operator. > > Is the general rule, that SRC behaves like SRC_OVER when antialiasing > is enabled? > Are there some special cases that need to be taken care of? > > Thanks, Clemens From philip.race at oracle.com Fri Oct 29 19:36:07 2010 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Oct 2010 12:36:07 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4CCB2227.5090506@oracle.com> I didn't get time to look at this yesterday. I think the problem is (sort of) in SunGraphics2D.setComposite() where we have } } else if (newCompType == CompositeType.SrcNoEa || newCompType == CompositeType.Src || newCompType == CompositeType.Clear) { This then categorises the composite state "SRC" as COMP_ISCOPY regardless of whether there is an extra alpha. This code was introduced in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957 I believe that there's some handling of the extra alpha for most rendering but its enough to mislead SurfaceData into thinking it can create and use LCD glyphs. I've not yet looked into what exactly happens after that but it seems like we end up in a loop that uses the LCD glyph data as if its greyscale mask and you'll get garbage. If this is the case we can't rely on the compositeState variable and will need to check the composite type. -phil. Denis Lila wrote: > Hello. > > After noticing some weird things I made some modifications to > Clemens' test. I've attached the results and the tester. > The most interesting results are the first 18 lines in each > image, all of which are produced by rendering to INT_RBG type > buffered images. The first 6 lines have both AA_ON and subpixel aa. > Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. > In each group of 6, the only thing that changes is the order in > which the hints, the composite, and the colour are set. > > Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). > The only thing they have in common is that the AA hint is on. > Lines 7-12 look ok - they only have LCD AA. We can see that the order > doesn't matter. > > On openJDK7 (with a build of a fresh clone of the 2d tree) lines > 1-3 look like what Clemens is seeing, but the next 3 don't look bad, > even though all of the first 6 lines are supposed to be drawn with > a black colour, SRC compositing, and both AA_ON and LCD AA. > The same goes for lines 13-15. What lines 1-3 and 13-15 have in > common is that the colour is set after the composite. > Lines 7-12 still look ok, but they are a bit different from what closed > java produces, even though subpixel antialiasing is clearly used in both. > > That's it for my observations. > Regards, > Denis. > > ----- "Clemens Eisserer" wrote: > > >> Hi again, >> >> Attached is the sample program as well as the output I get on >> jdk7b99, >> when running the sample program attached. >> >> - Clemens >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------ >> From philip.race at oracle.com Fri Oct 29 19:49:30 2010 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Oct 2010 12:49:30 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <4CCB2227.5090506@oracle.com> References: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CCB2227.5090506@oracle.com> Message-ID: <4CCB254A.7050404@oracle.com> This fixes it, although the same may need to be done to OGL and D3D subclasses of SurfaceData.java -phil. diff --git a/src/share/classes/sun/java2d/SurfaceData.java b/src/share/classes/sun/java2d/SurfaceData.java --- a/src/share/classes/sun/java2d/SurfaceData.java +++ b/src/share/classes/sun/java2d/SurfaceData.java @@ -450,6 +450,7 @@ public abstract class SurfaceData // For now the answer can only be true in the following cases: if (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY && sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR && + sg2d.imageComp != CompositeType.Src && sg2d.clipState <= SunGraphics2D.CLIP_RECTANGULAR && sg2d.surfaceData.getTransparency() == Transparency.OPAQUE) { Phil Race wrote: > I didn't get time to look at this yesterday. > I think the problem is (sort of) in SunGraphics2D.setComposite() where > we have > > } > } else if (newCompType == CompositeType.SrcNoEa || > newCompType == CompositeType.Src || > newCompType == CompositeType.Clear) > { > > This then categorises the composite state "SRC" as COMP_ISCOPY > regardless of whether there is an extra alpha. > > This code was introduced in > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957 > > I believe that there's some handling of the extra alpha for most > rendering but > its enough to mislead SurfaceData into thinking it can create and use > LCD glyphs. > I've not yet looked into what exactly happens after that but it > seems like we end up in a loop that uses the LCD glyph > data as if its greyscale mask and you'll get garbage. > > If this is the case we can't rely on the compositeState variable and > will need to check the composite type. > > -phil. > > Denis Lila wrote: >> Hello. >> >> After noticing some weird things I made some modifications to >> Clemens' test. I've attached the results and the tester. >> The most interesting results are the first 18 lines in each >> image, all of which are produced by rendering to INT_RBG type >> buffered images. The first 6 lines have both AA_ON and subpixel aa. >> Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. >> In each group of 6, the only thing that changes is the order in >> which the hints, the composite, and the colour are set. >> >> Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). >> The only thing they have in common is that the AA hint is on. >> Lines 7-12 look ok - they only have LCD AA. We can see that the order >> doesn't matter. >> >> On openJDK7 (with a build of a fresh clone of the 2d tree) lines >> 1-3 look like what Clemens is seeing, but the next 3 don't look bad, >> even though all of the first 6 lines are supposed to be drawn with >> a black colour, SRC compositing, and both AA_ON and LCD AA. >> The same goes for lines 13-15. What lines 1-3 and 13-15 have in >> common is that the colour is set after the composite. >> Lines 7-12 still look ok, but they are a bit different from what closed >> java produces, even though subpixel antialiasing is clearly used in >> both. >> >> That's it for my observations. >> Regards, >> Denis. >> >> ----- "Clemens Eisserer" wrote: >> >> >>> Hi again, >>> >>> Attached is the sample program as well as the output I get on >>> jdk7b99, >>> when running the sample program attached. >>> >>> - Clemens >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> > From linuxhippy at gmail.com Fri Oct 29 19:50:12 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 29 Oct 2010 21:50:12 +0200 Subject: [OpenJDK 2D-Dev] Java's definition of the SRC operator In-Reply-To: <4CCB1F2A.8070701@oracle.com> References: <4CCB1F2A.8070701@oracle.com> Message-ID: Hi Jim, > blendresult = PORTER_DUFF(rule, rendercolor, dstcolor, extraalpha) > // For SRC, blendresult = rendercolor modulated by extra alpha > storedresult = INTERP(dstcolor, blendresult, aacoverage) > // For full aa coverage, storedresult = blendresult > > The only part of this that could possibly be interpreted as "behaving like > SRC_OVER" would be the second INTERP and it depends on the aa coverage, not > on the alpha of the colors involved. ?Is that what they were talking about? Thanks for the detailed explanation. What confuses me is that pixels wich don't have full AA coverage take the src's alpha into the calculation. Shouldn't the following operations both yield the same result when rendered to an opaque destination? /*SRC*/ g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC)); g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON); g2d.setColor(new Color(255, 0, 0, 1)); g2d.drawLine(100, 120, 200, 220); /*SRC_OVER*/ g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER)); g2d.setColor(Color.red); g2d.drawLine(100, 140, 200, 240); Thanks, Clemens From james.graham at oracle.com Fri Oct 29 20:00:07 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 29 Oct 2010 13:00:07 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <4CCB2227.5090506@oracle.com> References: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CCB2227.5090506@oracle.com> Message-ID: <4CCB27C7.8000500@oracle.com> Why is SRC with an extra alpha handled any differently than SrcNoEa with a color that has alpha? The two cases are supposed to be folded together because it doesn't matter where the alpha comes from. There is also a paintType indicator that indicates when the paint is opaque. If you only register the loops for opaque paints then I think the state may not be enough as you say, but if the loops can handle alpha then they can handle Src with Ea... ...jim On 10/29/10 12:36 PM, Phil Race wrote: > I didn't get time to look at this yesterday. > I think the problem is (sort of) in SunGraphics2D.setComposite() where > we have > > } > } else if (newCompType == CompositeType.SrcNoEa || > newCompType == CompositeType.Src || > newCompType == CompositeType.Clear) > { > > This then categorises the composite state "SRC" as COMP_ISCOPY > regardless of whether there is an extra alpha. > > This code was introduced in > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957 > > I believe that there's some handling of the extra alpha for most > rendering but > its enough to mislead SurfaceData into thinking it can create and use > LCD glyphs. > I've not yet looked into what exactly happens after that but it > seems like we end up in a loop that uses the LCD glyph > data as if its greyscale mask and you'll get garbage. > > If this is the case we can't rely on the compositeState variable and > will need to check the composite type. > > -phil. > > Denis Lila wrote: >> Hello. >> >> After noticing some weird things I made some modifications to >> Clemens' test. I've attached the results and the tester. >> The most interesting results are the first 18 lines in each >> image, all of which are produced by rendering to INT_RBG type >> buffered images. The first 6 lines have both AA_ON and subpixel aa. >> Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. >> In each group of 6, the only thing that changes is the order in >> which the hints, the composite, and the colour are set. >> >> Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). >> The only thing they have in common is that the AA hint is on. >> Lines 7-12 look ok - they only have LCD AA. We can see that the order >> doesn't matter. >> >> On openJDK7 (with a build of a fresh clone of the 2d tree) lines >> 1-3 look like what Clemens is seeing, but the next 3 don't look bad, >> even though all of the first 6 lines are supposed to be drawn with >> a black colour, SRC compositing, and both AA_ON and LCD AA. >> The same goes for lines 13-15. What lines 1-3 and 13-15 have in >> common is that the colour is set after the composite. >> Lines 7-12 still look ok, but they are a bit different from what closed >> java produces, even though subpixel antialiasing is clearly used in both. >> >> That's it for my observations. >> Regards, >> Denis. >> >> ----- "Clemens Eisserer" wrote: >> >>> Hi again, >>> >>> Attached is the sample program as well as the output I get on >>> jdk7b99, >>> when running the sample program attached. >>> >>> - Clemens >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------ >>> > From james.graham at oracle.com Fri Oct 29 20:01:29 2010 From: james.graham at oracle.com (Jim Graham) Date: Fri, 29 Oct 2010 13:01:29 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <4CCB254A.7050404@oracle.com> References: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CCB2227.5090506@oracle.com> <4CCB254A.7050404@oracle.com> Message-ID: <4CCB2819.5000801@oracle.com> If you allow ALPHACOLOR (paintState <= ALPHACOLOR) then you should be able to handle Src with EA... ...jim On 10/29/10 12:49 PM, Phil Race wrote: > This fixes it, although the same may need to be done to OGL and D3D > subclasses > of SurfaceData.java > > -phil. > > diff --git a/src/share/classes/sun/java2d/SurfaceData.java > b/src/share/classes/sun/java2d/SurfaceData.java > --- a/src/share/classes/sun/java2d/SurfaceData.java > +++ b/src/share/classes/sun/java2d/SurfaceData.java > @@ -450,6 +450,7 @@ public abstract class SurfaceData > // For now the answer can only be true in the following cases: > if (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY && > sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR && > + sg2d.imageComp != CompositeType.Src && > sg2d.clipState <= SunGraphics2D.CLIP_RECTANGULAR && > sg2d.surfaceData.getTransparency() == Transparency.OPAQUE) > { > > > Phil Race wrote: >> I didn't get time to look at this yesterday. >> I think the problem is (sort of) in SunGraphics2D.setComposite() where >> we have >> >> } >> } else if (newCompType == CompositeType.SrcNoEa || >> newCompType == CompositeType.Src || >> newCompType == CompositeType.Clear) >> { >> >> This then categorises the composite state "SRC" as COMP_ISCOPY >> regardless of whether there is an extra alpha. >> >> This code was introduced in >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957 >> >> I believe that there's some handling of the extra alpha for most >> rendering but >> its enough to mislead SurfaceData into thinking it can create and use >> LCD glyphs. >> I've not yet looked into what exactly happens after that but it >> seems like we end up in a loop that uses the LCD glyph >> data as if its greyscale mask and you'll get garbage. >> >> If this is the case we can't rely on the compositeState variable and >> will need to check the composite type. >> >> -phil. >> >> Denis Lila wrote: >>> Hello. >>> >>> After noticing some weird things I made some modifications to >>> Clemens' test. I've attached the results and the tester. >>> The most interesting results are the first 18 lines in each >>> image, all of which are produced by rendering to INT_RBG type >>> buffered images. The first 6 lines have both AA_ON and subpixel aa. >>> Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. >>> In each group of 6, the only thing that changes is the order in >>> which the hints, the composite, and the colour are set. >>> >>> Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). >>> The only thing they have in common is that the AA hint is on. >>> Lines 7-12 look ok - they only have LCD AA. We can see that the order >>> doesn't matter. >>> >>> On openJDK7 (with a build of a fresh clone of the 2d tree) lines >>> 1-3 look like what Clemens is seeing, but the next 3 don't look bad, >>> even though all of the first 6 lines are supposed to be drawn with >>> a black colour, SRC compositing, and both AA_ON and LCD AA. >>> The same goes for lines 13-15. What lines 1-3 and 13-15 have in >>> common is that the colour is set after the composite. >>> Lines 7-12 still look ok, but they are a bit different from what closed >>> java produces, even though subpixel antialiasing is clearly used in >>> both. >>> >>> That's it for my observations. >>> Regards, >>> Denis. >>> >>> ----- "Clemens Eisserer" wrote: >>> >>> >>>> Hi again, >>>> >>>> Attached is the sample program as well as the output I get on >>>> jdk7b99, >>>> when running the sample program attached. >>>> >>>> - Clemens >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >> > From philip.race at oracle.com Fri Oct 29 20:28:36 2010 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Oct 2010 13:28:36 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <4CCB27C7.8000500@oracle.com> References: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CCB2227.5090506@oracle.com> <4CCB27C7.8000500@oracle.com> Message-ID: <4CCB2E74.2090304@oracle.com> On 10/29/2010 1:00 PM, Jim Graham wrote: > Why is SRC with an extra alpha handled any differently than SrcNoEa > with a color that has alpha? The two cases are supposed to be folded > together because it doesn't matter where the alpha comes from. > > There is also a paintType indicator that indicates when the paint is > opaque. If you only register the loops for opaque paints then I think > the state may not be enough as you say, but if the loops can handle > alpha then they can handle Src with Ea... Maybe that's the better answer than backing off to greyscale, ie the LCD loops aren't registered in this case and they can/should be, although I'm not sure they are currently set up to handle the Ea. -phil. > > ...jim > > On 10/29/10 12:36 PM, Phil Race wrote: >> I didn't get time to look at this yesterday. >> I think the problem is (sort of) in SunGraphics2D.setComposite() where >> we have >> >> } >> } else if (newCompType == CompositeType.SrcNoEa || >> newCompType == CompositeType.Src || >> newCompType == CompositeType.Clear) >> { >> >> This then categorises the composite state "SRC" as COMP_ISCOPY >> regardless of whether there is an extra alpha. >> >> This code was introduced in >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957 >> >> I believe that there's some handling of the extra alpha for most >> rendering but >> its enough to mislead SurfaceData into thinking it can create and use >> LCD glyphs. >> I've not yet looked into what exactly happens after that but it >> seems like we end up in a loop that uses the LCD glyph >> data as if its greyscale mask and you'll get garbage. >> >> If this is the case we can't rely on the compositeState variable and >> will need to check the composite type. >> >> -phil. >> >> Denis Lila wrote: >>> Hello. >>> >>> After noticing some weird things I made some modifications to >>> Clemens' test. I've attached the results and the tester. >>> The most interesting results are the first 18 lines in each >>> image, all of which are produced by rendering to INT_RBG type >>> buffered images. The first 6 lines have both AA_ON and subpixel aa. >>> Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. >>> In each group of 6, the only thing that changes is the order in >>> which the hints, the composite, and the colour are set. >>> >>> Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). >>> The only thing they have in common is that the AA hint is on. >>> Lines 7-12 look ok - they only have LCD AA. We can see that the order >>> doesn't matter. >>> >>> On openJDK7 (with a build of a fresh clone of the 2d tree) lines >>> 1-3 look like what Clemens is seeing, but the next 3 don't look bad, >>> even though all of the first 6 lines are supposed to be drawn with >>> a black colour, SRC compositing, and both AA_ON and LCD AA. >>> The same goes for lines 13-15. What lines 1-3 and 13-15 have in >>> common is that the colour is set after the composite. >>> Lines 7-12 still look ok, but they are a bit different from what closed >>> java produces, even though subpixel antialiasing is clearly used in >>> both. >>> >>> That's it for my observations. >>> Regards, >>> Denis. >>> >>> ----- "Clemens Eisserer" wrote: >>> >>>> Hi again, >>>> >>>> Attached is the sample program as well as the output I get on >>>> jdk7b99, >>>> when running the sample program attached. >>>> >>>> - Clemens >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >> From philip.race at oracle.com Fri Oct 29 22:14:14 2010 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Oct 2010 15:14:14 -0700 Subject: [OpenJDK 2D-Dev] Strange text rendering with SRC + Extra Alpha In-Reply-To: <4CCB2819.5000801@oracle.com> References: <171072780.1760911288291777681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <4CCB2227.5090506@oracle.com> <4CCB254A.7050404@oracle.com> <4CCB2819.5000801@oracle.com> Message-ID: <4CCB4736.9060901@oracle.com> And in fact that is handled as the greyscale and lcd text loops use the alpha component of the alpha colour on the graphics and SG2D appears to take care of this in calculating the argb color. And the garbage problem is due to a bug in surfacedata where that earlier b17 fix I mentioned tested for paintState > PAINT_OPAQUECOLOR instead of > PAINT_ALPHACOLOR and consequently selected a textpipe for greyscale instead of LCD glyphs. So the better fix is this :- diff --git a/src/share/classes/sun/java2d/SurfaceData.java b/src/share/classes/sun/java2d/SurfaceData.java --- a/src/share/classes/sun/java2d/SurfaceData.java +++ b/src/share/classes/sun/java2d/SurfaceData.java @@ -545,7 +545,7 @@ public abstract class SurfaceData sg2d.drawpipe = AAColorViaShape; sg2d.fillpipe = AAColorViaShape; sg2d.shapepipe = AAColorShape; - if (sg2d.paintState > sg2d.PAINT_OPAQUECOLOR || + if (sg2d.paintState > sg2d.PAINT_ALPHACOLOR || sg2d.compositeState > sg2d.COMP_ISCOPY) { sg2d.textpipe = colorText; I'd earlier postulated that the greyscale AA fast loops installed by the b17 fix wouldn't handle this either but they can for the same reason. -phil. Jim Graham wrote: > If you allow ALPHACOLOR (paintState <= ALPHACOLOR) then you should be > able to handle Src with EA... > > ...jim > > On 10/29/10 12:49 PM, Phil Race wrote: >> This fixes it, although the same may need to be done to OGL and D3D >> subclasses >> of SurfaceData.java >> >> -phil. >> >> diff --git a/src/share/classes/sun/java2d/SurfaceData.java >> b/src/share/classes/sun/java2d/SurfaceData.java >> --- a/src/share/classes/sun/java2d/SurfaceData.java >> +++ b/src/share/classes/sun/java2d/SurfaceData.java >> @@ -450,6 +450,7 @@ public abstract class SurfaceData >> // For now the answer can only be true in the following cases: >> if (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY && >> sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR && >> + sg2d.imageComp != CompositeType.Src && >> sg2d.clipState <= SunGraphics2D.CLIP_RECTANGULAR && >> sg2d.surfaceData.getTransparency() == Transparency.OPAQUE) >> { >> >> >> Phil Race wrote: >>> I didn't get time to look at this yesterday. >>> I think the problem is (sort of) in SunGraphics2D.setComposite() where >>> we have >>> >>> } >>> } else if (newCompType == CompositeType.SrcNoEa || >>> newCompType == CompositeType.Src || >>> newCompType == CompositeType.Clear) >>> { >>> >>> This then categorises the composite state "SRC" as COMP_ISCOPY >>> regardless of whether there is an extra alpha. >>> >>> This code was introduced in >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248957 >>> >>> I believe that there's some handling of the extra alpha for most >>> rendering but >>> its enough to mislead SurfaceData into thinking it can create and use >>> LCD glyphs. >>> I've not yet looked into what exactly happens after that but it >>> seems like we end up in a loop that uses the LCD glyph >>> data as if its greyscale mask and you'll get garbage. >>> >>> If this is the case we can't rely on the compositeState variable and >>> will need to check the composite type. >>> >>> -phil. >>> >>> Denis Lila wrote: >>>> Hello. >>>> >>>> After noticing some weird things I made some modifications to >>>> Clemens' test. I've attached the results and the tester. >>>> The most interesting results are the first 18 lines in each >>>> image, all of which are produced by rendering to INT_RBG type >>>> buffered images. The first 6 lines have both AA_ON and subpixel aa. >>>> Lines 7-12 have only subpixel AA, and lines 13-18 have only AA_ON. >>>> In each group of 6, the only thing that changes is the order in >>>> which the hints, the composite, and the colour are set. >>>> >>>> Lines 1-6 and 13-18 don't look right on closed jdk (1.6.0_21-b06). >>>> The only thing they have in common is that the AA hint is on. >>>> Lines 7-12 look ok - they only have LCD AA. We can see that the order >>>> doesn't matter. >>>> >>>> On openJDK7 (with a build of a fresh clone of the 2d tree) lines >>>> 1-3 look like what Clemens is seeing, but the next 3 don't look bad, >>>> even though all of the first 6 lines are supposed to be drawn with >>>> a black colour, SRC compositing, and both AA_ON and LCD AA. >>>> The same goes for lines 13-15. What lines 1-3 and 13-15 have in >>>> common is that the colour is set after the composite. >>>> Lines 7-12 still look ok, but they are a bit different from what >>>> closed >>>> java produces, even though subpixel antialiasing is clearly used in >>>> both. >>>> >>>> That's it for my observations. >>>> Regards, >>>> Denis. >>>> >>>> ----- "Clemens Eisserer" wrote: >>>> >>>> >>>>> Hi again, >>>>> >>>>> Attached is the sample program as well as the output I get on >>>>> jdk7b99, >>>>> when running the sample program attached. >>>>> >>>>> - Clemens >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>> >>