Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hi Jim. Actually, even if the lengths aren't close the lengths may give you enough information about the acceleration along the curve that you can do a decent approximation of the accelerated T value. The T could be biased by some formula that is weighted by the ratios of the control polygon lengths. As a very crude example, say you assumed that if the scaled leaf length fell into the first polygon segment's length then t should be proportionally a value from 0 to 1/3, and if it fell between the first poly len and the second then it would be proportionally a value from 1/3 to 2/3, etc. The code might look like this: I implemented this, and I'm not sure how to use this new approximation. I mean, currently there are really two t's. The first one is the parameter along the line connecting the 2 endpoints of the curve and the second is the result that we return. We can't use this new approximation to replace the first t, because for a curve like (0,0),(1000,0),(1000,0),(1000,0) and a desired length of 500, the t would be 1/6, so the computed (x,y) would be (1000/6,0) instead of (500,0), which would be right (and which is what we compute now). The only sensible way to use this kind of approximation would be as a direct replacement for getTCloseTo. I tried that, and its quality to speed ratio compared to getTCloseTo is remarkably good, but it's not really usable because the differences are very noticeable. I'll try to implement a good cubic root finder this weekend, and maybe then getTCloseTo will be much faster and we won't have to worry about this. (Also, note that in the original code we probably would have just been dashing along the flattened curve anyway and so we might have just been using the raw linear t in that case - so anything we do here is a refinement of what we used to do and icing on the cake to some extent)... I'd say the dashing precision is better than what we used to have. It's only slightly better, but even that is impressive when you consider that we were doing up to 1024 subdivisions before, and now it's only 16, I think. Regards, Denis.
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hi Jim. By without this optimization do you mean back when you did a full scan for the proper T? Yes. The improvement shown by the bench marks is substantial. Then this is great news! Indeed :-) How often do we end up needing getTCloseTo in practice? It depends on the ratios of the lengths of the sides of the control polygon. The closer they are to 1, the less we need it. I'm not sure how to answer more precisely - for that I would need a representative sample of curves drawn in practice. However, I did run dashing and stroking benchmarks. Stroking shows 25% speedup (because of the refinements to the transform pipeline) and cubic dashing has improved by 80%. Of course, all this is useless if I've done something to make things look horrible, so I'm going to run the gfx tests again. Regards, Denis. - Jim Graham james.gra...@oracle.com wrote: ...jim On 12/8/2010 1:54 PM, Denis Lila wrote: Hi Jim. How about if the 3 segments of the control polygon are all close to each other in length and angle, then the optimization applies. Is that easy to test? Hmm, that would actually be extremely easy to test and it would cost almost nothing. We already compute the control polygon lengths in onLeaf, and we're already assuming that every leaf is flat enough, so we probably don't even need to check the angles. Comparing lengths should be good enough. I'll try this out. I implemented this and updated the webrev. I tested on a few curves with very high and very low accelerations. The results were identical to what I used to get without this optimization. When the curve has no acceleration, all calls of getTCloseTo are skipped. Regards, Denis.
[OpenJDK 2D-Dev] hg: jdk7/2d/corba: 3 new changesets
Changeset: dc903ccc6219 Author:cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/dc903ccc6219 Added tag jdk7-b119 for changeset 39829414ae31 ! .hgtags Changeset: 2cc9f3299210 Author:ohair Date: 2010-12-03 19:43 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/2cc9f3299210 Merge ! .hgtags Changeset: 1523a060032c Author:katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/1523a060032c Added tag jdk7-b121 for changeset 2cc9f3299210 ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d: 7 new changesets
Changeset: b011f9ab61f8 Author:paulk Date: 2010-11-17 11:55 -0500 URL: http://hg.openjdk.java.net/jdk7/2d/rev/b011f9ab61f8 6997515: KERNEL=0 in JDK7 build causes loss of lzma compression. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: ba8ec3e1e7f2 Author:jqzuo Date: 2010-12-07 19:18 -0500 URL: http://hg.openjdk.java.net/jdk7/2d/rev/ba8ec3e1e7f2 Merge Changeset: fe71f5684c6a Author:igor Date: 2010-11-16 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/rev/fe71f5684c6a Merge Changeset: 7bf38037c3c9 Author:jqzuo Date: 2010-11-17 09:43 -0500 URL: http://hg.openjdk.java.net/jdk7/2d/rev/7bf38037c3c9 Merge Changeset: 05fbe45da7f7 Author:igor Date: 2010-11-30 09:23 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/rev/05fbe45da7f7 Merge Changeset: 2c2d4f88637b Author:igor Date: 2010-12-07 16:41 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/rev/2c2d4f88637b Merge Changeset: f1591eed71f6 Author:katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/rev/f1591eed71f6 Added tag jdk7-b121 for changeset 2c2d4f88637b ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 3 new changesets
Changeset: 073378594ec6 Author:cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/073378594ec6 Added tag jdk7-b119 for changeset 5484e7c53fa7 ! .hgtags Changeset: 3f3653ab7af8 Author:ohair Date: 2010-12-03 19:44 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3f3653ab7af8 Merge ! .hgtags Changeset: 3a548dc9cb45 Author:katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3a548dc9cb45 Added tag jdk7-b121 for changeset 3f3653ab7af8 ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 4 new changesets
Changeset: d1cb3e473c32 Author:ohair Date: 2010-11-23 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/d1cb3e473c32 7002248: Update urls for jaxp and jaxws source downloads Reviewed-by: darcy ! jaxp.properties Changeset: 1830ef24edb2 Author:lana Date: 2010-11-30 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/1830ef24edb2 Merge Changeset: 63dae40fa19f Author:lana Date: 2010-12-06 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/63dae40fa19f Merge Changeset: 03ff13d19c8f Author:katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/03ff13d19c8f Added tag jdk7-b121 for changeset 63dae40fa19f ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 4 new changesets
Changeset: f258bef45f3b Author:ohair Date: 2010-11-23 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/f258bef45f3b 7002248: Update urls for jaxp and jaxws source downloads Reviewed-by: darcy ! jaxws.properties Changeset: ca2fa57106b3 Author:lana Date: 2010-11-30 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/ca2fa57106b3 Merge Changeset: 0fa950117faa Author:lana Date: 2010-12-06 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/0fa950117faa Merge Changeset: 17b6c48a3449 Author:katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/17b6c48a3449 Added tag jdk7-b121 for changeset 0fa950117faa ! .hgtags
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Of course, all this is useless if I've done something to make things look horrible, so I'm going to run the gfx tests again. I just ran them. All is good. The only change compared to the old test result is that the number of dashed round rectangles that are identical to what is produced by the closed source code has doubled. This isn't all that significant, since it has gone from 4 identical images out of 162 total images to images to 8 out of 162, but it's still nice, and it definitely means that nothing has gotten worse. Regards, Denis.
[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 81 new changesets
Changeset: 320c5f5906a1 Author:cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/320c5f5906a1 Added tag jdk7-b119 for changeset ecab7eefb8f2 ! .hgtags Changeset: c80287e4d606 Author:ohair Date: 2010-12-03 19:47 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c80287e4d606 Merge ! .hgtags Changeset: f81c37805b5b Author:lana Date: 2010-11-30 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f81c37805b5b Merge Changeset: 07c1c59df4ef Author:dav Date: 2010-11-18 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/07c1c59df4ef 6990904: (dav) on oel5.5, Frame doesn't show if the Frame has only a MenuBar as its component. Reviewed-by: dcherepanov, art ! src/solaris/classes/sun/awt/X11/XFramePeer.java + test/java/awt/MenuBar/DeadlockTest1/DeadlockTest1.java Changeset: 9af8c8d2b2e7 Author:art Date: 2010-11-25 13:23 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9af8c8d2b2e7 6993784: Clarification to shaped/translucent windows specification is required Reviewed-by: anthony, dcherepanov ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java Changeset: dd603732f1cf Author:dav Date: 2010-11-25 15:39 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dd603732f1cf 6551412: [OpenJDK] Change the 'name=' entry in src/windows/resource/java.manifest XML file. Reviewed-by: ohair ! src/windows/resource/java.manifest Changeset: 6c4e7fe53c36 Author:dcherepanov Date: 2010-11-26 11:27 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6c4e7fe53c36 6561353: The text for J2SE NervousText demo should be updated to 7.0 Reviewed-by: art ! src/share/demo/applets/NervousText/example1.html Changeset: b6d79a32b07a Author:dcherepanov Date: 2010-11-26 14:36 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b6d79a32b07a 6699851: setMaximizedbounds not working properly on dual screen environment Reviewed-by: art, anthony ! src/share/classes/java/awt/Frame.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WFramePeer.java Changeset: 3a2355dcef13 Author:dcherepanov Date: 2010-11-26 15:07 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3a2355dcef13 6770017: PIT : java/awt/Choice/BlockedWin32Choice/BlockedWin32Choice.java fails on 6u12 b01 pit build Reviewed-by: art ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h Changeset: 31196f8ec2d9 Author:anthony Date: 2010-11-26 15:41 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/31196f8ec2d9 7002856: Provide an accessor for Container.validateUnconditionally() Summary: Introduce sun.awt.AWTAccessor.getContainerAccessor().validateUnconditionally() Reviewed-by: art ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java Changeset: 7ed7eb6d6ba7 Author:dcherepanov Date: 2010-11-26 15:52 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7ed7eb6d6ba7 6953894: docs build reports warning in java.awt.FileDialog Reviewed-by: art ! src/share/classes/java/awt/FileDialog.java Changeset: 4becb3dd7861 Author:anthony Date: 2010-11-30 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4becb3dd7861 6998592: FileDialog tests crashed on solaris Summary: Override GtkFileDialogPeer.toFront() Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h Changeset: 357ecafd727b Author:dav Date: 2010-11-30 21:54 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/357ecafd727b 6783910: (dav) java.awt.Color.brighter()/darker() methods make color opaque Reviewed-by: art, yan ! src/share/classes/java/awt/Color.java + test/java/awt/Color/OpacityChange/OpacityChange.java Changeset: 5fc778c913e7 Author:lana Date: 2010-11-30 14:50 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5fc778c913e7 Merge Changeset: 452c4c1cc747 Author:vikram Date: 2010-11-15 21:51 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/452c4c1cc747 6939261: Since 1.6.0_18 JMenus at JMenuBar are not selectable by their Mnemonic key anymore Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java Changeset: 3207aa4438fc Author:peytoia Date: 2010-11-17 01:02 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3207aa4438fc 6959267: Support Unicode 6.0.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData00.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template !
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
On 12/10/2010 8:27 AM, Denis Lila wrote: Hi Jim. Yes. The improvement shown by the bench marks is substantial. Then this is great news! Indeed :-) Woohoo! How often do we end up needing getTCloseTo in practice? It depends on the ratios of the lengths of the sides of the control polygon. The closer they are to 1, the less we need it. I'm not sure how to answer more precisely - for that I would need a representative sample of curves drawn in practice. I was thinking of, say, when applied to a circle. Does that get by without needing getTCloseTo? However, I did run dashing and stroking benchmarks. Stroking shows 25% speedup (because of the refinements to the transform pipeline) and cubic dashing has improved by 80%. Of course, all this is useless if I've done something to make things look horrible, so I'm going to run the gfx tests again. Good job! ...jim
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hi Denis, The example I gave was intended to be very crude - I was simply describing the technique, but as I said it would require better math to really know what the right formula would be. With respect to finding a cubic root, currently you are doing that in 2 dimensions, but what if we converted to 1 dimension? Consider that the control polygon is fairly linear. What if we rotated our perspective so that it was horizontal and then squashed it flat? Consider instead a 1 dimensional bezier with control values of: (where |mn| is the length of the m-n control polygon of the original curve - sum of all segments from point m to point n) 0.0, |01|, |02|, |03| Solve that 1 dimensional bezier for v=(leaflen*polylen)/linelen... ...jim On 12/10/2010 8:23 AM, Denis Lila wrote: Hi Jim. Actually, even if the lengths aren't close the lengths may give you enough information about the acceleration along the curve that you can do a decent approximation of the accelerated T value. The T could be biased by some formula that is weighted by the ratios of the control polygon lengths. As a very crude example, say you assumed that if the scaled leaf length fell into the first polygon segment's length then t should be proportionally a value from 0 to 1/3, and if it fell between the first poly len and the second then it would be proportionally a value from 1/3 to 2/3, etc. The code might look like this: I implemented this, and I'm not sure how to use this new approximation. I mean, currently there are really two t's. The first one is the parameter along the line connecting the 2 endpoints of the curve and the second is the result that we return. We can't use this new approximation to replace the first t, because for a curve like (0,0),(1000,0),(1000,0),(1000,0) and a desired length of 500, the t would be 1/6, so the computed (x,y) would be (1000/6,0) instead of (500,0), which would be right (and which is what we compute now). The only sensible way to use this kind of approximation would be as a direct replacement for getTCloseTo. I tried that, and its quality to speed ratio compared to getTCloseTo is remarkably good, but it's not really usable because the differences are very noticeable. I'll try to implement a good cubic root finder this weekend, and maybe then getTCloseTo will be much faster and we won't have to worry about this. (Also, note that in the original code we probably would have just been dashing along the flattened curve anyway and so we might have just been using the raw linear t in that case - so anything we do here is a refinement of what we used to do and icing on the cake to some extent)... I'd say the dashing precision is better than what we used to have. It's only slightly better, but even that is impressive when you consider that we were doing up to 1024 subdivisions before, and now it's only 16, I think. Regards, Denis.
[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 7005896: Java2D D3D pipeline doesn't recognise latest Windows OSes
Changeset: 0eeac8ca33e3 Author:prr Date: 2010-12-10 16:14 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0eeac8ca33e3 7005896: Java2D D3D pipeline doesn't recognise latest Windows OSes Reviewed-by: bae, jgodinez ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h
