From linuxhippy at gmail.com Mon Jun 2 20:36:46 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 2 Jun 2008 22:36:46 +0200 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <48406FCC.8010301@sun.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> Message-ID: <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> Hi Phil, Dmitri and Chris, Thank you very much for the detailed explanations, it made things much clearer for me. 1.) >The setupBlitVector() method does a bunch of JNI field fetches > from the native level, mallocs a GlyphBlitVector structure each time, fills >it by doing a JNI Get/ReleasePrimitiveArrayCritical, etc. I assume the Direct3D pipeline does basically the same as the OpenGL pipeline. What would you think about something like setupBlitVectorWithArguments(.,.,.,.,.), so code would not duplicated. I thought the same about utility-functions like RETURN_IF_NULL, wouldn't that be useful for everybody working with JNI, or at least on the native side? > The GlyphInfo holds the image and data about a particular glyph > It is a long-lived (until memory is needed) cache, and its contents > do not change. It doesn't have an absolute "x/y" rendering position. > It does have relative positioning information: ie where the image > should be placed relative to the glyph origin. --------------------------------------------------------------------- > XRender probably has somewhere for this information > too, but perhaps more importantly, you also need a way in the > rendering call to optionally tell it where precisely each glyph should be > displayed relative to the prevous one since otherwise you will > find it hard to use a cache in such cases. If XRender requires > that information to be in the glyph cache, then its not very > useful for such cases. Ah great, thats basically the same as XRender does. XRender stores the image data along with relative positioning information into the server-side glyph-set, and when rendering it optionally allows to specify the positioning information though the XGlyphElt?? structure. I hope that will fit nicely together. > It makes sense to do the same as OGL, if you can. Note that the > GlyphInfo struct has a field "struct _CacheCellInfo *cellInfo" which > is used by OGL/D3D so that if the glyph is freed, it knows to tell the > OGL/D3D and in Clemen's case, XRender cache to free it too. > As Chris says, see AccelGlyphCache.c. Yes, I already had a look at that Code because it was used a lot in the OpenGL pipeline. It seems to fit quite good, with the excepetion that X/Y information would not be needed because XRender does the cache-handling itself and uses linear IDs. But I guess the overhead should be quite small. > In 6u10 the AccelGlyph has been improved to support multiple caches > per glyph Good to know, thanks :) 2.) Currently I've implemented lines the same way as Cairo does (generating three trapezoids), which gives the same result as with XDrawLine when line_width is set to 1.0, it looks to some degree ugly :-/ I created some screenshots: http://picasaweb.google.com/linuxhippy/Cairo The problem is that I don't see any way to do nice lines with XRender, without a lot of overhead and many trapezoids. Carl Worth was very helful, pointing me to a solution: http://cm.bell-labs.com/who/hobby/87_2-04.pdf However that means stroking with a pen -> complex stuff probably generating many more than "just" 3 Trapezoids. Does Java2D specify how a line has to look? A possible workarround would be falling back to XDrawLine, but that would complicate the state-management quite a bit. 3.) I have an awkward problem: In sun/font/X11TextRenderer there is a trampoline-function into another shared-libary. To play a bit with text I changed it a bit and it looks like this: JNIEXPORT void JNICALL Java_sun_font_X11TextRenderer_doDrawGlyphList (JNIEnv *env, jobject xtr, jlong dstData, jint totalGlyphs, jboolean usePositions, jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, jfloat glyphListOrigX, jfloat glyphListOrigY, jlongArray images, jfloatArray positions) { jlongArray imgArray, jfloatArray posArray) AWTXRDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, subPixPos, rgbOrder, lcdContrast, glyphListOrigX, glyphListOrigY, images, positions); } and it calls the method in X11TextRenderer_md: JNIEXPORT void AWTXRDrawGlyphList (JNIEnv *env, jobject self, jlong dstData, jint numGlyphs, jboolean usePositions, jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, jfloat glyphListOrigX, jfloat glyphListOrigY, jlongArray imgArray, jfloatArray posArray) { jlong *images; images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); ..... } The strange thing is that the GetPrimitiveArrayCritical call crashes, but if I copy exactly the same call into the trampoline-function, everything works fine: V [libjvm.so+0x24252b] C [libmawt.so+0x1fc6c] AWTXRDrawGlyphList+0x8c C [libfontmanager.so+0xb294] Java_sun_font_X11TextRenderer_doDrawGlyphList+0x74 j sun.font.X11TextRenderer.doDrawGlyphList(JIZZZIFF[J[F)V+0 I am not a JNI nor a C profesional, any idea what I am doing wrong? Am I passing the JNI-Envirment-pointer somehow wrong, or the array-handles, or is it related to the fact that both methods are located in different shared libraries? If I copy the second method from X11TextRenderer_md directly into X11TextRenderer (doing nothing except the GetPrimitiveArrayCritical) everything works as expected. Sorry for this question ;) Thanks a lot, lg Clemens From cworth at cworth.org Mon Jun 2 20:45:26 2008 From: cworth at cworth.org (Carl Worth) Date: Mon, 02 Jun 2008 13:45:26 -0700 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> Message-ID: <87iqwrbm6x.wl%cworth@cworth.org> On Mon, 2 Jun 2008 22:36:46 +0200, "Clemens Eisserer" wrote: > 2.) Currently I've implemented lines the same way as Cairo does > (generating three trapezoids), which gives the same result as with > XDrawLine when line_width is set to 1.0, it looks to some degree ugly > :-/ > I created some screenshots: http://picasaweb.google.com/linuxhippy/Cairo > > The problem is that I don't see any way to do nice lines with XRender, > without a lot of overhead and many trapezoids. > Carl Worth was very helful, pointing me to a solution: > http://cm.bell-labs.com/who/hobby/87_2-04.pdf > However that means stroking with a pen -> complex stuff probably > generating many more than "just" 3 Trapezoids. No. I don't think you understood the solution. It should not generate any more trapezoids than your current approach. You are already stroking your lines with a pen---you just happen to be using a circular pen, (that is, the pen has the same cross-sectional diameter in all directions). The key part of Hobby's solution is that the cross-sectional "diameter" is different depending on the angle of the line being drawn. And it's this difference that gives the result you want, (the appearance of uniform line-width in the final result). So you should be able to easily write a function, (with an explicit or implicit Hobby pen polygon), that simply computes the correct cross-sectional width for any particular line, (based on its angle), and then generate your trapezoids based on that. So what you will then be handing to Xrender won't be any more complex, but the result should be much more appealing. I'll be quite interested to see your results if you pursue this approach. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From linuxhippy at gmail.com Mon Jun 2 21:04:51 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 2 Jun 2008 23:04:51 +0200 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <87iqwrbm6x.wl%cworth@cworth.org> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> <87iqwrbm6x.wl%cworth@cworth.org> Message-ID: <194f62550806021404x692a39a2g6a56945c8eceb3e9@mail.gmail.com> Hi Carl, You are right, I misunderstood the approach. As far as I understand now, I just have to adjust the width of the line-rectangle accoring to the pen-strcuture which is approproate for the choosen line-width, is this right? I'll read through the paper tomorrow. Thanks, Clemens > You are already stroking your lines with a pen---you just happen to be > using a circular pen, (that is, the pen has the same cross-sectional > diameter in all directions). The key part of Hobby's solution is that > the cross-sectional "diameter" is different depending on the angle of > the line being drawn. And it's this difference that gives the result > you want, (the appearance of uniform line-width in the final result). Thanks for the explanation. 2008/6/2 Carl Worth : > On Mon, 2 Jun 2008 22:36:46 +0200, "Clemens Eisserer" wrote: >> 2.) Currently I've implemented lines the same way as Cairo does >> (generating three trapezoids), which gives the same result as with >> XDrawLine when line_width is set to 1.0, it looks to some degree ugly >> :-/ >> I created some screenshots: http://picasaweb.google.com/linuxhippy/Cairo >> >> The problem is that I don't see any way to do nice lines with XRender, >> without a lot of overhead and many trapezoids. >> Carl Worth was very helful, pointing me to a solution: >> http://cm.bell-labs.com/who/hobby/87_2-04.pdf >> However that means stroking with a pen -> complex stuff probably >> generating many more than "just" 3 Trapezoids. > > No. I don't think you understood the solution. It should not generate > any more trapezoids than your current approach. > > You are already stroking your lines with a pen---you just happen to be > using a circular pen, (that is, the pen has the same cross-sectional > diameter in all directions). The key part of Hobby's solution is that > the cross-sectional "diameter" is different depending on the angle of > the line being drawn. And it's this difference that gives the result > you want, (the appearance of uniform line-width in the final result). > > So you should be able to easily write a function, (with an explicit or > implicit Hobby pen polygon), that simply computes the correct > cross-sectional width for any particular line, (based on its angle), > and then generate your trapezoids based on that. > > So what you will then be handing to Xrender won't be any more complex, > but the result should be much more appealing. > > I'll be quite interested to see your results if you pursue this > approach. > > -Carl > From cworth at cworth.org Mon Jun 2 21:26:32 2008 From: cworth at cworth.org (Carl Worth) Date: Mon, 02 Jun 2008 14:26:32 -0700 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <194f62550806021404x692a39a2g6a56945c8eceb3e9@mail.gmail.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> <87iqwrbm6x.wl%cworth@cworth.org> <194f62550806021404x692a39a2g6a56945c8eceb3e9@mail.gmail.com> Message-ID: <87hccbbkaf.wl%cworth@cworth.org> On Mon, 2 Jun 2008 23:04:51 +0200, "Clemens Eisserer" wrote: > You are right, I misunderstood the approach. > As far as I understand now, I just have to adjust the width of the > line-rectangle > accoring to the pen-strcuture which is approproate for the choosen > line-width, is this right? ... and according the the particular angle of the line segment you are drawing, but yes. > I'll read through the paper tomorrow. I'm certain you'll enjoy it. John Hobby is fantastic at explaining things very accurately and carefully. I've always found his papers quite a pleasure to read. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Dmitri.Trembovetski at Sun.COM Mon Jun 2 22:43:54 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 02 Jun 2008 15:43:54 -0700 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> Message-ID: <484477AA.8030101@Sun.COM> Hi Clemens, Clemens Eisserer wrote: > 3.) I have an awkward problem: > > The strange thing is that the GetPrimitiveArrayCritical call crashes, > but if I copy exactly the same call into the trampoline-function, Did you try to run it with -Xcheck:jni (preferably on a fastdebug build)? What does it say? Thanks, Dmitri > everything works fine: > V [libjvm.so+0x24252b] > C [libmawt.so+0x1fc6c] AWTXRDrawGlyphList+0x8c > C [libfontmanager.so+0xb294] > Java_sun_font_X11TextRenderer_doDrawGlyphList+0x74 > j sun.font.X11TextRenderer.doDrawGlyphList(JIZZZIFF[J[F)V+0 > > I am not a JNI nor a C profesional, any idea what I am doing wrong? > Am I passing the JNI-Envirment-pointer somehow wrong, or the > array-handles, or is it related to the fact that both methods are > located in different shared libraries? If I copy the second method > from X11TextRenderer_md directly into X11TextRenderer (doing nothing > except the GetPrimitiveArrayCritical) everything works as expected. > Sorry for this question ;) > > Thanks a lot, lg Clemens From linuxhippy at gmail.com Tue Jun 3 10:31:46 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 3 Jun 2008 12:31:46 +0200 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <484477AA.8030101@Sun.COM> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> <484477AA.8030101@Sun.COM> Message-ID: <194f62550806030331h33538930j34de6b25a8cd77ee@mail.gmail.com> Hi Dmitri, > Did you try to run it with -Xcheck:jni (preferably on a fastdebug > build)? What does it say? Thanks for the hint, it cleans the array-handle is not valid. I added printf-statements and Hotspot is of course right, the "original" object handle was != NULL, but the one I passed is zero. The strange thing is if I call a method in the same shared library (fontmanager.so) the handle is passed correctly, but when calling into libmawt.so the array-handle is NULL. I pass the array-handles by value, is this ok? For now I could work-arround that by simply calling GetPrimitiveArrayCritical in the first method, however thats somehow strange and I would like to understand where my mistake is to learn of my faults ;) Thanks a lot for your patience, Clemens One thing that also puzzles me is how the compiler knows about AWTXRDrawGlyphList? There's no header-file which specifies it, does the compiler guess? This is the how the code looks like: 1.) In libmawt.so the method which is called and crashes: void AWTXRDrawGlyphList (JNIEnv *env, jobject self, jlong dstData, jint numGlyphs, jboolean usePositions, jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, jfloat glyphListOrigX, jfloat glyphListOrigY, jlongArray imgArray, jfloatArray posArray) { images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); } 2.)The method called from JNI in libfontmanager.so and a test-dummy method: JNIEXPORT void JNICALL Java_sun_font_X11TextRenderer_doDrawGlyphList //Method called from JNI (JNIEnv *env, jobject xtr, jlong dstData, jint totalGlyphs, jboolean usePositions, jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, jfloat glyphListOrigX, jfloat glyphListOrigY, jlongArray images, jfloatArray positions) { TESTDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, //Does not crash subPixPos, rgbOrder, lcdContrast, glyphListOrigX, glyphListOrigY, images, positions); AWTXRDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, //Does crash, because images == NULL subPixPos, rgbOrder, lcdContrast, glyphListOrigX, glyphListOrigY, images, positions); } JNIEXPORT void TESTDrawGlyphList //DummyTestMethod (JNIEnv *env, jobject self, jlong dstData, jint numGlyphs, jboolean usePositions, jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, jfloat glyphListOrigX, jfloat glyphListOrigY, jlongArray imgArray, jfloatArray posArray) { jlong *images; images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); } These are the outputs when I run the code with Xcheck:jni: Pointer: -1388390664 <- Value of imgArray-handle before passed to the 2nd method in libmawt.so Pointer: 0 <- Passed value FATAL ERROR in native method: Non-array passed to JNI array operations and this is without XCheck:jni: V [libjvm.so+0x24252b] C [libmawt.so+0x1fc81] AWTXRDrawGlyphList+0xa1 C [libfontmanager.so+0xb393] Java_sun_font_X11TextRenderer_doDrawGlyphList+0x113 j sun.font.X11TextRenderer.doDrawGlyphList(JIZZZIFF[J[F)V+0 So the first call succeed (which basically does exectly the same, its just in another shared library), but the second time the parameter is not passed :-/ From linuxhippy at gmail.com Tue Jun 3 13:31:55 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 3 Jun 2008 15:31:55 +0200 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <194f62550806030331h33538930j34de6b25a8cd77ee@mail.gmail.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> <484477AA.8030101@Sun.COM> <194f62550806030331h33538930j34de6b25a8cd77ee@mail.gmail.com> Message-ID: <194f62550806030631q1ff7f69cib9d76cfac640d09e@mail.gmail.com> Hi again, I now inserted printf-statements to see the value of the parameters before and after passing them: In X11TextRenderer: numGlpyhs:10, usePositions:0, subpixPos:0, rgbOrder:0, lcdc:140, glypx:100.500000, glyphy:400.500000, Images: -1376605040, NULL In X11TextRenderer_md: numGlpyhs:10, usePositions:0, subpixPos:0, rgbOrder:0, lcdc:140, glypx:0.000000, glyphy:3.392578, Images: 0 Positions:1081673728 So somehow it looks like passing the jfloats causes troubles, after commenting them out, everything works as expected: In X11TextRenderer: numGlpyhs:10, usePositions:0, subpixPos:0, rgbOrder:0, lcdc:140, glypx:100.500000, glyphy:400.50000, Images: -1376605792 In _md: numGlpyhs:10, usePositions:0, subpixPos:0, rgbOrder:0, lcdc:140, glypx:-0.000000, glyphy:-0.000000, Images: -1376605792, Positions:0 Any idea why passing the jfloats fail? Thank you in advance, lg Clemens 2008/6/3 Clemens Eisserer : > Hi Dmitri, > >> Did you try to run it with -Xcheck:jni (preferably on a fastdebug >> build)? What does it say? > Thanks for the hint, it cleans the array-handle is not valid. > > I added printf-statements and Hotspot is of course right, the > "original" object handle was != NULL, but the one I passed is zero. > The strange thing is if I call a method in the same shared library > (fontmanager.so) the handle is passed correctly, but when calling into > libmawt.so the array-handle is NULL. > I pass the array-handles by value, is this ok? > > For now I could work-arround that by simply calling > GetPrimitiveArrayCritical in the first method, however thats somehow > strange and I would like to understand where my mistake is to learn of > my faults ;) > > Thanks a lot for your patience, Clemens > > One thing that also puzzles me is how the compiler knows about > AWTXRDrawGlyphList? > There's no header-file which specifies it, does the compiler guess? > This is the how the code looks like: > > 1.) In libmawt.so the method which is called and crashes: > void AWTXRDrawGlyphList > (JNIEnv *env, jobject self, > jlong dstData, jint numGlyphs, jboolean usePositions, > jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, > jfloat glyphListOrigX, jfloat glyphListOrigY, > jlongArray imgArray, jfloatArray posArray) > { > images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); > } > > 2.)The method called from JNI in libfontmanager.so and a test-dummy method: > JNIEXPORT void JNICALL Java_sun_font_X11TextRenderer_doDrawGlyphList > //Method called from JNI > (JNIEnv *env, jobject xtr, > jlong dstData, jint totalGlyphs, jboolean usePositions, > jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, > jfloat glyphListOrigX, jfloat glyphListOrigY, > jlongArray images, jfloatArray positions) > { > TESTDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, > //Does not crash > subPixPos, rgbOrder, lcdContrast, glyphListOrigX, > glyphListOrigY, images, positions); > > AWTXRDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, > //Does crash, because images == NULL > subPixPos, rgbOrder, lcdContrast, glyphListOrigX, > glyphListOrigY, images, positions); > } > > JNIEXPORT void TESTDrawGlyphList //DummyTestMethod > (JNIEnv *env, jobject self, > jlong dstData, jint numGlyphs, jboolean usePositions, > jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, > jfloat glyphListOrigX, jfloat glyphListOrigY, > jlongArray imgArray, jfloatArray posArray) > { > jlong *images; > images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); > } > > These are the outputs when I run the code with Xcheck:jni: > Pointer: -1388390664 <- Value of imgArray-handle before passed to the > 2nd method in libmawt.so > Pointer: 0 <- Passed value > FATAL ERROR in native method: Non-array passed to JNI array operations > > and this is without XCheck:jni: > V [libjvm.so+0x24252b] > C [libmawt.so+0x1fc81] AWTXRDrawGlyphList+0xa1 > C [libfontmanager.so+0xb393] > Java_sun_font_X11TextRenderer_doDrawGlyphList+0x113 > j sun.font.X11TextRenderer.doDrawGlyphList(JIZZZIFF[J[F)V+0 > > So the first call succeed (which basically does exectly the same, its > just in another shared library), but the second time the parameter is > not passed :-/ > From lana.steuck at sun.com Thu Jun 5 21:24:01 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 05 Jun 2008 21:24:01 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 9 new changesets Message-ID: <20080605212549.320EA28097@hg.openjdk.java.net> Changeset: da9a7ef8d34e Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/da9a7ef8d34e Added tag jdk7-b27 for changeset 3e599d98875d ! .hgtags Changeset: 94ded5c8cfba Author: emcmanus Date: 2008-05-14 18:38 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/94ded5c8cfba 6701459: Synchronization bug pattern found in javax.management.relation.RelationService Summary: Fixed this and many other problems found by FindBugs. Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/security/FileLoginModule.java ! src/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/share/classes/javax/management/NumericValueExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/StandardMBean.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetParser.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfoSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/monitor/CounterMonitor.java ! src/share/classes/javax/management/monitor/GaugeMonitor.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanConstructorInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/relation/RelationNotification.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/timer/Timer.java Changeset: 1483094a7c17 Author: emcmanus Date: 2008-05-16 11:34 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1483094a7c17 6703552: Missing files from changeset for 6701459 Summary: Previous push missed a small number of files. Reviewed-by: dfuchs ! src/share/classes/javax/management/openmbean/OpenMBeanOperationInfoSupport.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/relation/RelationNotificationSeqNoTest.java Changeset: a36a7f0f11ec Author: tbell Date: 2008-05-22 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a36a7f0f11ec Merge Changeset: cbd182c404d8 Author: tbell Date: 2008-05-23 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cbd182c404d8 Merge Changeset: 7971bbb6dc42 Author: ohair Date: 2008-05-15 13:04 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7971bbb6dc42 6590549: Cygwin build of OpenJDK has problems and not very well documented Summary: Just the Makefile changes to fix a cygwin nawk BINMODE=w problem. Reviewed-by: igor, tbell ! make/common/shared/Defs-utils.gmk ! make/java/java/Makefile ! make/java/nio/Makefile Changeset: b6601ba7f6df Author: xdono Date: 2008-05-27 17:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b6601ba7f6df Merge Changeset: 02e4c5348592 Author: lana Date: 2008-06-03 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/02e4c5348592 Merge Changeset: 3c4fc5111ff2 Author: lana Date: 2008-06-05 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3c4fc5111ff2 Merge From linuxhippy at gmail.com Thu Jun 5 22:16:28 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 6 Jun 2008 00:16:28 +0200 Subject: [OpenJDK 2D-Dev] Rotation per-pixel accuracy Message-ID: <194f62550806051516i5b5c04ewf9dda6fde449c365@mail.gmail.com> Hi, The last two days I worked on text-rendering, and although major parts are missing (caching, optimizations, ...), it works already for no-AA and grayscale-AA'ed glyphs (I will look at subpixel-rgb later, frightens me somehow ;) ). I was able to solve the problem with the corrupted jfloat-arguments, I simply use jdouble now and everything works fine (could it really be a gcc bug?). As always I've some questions: 1.) I played a bit with rotated text to see how accurat my implementation is. I am drawing the text rotated to a BufferedImage as well as directly to screen and blit the BI to the same position on screen. My XRender implementation matches almost with the BufferedImage result, however the existing X11-pipeline differs quite a bit. The X11-Pipeline is consistent when I draw with AlphaColor or not, XRender currently is not (because it still falls back to software for the alphacolor case, I'll have a look at validate later). When not rotated all results are consistent against each other. I did some screenshots for some combinations: http://picasaweb.google.com/linuxhippy/RotatedText Are there rules that rendering has to be per-pixel consistent, with what should I compare to see wether my implementation works correct? And how important are cases where advances are non-integer for performance? 2.) When does GlyphList use positions, which common use-case will trigger it? 3.) Does the JDK contain utility functions for native-code. I would like to write my own glyph-cache-management, and don't want to flood my implementation with common-use-case code like hashtable or list implementations. Does the JDK contain contain stuff like this? 4.) Are there any "good pratice" rules how much memory may be allocated on the stack within native code? E.g. XRender expects the rows of glyphs padded to 4bytes, so often I need to create a small copy with different dimensions. Thanks for your patience, Clemens PS: I blog about this project, if you're interested: http://linuxhippy.blogspot.com/ From Jim.A.Graham at Sun.COM Thu Jun 5 22:45:07 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Thu, 05 Jun 2008 15:45:07 -0700 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <194f62550806030631q1ff7f69cib9d76cfac640d09e@mail.gmail.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> <484477AA.8030101@Sun.COM> <194f62550806030331h33538930j34de6b25a8cd77ee@mail.gmail.com> <194f62550806030631q1ff7f69cib9d76cfac640d09e@mail.gmail.com> Message-ID: <0K20000ERHUWQM10@fe-sfbay-09.sun.com> This is often a problem that can happen if you don't have a prototype for the function. The default passing semantics for floating point is to pass them as doubles unless there is a prototype that says that they are floats. Did you get the prototype correct, and did you make sure it was included? ...jim Clemens Eisserer wrote: > Hi again, > > I now inserted printf-statements to see the value of the parameters > before and after passing them: > In X11TextRenderer: numGlpyhs:10, usePositions:0, > subpixPos:0, rgbOrder:0, lcdc:140, glypx:100.500000, > glyphy:400.500000, Images: -1376605040, NULL > In X11TextRenderer_md: numGlpyhs:10, usePositions:0, subpixPos:0, > rgbOrder:0, lcdc:140, glypx:0.000000, glyphy:3.392578, Images: 0 > Positions:1081673728 > > So somehow it looks like passing the jfloats causes troubles, after > commenting them out, everything works as expected: > In X11TextRenderer: numGlpyhs:10, usePositions:0, subpixPos:0, > rgbOrder:0, lcdc:140, glypx:100.500000, glyphy:400.50000, Images: > -1376605792 > In _md: numGlpyhs:10, usePositions:0, subpixPos:0, rgbOrder:0, > lcdc:140, glypx:-0.000000, glyphy:-0.000000, Images: -1376605792, > Positions:0 > > Any idea why passing the jfloats fail? > > Thank you in advance, lg Clemens > > > 2008/6/3 Clemens Eisserer : >> Hi Dmitri, >> >>> Did you try to run it with -Xcheck:jni (preferably on a fastdebug >>> build)? What does it say? >> Thanks for the hint, it cleans the array-handle is not valid. >> >> I added printf-statements and Hotspot is of course right, the >> "original" object handle was != NULL, but the one I passed is zero. >> The strange thing is if I call a method in the same shared library >> (fontmanager.so) the handle is passed correctly, but when calling into >> libmawt.so the array-handle is NULL. >> I pass the array-handles by value, is this ok? >> >> For now I could work-arround that by simply calling >> GetPrimitiveArrayCritical in the first method, however thats somehow >> strange and I would like to understand where my mistake is to learn of >> my faults ;) >> >> Thanks a lot for your patience, Clemens >> >> One thing that also puzzles me is how the compiler knows about >> AWTXRDrawGlyphList? >> There's no header-file which specifies it, does the compiler guess? >> This is the how the code looks like: >> >> 1.) In libmawt.so the method which is called and crashes: >> void AWTXRDrawGlyphList >> (JNIEnv *env, jobject self, >> jlong dstData, jint numGlyphs, jboolean usePositions, >> jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, >> jfloat glyphListOrigX, jfloat glyphListOrigY, >> jlongArray imgArray, jfloatArray posArray) >> { >> images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); >> } >> >> 2.)The method called from JNI in libfontmanager.so and a test-dummy method: >> JNIEXPORT void JNICALL Java_sun_font_X11TextRenderer_doDrawGlyphList >> //Method called from JNI >> (JNIEnv *env, jobject xtr, >> jlong dstData, jint totalGlyphs, jboolean usePositions, >> jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, >> jfloat glyphListOrigX, jfloat glyphListOrigY, >> jlongArray images, jfloatArray positions) >> { >> TESTDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, >> //Does not crash >> subPixPos, rgbOrder, lcdContrast, glyphListOrigX, >> glyphListOrigY, images, positions); >> >> AWTXRDrawGlyphList(env, xtr, dstData, totalGlyphs, usePositions, >> //Does crash, because images == NULL >> subPixPos, rgbOrder, lcdContrast, glyphListOrigX, >> glyphListOrigY, images, positions); >> } >> >> JNIEXPORT void TESTDrawGlyphList //DummyTestMethod >> (JNIEnv *env, jobject self, >> jlong dstData, jint numGlyphs, jboolean usePositions, >> jboolean subPixPos, jboolean rgbOrder, jint lcdContrast, >> jfloat glyphListOrigX, jfloat glyphListOrigY, >> jlongArray imgArray, jfloatArray posArray) >> { >> jlong *images; >> images = (jlong *) (*env)->GetPrimitiveArrayCritical(env, imgArray, NULL); >> } >> >> These are the outputs when I run the code with Xcheck:jni: >> Pointer: -1388390664 <- Value of imgArray-handle before passed to the >> 2nd method in libmawt.so >> Pointer: 0 <- Passed value >> FATAL ERROR in native method: Non-array passed to JNI array operations >> >> and this is without XCheck:jni: >> V [libjvm.so+0x24252b] >> C [libmawt.so+0x1fc81] AWTXRDrawGlyphList+0xa1 >> C [libfontmanager.so+0xb393] >> Java_sun_font_X11TextRenderer_doDrawGlyphList+0x113 >> j sun.font.X11TextRenderer.doDrawGlyphList(JIZZZIFF[J[F)V+0 >> >> So the first call succeed (which basically does exectly the same, its >> just in another shared library), but the second time the parameter is >> not passed :-/ >> From linuxhippy at gmail.com Thu Jun 5 22:55:31 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 6 Jun 2008 00:55:31 +0200 Subject: [OpenJDK 2D-Dev] Why does the OpenGL pipeline not use setupBlitVector? In-Reply-To: <0K20000ERHUWQM10@fe-sfbay-09.sun.com> References: <194f62550805300113u5ac7c041o2de14721c3418863@mail.gmail.com> <0AD523CC-8459-4783-9029-FFD0483C8726@sun.com> <48406FCC.8010301@sun.com> <194f62550806021336x7949da28jdf9efba11c519933@mail.gmail.com> <484477AA.8030101@Sun.COM> <194f62550806030331h33538930j34de6b25a8cd77ee@mail.gmail.com> <194f62550806030631q1ff7f69cib9d76cfac640d09e@mail.gmail.com> <0K20000ERHUWQM10@fe-sfbay-09.sun.com> Message-ID: <194f62550806051555o7a41b940x1b44dd3de8508839@mail.gmail.com> Hi Jim, > This is often a problem that can happen if you don't have a prototype for > the function. The default passing semantics for floating point is to pass > them as doubles unless there is a prototype that says that they are floats. > > Did you get the prototype correct, and did you make sure it was included? Thanks a lot, that solves the problem. Sorry for bothering with such a simple problem, I am not really used to C :-/ Thanks, Clemens From linuxhippy at gmail.com Fri Jun 6 01:02:48 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 6 Jun 2008 03:02:48 +0200 Subject: [OpenJDK 2D-Dev] Rotation per-pixel accuracy In-Reply-To: <194f62550806051516i5b5c04ewf9dda6fde449c365@mail.gmail.com> References: <194f62550806051516i5b5c04ewf9dda6fde449c365@mail.gmail.com> Message-ID: <194f62550806051802i15c17d8i61254e2de3f0c607@mail.gmail.com> Hi again, > Are there rules that rendering has to be per-pixel consistent, with > what should I compare to see wether my implementation works correct? Sorry about the traffic ... it seems different rounding errors were the cause for the different results, the rotated text was drawn to the BI at the position 0/20, whereas it was rendered at 100/100 to screen. With adjusted positions I get consistent rendering with rotation also. Sorry for the traffic :-/ Thanks, Clemens From lana.steuck at sun.com Fri Jun 6 06:45:22 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 06 Jun 2008 06:45:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: Added tag jdk7-b27 for changeset 11b4dc9f2be3 Message-ID: <20080606064522.5FADC2816D@hg.openjdk.java.net> Changeset: 56652b46f328 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/56652b46f328 Added tag jdk7-b27 for changeset 11b4dc9f2be3 ! .hgtags From lana.steuck at sun.com Fri Jun 6 06:46:15 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 06 Jun 2008 06:46:15 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: Added tag jdk7-b27 for changeset e84e9018bebb Message-ID: <20080606064617.396DD28172@hg.openjdk.java.net> Changeset: 27509b7d21ed Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/27509b7d21ed Added tag jdk7-b27 for changeset e84e9018bebb ! .hgtags From lana.steuck at sun.com Fri Jun 6 06:48:26 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 06 Jun 2008 06:48:26 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 62 new changesets Message-ID: <20080606065025.0245728177@hg.openjdk.java.net> Changeset: b97de546208e Author: xlu Date: 2008-04-03 12:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b97de546208e 6671882: memory access after free in solaris/vm/os_solaris.cpp Summary: Corrected the wrong memory access problem and made some minor clean ups Reviewed-by: dholmes, jcoomes ! src/os/solaris/vm/os_solaris.cpp Changeset: cf4e16e9ca60 Author: kamg Date: 2008-04-04 10:48 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/cf4e16e9ca60 Merge Changeset: a294fd0c4b38 Author: kamg Date: 2008-04-09 14:22 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a294fd0c4b38 6583644: Move all managed/SCCS files out of 'build' into 'make' directory Summary: Moved makefiles out of build and build/closed into make/ Reviewed-by: kvn, ohair ! .hgignore - build/hotspot_distro - build/linux/Makefile - build/linux/Queens.class - build/linux/README - build/linux/adlc_updater - build/linux/build.sh - build/linux/makefiles/adjust-mflags.sh - build/linux/makefiles/adlc.make - build/linux/makefiles/amd64.make - build/linux/makefiles/buildtree.make - build/linux/makefiles/compiler1.make - build/linux/makefiles/compiler2.make - build/linux/makefiles/core.make - build/linux/makefiles/cscope.make - build/linux/makefiles/debug.make - build/linux/makefiles/defs.make - build/linux/makefiles/dtrace.make - build/linux/makefiles/fastdebug.make - build/linux/makefiles/gcc.make - build/linux/makefiles/hp.make - build/linux/makefiles/hp1.make - build/linux/makefiles/i486.make - build/linux/makefiles/jsig.make - build/linux/makefiles/jvmg.make - build/linux/makefiles/jvmti.make - build/linux/makefiles/launcher.make - build/linux/makefiles/makedeps.make - build/linux/makefiles/mapfile-vers-debug - build/linux/makefiles/mapfile-vers-jsig - build/linux/makefiles/mapfile-vers-product - build/linux/makefiles/optimized.make - build/linux/makefiles/product.make - build/linux/makefiles/profiled.make - build/linux/makefiles/rules.make - build/linux/makefiles/sa.make - build/linux/makefiles/saproc.make - build/linux/makefiles/sparcWorks.make - build/linux/makefiles/tiered.make - build/linux/makefiles/top.make - build/linux/makefiles/vm.make - build/linux/platform_amd64 - build/linux/platform_amd64.suncc - build/linux/platform_i486 - build/linux/platform_i486.suncc - build/linux/platform_sparc - build/sa.files - build/solaris/Makefile - build/solaris/Queens.class - build/solaris/adlc_updater - build/solaris/build.sh - build/solaris/makefiles/adjust-mflags.sh - build/solaris/makefiles/adlc.make - build/solaris/makefiles/amd64.make - build/solaris/makefiles/buildtree.make - build/solaris/makefiles/compiler1.make - build/solaris/makefiles/compiler2.make - build/solaris/makefiles/core.make - build/solaris/makefiles/cscope.make - build/solaris/makefiles/debug.make - build/solaris/makefiles/defs.make - build/solaris/makefiles/dtrace.make - build/solaris/makefiles/fastdebug.make - build/solaris/makefiles/gcc.make - build/solaris/makefiles/hp.make - build/solaris/makefiles/hp1.make - build/solaris/makefiles/i486.make - build/solaris/makefiles/jsig.make - build/solaris/makefiles/jvmg.make - build/solaris/makefiles/jvmti.make - build/solaris/makefiles/kernel.make - build/solaris/makefiles/launcher.make - build/solaris/makefiles/makedeps.make - build/solaris/makefiles/mapfile-vers - build/solaris/makefiles/mapfile-vers-COMPILER1 - build/solaris/makefiles/mapfile-vers-COMPILER2 - build/solaris/makefiles/mapfile-vers-CORE - build/solaris/makefiles/mapfile-vers-TIERED - build/solaris/makefiles/mapfile-vers-debug - build/solaris/makefiles/mapfile-vers-jsig - build/solaris/makefiles/mapfile-vers-jvm_db - build/solaris/makefiles/mapfile-vers-jvm_dtrace - build/solaris/makefiles/mapfile-vers-nonproduct - build/solaris/makefiles/optimized.make - build/solaris/makefiles/product.make - build/solaris/makefiles/profiled.make - build/solaris/makefiles/reorder_COMPILER1_i486 - build/solaris/makefiles/reorder_COMPILER1_sparc - build/solaris/makefiles/reorder_COMPILER1_sparcv9 - build/solaris/makefiles/reorder_COMPILER2_amd64 - build/solaris/makefiles/reorder_COMPILER2_i486 - build/solaris/makefiles/reorder_COMPILER2_sparc - build/solaris/makefiles/reorder_COMPILER2_sparcv9 - build/solaris/makefiles/reorder_CORE_amd64 - build/solaris/makefiles/reorder_CORE_i486 - build/solaris/makefiles/reorder_CORE_sparc - build/solaris/makefiles/reorder_CORE_sparcv9 - build/solaris/makefiles/reorder_TIERED_amd64 - build/solaris/makefiles/reorder_TIERED_i486 - build/solaris/makefiles/reorder_TIERED_sparc - build/solaris/makefiles/rules.make - build/solaris/makefiles/sa.make - build/solaris/makefiles/saproc.make - build/solaris/makefiles/sparc.make - build/solaris/makefiles/sparcWorks.make - build/solaris/makefiles/sparcv9.make - build/solaris/makefiles/tiered.make - build/solaris/makefiles/top.make - build/solaris/makefiles/vm.make - build/solaris/platform_amd64 - build/solaris/platform_amd64.gcc - build/solaris/platform_i486 - build/solaris/platform_i486.gcc - build/solaris/platform_sparc - build/solaris/platform_sparc.gcc - build/solaris/platform_sparcv9 - build/solaris/platform_sparcv9.gcc - build/solaris/reorder.sh - build/test/Queens.java - build/windows/README - build/windows/build.bat - build/windows/build.make - build/windows/build_vm_def.sh - build/windows/create.bat - build/windows/cross_build.bat - build/windows/get_msc_ver.sh - build/windows/jvmexp.lcf - build/windows/jvmexp_g.lcf - build/windows/makefiles/adlc.make - build/windows/makefiles/compile.make - build/windows/makefiles/debug.make - build/windows/makefiles/defs.make - build/windows/makefiles/fastdebug.make - build/windows/makefiles/generated.make - build/windows/makefiles/jvmti.make - build/windows/makefiles/makedeps.make - build/windows/makefiles/product.make - build/windows/makefiles/rules.make - build/windows/makefiles/sa.make - build/windows/makefiles/sanity.make - build/windows/makefiles/shared.make - build/windows/makefiles/top.make - build/windows/makefiles/vm.make - build/windows/platform_amd64 - build/windows/platform_i486 - build/windows/projectfiles/common/Makefile - build/windows/projectfiles/compiler1/Makefile - build/windows/projectfiles/compiler1/vm.def - build/windows/projectfiles/compiler1/vm.dsw - build/windows/projectfiles/compiler2/ADLCompiler.dsp - build/windows/projectfiles/compiler2/ADLCompiler.dsw - build/windows/projectfiles/compiler2/Makefile - build/windows/projectfiles/compiler2/vm.def - build/windows/projectfiles/compiler2/vm.dsw - build/windows/projectfiles/core/Makefile - build/windows/projectfiles/core/vm.def - build/windows/projectfiles/core/vm.dsw - build/windows/projectfiles/kernel/Makefile - build/windows/projectfiles/kernel/vm.def - build/windows/projectfiles/kernel/vm.dsw - build/windows/projectfiles/tiered/ADLCompiler.dsp - build/windows/projectfiles/tiered/ADLCompiler.dsw - build/windows/projectfiles/tiered/Makefile - build/windows/projectfiles/tiered/vm.def - build/windows/projectfiles/tiered/vm.dsw ! make/defs.make + make/hotspot_distro ! make/jprt.properties + make/linux/Makefile + make/linux/Queens.class + make/linux/README + make/linux/adlc_updater + make/linux/build.sh + make/linux/makefiles/adjust-mflags.sh + make/linux/makefiles/adlc.make + make/linux/makefiles/amd64.make + make/linux/makefiles/buildtree.make + make/linux/makefiles/compiler1.make + make/linux/makefiles/compiler2.make + make/linux/makefiles/core.make + make/linux/makefiles/cscope.make + make/linux/makefiles/debug.make + make/linux/makefiles/defs.make + make/linux/makefiles/dtrace.make + make/linux/makefiles/fastdebug.make + make/linux/makefiles/gcc.make + make/linux/makefiles/hp.make + make/linux/makefiles/hp1.make + make/linux/makefiles/i486.make + make/linux/makefiles/ia64.make + make/linux/makefiles/jsig.make + make/linux/makefiles/jvmg.make + make/linux/makefiles/jvmti.make + make/linux/makefiles/launcher.make + make/linux/makefiles/makedeps.make + make/linux/makefiles/mapfile-vers-debug + make/linux/makefiles/mapfile-vers-jsig + make/linux/makefiles/mapfile-vers-product + make/linux/makefiles/optimized.make + make/linux/makefiles/product.make + make/linux/makefiles/profiled.make + make/linux/makefiles/rules.make + make/linux/makefiles/sa.make + make/linux/makefiles/saproc.make + make/linux/makefiles/sparc.make + make/linux/makefiles/sparcWorks.make + make/linux/makefiles/sparcv9.make + make/linux/makefiles/tiered.make + make/linux/makefiles/top.make + make/linux/makefiles/vm.make + make/linux/platform_amd64 + make/linux/platform_amd64.suncc + make/linux/platform_i486 + make/linux/platform_i486.suncc + make/linux/platform_ia64 + make/linux/platform_sparc + make/openjdk_distro + make/sa.files + make/solaris/Makefile + make/solaris/Queens.class + make/solaris/adlc_updater + make/solaris/build.sh + make/solaris/makefiles/adjust-mflags.sh + make/solaris/makefiles/adlc.make + make/solaris/makefiles/amd64.make + make/solaris/makefiles/buildtree.make + make/solaris/makefiles/compiler1.make + make/solaris/makefiles/compiler2.make + make/solaris/makefiles/core.make + make/solaris/makefiles/cscope.make + make/solaris/makefiles/debug.make + make/solaris/makefiles/defs.make + make/solaris/makefiles/dtrace.make + make/solaris/makefiles/fastdebug.make + make/solaris/makefiles/gcc.make + make/solaris/makefiles/hp.make + make/solaris/makefiles/hp1.make + make/solaris/makefiles/i486.make + make/solaris/makefiles/jsig.make + make/solaris/makefiles/jvmg.make + make/solaris/makefiles/jvmti.make + make/solaris/makefiles/kernel.make + make/solaris/makefiles/launcher.make + make/solaris/makefiles/makedeps.make + make/solaris/makefiles/mapfile-vers + make/solaris/makefiles/mapfile-vers-COMPILER1 + make/solaris/makefiles/mapfile-vers-COMPILER2 + make/solaris/makefiles/mapfile-vers-CORE + make/solaris/makefiles/mapfile-vers-TIERED + make/solaris/makefiles/mapfile-vers-debug + make/solaris/makefiles/mapfile-vers-jsig + make/solaris/makefiles/mapfile-vers-jvm_db + make/solaris/makefiles/mapfile-vers-jvm_dtrace + make/solaris/makefiles/mapfile-vers-nonproduct + make/solaris/makefiles/optimized.make + make/solaris/makefiles/product.make + make/solaris/makefiles/profiled.make + make/solaris/makefiles/reorder_COMPILER1_i486 + make/solaris/makefiles/reorder_COMPILER1_sparc + make/solaris/makefiles/reorder_COMPILER1_sparcv9 + make/solaris/makefiles/reorder_COMPILER2_amd64 + make/solaris/makefiles/reorder_COMPILER2_i486 + make/solaris/makefiles/reorder_COMPILER2_sparc + make/solaris/makefiles/reorder_COMPILER2_sparcv9 + make/solaris/makefiles/reorder_CORE_amd64 + make/solaris/makefiles/reorder_CORE_i486 + make/solaris/makefiles/reorder_CORE_sparc + make/solaris/makefiles/reorder_CORE_sparcv9 + make/solaris/makefiles/reorder_TIERED_amd64 + make/solaris/makefiles/reorder_TIERED_i486 + make/solaris/makefiles/reorder_TIERED_sparc + make/solaris/makefiles/rules.make + make/solaris/makefiles/sa.make + make/solaris/makefiles/saproc.make + make/solaris/makefiles/sparc.make + make/solaris/makefiles/sparcWorks.make + make/solaris/makefiles/sparcv9.make + make/solaris/makefiles/tiered.make + make/solaris/makefiles/top.make + make/solaris/makefiles/vm.make + make/solaris/platform_amd64 + make/solaris/platform_amd64.gcc + make/solaris/platform_i486 + make/solaris/platform_i486.gcc + make/solaris/platform_sparc + make/solaris/platform_sparc.gcc + make/solaris/platform_sparcv9 + make/solaris/platform_sparcv9.gcc + make/solaris/reorder.sh + make/test/Queens.java + make/windows/README + make/windows/build.bat + make/windows/build.make + make/windows/build_vm_def.sh + make/windows/create.bat + make/windows/cross_build.bat + make/windows/get_msc_ver.sh + make/windows/jvmexp.lcf + make/windows/jvmexp_g.lcf + make/windows/makefiles/adlc.make + make/windows/makefiles/compile.make + make/windows/makefiles/debug.make + make/windows/makefiles/defs.make + make/windows/makefiles/fastdebug.make + make/windows/makefiles/generated.make + make/windows/makefiles/jvmti.make + make/windows/makefiles/makedeps.make + make/windows/makefiles/product.make + make/windows/makefiles/rules.make + make/windows/makefiles/sa.make + make/windows/makefiles/sanity.make + make/windows/makefiles/shared.make + make/windows/makefiles/top.make + make/windows/makefiles/vm.make + make/windows/platform_amd64 + make/windows/platform_i486 + make/windows/platform_ia64 + make/windows/projectfiles/common/Makefile + make/windows/projectfiles/compiler1/Makefile + make/windows/projectfiles/compiler1/vm.def + make/windows/projectfiles/compiler1/vm.dsw + make/windows/projectfiles/compiler2/ADLCompiler.dsp + make/windows/projectfiles/compiler2/ADLCompiler.dsw + make/windows/projectfiles/compiler2/Makefile + make/windows/projectfiles/compiler2/vm.def + make/windows/projectfiles/compiler2/vm.dsw + make/windows/projectfiles/core/Makefile + make/windows/projectfiles/core/vm.def + make/windows/projectfiles/core/vm.dsw + make/windows/projectfiles/kernel/Makefile + make/windows/projectfiles/kernel/vm.def + make/windows/projectfiles/kernel/vm.dsw + make/windows/projectfiles/tiered/ADLCompiler.dsp + make/windows/projectfiles/tiered/ADLCompiler.dsw + make/windows/projectfiles/tiered/Makefile + make/windows/projectfiles/tiered/vm.def + make/windows/projectfiles/tiered/vm.dsw Changeset: ebec5b9731e2 Author: kamg Date: 2008-04-10 12:21 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ebec5b9731e2 6615981: JVM class file parser incorrectly rejects class files with version < 45.2 Summary: A check on Code length did not take into account the old sizes of the max_stack, max_locals, and code_length. Reviewed-by: phh, sbohne ! src/share/vm/classfile/classFileParser.cpp Changeset: c6ff24ceec1c Author: sbohne Date: 2008-04-10 15:49 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c6ff24ceec1c 6686407: Fix for 6666698 broke -XX:BiasedLockingStartupDelay=0 Summary: Stack allocated VM_EnableBiasedLocking op must be marked as such Reviewed-by: xlu, acorn, never, dholmes ! src/share/vm/runtime/biasedLocking.cpp Changeset: 0834225a7916 Author: ysr Date: 2008-03-16 21:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/0834225a7916 6634032: CMS: Need CMSInitiatingPermOccupancyFraction for perm, divorcing from CMSInitiatingOccupancyFraction Summary: The option CMSInitiatingPermOccupancyFraction now controls perm triggering threshold. Even though the actual value of the threshold has not yet been changed, so there is no change in policy, we now have the infrastructure in place for dynamically deciding when to collect the perm gen, an issue that will be addressed in the near future. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/runtime/globals.hpp Changeset: d05ebaf00ed0 Author: tonyp Date: 2008-03-27 17:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d05ebaf00ed0 Merge ! src/share/vm/runtime/globals.hpp Changeset: 2acabb781f53 Author: apetrusenko Date: 2008-04-07 09:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2acabb781f53 Merge Changeset: f38a25e2458a Author: kamg Date: 2008-04-09 10:38 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f38a25e2458a Merge Changeset: deb97b8ef02b Author: never Date: 2008-03-26 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/deb97b8ef02b 6679708: No_Safepoint_Verifier and BacktraceBuilder have uninitialized fields Summary: fix or remove uninitialized fields Reviewed-by: kvn, rasbold ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 8a4ef4e001d3 Author: never Date: 2008-03-28 09:00 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8a4ef4e001d3 6680594: Load + Load isn't canonicalized leading to missed GVN opportunities Reviewed-by: kvn, jrose ! src/share/vm/opto/addnode.cpp Changeset: c7c777385a15 Author: jrose Date: 2008-04-02 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c7c777385a15 6667042: PrintAssembly option does not work without special plugin Summary: remove old private plugin interface, simplify, rework old plugin to use unchanged Gnu sources Reviewed-by: kvn, rasbold ! .hgignore ! build/linux/makefiles/vm.make ! build/linux/platform_amd64 ! build/linux/platform_i486 ! build/linux/platform_sparc ! build/solaris/makefiles/vm.make ! build/solaris/platform_amd64 ! build/solaris/platform_amd64.gcc ! build/solaris/platform_i486 ! build/solaris/platform_i486.gcc ! build/solaris/platform_sparc ! build/solaris/platform_sparc.gcc ! build/solaris/platform_sparcv9 ! build/solaris/platform_sparcv9.gcc ! build/windows/makefiles/vm.make ! build/windows/platform_amd64 ! build/windows/platform_i486 - src/cpu/sparc/vm/disassembler_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp - src/cpu/x86/vm/disassembler_x86.cpp ! src/cpu/x86/vm/disassembler_x86.hpp + src/share/tools/hsdis/Makefile + src/share/tools/hsdis/README + src/share/tools/hsdis/hsdis-demo.c + src/share/tools/hsdis/hsdis.c + src/share/tools/hsdis/hsdis.h ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/code/vmreg.hpp + src/share/vm/compiler/disassembler.cpp + src/share/vm/compiler/disassembler.hpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: a6cb86dd209b Author: kvn Date: 2008-04-02 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a6cb86dd209b 6681577: PIT: some VM tests fails with -XX:+AggressiveOpts in 6u5p b01 Summary: C2 spends > 60% in escape analysis code during test nsk/regression/b4675027. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: f96100ac3d12 Author: rasbold Date: 2008-04-03 06:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f96100ac3d12 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 38a50dd839cf Author: never Date: 2008-04-03 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/38a50dd839cf 6619271: The -Xprintflags causes the VM to segv Summary: add null checks Reviewed-by: jrose, kvn ! src/share/vm/runtime/globals.cpp Changeset: 541929da62d2 Author: rasbold Date: 2008-04-03 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/541929da62d2 6624474: Server compiler generates unexpected LinkageError Summary: Fix load_signature_classes to tolerate LinkageErrors Reviewed-by: kvn, never ! src/share/vm/oops/methodOop.cpp Changeset: a7d0f95410bd Author: never Date: 2008-04-03 21:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a7d0f95410bd 6646020: assert(in_bb(n),"must be in block") in -Xcomp mode Reviewed-by: kvn, rasbold ! src/share/vm/opto/superword.cpp + test/compiler/6646020/Tester.java Changeset: c9314fa4f757 Author: rasbold Date: 2008-04-07 15:15 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c9314fa4f757 6663908: NegativeArraySizeException is not thrown Summary: Don't optimize zero length array allocations at compile time. Reviewed-by: kvn, never ! src/share/vm/opto/parse3.cpp Changeset: 93b6525e3b82 Author: sgoldman Date: 2008-04-08 12:23 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/93b6525e3b82 6603919: Stackwalking crash on x86 -server with Sun Studio's collect -j on Summary: Rewrite frame::safe_for_sender and friends to be safe for collector/analyzer Reviewed-by: dcubed, kvn ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe.hpp Changeset: a761c2d3b76a Author: rasbold Date: 2008-04-09 09:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a761c2d3b76a 6684385: Loop unswitching crashes without LoopNode Summary: Without LoopNode, exit early from loop unswitching and partial peeling Reviewed-by: kvn, never, sgoldman ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp Changeset: 9f4457a14b58 Author: rasbold Date: 2008-04-09 15:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9f4457a14b58 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/runtime/globals.hpp Changeset: a49a647afe9a Author: kamg Date: 2008-04-11 09:56 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a49a647afe9a Merge ! .hgignore ! make/linux/makefiles/vm.make ! make/linux/platform_amd64 ! make/linux/platform_i486 ! make/linux/platform_sparc ! make/solaris/makefiles/vm.make ! make/solaris/platform_amd64 ! make/solaris/platform_amd64.gcc ! make/solaris/platform_i486 ! make/solaris/platform_i486.gcc ! make/solaris/platform_sparc ! make/solaris/platform_sparc.gcc ! make/solaris/platform_sparcv9 ! make/solaris/platform_sparcv9.gcc ! make/windows/makefiles/vm.make ! make/windows/platform_amd64 ! make/windows/platform_i486 - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp Changeset: 7747916a0945 Author: ysr Date: 2008-04-08 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7747916a0945 6685160: fix cscope build with hg Summary: Use hg's fstatus instead of teamware's nametable to trigger cscope database rebuild Reviewed-by: jcoomes, kamg ! build/linux/makefiles/cscope.make ! build/solaris/makefiles/cscope.make Changeset: 7c5dac90daef Author: apetrusenko Date: 2008-04-14 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7c5dac90daef Merge Changeset: ba764ed4b6f2 Author: coleenp Date: 2008-04-13 17:43 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ba764ed4b6f2 6420645: Create a vm that uses compressed oops for up to 32gb heapsizes Summary: Compressed oops in instances, arrays, and headers. Code contributors are coleenp, phh, never, swamyv Reviewed-by: jmasa, kamg, acorn, tbell, kvn, rasbold ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapSet.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescription.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionAMD64.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionIA64.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionIntelX86.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionSPARC32Bit.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionSPARC64Bit.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/DefaultOopVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java + agent/src/share/classes/sun/jvm/hotspot/oops/NarrowOopField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArray.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHistogramElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopPrinter.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/AddressVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java + agent/src/share/classes/sun/jvm/hotspot/types/NarrowOopField.java ! agent/src/share/classes/sun/jvm/hotspot/types/Type.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicField.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicFieldWrapper.java + agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicNarrowOopField.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicOopField.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicType.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java ! make/Makefile ! make/solaris/makefiles/sparcWorks.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/register_definitions_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.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/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.inline.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/genRemSet.inline.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/hpi.cpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 34935c25a52d Author: kamg Date: 2008-04-15 18:11 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/34935c25a52d Merge ! make/linux/makefiles/cscope.make ! make/solaris/makefiles/cscope.make Changeset: e7a91a357527 Author: kamg Date: 2008-04-16 17:36 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e7a91a357527 6622385: Accessing protected static methods Summary: Protected contraints should only be applied if member is not static Reviewed-by: acorn, coleenp ! src/share/vm/runtime/reflection.cpp Changeset: 018d5b58dd4f Author: kamg Date: 2008-04-17 22:18 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/018d5b58dd4f 6537506: Provide a mechanism for specifying Java-level USDT-like dtrace probes Summary: Initial checkin of JSDT code Reviewed-by: acorn, sbohne ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/mapfile-vers ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + src/os/linux/vm/dtraceJSDT_linux.cpp + src/os/solaris/vm/dtraceJSDT_solaris.cpp + src/os/windows/vm/dtraceJSDT_windows.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h + src/share/vm/runtime/dtraceJSDT.cpp + src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: deadee49286e Author: sgoldman Date: 2008-04-11 06:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/deadee49286e 6644928: Internal Error (src/share/vm/code/relocInfo.hpp:1089) Summary: Cardtable base can be zero, ExternalAddress can't take a NULL. ! src/cpu/x86/vm/assembler_x86_32.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp Changeset: fb75a7673531 Author: rasbold Date: 2008-04-16 14:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fb75a7673531 Merge ! src/cpu/x86/vm/assembler_x86_64.cpp Changeset: d1a5218d7eaf Author: kvn Date: 2008-04-16 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d1a5218d7eaf 6686791: Side effect in NumberFormat tests with -server -Xcomp Summary: Optimization in CmpPNode::sub() removed the valid compare instruction because of false positive answer from detect_dominating_control(). Reviewed-by: jrose, sgoldman ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: aab136449123 Author: trims Date: 2008-04-17 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/aab136449123 6690518: Bump Version to 13 B01 Summary: Change Hotspot version and build number for 13b1 Reviewed-by: pbk ! make/hotspot_version Changeset: 86a689f680c5 Author: kamg Date: 2008-04-18 07:51 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/86a689f680c5 Merge Changeset: ec73d88d5b43 Author: kamg Date: 2008-04-23 06:35 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/ec73d88d5b43 Merge ! make/hotspot_version ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: 9e5a7340635e Author: sgoldman Date: 2008-04-17 07:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/9e5a7340635e 6688137: c++ interpreter fails on 64bit sparc Summary: Misc. 64bit and endian fixes for sparc Reviewed-by: never, kvn, rasbold Contributed-by: volker.simonis at gmail.com ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: b130b98db9cf Author: kvn Date: 2008-04-23 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b130b98db9cf 6689060: Escape Analysis does not work with Compressed Oops Summary: 64-bits VM crashes with -XX:+AggresiveOpts (Escape Analysis + Compressed Oops) Reviewed-by: never, sgoldman ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d942c7e64bd9 Author: never Date: 2008-04-23 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d942c7e64bd9 6601321: Assert(j == 1 || b->_nodes[j-1]->is_Phi(),"CreateEx must be first instruction in block") Reviewed-by: kvn, rasbold, sgoldman, jrose ! src/share/vm/opto/lcm.cpp Changeset: 72f4a668df19 Author: kvn Date: 2008-04-23 19:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/72f4a668df19 6625997: CastPP, CheckCastPP and Proj nodes are not dead loop safe Summary: EA and initialization optimizations could bypass these nodes. Reviewed-by: rasbold, never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.hpp Changeset: e0bd2e08e3d0 Author: never Date: 2008-04-24 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e0bd2e08e3d0 6663848: assert(i < Max(),"oob") in C2 with -Xcomp Summary: NeverBranchNodes aren't handled properly Reviewed-by: kvn, sgoldman, rasbold, jrose ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp + test/compiler/6663848/Tester.java Changeset: a76240c8b133 Author: rasbold Date: 2008-04-28 08:08 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a76240c8b133 Merge ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c0939256690b Author: rasbold Date: 2008-04-24 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c0939256690b 6646019: array subscript expressions become top() with -d64 Summary: stop compilation after negative array allocation Reviewed-by: never, jrose ! src/share/vm/opto/parse2.cpp + test/compiler/6646019/Test.java Changeset: 3e2d987e2e68 Author: rasbold Date: 2008-04-29 06:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3e2d987e2e68 Merge Changeset: 6e825ad773c6 Author: jrose Date: 2008-04-29 19:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/6e825ad773c6 6695288: runThese tests expr30303 and drem00301m1 fail when compiled code executes without deopt Summary: rework Value method for ModD and ModF, to DTRT for infinities Reviewed-by: sgoldman, kvn, rasbold ! src/share/vm/opto/divnode.cpp Changeset: 60b728ec77c1 Author: jrose Date: 2008-04-29 19:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/60b728ec77c1 6652736: well known classes in system dictionary are inefficiently processed Summary: combine many scalar variables into a single enum-indexed array in SystemDictionary. Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! 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/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/threadService.cpp Changeset: 435e64505015 Author: phh Date: 2008-04-24 15:07 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/435e64505015 6693457: Open-source hotspot linux-sparc support Summary: Move os_cpu/linux_sparc from closed to open Reviewed-by: kamg + make/linux/platform_sparcv9 + src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/linux_sparc.ad + src/os_cpu/linux_sparc/vm/linux_sparc.s + src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/prefetch_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: 8a79f7ec8f5d Author: kamg Date: 2008-04-29 11:21 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8a79f7ec8f5d 6692246: Regression : JDK 6u4 b01 fails two JCK tests when fallback is switched off Summary: Added a clause to allow null to be an operand to the arraylength bytecode Reviewed-by: sbohne, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: b7268662a986 Author: coleenp Date: 2008-04-29 19:31 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b7268662a986 6689523: max heap calculation for compressed oops is off by MaxPermSize Summary: Need to subtract MaxPermSize from the total heap size when determining whether compressed oops is turned on. Reviewed-by: jmasa, jcoomes, kvn ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 7f3a69574470 Author: kamg Date: 2008-04-30 10:58 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7f3a69574470 6695506: JVM should accept classfiles with classfile version 51 Summary: increase class file parser's acceptable max to 51 Reviewed-by: sbohne, ikrylov ! src/share/vm/classfile/classFileParser.cpp Changeset: 53735b80b9f1 Author: sbohne Date: 2008-05-01 09:38 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/53735b80b9f1 Merge Changeset: bcdc68eb7e1f Author: sbohne Date: 2008-05-02 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/bcdc68eb7e1f Merge Changeset: c0492d52d55b Author: apetrusenko Date: 2008-04-01 15:13 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c0492d52d55b 6539517: CR 6186200 should be extended to perm gen allocation to prevent spurious OOM's from perm gen Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 3febac328d82 Author: apetrusenko Date: 2008-04-16 12:58 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3febac328d82 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp Changeset: fcbfc50865ab Author: iveresov Date: 2008-04-29 13:51 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fcbfc50865ab 6684395: Port NUMA-aware allocator to linux Summary: NUMA-aware allocator port to Linux Reviewed-by: jmasa, apetrusenko ! build/linux/makefiles/mapfile-vers-debug ! build/linux/makefiles/mapfile-vers-product ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/os.hpp Changeset: 8bd1e4487c18 Author: iveresov Date: 2008-05-04 03:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8bd1e4487c18 Merge ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/runtime/globals.hpp Changeset: b5489bb705c9 Author: ysr Date: 2008-05-06 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b5489bb705c9 6662086: 6u4+, 7b11+: CMS never clears referents when -XX:+ParallelRefProcEnabled Summary: Construct the relevant CMSIsAliveClosure used by CMS during parallel reference processing with the correct span. It had incorrectly been constructed with an empty span, a regression introduced in 6417901. Reviewed-by: jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: e3729351c946 Author: iveresov Date: 2008-05-09 16:34 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e3729351c946 6697534: Premature GC and invalid lgrp selection with NUMA-aware allocator. Summary: Don't move tops of the chunks in ensure_parsibility(). Handle the situation with Solaris when a machine has a locality group with no memory. Reviewed-by: apetrusenko, jcoomes, ysr ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: f3de1255b035 Author: rasbold Date: 2008-05-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f3de1255b035 6603011: RFE: Optimize long division Summary: Transform long division by constant into multiply Reviewed-by: never, kvn ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 7cce9e4e0f7c Author: rasbold Date: 2008-05-09 05:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7cce9e4e0f7c Merge Changeset: 83c868b757c0 Author: jrose Date: 2008-05-14 00:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/83c868b757c0 6701024: SAJDI functionality is broken Summary: back out sa-related changes to 6652736, use concrete expressions for WKK names in the SA Reviewed-by: never, sundar ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 7a0a921a1a8c Author: rasbold Date: 2008-05-14 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7a0a921a1a8c Merge Changeset: e3d2692f8442 Author: trims Date: 2008-05-20 19:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e3d2692f8442 Merge Changeset: c14dab40ed9b Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c14dab40ed9b Added tag jdk7-b27 for changeset e3d2692f8442 ! .hgtags From lana.steuck at sun.com Fri Jun 6 06:52:29 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 06 Jun 2008 06:52:29 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: Added tag jdk7-b27 for changeset bafed478d67c Message-ID: <20080606065231.5DCDB2817C@hg.openjdk.java.net> Changeset: b996318955c0 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/b996318955c0 Added tag jdk7-b27 for changeset bafed478d67c ! .hgtags From lana.steuck at sun.com Fri Jun 6 06:53:26 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 06 Jun 2008 06:53:26 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: Added tag jdk7-b27 for changeset 27d8f42862c1 Message-ID: <20080606065328.DD60E28181@hg.openjdk.java.net> Changeset: eefcd5204500 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/eefcd5204500 Added tag jdk7-b27 for changeset 27d8f42862c1 ! .hgtags From lana.steuck at sun.com Fri Jun 6 06:54:30 2008 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 06 Jun 2008 06:54:30 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: Added tag jdk7-b27 for changeset a17265993253 Message-ID: <20080606065432.BED8228188@hg.openjdk.java.net> Changeset: 4ef4bd318569 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4ef4bd318569 Added tag jdk7-b27 for changeset a17265993253 ! .hgtags From Jim.A.Graham at Sun.COM Fri Jun 6 20:38:41 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Fri, 06 Jun 2008 13:38:41 -0700 Subject: [OpenJDK 2D-Dev] Rotation per-pixel accuracy In-Reply-To: <194f62550806051802i15c17d8i61254e2de3f0c607@mail.gmail.com> References: <194f62550806051516i5b5c04ewf9dda6fde449c365@mail.gmail.com> <194f62550806051802i15c17d8i61254e2de3f0c607@mail.gmail.com> Message-ID: <0K2200AZD6O5XEF0@fe-sfbay-10.sun.com> Good to hear it as it avoids some hard decisions. Per-pixel consistency is always the desired goal, but sometimes you have to look at what is possible to accomplish with the APIs we depend on and make some hard decisions. If it would take a "work around" technique that would take 100x as long in order to get per-pixel accuracy we start looking the other way, when it takes only 20% longer, we usually go for it and somewhere in between is a line we've never really drawn very well. And then there is always the possibility that a fresh approach will discover a new way to get per-pixel accuracy without any performance hits and so we sometimes stall on the hard question waiting for someone to have a flash of inspiration. :-( So, all in all, good to hear that we don't have to make a decision here... ;-) ...jim Clemens Eisserer wrote: > Hi again, > >> Are there rules that rendering has to be per-pixel consistent, with >> what should I compare to see wether my implementation works correct? > Sorry about the traffic ... it seems different rounding errors were > the cause for the different results, > the rotated text was drawn to the BI at the position 0/20, whereas it > was rendered at 100/100 to screen. > > With adjusted positions I get consistent rendering with rotation also. > > Sorry for the traffic :-/ > > Thanks, Clemens From linuxhippy at gmail.com Mon Jun 9 10:08:09 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 9 Jun 2008 12:08:09 +0200 Subject: [OpenJDK 2D-Dev] Question about AccelGlyphCache_AddGlyph Message-ID: <194f62550806090308j79e221f2pd8db289abbedc7f7@mail.gmail.com> Hello, 1. In AccelGlyphCache_AddGlyph the cache simply nulls the cellInfo-field, if the glyphinfo is removed from cache: // if the cell is occupied, notify the base glyph that its // cached version is about to be kicked out cellinfo->glyphInfo->cellInfo = NULL; Is this really always safe? Couldn't there be the case that glyphInfo has already been free'd, so that cellinfo->glyphInfo points to garbage? 2. Where can I set the logging-level used at build-time, so that the J2dTraceLn's will be compiled in? Thanks, Clemens From linuxhippy at gmail.com Mon Jun 9 12:03:43 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 9 Jun 2008 14:03:43 +0200 Subject: [OpenJDK 2D-Dev] Question about AccelGlyphCache_AddGlyph In-Reply-To: <194f62550806090308j79e221f2pd8db289abbedc7f7@mail.gmail.com> References: <194f62550806090308j79e221f2pd8db289abbedc7f7@mail.gmail.com> Message-ID: <194f62550806090503gd056c1eh7e7615d37ba1aea7@mail.gmail.com> Sorry again, already found where it is set to null :-/ lg Clemens 2008/6/9 Clemens Eisserer : > Hello, > > 1. In AccelGlyphCache_AddGlyph the cache simply nulls the > cellInfo-field, if the glyphinfo is removed from cache: > // if the cell is occupied, notify the base glyph that its > // cached version is about to be kicked out > cellinfo->glyphInfo->cellInfo = NULL; > > Is this really always safe? Couldn't there be the case that glyphInfo > has already been free'd, so that cellinfo->glyphInfo points to > garbage? > > 2. Where can I set the logging-level used at build-time, so that the > J2dTraceLn's will be compiled in? > > Thanks, Clemens > From Dmitri.Trembovetski at Sun.COM Mon Jun 9 14:51:34 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 09 Jun 2008 07:51:34 -0700 Subject: [OpenJDK 2D-Dev] Question about AccelGlyphCache_AddGlyph In-Reply-To: <194f62550806090503gd056c1eh7e7615d37ba1aea7@mail.gmail.com> References: <194f62550806090308j79e221f2pd8db289abbedc7f7@mail.gmail.com> <194f62550806090503gd056c1eh7e7615d37ba1aea7@mail.gmail.com> Message-ID: <484D4376.7000105@Sun.COM> Clemens Eisserer wrote: > Sorry again, already found where it is set to null :-/ > > lg Clemens > > 2008/6/9 Clemens Eisserer : >> Hello, >> >> 1. In AccelGlyphCache_AddGlyph the cache simply nulls the >> cellInfo-field, if the glyphinfo is removed from cache: >> // if the cell is occupied, notify the base glyph that its >> // cached version is about to be kicked out >> cellinfo->glyphInfo->cellInfo = NULL; >> >> Is this really always safe? Couldn't there be the case that glyphInfo >> has already been free'd, so that cellinfo->glyphInfo points to >> garbage? I guess you found that already. >> 2. Where can I set the logging-level used at build-time, so that the >> J2dTraceLn's will be compiled in? If you build a debug or fastdebug build, they're compiled in. J2dRlsTraceLns (Rls -> Release) are always compiled in, even in an optimized binaries, so don't use them in performance critical places. To enable, set J2D_TRACE_LEVEL=N (where is in 1-4), see src/share/native/sun/java2d/Trace.h/c Thanks, Dmitri >> >> Thanks, Clemens >> From linuxhippy at gmail.com Mon Jun 9 20:24:33 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 9 Jun 2008 22:24:33 +0200 Subject: [OpenJDK 2D-Dev] Problems with lcd-antialiased glyphs Message-ID: <194f62550806091324m9f8c27l9c3fc4c92e6d6111@mail.gmail.com> Hello, I started working on lcd-antialiased text now that grayscale and non-AA case works fine (http://linuxhippy.blogspot.com), however I experience some problems. I know the basics, and how it basically works - but I have a hard time understanding the insights. I am running a bit out of time, so I hope I don't bother anybody by asking on this list. XRender provides (only) component alpha for subpixel-antialiasing. The glyph is uploaded to an ARGB surface which is used as mask, each component acts as mask for its counterpart (http://anholt.livejournal.com/32058.html). I tried uploading the glyph-images produced by Java2D directly into an ARGB-glyphcache and using that, but the results are (of course) not intended: http://picasaweb.google.com/linuxhippy/Subpixel It seems the concepts do not match 100%, e.g. java2d does not provide an alpha-component. I tried setting the alpha-value manually but the results are really strange - for 100% alpha the background suddenly turns into yellow (with black used as src over white as background) And what is the LUT-Table for, why doesn't XRender need it? Has the XRender approach disavantages, and/or what is the cause the Java2D uses a more complex approach? Thank you for your patience and help, Clemens From Phil.Race at Sun.COM Wed Jun 11 18:18:41 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 11 Jun 2008 11:18:41 -0700 Subject: [OpenJDK 2D-Dev] Problems with lcd-antialiased glyphs In-Reply-To: <194f62550806091324m9f8c27l9c3fc4c92e6d6111@mail.gmail.com> References: <194f62550806091324m9f8c27l9c3fc4c92e6d6111@mail.gmail.com> Message-ID: <48501701.3000709@sun.com> Seems like this should work although 2D doesn't use an alpha component in the LCD software loops that's not an issue so long as alpha is 1 (ie 255). The equation you point to then reduces to the blend 2D does. Eg for the red component : dstR = srcR * maskR + (1-maskR) * dstR; where maskR is the LCD glyph cache component for the red subpixel. Your ARGB values for a solid pixel would look like 0xffffffff and for a transparent pixel 0xff000000. So if its all zeros then the above is dstR = (srcR * 0) + (1-0) * dstR; So it should leave dst unchanged (if not untouched). Since you are getting yellow where the glyph cache component will have all zeros, then clearly something has gone wrong, but I think its in the details rather than the concepts. Looking at the yellow RGB in your .png its 0xfefe00 I'm going to guess you have the alpha value set as zero and you've got something like RGBA when you should have ARGB, so the zero alpha component is being interpreted as the blue component. And "fe" instead of "ff" is a rounding error somewhere. I'd hope xrender bypasses doing the blend if the component is "00" or "ff", but maybe it doesn't. Verify your ARGB values that are uploaded are what you expect and in the correct order required. If they are then maybe its something in the xrender usage. The LUTs are used as pre and post conversions on the components of the destination. They apply an inverse gamma adjustment on the component that is read from the device, and a gamma adjustment on the results before they are written back. If Xrender does something like this at all, then it should have some way for you to specify the gamma value. If it doesn't then you'll either have to accept what it does, or if the results aren't ideal, then Xrender can't be used at all for this case. The effect of this is to increase or decrease the contrast, and JDK needs this to be compatible with Windows behaviours. So if you don't or can't apply it then the text rendered will be different in contrast between the xrender and the other pipelines, but has no bearing on the bigger problems you are seeing. -Phil. Clemens Eisserer wrote: > Hello, > > I started working on lcd-antialiased text now that grayscale and > non-AA case works fine (http://linuxhippy.blogspot.com), however I > experience some problems. > I know the basics, and how it basically works - but I have a hard time > understanding the insights. > I am running a bit out of time, so I hope I don't bother anybody by > asking on this list. > > XRender provides (only) component alpha for subpixel-antialiasing. > The glyph is uploaded to an ARGB surface which is used as mask, each > component acts as mask for its counterpart > (http://anholt.livejournal.com/32058.html). > > I tried uploading the glyph-images produced by Java2D directly into an > ARGB-glyphcache and using that, but the results are (of course) not > intended: > http://picasaweb.google.com/linuxhippy/Subpixel > It seems the concepts do not match 100%, e.g. java2d does not provide > an alpha-component. > I tried setting the alpha-value manually but the results are really > strange - for 100% alpha the background suddenly turns into yellow > (with black used as src over white as background) > And what is the LUT-Table for, why doesn't XRender need it? > Has the XRender approach disavantages, and/or what is the cause the > Java2D uses a more complex approach? > > Thank you for your patience and help, Clemens From Ben.Loud at rlmgroup.com.au Thu Jun 12 10:21:56 2008 From: Ben.Loud at rlmgroup.com.au (Ben Loud) Date: Thu, 12 Jun 2008 19:51:56 +0930 Subject: [OpenJDK 2D-Dev] Font Metrics in OpenJDK vs Sun JDK Message-ID: <993F95453DDC3643B662C62D8D2D4ED56EF5F2@srv013.rlmgroup.com.au> 2D Folk, Since working with OpenJDK, I've notice that text just doesnt look right. I made a simple comparison between Sun's JDK6 and OpenJDK see: http://benloud.com/fonts.png You can see there are clearly significant differences in the horizontal character spacing, particularly noticable in "Beagle" and "Spirit", and also the heights are different. I also compared the font metrics of a string: For Tahoma, plain, 11pt, "The Quick Brown Fox Jumped Over The Lazy Dog." AWT FontMetrics: Ascent Descent Leading Height String Width Sun JDK: 11 3 0 14 241 OpenJDK: 11 3 -1 13 265 TextLayout: Ascent Descent Leading Advance Bounds Sun JDK: 11.005371 2.2719727 0.0 240.0 [x=0.0,y=-8.359375,w=238.29688,h=10.625] OpenJDK: 11.0 3.0 -1.0 264.0 [x=0.0,y=0.0,w=263.29688,h=18.453125] Again you can see there are significant differences, particularly in the advances and bounds, and the -1 for leading is a bit odd. Will it be possible to get metrics that are consistent with Suns JDK? Because right now, Swing apps on OpenJDK look quite wrong to me. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Thu Jun 12 11:53:11 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 12 Jun 2008 13:53:11 +0200 Subject: [OpenJDK 2D-Dev] Problems with lcd-antialiased glyphs In-Reply-To: <48501701.3000709@sun.com> References: <194f62550806091324m9f8c27l9c3fc4c92e6d6111@mail.gmail.com> <48501701.3000709@sun.com> Message-ID: <194f62550806120453n502c9be8n2cb7b51740165565@mail.gmail.com> Hi Phil, > Verify your ARGB values that are uploaded are what you expect > and in the correct order required. > If they are then maybe its something in the xrender usage. Thanks a lot for looking into this, you were right of course and the values were in wrong order. It seems to be BGRA, however the Xrender-docs mention the data has to be in the format of a ZPIXMAP, so I guess I am doing it wrong anyway, and I should be using an XImage for uploading instead of self-allocated buffers. I guess I am just doing manual byte-swapping here ;) It now looks quite ok: http://picasaweb.google.com/linuxhippy/Subpixel , but there is a difference, maybe because of the gamma adjustments. > The LUTs are used as pre and post conversions on the components > of the destination. They apply an inverse gamma adjustment on > the component that is read from the device, and a gamma adjustment > on the results before they are written back. > If Xrender does something like this at all, then it should have > some way for you to specify the gamma value. If it doesn't then > you'll either have to accept what it does, or if the results aren't > ideal, then Xrender can't be used at all for this case. > The effect of this is to increase or decrease the contrast, and > JDK needs this to be compatible with Windows behaviours. > So if you don't or can't apply it then the text rendered will be different > in contrast between the xrender and the other pipelines, but has > no bearing on the bigger problems you are seeing. Well maybe there are some tricks to get it done right, but the XRender-Api does not (at least not explicitly) mention anything like contrast or gamma, I'll ask on the xorg-list maybe there are other ways. I may have misunderstood the blog here (http://anholt.livejournal.com/32058.html), but if they optimize subpixel-text with just two composition operations, is there even any room for gamma adjustment? Thanks a lot, Clemens From Phil.Race at Sun.COM Thu Jun 12 14:19:06 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 12 Jun 2008 07:19:06 -0700 Subject: [OpenJDK 2D-Dev] Font Metrics in OpenJDK vs Sun JDK In-Reply-To: <993F95453DDC3643B662C62D8D2D4ED56EF5F2@srv013.rlmgroup.com.au> References: <993F95453DDC3643B662C62D8D2D4ED56EF5F2@srv013.rlmgroup.com.au> Message-ID: <4851305A.8070409@sun.com> The -1 for leading is probably a bug somewhere. Maybe you can look into it The difference in advance may be due to the absence of byte code hinting in the freetype found by OpenJDK. Since you have Tahoma I have to assume you are running on windows and built your own freetype, rather than using the one on the O/S. If you build freetype with hinting for testing purposes then the difference may be much less. -phil. Ben Loud wrote: > 2D Folk, > > Since working with OpenJDK, I've notice that text just doesnt look > right. I made a simple comparison between Sun's JDK6 and OpenJDK see: > http://benloud.com/fonts.png You can see there are clearly significant > differences in the horizontal character spacing, particularly > noticable in "Beagle" and "Spirit", and also the heights are > different. I also compared the font metrics of a string: > > For Tahoma, plain, 11pt, "The Quick Brown Fox Jumped Over The Lazy Dog." > AWT FontMetrics: > Ascent Descent Leading Height String Width > Sun JDK: 11 3 0 14 241 > OpenJDK: 11 3 -1 13 265 > > TextLayout: > Ascent Descent Leading Advance Bounds > Sun JDK: 11.005371 2.2719727 0.0 240.0 > [x=0.0,y=-8.359375,w=238.29688,h=10.625] > OpenJDK: 11.0 3.0 -1.0 264.0 > [x=0.0,y=0.0,w=263.29688,h=18.453125] > > Again you can see there are significant differences, particularly in > the advances and bounds, and the -1 for leading is a bit odd. > > Will it be possible to get metrics that are consistent with Suns JDK? > Because right now, Swing apps on OpenJDK look quite wrong to me. > > Thanks. > > From phil.race at sun.com Thu Jun 12 20:25:31 2008 From: phil.race at sun.com (phil.race at sun.com) Date: Thu, 12 Jun 2008 20:25:31 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties Message-ID: <20080612202626.50CE4289A6@hg.openjdk.java.net> Changeset: f0ede391c615 Author: prr Date: 2008-06-12 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f0ede391c615 6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties Reviewed-by: tdv, igor ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java + src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/native/sun/awt/fontconfig.h ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java From roman at kennke.org Thu Jun 12 21:40:16 2008 From: roman at kennke.org (Roman Kennke) Date: Thu, 12 Jun 2008 23:40:16 +0200 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties In-Reply-To: <20080612202626.50CE4289A6@hg.openjdk.java.net> References: <20080612202626.50CE4289A6@hg.openjdk.java.net> Message-ID: <1213306816.30214.4.camel@moonlight> Hi there, I don't know yet about the content of the patch, but I think it might be interesting to know that Mario is working on a pure Java implementation of fontconfig right now. Might be useful when it's finished. /Roman Am Donnerstag, den 12.06.2008, 20:25 +0000 schrieb phil.race at sun.com: > Changeset: f0ede391c615 > Author: prr > Date: 2008-06-12 13:17 -0700 > URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f0ede391c615 > > 6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties > Reviewed-by: tdv, igor > > ! make/sun/headless/mapfile-vers > ! make/sun/xawt/mapfile-vers > ! src/share/classes/sun/awt/FontConfiguration.java > ! src/share/classes/sun/font/FontManager.java > ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java > ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java > + src/solaris/classes/sun/font/FcFontConfiguration.java > ! src/solaris/native/sun/awt/fontconfig.h > ! src/solaris/native/sun/awt/fontpath.c > ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java > -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From roxton at gmail.com Fri Jun 13 15:34:53 2008 From: roxton at gmail.com (Adam Augusta) Date: Fri, 13 Jun 2008 11:34:53 -0400 Subject: [OpenJDK 2D-Dev] Basic Color Management Message-ID: <65ef85890806130834h3b68b404je5476b5d41e3902f@mail.gmail.com> I need to do RGB->RGB, RGB->CMYK, CMYK->RGB conversion using source and destination ICC profiles and rendering intents. As far as I can tell, there's no way to do this directly in Java2D or JAI. My understanding is that there are some issues with RGB->CMYK conversion, and while the underlying CMM seems to support rendering intents on their transforms, none of that is exposed in the documented API. I'm about to create a glue layer with JNI and Little CMS, but I wanted to see if you had any insight into how I can meet my requirements in a pure Java platform. -Adam PS: The Java2D website directed me here: http://java.sun.com/products/java-media/2D/mail/java2d-comments.html But when I submitted a comment, I got an e-mail saying the alias is no longer in use, and that I should use this list instead. From Ben.Loud at rlmgroup.com.au Fri Jun 13 16:39:01 2008 From: Ben.Loud at rlmgroup.com.au (Ben Loud) Date: Sat, 14 Jun 2008 02:09:01 +0930 Subject: [OpenJDK 2D-Dev] Font Metrics in OpenJDK vs Sun JDK References: <993F95453DDC3643B662C62D8D2D4ED56EF5F2@srv013.rlmgroup.com.au> <4851305A.8070409@sun.com> Message-ID: <993F95453DDC3643B662C62D8D2D4ED56EF5F3@srv013.rlmgroup.com.au> Thanks Phil! You were of course, completely right. I rebuilt FreeType with the bytecode interpreter enabled and now both the AWT FontMetrics string width and the TextLayout.getBounds() width match the Sun JDK exactly (and I really mean EXACTLY). The leading is still -1 though. In fact, if I get a LineMetrics from the Font, in the Sun JDK I get these: Height: 13.277344 Ascent: 11.005371 Descent: 2.2719727 Leading: -0.0 But in OpenJDK I get: Height: 13.0 Ascent: 11.0 Descent: 3.0 Leading: -1.0 I had a go at looking in to it myself but didnt get very far. I stuck a breakpoint in the StrikeMetrics constructor and could see that it was indeed getting those values. I also looked at the native code for FreetypeFontScaler.getFontMetricsNative(), and it seems correct as best as I can tell, but I havent yet figured out how to debug native JDK code. Still, its clear that the -1 is just the result of 13+(-11)-3, which is the right way to calculate it. The problem is that for some reason we're getting whole numbers for these metrics, and not even correctly rounded numbers (2.27 vs 3.0 for the descent). I'm stumped as to why. Also there an issue with the TextLayout bounds, in the Sun JDK, my TextLayout test gives the string the bounds: [x=0.0,y=-8.359375,w=238.29688,h=10.625] but in OpenJDK I get: [x=0.0,y=0.0,w=238.29688,h=18.453125] Notice that OpenJDK has given y=0, but it should be relative to the baseline. The height is also very wrong, although its suspicously close to h-y (taking the expected values from the Sun JDK). I'll keep digging and see if I can trace how thats calculated. ________________________________ From: Phil Race [mailto:Phil.Race at Sun.COM] Sent: Thu 12/06/2008 23:49 To: Ben Loud Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Font Metrics in OpenJDK vs Sun JDK The -1 for leading is probably a bug somewhere. Maybe you can look into it The difference in advance may be due to the absence of byte code hinting in the freetype found by OpenJDK. Since you have Tahoma I have to assume you are running on windows and built your own freetype, rather than using the one on the O/S. If you build freetype with hinting for testing purposes then the difference may be much less. -phil. Ben Loud wrote: > 2D Folk, > > Since working with OpenJDK, I've notice that text just doesnt look > right. I made a simple comparison between Sun's JDK6 and OpenJDK see: > http://benloud.com/fonts.png You can see there are clearly significant > differences in the horizontal character spacing, particularly > noticable in "Beagle" and "Spirit", and also the heights are > different. I also compared the font metrics of a string: > > For Tahoma, plain, 11pt, "The Quick Brown Fox Jumped Over The Lazy Dog." > AWT FontMetrics: > Ascent Descent Leading Height String Width > Sun JDK: 11 3 0 14 241 > OpenJDK: 11 3 -1 13 265 > > TextLayout: > Ascent Descent Leading Advance Bounds > Sun JDK: 11.005371 2.2719727 0.0 240.0 > [x=0.0,y=-8.359375,w=238.29688,h=10.625] > OpenJDK: 11.0 3.0 -1.0 264.0 > [x=0.0,y=0.0,w=263.29688,h=18.453125] > > Again you can see there are significant differences, particularly in > the advances and bounds, and the -1 for leading is a bit odd. > > Will it be possible to get metrics that are consistent with Suns JDK? > Because right now, Swing apps on OpenJDK look quite wrong to me. > > Thanks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitri.Trembovetski at Sun.COM Fri Jun 13 17:26:53 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 13 Jun 2008 10:26:53 -0700 Subject: [OpenJDK 2D-Dev] Basic Color Management In-Reply-To: <65ef85890806130834h3b68b404je5476b5d41e3902f@mail.gmail.com> References: <65ef85890806130834h3b68b404je5476b5d41e3902f@mail.gmail.com> Message-ID: <4852ADDD.9020001@Sun.COM> Have you looked at java.awt.color package? java.awt.BufferedImage has a ColorModel with ColorSpace describing how to interpret the colors, and which may be defined by ICC profile: http://java.sun.com/javase/6/docs/api/java/awt/image/ColorModel.html http://java.sun.com/javase/6/docs/api/java/awt/color/ColorSpace.html Thanks, Dmitri Adam Augusta wrote: > I need to do RGB->RGB, RGB->CMYK, CMYK->RGB conversion using source > and destination ICC profiles and rendering intents. As far as I can > tell, there's no way to do this directly in Java2D or JAI. My > understanding is that there are some issues with RGB->CMYK conversion, > and while the underlying CMM seems to support rendering intents on > their transforms, none of that is exposed in the documented API. > > I'm about to create a glue layer with JNI and Little CMS, but I wanted > to see if you had any insight into how I can meet my requirements in a > pure Java platform. > > -Adam > > PS: The Java2D website directed me here: > http://java.sun.com/products/java-media/2D/mail/java2d-comments.html > > But when I submitted a comment, I got an e-mail saying the alias is no > longer in use, and that I should use this list instead. From roxton at gmail.com Fri Jun 13 17:34:09 2008 From: roxton at gmail.com (Adam Augusta) Date: Fri, 13 Jun 2008 13:34:09 -0400 Subject: [OpenJDK 2D-Dev] Basic Color Management In-Reply-To: <4852ADDD.9020001@Sun.COM> References: <65ef85890806130834h3b68b404je5476b5d41e3902f@mail.gmail.com> <4852ADDD.9020001@Sun.COM> Message-ID: <65ef85890806131034u17e85939j632698e251d5634e@mail.gmail.com> On Fri, Jun 13, 2008 at 1:26 PM, Dmitri Trembovetski wrote: > java.awt.BufferedImage has a ColorModel with > ColorSpace describing how to interpret the > colors, and which may be defined by ICC profile: > http://java.sun.com/javase/6/docs/api/java/awt/image/ColorModel.html > http://java.sun.com/javase/6/docs/api/java/awt/color/ColorSpace.html By the spec, profiles support four rendering intents, absolute colorimetric, relative colorimetric, perceptual, and saturation. You can define a ColorSpace by an ICC profile, but there's no opportunity to specify a rendering intent. (I know Batik extended ColorSpace to support a rendering intent, but Batik is an SVG library.) Thanks for your response. -Adam From Ben.Loud at rlmgroup.com.au Sat Jun 14 03:13:02 2008 From: Ben.Loud at rlmgroup.com.au (Ben Loud) Date: Sat, 14 Jun 2008 12:43:02 +0930 Subject: [OpenJDK 2D-Dev] Basic Color Management References: <65ef85890806130834h3b68b404je5476b5d41e3902f@mail.gmail.com><4852ADDD.9020001@Sun.COM> <65ef85890806131034u17e85939j632698e251d5634e@mail.gmail.com> Message-ID: <993F95453DDC3643B662C62D8D2D4ED56EF5F4@srv013.rlmgroup.com.au> I know what you mean. I would like to see more comprehensive support for color management in the JDK. Right now all we get is to/fromXYZ() which is defined to be done using relative colorimetric, and to/fromsRGB, which is defined to use perceptual, but these only work on float arrays, and there's no support for saturation or absolute colorimetric, and no way to create an optimized transform between profiles. It wouldnt be difficult to add, of course the capability is all there in littlecms and exists to some extent in sun.java2d.cmm.*, perhaps it will be considered for a future JDK version. ________________________________ From: 2d-dev-bounces at openjdk.java.net on behalf of Adam Augusta Sent: Sat 14/06/2008 03:04 To: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Basic Color Management On Fri, Jun 13, 2008 at 1:26 PM, Dmitri Trembovetski wrote: > java.awt.BufferedImage has a ColorModel with > ColorSpace describing how to interpret the > colors, and which may be defined by ICC profile: > http://java.sun.com/javase/6/docs/api/java/awt/image/ColorModel.html > http://java.sun.com/javase/6/docs/api/java/awt/color/ColorSpace.html By the spec, profiles support four rendering intents, absolute colorimetric, relative colorimetric, perceptual, and saturation. You can define a ColorSpace by an ICC profile, but there's no opportunity to specify a rendering intent. (I know Batik extended ColorSpace to support a rendering intent, but Batik is an SVG library.) Thanks for your response. -Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Sat Jun 14 06:25:10 2008 From: aph at redhat.com (Andrew Haley) Date: Sat, 14 Jun 2008 07:25:10 +0100 Subject: [OpenJDK 2D-Dev] Basic Color Management In-Reply-To: <993F95453DDC3643B662C62D8D2D4ED56EF5F4@srv013.rlmgroup.com.au> References: <65ef85890806130834h3b68b404je5476b5d41e3902f@mail.gmail.com><4852ADDD.9020001@Sun.COM> <65ef85890806131034u17e85939j632698e251d5634e@mail.gmail.com> <993F95453DDC3643B662C62D8D2D4ED56EF5F4@srv013.rlmgroup.com.au> Message-ID: <48536446.3070000@redhat.com> Ben Loud wrote: > I know what you mean. I would like to see more comprehensive support > for color management in the JDK. Right now all we get is > to/fromXYZ() which is defined to be done using relative > colorimetric, and to/fromsRGB, which is defined to use perceptual, > but these only work on float arrays, and there's no support for > saturation or absolute colorimetric, and no way to create an > optimized transform between profiles. I don't understand why you say there's no way to create an optimized transform between profiles, since this is exactly what java.awt.image.ColorConvertOp does. > It wouldnt be difficult to add, of course the capability is all > there in littlecms and exists to some extent in sun.java2d.cmm.*, > perhaps it will be considered for a future JDK version. Yes. This seems like a fairly modest Java spec enhancement. Adam Augusta wrote: > By the spec, profiles support four rendering intents, absolute > colorimetric, relative colorimetric, perceptual, and saturation. You > can define a ColorSpace by an ICC profile, but there's no opportunity > to specify a rendering intent. > > (I know Batik extended ColorSpace to support a rendering intent, but > Batik is an SVG library.) If you look at http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/ext/awt/color/ICCColorSpaceExt.html you'll see it doesn't work anyway. For it really to be useful, ColorConvertOp(ICC_Profile[] profiles, RenderingHints hints) would have to know about ICCColorSpaceExt. Andrew. From roxton at gmail.com Mon Jun 16 23:49:53 2008 From: roxton at gmail.com (Adam Augusta) Date: Mon, 16 Jun 2008 19:49:53 -0400 Subject: [OpenJDK 2D-Dev] Writing a CMYK file Message-ID: <65ef85890806161649s177e072fh4e6c32a657a41c24@mail.gmail.com> Without too much difficulty, I managed to convert my sRGB image into CMYK with my profile by using JNA to utilize Little CMS. I took the resulting samples, sanity-checked them, and then stuffed them into a WritableRaster with a PixelInterleavedSampleModel. I figured that from here it would be a snap to save to a CMYK image file, perhaps in TIFF format, but I've been poring through Image I/O and I don't see how to do it. Can anyone help? -Adam From roxton at gmail.com Tue Jun 17 16:27:19 2008 From: roxton at gmail.com (Adam Augusta) Date: Tue, 17 Jun 2008 12:27:19 -0400 Subject: [OpenJDK 2D-Dev] Writing a CMYK file In-Reply-To: <65ef85890806161649s177e072fh4e6c32a657a41c24@mail.gmail.com> References: <65ef85890806161649s177e072fh4e6c32a657a41c24@mail.gmail.com> Message-ID: <65ef85890806170927u4a309503g14c44600bb46898@mail.gmail.com> I just wanted to share my prototyped solution to this. The answer was staring me in the face, but it may prove useful to someone else. final DataBufferByte buffer = new DataBufferByte(myCmykByteArray, myCmykByteArray.length); final WritableRaster raster = Raster.createInterleavedRaster(buffer, imageWidth, imageHeight, imageWidth*4, 4, new int[] {0, 1, 2, 3}, new Point(0,0)); final ICC_Profile profileCmyk; try { profileCmyk = ICC_Profile.getInstance("c:\\myprofile.icc"); } catch (IOException e) { ... } final ICC_ColorSpace colorSpaceCmyk = new ICC_ColorSpace(profileCmyk); final ColorModel model = new ComponentColorModel(colorSpaceCmyk, new int[] {8,8,8,8}, false, false, ColorModel.OPAQUE, DataBuffer.TYPE_BYTE); BufferedImage bufferedImage = new BufferedImage(model, raster, false, null); final File output = new File("c:\\fileoutput.tif"); final FileImageOutputStream outputStream; try { outputStream = new FileImageOutputStream(output); } catch (IOException e) { ... } final ImageWriter writer = ImageIO.getImageWritersByMIMEType("image/tiff").next(); writer.setOutput(outputStream); try { writer.write(bufferedImage); } catch (IOException e) { throw new RuntimeException("Oh noes", e); } -Adam From steven.loomis at sun.com Wed Jun 18 01:48:11 2008 From: steven.loomis at sun.com (steven.loomis at sun.com) Date: Wed, 18 Jun 2008 01:48:11 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6711377: test/java/awt/font/TextLayout/VisibleAdvance.java missing GPL Message-ID: <20080618014836.B506028D01@hg.openjdk.java.net> Changeset: 9fae0ea75985 Author: srl Date: 2008-06-17 18:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9fae0ea75985 6711377: test/java/awt/font/TextLayout/VisibleAdvance.java missing GPL Reviewed-by: igor, prr ! test/java/awt/font/TextLayout/VisibleAdvance.java From gust at nouveausystems.com Wed Jun 18 12:05:25 2008 From: gust at nouveausystems.com (Philip Gust) Date: Wed, 18 Jun 2008 05:05:25 -0700 Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double Message-ID: <20080618120355.557082329040@mail.openjdk.java.net> Jim, Sometimes it's convenient to work with size and origin. Our graphics system adds some operations on Rectangle2D.Float/Double including the ability to construct one using a Point2D and a Dimension2D, and the ability to ask for size and origin of a Rectangle2D.Float/Double separate from bounds. We had to implement our own equivalent to Dimension2D.Float/Double because one wasn't provided in Java2D. I'd also suggest adding the constructors and the size/origin enquiry functions as appropriate to Java2D shape classes. We find them to be very useful. > Hi Ben, > > Since it was only used for doing component layouts (in integer space), > it wasn't really needed anywhere, though I suppose that this begs the > question as to why Dimension2D was created in the first place. > (scratches head, doesn't remember). > >Do you have a use case for it now? > > ...jim > > LOUD, Ben wrote: >> I was just wondering, is there any reason why there are no Float and Double subclasses of Dimension2D? I'm suprised such a simple thing was never included. >> >> Thats all. Thanks! >> >> >> "Warning: >> The information contained in this email and any attached files is >> confidential to BAE Systems Australia. If you are not the intended >> recipient, any use, disclosure or copying of this email or any >> attachments is expressly prohibited. If you have received this email >> in error, please notify us immediately. VIRUS: Every care has been >> taken to ensure this email and its attachments are virus free, >> however, any loss or damage incurred in using this email is not the >> sender's responsibility. It is your responsibility to ensure virus >> checks are completed before installing any data sent in this email to >> your computer." >> >> Philip Gust Nouveau Systems, Inc. phone: +1 650 961-7992 fax: +1 520 843-7217 mailto: gust at NouveauSystems.com Nouveau Systems products seamlessly integrate collaboration, information management, processes automation, and capture of mission-critical knowledge. To learn how Nouveau Systems products can help your organization drive innovation, visit: http://www.NouveauSystems.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From devel at thanlwinsoft.org Thu Jun 19 20:14:23 2008 From: devel at thanlwinsoft.org (Keith Stribley) Date: Thu, 19 Jun 2008 21:14:23 +0100 Subject: [OpenJDK 2D-Dev] Kerning and Ligatures using Layout Engine Message-ID: <485ABE1F.70601@thanlwinsoft.org> I am interested in getting clig,liga,mark,mkmk,kern OpenType tables to be processed by the OpenJDK layout engine for the Myanmar code block. Currently Unicode 5.1 Myanmar fonts cannot be used with Java AWT/Swing. I noticed that the layout engine code in OpenJDK is essentially an old version of the ICU layout engine and ICU is capable of rendering Myanmar Unicode 5.1 compliant fonts such as Myanmar3 and Padauk correctly. The first step was to make sun.font.FontManager.isComplexCharCode() return true for the Myanmar range. However, I then needed to modify the sun.font.GlyphLayout.EngineRecord. This has an eflags fields which is passed to ICU. I'm not quite sure why 0x4 is used as the value when there are marks, I believe it corresponds to "no canonical processing", though I don't know why that is needed. More seriously, this does not trigger ICU kerning or ligatures. this.eflags needs to be set to 0x3 for this. 1=kerning, 2=ligatures (see http://www.icu-project.org/apiref/icu4c/classLayoutEngine.html#cee4ea27f3211be215ea9b9bd3a91c32) My question is therefore, why aren't kerning and ligatures turned on, at least for complex scripts. I've noticed that with Latin text that if you set TextAttribute.KERNING and TextAttribute.LIGATURES ligatures work for non-complex text e.g. ffi with DoulosSIL, but if you have a mark in the text, ligatures stop working, though the mark attaches correctly. I would therefore have thought that there is little to be lost from using eflags = 0x3 in all the cases where eflags is set. I guess there might be a slight speed drop, but is it still significant these days? Is there a specific reason why kerning and ligatures haven't been enabled in ICU when used in the JDK? Does it have some unexpected side affect? Currently EngineRecord only sets eflags for NON_SPACING_MARK, ENCLOSING_MARK, COMBINING_SPACING_MARK. At the moment, this isn't sufficient for Burmese since the character properties in the jdk haven't been updated to Unicode 5.1, hence I enabled it for the whole code block in my test build. For reference, Myanmar fonts are available at: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=Padauk http://myanmarnlpteam.blogspot.com/2007/08/download-links.html http://www.mymyanmar.net/2g/ (Another Myanmar font, Parabaik uses OpenType rlig, which ICU doesn't process for this code block without further code changes). There is a possible patch below, which displays Unicode 5.1 Myanmar correctly with Padauk, MyMyanmar Unicode and Myanmar3 fonts when used with the methods TextLayout.draw, drawString and drawChars in Font2DTest. Some attached marks get lost with Padauk using TextLayout.getOutline+draw. I would appreciate feedback on whether to submit this as a patch purely for the Myanmar script or whether eflags should be changed more generally. Regards, Keith Stribley --- ./jdk/src/share/classes/sun/font/GlyphLayout.java.orig 2008-05-29 15:01:33.000000000 +0100 +++ ./jdk/src/share/classes/sun/font/GlyphLayout.java 2008-05-29 23:13:26.000000000 +0100 @@ -644,11 +644,15 @@ ch = toCodePoint((char)ch,_textRecord.text[++i]); // inc } int gc = getType(ch); + if (script == 28) { // Myanmar - see LEScripts.h + this.eflags = 0x3;// 1=kerning, 2=ligatures + break; + } if (gc == NON_SPACING_MARK || gc == ENCLOSING_MARK || gc == COMBINING_SPACING_MARK) { // could do range test also - this.eflags = 0x4; + this.eflags = 0x4; // 4 = no canonical processing, but would 0x3 be better? break; } } --- ./jdk/src/share/classes/sun/font/FontManager.java.orig 2008-05-28 12:46:03.000000000 +0100 +++ ./jdk/src/share/classes/sun/font/FontManager.java 2008-05-29 21:33:31.000000000 +0100 @@ -3594,6 +3594,12 @@ // 0E00 - 0E7F if Thai, assume shaping for vowel, tone marks return true; } + else if (code < 0x1000) { + return false; + } + else if (code < 0x10A0) { // 1000-109F Myanmar + return true; + } else if (code < 0x1780) { return false; } From jennifer.godinez at sun.com Mon Jun 23 20:40:33 2008 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 23 Jun 2008 20:40:33 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6708509: print dialog is not displayed when default paper is custom Message-ID: <20080623204047.1EDFA281AF@hg.openjdk.java.net> Changeset: 5755fe417a12 Author: jgodinez Date: 2008-06-23 13:00 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5755fe417a12 6708509: print dialog is not displayed when default paper is custom Reviewed-by: tdv, prr ! src/windows/native/sun/windows/awt_PrintJob.cpp + test/java/awt/print/PrinterJob/PrintAWTImage.java + test/java/awt/print/PrinterJob/duke.gif From Phil.Race at Sun.COM Tue Jun 24 18:53:44 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 24 Jun 2008 11:53:44 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group Message-ID: <486142B8.9010705@sun.com> I hereby nominate Doug Felt as a member of the OpenJDK 2D group. Doug has made significant contributions to the Java 2D text APIs and their implementation starting in 1997 and in every release from JDK 1.2 up to and including JDK 6. As part of the Taligent (later IBM) team he helped to create the advanced text APIs including those in the java.awt.font package, and as part of the ICU team directly handled integrating bidi text and ICU opentype layout in JDK. Doug has also been a JavaOne speaker on the JDK's text APIs and implementation. Please cast your vote by replying publicly to this message with either Vote: yes or Vote: no as the first line of the message body. You may indicate the reason for your vote, if you wish, on subsequent lines. This is optional and not required. Votes must be cast in the open; votes sent as private replies will not be counted. Only current members of the 2D Group are eligible to vote. Votes are due by midnight UTC Sun 29th June 2008 after which time the votes will be tallied and reported to this list . -Phil. From kirillcool at yahoo.com Tue Jun 24 18:56:23 2008 From: kirillcool at yahoo.com (Kirill Grouchnikov) Date: Tue, 24 Jun 2008 11:56:23 -0700 (PDT) Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group Message-ID: <119075.80355.qm@web52911.mail.re2.yahoo.com> yes ----- Original Message ---- From: Phil Race To: 2d-dev <2d-dev at openjdk.java.net> Sent: Tuesday, June 24, 2008 11:53:44 AM Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group I hereby nominate Doug Felt as a member of the OpenJDK 2D group. Doug has made significant contributions to the Java 2D text APIs and their implementation starting in 1997 and in every release from JDK 1.2 up to and including JDK 6. As part of the Taligent (later IBM) team he helped to create the advanced text APIs including those in the java.awt.font package, and as part of the ICU team directly handled integrating bidi text and ICU opentype layout in JDK. Doug has also been a JavaOne speaker on the JDK's text APIs and implementation. Please cast your vote by replying publicly to this message with either Vote: yes or Vote: no as the first line of the message body. You may indicate the reason for your vote, if you wish, on subsequent lines. This is optional and not required. Votes must be cast in the open; votes sent as private replies will not be counted. Only current members of the 2D Group are eligible to vote. Votes are due by midnight UTC Sun 29th June 2008 after which time the votes will be tallied and reported to this list . -Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Phil.Race at Sun.COM Tue Jun 24 19:02:49 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 24 Jun 2008 12:02:49 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <486144D9.7090008@sun.com> Vote: yes -phil. Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from > JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Jennifer.Godinez at Sun.COM Tue Jun 24 19:14:14 2008 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Tue, 24 Jun 2008 12:14:14 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <48614786.4020005@Sun.COM> Vote: yes Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Christopher.Campbell at Sun.COM Tue Jun 24 19:31:56 2008 From: Christopher.Campbell at Sun.COM (Chris Campbell) Date: Tue, 24 Jun 2008 12:31:56 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <533BFB70-944F-44C3-847B-1E7BD4D85C85@sun.com> Vote: yes On Jun 24, 2008, at 11:53 AM, Phil Race wrote: > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from > JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time > the votes will be tallied and reported to this list . > > -Phil. From Dmitri.Trembovetski at Sun.COM Tue Jun 24 19:35:31 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 24 Jun 2008 12:35:31 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <48614C83.8000106@Sun.COM> vote: yes Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Igor.Nekrestyanov at Sun.COM Tue Jun 24 19:59:19 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Tue, 24 Jun 2008 23:59:19 +0400 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <48615217.4000602@sun.com> vote: yes -igor Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from > JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Jim.A.Graham at Sun.COM Tue Jun 24 21:39:40 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 24 Jun 2008 14:39:40 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <0K2Z0034ULH72FH0@fe-sfbay-09.sun.com> Vote: yes Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Phil.Race at Sun.COM Tue Jun 24 23:50:54 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 24 Jun 2008 16:50:54 -0700 Subject: [OpenJDK 2D-Dev] Kerning and Ligatures using Layout Engine In-Reply-To: <485ABE1F.70601@thanlwinsoft.org> References: <485ABE1F.70601@thanlwinsoft.org> Message-ID: <4861885E.2050709@sun.com> I can take a stab at this but it probably needs the ICU developer to confirm what's happening there. Keith Stribley wrote: > I am interested in getting clig,liga,mark,mkmk,kern OpenType tables to Those are not tables. Those are features in the OpenType GSUB and GPOS tables. > be processed by the OpenJDK layout engine for the Myanmar code block. > Currently Unicode 5.1 Myanmar fonts cannot be used with Java AWT/Swing. > > I noticed that the layout engine code in OpenJDK is essentially an old > version of the ICU layout engine and ICU is capable of rendering Myanmar > Unicode 5.1 compliant fonts such as Myanmar3 and Padauk correctly. FYI: it was "current" at the point in JDK 6 development when it was integrated. JDK 7 will get an updated version in due course. > > The first step was to make sun.font.FontManager.isComplexCharCode() > return true for the Myanmar range. However, I then needed to modify the > sun.font.GlyphLayout.EngineRecord. This has an eflags fields which is > passed to ICU. > I'm not quite sure why 0x4 is used as the value when there are marks, I > believe it corresponds to "no canonical processing", though I don't know > why that is needed. I think you have this backwards. 0x4 means do canonical processing and its there for performance. ie if its not set then we can skip a lot of work. I don't recall (at all) how much that was but I suspect it was significant. > More seriously, this does not trigger ICU kerning or > ligatures. > this.eflags needs to be set to 0x3 for this. 1=kerning, 2=ligatures (see > http://www.icu-project.org/apiref/icu4c/classLayoutEngine.html#cee4ea27f3211be215ea9b9bd3a91c32) > No, I believe that comes from _typo_flags. > My question is therefore, why aren't kerning and ligatures turned on, at > least for complex scripts. I've noticed that with Latin text that if you > set TextAttribute.KERNING and TextAttribute.LIGATURES ligatures work for > non-complex text e.g. ffi with DoulosSIL, but if you have a mark in the > text, ligatures stop working, though the mark attaches correctly. I > would therefore have thought that there is little to be lost from using > eflags = 0x3 in all the cases where eflags is set. I guess there might > be a slight speed drop, but is it still significant these days? Is there > a specific reason why kerning and ligatures haven't been enabled in ICU > when used in the JDK? Does it have some unexpected side affect? I think the basic reason is compatibility of text advance. Text that is rendered through drawString() and text that is rendered via TextLayout() should be the same. So optional ligatures and kerning need to be requested by those who know they want them. You might then ask but why not at least do this for complex scripts where text has to go through layout and mandatory ligatures are performed. I would have to dig to be sure what actually happens in ICU, but one scenario is mixed script text. Eg some latin followed by some complex script. If the optional ligatures were performed by layout and you are in say a text editor and delete the complex text leaving only the latin text it would look odd if the optional ligatures no longer formed and if kerning stopped being applied. However if you are pointing out that even when specifying TextAttribute.KERNING and TextAttribute.LIGATURES that they do not get applied, then that would seem like a bug. But my reading of the code is that that the request for kerning and ligatures is not held in "eflags" but in "_typo_flags" and the value passed down to layout is "_typo_flags | eflags" As far as I can see your patch is equivalent to always adding the TextAttribute.KERNING and TextAttribute.LIGATURES as attributes on these two fonts (no JDK source code changes needed). Is that what you see? > > Currently EngineRecord only sets eflags for NON_SPACING_MARK, > ENCLOSING_MARK, COMBINING_SPACING_MARK. That is I believe for performance. At the moment, this isn't > sufficient for Burmese since the character properties in the jdk haven't > been updated to Unicode 5.1, hence I enabled it for the whole code block > in my test build. > > For reference, Myanmar fonts are available at: > http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=Padauk > http://myanmarnlpteam.blogspot.com/2007/08/download-links.html > http://www.mymyanmar.net/2g/ > > (Another Myanmar font, Parabaik uses OpenType rlig, which ICU doesn't > process for this code block without further code changes). > > There is a possible patch below, which displays Unicode 5.1 Myanmar > correctly with Padauk, MyMyanmar Unicode and Myanmar3 fonts when used > with the methods TextLayout.draw, drawString and drawChars in > Font2DTest. Some attached marks get lost with Padauk using > TextLayout.getOutline+draw. > > I would appreciate feedback on whether to submit this as a patch purely > for the Myanmar script or whether eflags should be changed more generally. Before we can accept any patch you will need to sign and submit the Sun Contributor Agreement. See http://openjdk.java.net/contribute/ > > Regards, > Keith Stribley > > --- ./jdk/src/share/classes/sun/font/GlyphLayout.java.orig 2008-05-29 > 15:01:33.000000000 +0100 > +++ ./jdk/src/share/classes/sun/font/GlyphLayout.java 2008-05-29 > 23:13:26.000000000 +0100 > @@ -644,11 +644,15 @@ > ch = toCodePoint((char)ch,_textRecord.text[++i]); > // inc > } > int gc = getType(ch); > + if (script == 28) { // Myanmar - see LEScripts.h > + this.eflags = 0x3;// 1=kerning, 2=ligatures > + break; > + } > if (gc == NON_SPACING_MARK || > gc == ENCLOSING_MARK || > gc == COMBINING_SPACING_MARK) { // could do range > test also > > - this.eflags = 0x4; > + this.eflags = 0x4; // 4 = no canonical processing, > but would 0x3 be better? I think you have this backwards. 0x4 means DO canonical processing. > break; > } > } > --- ./jdk/src/share/classes/sun/font/FontManager.java.orig 2008-05-28 > 12:46:03.000000000 +0100 > +++ ./jdk/src/share/classes/sun/font/FontManager.java 2008-05-29 > 21:33:31.000000000 +0100 > @@ -3594,6 +3594,12 @@ > // 0E00 - 0E7F if Thai, assume shaping for vowel, tone marks > return true; > } > + else if (code < 0x1000) { > + return false; > + } > + else if (code < 0x10A0) { // 1000-109F Myanmar > + return true; > + } > else if (code < 0x1780) { > return false; > } > -phil. From Andrew.Brygin at Sun.COM Wed Jun 25 08:19:03 2008 From: Andrew.Brygin at Sun.COM (Andrew Brygin) Date: Wed, 25 Jun 2008 12:19:03 +0400 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <4861FF77.7090208@sun.com> Vote: yes Andrew Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from > JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Alexey.Ushakov at Sun.COM Wed Jun 25 08:42:20 2008 From: Alexey.Ushakov at Sun.COM (Alexey Ushakov) Date: Wed, 25 Jun 2008 12:42:20 +0400 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <486204EC.4090804@sun.com> Vote: yes Best Regards, Alexey Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from > JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Steven.Loomis at Sun.COM Wed Jun 25 15:07:37 2008 From: Steven.Loomis at Sun.COM (Steven R. Loomis) Date: Wed, 25 Jun 2008 08:07:37 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <48625F39.2040101@Sun.COM> Vote: yes Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from > JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From Phil.Race at Sun.COM Wed Jun 25 19:13:20 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 25 Jun 2008 12:13:20 -0700 Subject: [OpenJDK 2D-Dev] Kerning and Ligatures using Layout Engine In-Reply-To: <4861885E.2050709@sun.com> References: <485ABE1F.70601@thanlwinsoft.org> <4861885E.2050709@sun.com> Message-ID: <486298D0.2000809@sun.com> Phil Race wrote: > I can take a stab at this but it probably needs the ICU developer to > confirm > what's happening there. Here's what the opentype layout engine developer over at the ICU project said. > I'm surprised to read that ICU handles Myanmar correctly. I suppose that > the default processing must work with the fonts he sites. My quick reading > of the description of the Myanmar script in the Unicode 5.0 book suggests > that it would need more processing. His comment about 'rlig' seems to bear > this out. > > If the presence of marks is inhibiting ligature formation, that could be a > bug. I'd need to see some specific test cases to know what's going on. In > general, I would expect it to work. (I did recently fix some bugs having to > do w/ canonical processing that might be relevant here...) So probably taking the up to date ICU layout code into JDK would tell us if that's one of these recent fixed bugs. Steven is planning to do that but I'm not sure when it'll happen. So specific test cases (the text and a reference to the font, and an "actual" vs "expected" description) would be better. But this may in part come down to ICU not actually having all the code it needs to render Myanmar script. -Phil. From devel at thanlwinsoft.org Wed Jun 25 20:20:35 2008 From: devel at thanlwinsoft.org (Keith Stribley) Date: Wed, 25 Jun 2008 21:20:35 +0100 Subject: [OpenJDK 2D-Dev] Kerning and Ligatures using Layout Engine In-Reply-To: <4861885E.2050709@sun.com> References: <485ABE1F.70601@thanlwinsoft.org> <4861885E.2050709@sun.com> Message-ID: <4862A893.10108@thanlwinsoft.org> Hi Phil, thanks for your response, it has helped clarify my understanding and I think I've found the real bug - see below. Phil Race wrote: > Keith Stribley wrote: >> I am interested in getting clig,liga,mark,mkmk,kern OpenType tables to > > Those are not tables. Those are features in the OpenType GSUB and GPOS > tables. Yes, sorry for the confusion. > > FYI: it was "current" at the point in JDK 6 development when it was > integrated. > JDK 7 will get an updated version in due course. Great, though I'm not sure it will affect the Myanmar rendering in this case. ICU 4 in general has support for Unicode 5.1, which is needed for Myanmar. >> I'm not quite sure why 0x4 is used as the value when there are marks, I >> believe it corresponds to "no canonical processing", though I don't know >> why that is needed. > > I think you have this backwards. Sorry, I read the comment in LayoutEngine::characterProcessing(...) too quickly and was perhaps confused by the actual behaviour. Is the "canonical processing" flag an OpenJDK specific optimisation? I couldn't see it in ICU svn history, but perhaps I was looking at the wrong revisions. > So optional ligatures and kerning need to be requested by those > who know they want them. This is fine for Latin text, but not for Burmese, which is heavily dependent on ligatures to make it readable. Most Burmese Unicode fonts also use kerning. > > I would have to dig to be sure what actually happens > in ICU, but one scenario is mixed script text. Eg some latin followed > by some complex script. If the optional ligatures were performed by > layout and you are in say a text editor and delete the complex > text leaving only the latin text it would look odd if the optional > ligatures no longer formed and if kerning stopped being applied. Currently the opposite happens. As soon as the complex script is present, the kerning and ligatures stop if they were requested in the TextAttributes. Consider the latin case with say DoulosSIL http://scripts.sil.org/DoulosSIL_download : fi ffi fi ffi a?? Both lines should show the ffi ligatures when set in the TextAttributes, but only the first one does, because the marks on the second line trigger eflags. > > However if you are pointing out that even when specifying > TextAttribute.KERNING and TextAttribute.LIGATURES that they do not > get applied, then that would seem like a bug. Yes. > But my reading of > the code is that that the request for kerning and ligatures is > not held in "eflags" but in "_typo_flags" and the value > passed down to layout is "_typo_flags | eflags" I've looked some more into this, and I believe there is a bug in the OpenTypeLayoutEngine constructor (jdk/src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp). This currently does not expect a value greater than 3 for typoFlags, so if 4 is applied then kerning and ligatures are disabled, which is fine if only bit 4 is set, but not if you have 7 from the or that you describe. This wouldn't trigger in the normal ICU as I don't think they use the 0x4 flag. I've now added & 0x3, so that 0x4 bit will be ignored when setting the feature mask: switch (typoFlags & 0x3) { case 0: break; // default case 1: fFeatureMask = kernFeatures; break; case 2: fFeatureMask = ligaFeatures; break; case 3: fFeatureMask = kernAndLigaFeatures; break; default: break; } > > As far as I can see your patch is equivalent to always > adding the TextAttribute.KERNING and TextAttribute.LIGATURES > as attributes on these two fonts (no JDK source code changes > needed). Is that what you see? Now I've found the bug in OpenTypeLayoutEngine and if that was fixed, that might be the case. But I don't think it should be regarded as just applying for 2 specific fonts. Burmese relies on ligatures in many words (as do most if not all of the other languages using the Myanmar code block). If ligatures and kerning aren't enabled Burmese Unicode text is unreadable. I think they should be enabled by default for the Myanmar code block, at least when marks are present. Most people will not realise that these attributes need to be set to get correct Burmese (and with the current bug, they won't take affect anyway because they involve marks). > > Before we can accept any patch you will need to sign and submit > the Sun Contributor Agreement. See http://openjdk.java.net/contribute/ I've just signed and emailed it. Regards, Keith From devel at thanlwinsoft.org Wed Jun 25 20:59:33 2008 From: devel at thanlwinsoft.org (Keith Stribley) Date: Wed, 25 Jun 2008 21:59:33 +0100 Subject: [OpenJDK 2D-Dev] Kerning and Ligatures using Layout Engine In-Reply-To: <486298D0.2000809@sun.com> References: <485ABE1F.70601@thanlwinsoft.org> <4861885E.2050709@sun.com> <486298D0.2000809@sun.com> Message-ID: <4862B1B5.60005@thanlwinsoft.org> Phil Race wrote: > > Here's what the opentype layout engine developer over at the ICU > project said. > > > I'm surprised to read that ICU handles Myanmar correctly. I suppose > that > > the default processing must work with the fonts he sites. Yes, the fonts have been designed to use the default processing which is enabled by default in Uniscribe if Complex language support is turned on in Windows XP SP2 or Vista. > My quick reading > > of the description of the Myanmar script in the Unicode 5.0 book > suggests > > that it would need more processing. His comment about 'rlig' seems > to bear > > this out. Currently, there is no standard set of OpenType features which have been defined for Myanmar. It is possible to do the reordering with a sequence of context ligatures and this is what has been done in the existing Myanmar Unicode fonts. It is possible that in the future Myanmar specific OpenType features will be officially defined, in which case Myanmar specific Layout code could be written to simplify the number of lookups in the font. These ligatures are all really required for Myanmar, but different fonts have chosen to use different features (not just rlig) if they are currently turned on by default in Uniscribe. Since liga and clig are turned on by default in ICU when ligature processing is turned on they work better with it than rlig. The reason rlig doesn't work is that it isn't defined in the ligaFeatures define in the top of OpenTypeLayoutEngine.cpp. I tried adding this in the past with ICU layout and it seemed to work in my test app. > > > > If the presence of marks is inhibiting ligature formation, that > could be a > > bug. I'd need to see some specific test cases to know what's going > on. In > > general, I would expect it to work. (I did recently fix some bugs > having to > > do w/ canonical processing that might be relevant here...) I believe it is specific to the way OpenJDK calls ICU. Try the following in a java editor with DoulosSIL or another font with ffi ligatures. The ffi ligatures should be enabled on both lines, but are only enabled on the first until you delete the marks on the second. fi ffi fi ffi a?? (I was testing using the notepad demo app tweaked to set the font and TextAttributes) > > So probably taking the up to date ICU layout code into JDK would tell us > if that's one of these recent fixed bugs. Steven is planning to do that > but I'm not sure when it'll happen. > So specific test cases (the text and a reference to the font, and > an "actual" vs "expected" description) would be better. Shall I open a bug for this and attach some screenshots of the rendering? > But this > may in part come down to ICU not actually having all the code it needs > to render Myanmar script. > The fonts I'm using work fine with the default features enabled in Uniscribe and mostly work in Pango. I agree that the fonts could be simplified if Burmese reordering was handled in a standard manner by the commonly used layout engines, but for the moment they are being written to take advantage of features which are enabled by default in common rendering engines. Keith