[OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 19 new changesets
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
[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 72 new changesets
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.
[OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 3 new changesets
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
[OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 3 new changesets
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
[OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 68 new changesets
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 i
[OpenJDK 2D-Dev] hg: jdk7/2d/corba: 3 new changesets
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
[OpenJDK 2D-Dev] hg: jdk7/2d: 8 new changesets
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
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
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.1,-100.1),
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, actual
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
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
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
> 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 t
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
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
