From andrew.brygin at sun.com Sat Nov 1 17:57:46 2008 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Sat, 01 Nov 2008 17:57:46 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6541476: PNG imageio plugin incorrectly handles iTXt chunk Message-ID: <20081101175809.20C2BDD8B@hg.openjdk.java.net> Changeset: 3a9d06af8830 Author: bae Date: 2008-11-01 20:42 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3a9d06af8830 6541476: PNG imageio plugin incorrectly handles iTXt chunk Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/ITXtTest.java From roman.kennke at aicas.com Tue Nov 4 09:16:09 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 04 Nov 2008 10:16:09 +0100 Subject: [OpenJDK 2D-Dev] Optimizing pixmap reads and write Message-ID: <1225790169.7009.8.camel@moonlight> I'm currently implementing a SurfaceData for VxWorks/WindML. Unfortunately, this graphics library (WindML) doesn't provide me direct framebuffer access. Therefore I have to perform read and write operations for rendering operations (at least, for images and likewise non-primitives). I was thinking that in many cases I can avoid reading the surface data (i.e. for rendering opaque images) or in some cases writing (when transferring the surface data to another incompatible surface). So I implemented my GetRasInfo like this (pseudocode): malloc(pixels, size); if (lockFlags & SD_LOCK_READ) { readPixelsFromSurface(); } and the Release function: if (lockFlags & SD_LOCK_WRITE) { writePixelsToSurface(); } free(pixels); Unfortunately, this doesn't work well. When rendering translucent or bitmask images, it does NOT set the the SD_LOCK_READ flag, and therefore I don't read the surface pixels here, resulting in uninitialized background for these images. This means, it only renders correctly if I ignore the SD_LOCK_READ flag and read every time, even if I wouldn't need to. My question is, did I get something wrong in my understanding of the flags? Or is this a bug? Or just something that hasn't been implemented/optimized yet, because it isn't needed on OpenJDKs primary platforms? (Although, I would think, that at least for non-DGA surfaces it would be a nice little optimization at least on X11). /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From mark at klomp.org Tue Nov 4 09:30:09 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 04 Nov 2008 10:30:09 +0100 Subject: [OpenJDK 2D-Dev] Bug in pisces Renderer (uninitialized crossings) In-Reply-To: <1225119212.3329.29.camel@dijkstra.wildebeest.org> References: <1225119212.3329.29.camel@dijkstra.wildebeest.org> Message-ID: <1225791009.3320.4.camel@dijkstra.wildebeest.org> Hi, If anybody would take a look at this fix that would be appreciated. Thanks, Mark On Mon, 2008-10-27 at 15:53 +0100, Mark Wielaard wrote: > There is a bug in the pisces Renderer in crossingListFinished(). Both > crossings and crossingIndices might not have been initialized, so have > to be checked for being null. They only get initialized if > setCrossingsExtents() was called earlier, which might not always be the > case when crossingListFinished() is called from _endRendering(). > > You can see this with for example this applet (you will need to have the > IcedTeaPlugin installed): > http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer > The magnifying glass will not work, and you will get an exception: > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > at sun.java2d.pisces.Renderer.crossingListFinished(Renderer.java:778) > at sun.java2d.pisces.Renderer._endRendering(Renderer.java:466) > at sun.java2d.pisces.Renderer.endRendering(Renderer.java:478) > at sun.java2d.pisces.PiscesRenderingEngine.getAATileGenerator(PiscesRenderingEngine.java:327) > at sun.java2d.pipe.AAShapePipe.renderPath(AAShapePipe.java:93) > at sun.java2d.pipe.AAShapePipe.fill(AAShapePipe.java:65) > at sun.java2d.pipe.ValidatePipe.fill(ValidatePipe.java:160) > at sun.java2d.SunGraphics2D.fill(SunGraphics2D.java:2422) > at org.jfree.chart.plot.Plot.fillBackground(Plot.java:1021) > [...] > > Attached is the workaround that I checked into IcedTea to make this work > reliably: > > 2008-10-27 Mark Wielaard > > * patches/icedtea-renderer-crossing.patch: New patch. > * Makefile.am (ICEDTEA_PATCHES): Add new patch. > * HACKING: Document new patch. > > Cheers, > > Mark From Jim.A.Graham at Sun.COM Tue Nov 4 11:02:19 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 04 Nov 2008 03:02:19 -0800 Subject: [OpenJDK 2D-Dev] Optimizing pixmap reads and write In-Reply-To: <1225790169.7009.8.camel@moonlight> References: <1225790169.7009.8.camel@moonlight> Message-ID: <0K9T00D362NUR750@fe-sfbay-09.sun.com> Hi Roman, This isn't well documented in SurfaceData.h, but there is a set of flags "SD_LOCK_NEED_PIXELS" which indicates if you need to do the read. This is used in X11SurfaceData.c, but that file has so many ifdefs and alternate pixel access modes now that you really have to dig through it to see this. It is also used in GDIWindowSurfaceData.cpp which is a little less complicated than the X11 counterpart, but not by much. SD_LOCK_NEED_PIXELS is an OR of the READ and the PARTIAL flags. Primitives that know that they will be obliterating the entire rectangle that they are asking to lock will use SD_LOCK_WRITE without the PARTIAL flag. If they cannot guarantee that they will obliterate the destination then they use the PARTIAL flag (in addition to WRITE) so that the read will be triggered. Hope that helps... ...jim Roman Kennke wrote: > I'm currently implementing a SurfaceData for VxWorks/WindML. > Unfortunately, this graphics library (WindML) doesn't provide me direct > framebuffer access. Therefore I have to perform read and write > operations for rendering operations (at least, for images and likewise > non-primitives). I was thinking that in many cases I can avoid reading > the surface data (i.e. for rendering opaque images) or in some cases > writing (when transferring the surface data to another incompatible > surface). So I implemented my GetRasInfo like this (pseudocode): > > malloc(pixels, size); > if (lockFlags & SD_LOCK_READ) { > readPixelsFromSurface(); > } > > and the Release function: > > if (lockFlags & SD_LOCK_WRITE) { > writePixelsToSurface(); > } > free(pixels); > > Unfortunately, this doesn't work well. When rendering translucent or > bitmask images, it does NOT set the the SD_LOCK_READ flag, and therefore > I don't read the surface pixels here, resulting in uninitialized > background for these images. This means, it only renders correctly if I > ignore the SD_LOCK_READ flag and read every time, even if I wouldn't > need to. > > My question is, did I get something wrong in my understanding of the > flags? Or is this a bug? Or just something that hasn't been > implemented/optimized yet, because it isn't needed on OpenJDKs primary > platforms? (Although, I would think, that at least for non-DGA surfaces > it would be a nice little optimization at least on X11). > > /Roman > From Artem.Ananiev at Sun.COM Thu Nov 6 12:27:27 2008 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Thu, 06 Nov 2008 15:27:27 +0300 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <4912D242.1010404@sun.com> References: <4912D242.1010404@sun.com> Message-ID: <4912E2AF.6090708@sun.com> Hi, Marek, as your test uses Swing menus, it looks like a Swing (or probably Java2D, because of font metrics) problem, rather than AWT one. Thanks, Artem Marek Slama wrote: > Hello, > > we encounter problem with too big spacing around text in Swing > components in openjdk. I attach > 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu > 8.10/Metal L&F. I was pointed > to this maling list. Is it known problem? I do not know if it is > specific to Ubuntu only. > > java version "1.6.0_10" > Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) > > java version "1.6.0_0" > IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) > OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) > > Both use the same font: > javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] > > > Original issue report is https://bugs.launchpad.net/bugs/289784 > > Thanks > > Marek From Igor.Nekrestyanov at Sun.COM Thu Nov 6 17:47:40 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Thu, 06 Nov 2008 20:47:40 +0300 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <4912E2AF.6090708@sun.com> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> Message-ID: <49132DBC.5080106@sun.com> This is likely to be same as http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 that was recently fixed and did not make it into main openjdk ws yet but you can pull these changes from 2D workspace to test. -igor Artem Ananiev wrote: > Hi, Marek, > > as your test uses Swing menus, it looks like a Swing (or probably > Java2D, because of font metrics) problem, rather than AWT one. > > Thanks, > > Artem > > Marek Slama wrote: >> Hello, >> >> we encounter problem with too big spacing around text in Swing >> components in openjdk. I attach >> 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu >> 8.10/Metal L&F. I was pointed >> to this maling list. Is it known problem? I do not know if it is >> specific to Ubuntu only. >> >> java version "1.6.0_10" >> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >> >> java version "1.6.0_0" >> IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) >> OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) >> >> Both use the same font: >> javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] >> >> >> Original issue report is https://bugs.launchpad.net/bugs/289784 >> >> Thanks >> >> Marek From roman.kennke at aicas.com Thu Nov 6 20:36:45 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 06 Nov 2008 21:36:45 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] Memory leak in LCMS.c Message-ID: <1226003805.25157.8.camel@moonlight> I found a memory leak in LCMS.c, where one ReleaseByteArrayElements() call is missing in loadProfile(). I think the IcedTea people discovered this independently and already included that in IcedTea and I believe also in OpenJDK6, but it doesn't seem to be in JDK7 yet. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- diff -r 7337308ff346 src/share/native/sun/java2d/cmm/lcms/LCMS.c --- a/src/share/native/sun/java2d/cmm/lcms/LCMS.c Thu Nov 06 12:32:40 2008 +0100 +++ b/src/share/native/sun/java2d/cmm/lcms/LCMS.c Thu Nov 06 12:33:11 2008 +0100 @@ -192,6 +192,8 @@ JNU_ThrowIllegalArgumentException(env, "Invalid profile data"); } + (*env)->ReleaseByteArrayElements(env, data, dataArray, JNI_ABORT); + return sProf.j; } From mark at klomp.org Fri Nov 7 13:05:47 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 07 Nov 2008 14:05:47 +0100 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <49132DBC.5080106@sun.com> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> <49132DBC.5080106@sun.com> Message-ID: <1226063147.3310.12.camel@dijkstra.wildebeest.org> Hi, On Thu, 2008-11-06 at 20:47 +0300, Igor Nekrestyanov wrote: > This is likely to be same as > http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 > that was recently fixed and did not make it into main openjdk ws yet but > you can pull these changes from 2D workspace to test. For those in the community without access to internal sun machines this is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761856 and: http://hg.openjdk.java.net/jdk7/2d-gate/jdk/rev/9cdababf6179 This was also reported against IcedTea as: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=227 I have imported the patch into IcedTea6 and tested that it fixes the mentioned issues: 2008-10-29 Mark Wielaard * patches/icedtea-6761856-freetypescaler.patch: New patch. * Makefile.am (ICEDTEA_PATCHES): Add new patch. * HACKING: Document new patch. Cheers, Mark From mark at klomp.org Fri Nov 7 13:13:49 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 07 Nov 2008 14:13:49 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] Memory leak in LCMS.c In-Reply-To: <1226003805.25157.8.camel@moonlight> References: <1226003805.25157.8.camel@moonlight> Message-ID: <1226063629.3310.18.camel@dijkstra.wildebeest.org> Hi Roman, On Thu, 2008-11-06 at 21:36 +0100, Roman Kennke wrote: > I found a memory leak in LCMS.c, where one ReleaseByteArrayElements() > call is missing in loadProfile(). I think the IcedTea people discovered > this independently and already included that in IcedTea and I believe > also in OpenJDK6, but it doesn't seem to be in JDK7 yet. Yes, this was the issue Tom Fitzsimmons reported last year: http://mail.openjdk.java.net/pipermail/awt-dev/2007-November/000107.html Which was patches/icedtea-lcms-leak.patch in IcedTea6 before 1.3. Integrated last month into OpenJDK6 in b12 through: http://bugs.sun.com/view_bug.do?bug_id=6733501 Cheers, Mark From Igor.Nekrestyanov at Sun.COM Fri Nov 7 14:10:14 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Fri, 07 Nov 2008 17:10:14 +0300 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <1226063147.3310.12.camel@dijkstra.wildebeest.org> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> <49132DBC.5080106@sun.com> <1226063147.3310.12.camel@dijkstra.wildebeest.org> Message-ID: <49144C46.9090303@sun.com> Thank you Mark! i keep forgetting that bug database is not available to everyone yet :( -igor Mark Wielaard wrote: > Hi, > > On Thu, 2008-11-06 at 20:47 +0300, Igor Nekrestyanov wrote: > >> This is likely to be same as >> http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 >> that was recently fixed and did not make it into main openjdk ws yet but >> you can pull these changes from 2D workspace to test. >> > > For those in the community without access to internal sun machines this > is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761856 > and: http://hg.openjdk.java.net/jdk7/2d-gate/jdk/rev/9cdababf6179 > > This was also reported against IcedTea as: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=227 > > I have imported the patch into IcedTea6 and tested that it fixes the > mentioned issues: > > 2008-10-29 Mark Wielaard > > * patches/icedtea-6761856-freetypescaler.patch: New patch. > * Makefile.am (ICEDTEA_PATCHES): Add new patch. > * HACKING: Document new patch. > > Cheers, > > Mark > > From Marek.Slama at Sun.COM Fri Nov 7 14:22:02 2008 From: Marek.Slama at Sun.COM (Marek Slama) Date: Fri, 07 Nov 2008 15:22:02 +0100 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <49132DBC.5080106@sun.com> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> <49132DBC.5080106@sun.com> Message-ID: <49144F0A.4080902@sun.com> Igor Nekrestyanov wrote: > This is likely to be same as > http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 > that was recently fixed and did not make it into main openjdk ws yet > but you can pull these changes from 2D workspace to test. > I can confirm spacing issue is fixed. I tested on 2D workspace. Marek > -igor > > Artem Ananiev wrote: >> Hi, Marek, >> >> as your test uses Swing menus, it looks like a Swing (or probably >> Java2D, because of font metrics) problem, rather than AWT one. >> >> Thanks, >> >> Artem >> >> Marek Slama wrote: >>> Hello, >>> >>> we encounter problem with too big spacing around text in Swing >>> components in openjdk. I attach >>> 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu >>> 8.10/Metal L&F. I was pointed >>> to this maling list. Is it known problem? I do not know if it is >>> specific to Ubuntu only. >>> >>> java version "1.6.0_10" >>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >>> >>> java version "1.6.0_0" >>> IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) >>> OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) >>> >>> Both use the same font: >>> javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] >>> >>> >>> Original issue report is https://bugs.launchpad.net/bugs/289784 >>> >>> Thanks >>> >>> Marek > From Martin.vGagern at gmx.net Sat Nov 8 14:51:09 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sat, 08 Nov 2008 15:51:09 +0100 Subject: [OpenJDK 2D-Dev] Bug fixes for com.sun.imageio.plugins.png.PNGMetadata Message-ID: <4915A75D.7020108@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I've recently encountered a bunch of bugs in PNGMetadata: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5106550 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082756 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6541476 For the first I have written a fix and posted it to jdk7-dev: http://mail.openjdk.java.net/pipermail/jdk7-dev/2008-October/000272.html After not getting a reply there, I asked in core-libs-dev, and was referred here. I'm interested in contributing my fixes for these other issues as well. I might even look at some more IIO metadata bugs out there, see http://bugs.sun.com/bugdatabase/search.do?process=1&category=java&bugStatus=1%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9&subcategory=imageio&type=bug&keyword=metadata But before I start flooding this mailing list with them, I'd rather get some replies first. 1. Is there someone going to sponsor this? 2. Do you want them all in a single hg branch or rather multiple separate branches? I guess the issues would be independent enough to allow bultiple independent branches. 3. How about mailing threads? One thread per bug report? 4. I tend to have multiple commits per fix. Do you want a diff for each, or rather a single hg bundle containing them all, or both of this? 5. Would you prefer a public hg branch somewhere to exchange the current state of affairs? Greetings, Martin von Gagern -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkVp10ACgkQRhp6o4m9dFthsQCeIKpzPO/GM5ieuQfkHeW/PaHi wBMAnj7jwafJBnCf44our/dDu0sD0xwI =z2PP -----END PGP SIGNATURE----- From Martin.vGagern at gmx.net Mon Nov 10 10:58:36 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 10 Nov 2008 11:58:36 +0100 Subject: [OpenJDK 2D-Dev] 6541476: PNG imageio plugin incorrectly handles iTXt chunk Message-ID: <491813DC.3030805@gmx.net> Bug 6541476; State: 8-Fix Available, bug; Priority: 4-Low http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6541476 PNGMetadata is inconsitent in what data types get stored in its various iTXt_* lists. Method mergeNativeTree used different data types than the rest of the code for the following two attributes: 1. iTXt_compressionFlag uses Integer, but Boolean in mergeNativeTree 2. iTXt_compressionMethod uses Integer, but String in mergeNativeTree The attached patch addresses this by: 1. Changing all Lists to compile time type checked generics. Now the code compiles with -Xlint:unchecked 2. Cast the boolean compressionFlag to an integer before adding 3. Request the compressionMethod as an integer attribute 4. Change the comment about the compressionMethod datatype in the DTD 5. Provide a simple test case The compressionMethod of the iTXtEntry element is worth a closer look. While compressionMethod attributes of other elements in the native PNG metadata format use enum types in the DTD, this one has been defined as String in the spec and represented as integers on export so far. I believe it would be better to turn it into an enum as well, probably in a way which would retain backward and forward compatibility. However, I would consider this a separate issue, and discuss it in a separate thread. Therefore I'd deem this patch here ready to be applied as a self comtained fix for a single issue, even though I would like for another fix to change the DTD again before OpenJDK7 gets released. The Evaluation of CR 6541476 also mentions some issues reading UTF8 data for iTXt chunks. This I'd also consider a separate issue, and would address it in a separate fix, along with a separate test case to reproduce the issue in the first place. The attached patch is from my mercurial patch queue. Once you consider it ready for inclusion, I will commit it locally and export a mercurial patch instead. Greetings, Martin von Gagern -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug6541476.patch URL: From Martin.vGagern at gmx.net Mon Nov 10 10:58:25 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 10 Nov 2008 11:58:25 +0100 Subject: [OpenJDK 2D-Dev] 5106550: PNG writer merge standard metadata fails for TextEntry sans #IMPLIED attributes Message-ID: <491813D1.5010207@gmx.net> Bug ID: 5106550; State: 3-Accepted, bug; Priority: 4-Low http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5106550 The bug lies in the fact that for TextEntry nodes in standard metadata format, PNGMetadata requires additional attributes besides the ones marked #REQUIRED in the DTD. Namely missing encoding, language or compression will result in an IIOInvalidTreeException: > Exception in thread "main" javax.imageio.metadata.IIOInvalidTreeException: Required attribute encoding not present! > at com.sun.imageio.plugins.png.PNGMetadata.fatal(PNGMetadata.java:1085) > at com.sun.imageio.plugins.png.PNGMetadata.getAttribute(PNGMetadata.java:1208) > at com.sun.imageio.plugins.png.PNGMetadata.getAttribute(PNGMetadata.java:1217) > at com.sun.imageio.plugins.png.PNGMetadata.mergeStandardTree(PNGMetadata.java:1921) > at com.sun.imageio.plugins.png.PNGMetadata.mergeTree(PNGMetadata.java:1232) > at MergeStdCommentTest.main(MergeStdCommentTest.java:37) The patch fixes this by 1. not reading the "encoding" attribute at all, as it isn't even used in the following code 2. having the "language" attribute default to "", as http://www.w3.org/TR/PNG/#11iTXt states that "if the language tag is empty, the language is unspecified" 3. having the "compression" attribute default to "none", as this is the default given in the DTD 4. ignore any node with missing or empty "keyword", as the PNG standard requires a keyword of length at least 1 according to http://www.w3.org/TR/PNG/#11tEXt I changed invocations from the previously used private String getAttribute(Node node, String name) which implied a required argument to the more flexible private String getStringAttribute(Node node, String name, String defaultValue, boolean required) Open question: Do you agree in dropping nodes with missing keywords? This follows the concept of not merging parts of the standard metadata model which have no counterpart in a specific file format, but might still lead to unexpected behaviour. I previously had this fix submitted to jdk7-dev, and mentioned in a posting "Bug fixes for com.sun.imageio.plugins.png.PNGMetadata" here. http://mail.openjdk.java.net/pipermail/jdk7-dev/2008-October/000272.html http://mail.openjdk.java.net/pipermail/2d-dev/2008-November/000540.html In the meantime, I have had a look at the mq extension of mercurial. Thus the attached patch is now a single patch straight out of my patch queue. I submit it here, waiting for comments, discussion, sponsorship. Once you consider it ready for inclusion, I can commit it localy and post a patch exported by hg. Greetings, Martin von Gagern -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug5106550.patch URL: From Martin.vGagern at gmx.net Mon Nov 10 10:58:51 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 10 Nov 2008 11:58:51 +0100 Subject: [OpenJDK 2D-Dev] 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" Message-ID: <491813EB.3080600@gmx.net> Bug ID: 5082756; State: 6-Fix Understood, bug; Priority: 4-Low http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082756 While the DTDs for the different metdata formats usually specify boolean values as ( "TRUE" | "FALSE" ), the implementations tend to use "true" and "false" instead. There are two possible approaches to this problem: 1. Have the implementation match the specification, i.e. use upper case 2. Adjust the specification to match implementation, i.e. use lower case While the former has the benefit of only touching internal com.sun implementation classes, the latter has the long therm benefit that implementations can use the default String conversion methods from class Boolean without further case conversion. While I would have wished for the specification to use lower case in the first place, I would now stick with the way it is, and adjust the implementation to upper case. Both approaches can be implemented with different degrees of tolerance when accepting values: a) strict: only allow the values also allowed by the DTD b) two possibilities: allow both "true" and "TRUE" c) ignore case: also allow "tRuE" Here I am in favor of the middle way. This gives you backward compatibility, but won't allow additional values without reason. The benefit is that with this it is more likely that an application developed under OpenJDK will work under other JREs as well. The downside of course is that applications developed for a JRE that completely ignores case would fail on OpenJDK. As I expect OpenJDK to have a larger market share, I would think this less likely to get unnoticed, though. There is also a slight performance benefit from not allowing mixed case, but I guess thats negligible here. So corresponding to my personal preferences, the attached patch changes all attribute creations to uppercase, and allows for both cases in PNGMetadata, but no mixed forms. The GIFMetadata implementation which already uses equalsIgnoreCase and thus allows for mixed case I left untouched for the moment. For the sake of consistency, we might to change that to the more strict two cases instead. I haven't any test case ready yet. I'll write one when we are agreed on the intended behaviour. The attached patch is from my mercurial patch queue. Once you consider it ready for inclusion, I will commit it locally and export a mercurial patch instead. Greetings, Martin von Gagern -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug5082756.patch URL: From Martin.vGagern at gmx.net Mon Nov 10 16:20:04 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 10 Nov 2008 17:20:04 +0100 Subject: [OpenJDK 2D-Dev] 6541476 (Eval): PNG imageio plugin incorrectly handles iTXt chunk Message-ID: <49185F34.1010307@gmx.net> Bug 6541476; State: 8-Fix Available, bug; Priority: 4-Low http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6541476 This is the second half od the issues mentioned in bug report 6541476. While my previous post for this bug number concentrated on the metadata class and the use of typesafe generics, this one here deals with the reader and writer classes and how they handle UTF-8 data. The current status of the reporitory does this: 1. translatedKeyword written in latin1 (writeBytes) but tried to read as modified UTF-8 prefixed with byte count (readUTF). The spec requires unmodified UTF-8 without byte count. 2. uncompressed text read and written as modified UTF-8 with byte count, in violation of the spec which requires unmodified UTF-8 and no byte count. 3. compressed text is stored and loaded as latin1. High bits are silently dropped when storing. The spec again requires unmodified UTF-8. My patch atempts to fix these issues, and to verify them using a suitable test case. As often there are multiple ways to do things. I'll highlight a few of the choices I made, if you want to discuss them. I use the Charset class as a central instrument for UTF-8 conversion. I use nio buffers as input and output of its encode and decode methods. This means that I have a bit more syntactic overhead than I would have using simply String.getBytes(utf8) and friends. It also means that I have the nio objects at hand if I ever chose to work on improving performance. Other than these buffer objects, I stick with the Stream API, not the nio channels. I wrote a wrapper class to turn an ImageOutputStream into an OutputStream, in order to layer a DeflatorOutputStream around it. For writing from a ByteBuffer to an [Image]OutputStream, I constructed a little helper to distinguish the cases of buffers with and without backing array. This should benefit performance. In the other hand, in the reader I simply copied code from the inflate method which reads characters one at a time, probably terribly inefficient. One might get better performance here at the cost of increased syntactic overhead. In the Test I actually check the resulting byte sequence for the uncompressed text chunk. This is done in order to rule out any symmetric errors, which would allow correct read-back and still leave incorrect data in the files. E.g. consistent use of modified UTF-8 would be such a case. The compressed chunk I don't check exactly, just its header, as the compression algorithm may yield different but equivalent results for different implementations. The attached patch is from my mercurial patch queue. Once you consider it ready for inclusion, I will commit it locally and export a mercurial patch instead. Greetings, Martin von Gagern -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug6541476-UTF.patch URL: From Igor.Nekrestyanov at Sun.COM Mon Nov 10 22:58:07 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Tue, 11 Nov 2008 01:58:07 +0300 Subject: [OpenJDK 2D-Dev] Bug fixes for com.sun.imageio.plugins.png.PNGMetadata In-Reply-To: <4915A75D.7020108@gmx.net> References: <4915A75D.7020108@gmx.net> Message-ID: <4918BC7F.5050702@sun.com> Hi Martin, yes, this is correct list for ImageIO fixes. I am not ImageIO expert and someone who better understands this code will need to review this. If changes are ok then we will integrate it acknowledging your contribution. Usually it is more convenient to deal with independent issues separately. So, it was good idea to start several threads. Patches are usually ok but it is actually much easier to review changes if you can generate webrev for suggested change, post it somethere and send link to it. See http://blogs.sun.com/jcc/entry/webrev_for_openjdk_a_code Also, i believe that 6541476 was recently fixed (change did not make into master workspace yet). Please check latest 2d workspace and see if fix needs any further improvements. -igor Martin von Gagern wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I've recently encountered a bunch of bugs in PNGMetadata: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5106550 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082756 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6541476 > > For the first I have written a fix and posted it to jdk7-dev: > http://mail.openjdk.java.net/pipermail/jdk7-dev/2008-October/000272.html > After not getting a reply there, I asked in core-libs-dev, and was > referred here. > > I'm interested in contributing my fixes for these other issues as well. > I might even look at some more IIO metadata bugs out there, see > http://bugs.sun.com/bugdatabase/search.do?process=1&category=java&bugStatus=1%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9&subcategory=imageio&type=bug&keyword=metadata > > But before I start flooding this mailing list with them, I'd rather get > some replies first. > > 1. Is there someone going to sponsor this? > > 2. Do you want them all in a single hg branch or rather multiple > separate branches? I guess the issues would be independent enough to > allow bultiple independent branches. > > 3. How about mailing threads? One thread per bug report? > > 4. I tend to have multiple commits per fix. Do you want a diff for each, > or rather a single hg bundle containing them all, or both of this? > > 5. Would you prefer a public hg branch somewhere to exchange the current > state of affairs? > > Greetings, > Martin von Gagern > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkVp10ACgkQRhp6o4m9dFthsQCeIKpzPO/GM5ieuQfkHeW/PaHi > wBMAnj7jwafJBnCf44our/dDu0sD0xwI > =z2PP > -----END PGP SIGNATURE----- > From Martin.vGagern at gmx.net Wed Nov 12 13:05:20 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Wed, 12 Nov 2008 14:05:20 +0100 Subject: [OpenJDK 2D-Dev] 6541476: PNG imageio plugin incorrectly handles iTXt chunk In-Reply-To: <491813DC.3030805@gmx.net> References: <491813DC.3030805@gmx.net> Message-ID: <491AD490.8060806@gmx.net> Hi again. As Igor kindly pointed out, there is in fact a fix for 6541476 in tree. http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3a9d06af8830 I now compared this to my own corrections. In general the changeset in your repository has less modifications and looks somewhat cleaner. Still I found several things to improve. I'll sum them up here, and attach a patch. 1. Use of Generics. Classification: Not a bug, but could be done better. While the fix makes use of typesave generics for the iTXt chunks, it doesn't change the other lists. My original patch here converted all lists, so that PNGMetadata could be compiled with -Xlint:unchecked without warnings. Just now I made an effort to extend this to the whole png plugin directory, which involved PNGImageDataEnumeration as well. 2. EOF in readNullTerminatedString. Classification: Bug, newly introduced regression. The loop that reads null terminated strings just looks for 0 being returned from ImageInputStream.read(). This ignores the possible value of -1 which would indicate an end of stream. Because of this, truncated PNG files could lead to long execution time (while the loop iterates at the end of the stream) followed by an OutOfMemoryError (when enough -1 values have ben "read" and buffered). My patch manually checks for -1 and throws an EOFException if encountered. An alternative approach would be to use DataInput.readyByte(). 3. Usage of default charset. Classification: Bug, parts already present in previous versions. The bug fix introduced an invocation of the "String(byte[])" constructor in parse_zTXt_chunk which is wrong. That constructor uses default charset, where the old inflate method employed ISO-8859-1 conversion. I added the charset name to that constructor invocation, and another one for parse_tEXt_chunk where it had been missing even before changeset 3a9d06af8830. In write_zTXt the fix introduced a call to String.getBytes() which is wrong for the same reasons. As the tEXt chunk uses ImageOutputStream.writeBytes which does ISO-8859-1 conversion, there was no previous bug in the PNGImageWriter. 4. Unnecessary overhead in deflate(byte[]). Classification: Not a bug, but could be done better. The newly modified deflate method now takes a byte array as input, not a String anymore. Still it feeds bytes on at a time into the deflater, causing unnecessary syntactic overhead and probably a performance penalty as well. As the contract of the write(byte[]) method already ensures that all bytes get written, simply writing the whole array to the deflater is much simpler and more efficient. In the other direction the inflate method could be written to read into a byte array, but looping would still be required as the size of the array isn't known in advance. There might be some performance to gain, but at the cost of clarity, so I left it as it is. 5. Integer iTXtEntry at compressionFlag in generated native tree. Classification: Bug, present in previous versions. According to the DTD, the compressionFlag of an iTXtEntry should be "TRUE" or "FALSE". The old code exported "0" or "1" using Integer.toString() which the patch kept using a `? "1" : "0"' construct. In the other direction mergeNativeTree uses getBooleanAttribute which would do the correct thing once bug 5082756 has been fixed. I already posted a patch for that. Right now it expects "true" or "false" so it will accept neither "1"/"0" nor "TRUE"/"FALSE". I also included another test case. The core is the test case I already included in my post "6541476 (Eval)...". It has the advantage of actually checking the bytes written to file, and ensuring that umodified UTF-8 is used. This is no problem with the code from changeset 3a9d06af8830 but might be a nice thing to have in any case. I also modified this test so that it exhibits the issue 2 above, the missed EOF and resulting error for truncated PNG files. I hope I got the jtreg tags correct. I guess I could turn that truncated file scenario into a separate test, but the way it is now I'm much more confident that the test does what I expect, as I know it can read correct images and only fails for truncated ones. I guess I could write test cases for the other issues classified as "bug" above, if you think that worthwhile. Please review my patch, and let me know when I should commit it locally and export it via hg. Greetings, Martin von Gagern -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug6541476-corrections.patch URL: From Andrew.Brygin at Sun.COM Wed Nov 12 14:41:49 2008 From: Andrew.Brygin at Sun.COM (Andrew Brygin) Date: Wed, 12 Nov 2008 17:41:49 +0300 Subject: [OpenJDK 2D-Dev] 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" In-Reply-To: <491813EB.3080600@gmx.net> References: <491813EB.3080600@gmx.net> Message-ID: <491AEB2D.7000002@sun.com> Hello Martin, fix looks fine for me in general, just one minor note: There is getBooleanAttribute() method in the GIFMetadata class, which probably should be modified as a part of this fix. This method uses equalsIgnoreCase() to compare attribute values and refers this bug as a reason for this "too tolerant" approach. It also seems to be inconsistent with suggested implementation of similar method in the PNGMetadata class. Could you also provide a regression test for this change? Thanks, Andrew Martin von Gagern wrote: > Bug ID: 5082756; State: 6-Fix Understood, bug; Priority: 4-Low > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082756 > > While the DTDs for the different metdata formats usually specify boolean > values as ( "TRUE" | "FALSE" ), the implementations tend to use "true" > and "false" instead. > > There are two possible approaches to this problem: > 1. Have the implementation match the specification, i.e. use upper case > 2. Adjust the specification to match implementation, i.e. use lower case > While the former has the benefit of only touching internal com.sun > implementation classes, the latter has the long therm benefit that > implementations can use the default String conversion methods from class > Boolean without further case conversion. > > While I would have wished for the specification to use lower case in the > first place, I would now stick with the way it is, and adjust the > implementation to upper case. > > Both approaches can be implemented with different degrees of tolerance > when accepting values: > a) strict: only allow the values also allowed by the DTD > b) two possibilities: allow both "true" and "TRUE" > c) ignore case: also allow "tRuE" > > Here I am in favor of the middle way. This gives you backward > compatibility, but won't allow additional values without reason. The > benefit is that with this it is more likely that an application > developed under OpenJDK will work under other JREs as well. The downside > of course is that applications developed for a JRE that completely > ignores case would fail on OpenJDK. As I expect OpenJDK to have a larger > market share, I would think this less likely to get unnoticed, though. > There is also a slight performance benefit from not allowing mixed case, > but I guess thats negligible here. > > So corresponding to my personal preferences, the attached patch changes > all attribute creations to uppercase, and allows for both cases in > PNGMetadata, but no mixed forms. The GIFMetadata implementation which > already uses equalsIgnoreCase and thus allows for mixed case I left > untouched for the moment. For the sake of consistency, we might to > change that to the more strict two cases instead. > > I haven't any test case ready yet. I'll write one when we are agreed on > the intended behaviour. > > The attached patch is from my mercurial patch queue. Once you consider > it ready for inclusion, I will commit it locally and export a mercurial > patch instead. > > Greetings, > Martin von Gagern > From Martin.vGagern at gmx.net Wed Nov 12 18:29:32 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Wed, 12 Nov 2008 19:29:32 +0100 Subject: [OpenJDK 2D-Dev] 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" In-Reply-To: <491AEB2D.7000002@sun.com> References: <491813EB.3080600@gmx.net> <491AEB2D.7000002@sun.com> Message-ID: <491B208C.9050709@gmx.net> Hello Andrew, Andrew Brygin wrote: > fix looks fine for me in general, just one minor note: Thanks for looking at this. Let me know when you think it ready for inclusion. > There is getBooleanAttribute() method in the GIFMetadata class, which > probably should be modified as a part of this fix. This method uses > equalsIgnoreCase() to compare attribute values and refers this bug > as a reason for this "too tolerant" approach. It also seems to be > inconsistent > with suggested implementation of similar method in the PNGMetadata class. I had mentioned that issue with GIFMetadata in my mail, yes. I now made GIFMetadata behave like PNGMetadata, i.e. only allow strictly upper or strictly lower case, no mixed forms. > Could you also provide a regression test for this change? I wrote a test case. For the formats PNG, JPEG and GIF it merges a native tree containing uppercase versions of every possible boolean value. It then verifies that in the tree generated by asTree the values are still uppercase. The verification is repeated again after the images got written to a stream and were read back. Standard trees are verified as well, though not merged with. The text class divides roughly into two parts. One listing the test cases, consisting of MIME type, Metadata XML and XPath expressions of the values to be checked, the other performs the specified tests. The framework seems pretty flexible and might well be used for other metadata-related tests as well. Do you agree with the imageio/metadata directory, as it affects multiple plugins and duplicating the code seems a bad idea? Greetings, Martin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug5082756.patch URL: From mark at klomp.org Thu Nov 13 12:30:11 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 13 Nov 2008 13:30:11 +0100 Subject: [OpenJDK 2D-Dev] Bug in pisces Renderer (uninitialized crossings) In-Reply-To: <1225791009.3320.4.camel@dijkstra.wildebeest.org> References: <1225119212.3329.29.camel@dijkstra.wildebeest.org> <1225791009.3320.4.camel@dijkstra.wildebeest.org> Message-ID: <1226579411.4563.17.camel@dijkstra.wildebeest.org> Hi, On Tue, 2008-11-04 at 10:30 +0100, Mark Wielaard wrote: > If anybody would take a look at this fix that would be appreciated. Anybody? > On Mon, 2008-10-27 at 15:53 +0100, Mark Wielaard wrote: > > There is a bug in the pisces Renderer in crossingListFinished(). Both > > crossings and crossingIndices might not have been initialized, so have > > to be checked for being null. They only get initialized if > > setCrossingsExtents() was called earlier, which might not always be the > > case when crossingListFinished() is called from _endRendering(). > > > > You can see this with for example this applet (you will need to have the > > IcedTeaPlugin installed): > > http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer > > The magnifying glass will not work, and you will get an exception: > > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > > at sun.java2d.pisces.Renderer.crossingListFinished(Renderer.java:778) > > at sun.java2d.pisces.Renderer._endRendering(Renderer.java:466) > > at sun.java2d.pisces.Renderer.endRendering(Renderer.java:478) > > at sun.java2d.pisces.PiscesRenderingEngine.getAATileGenerator(PiscesRenderingEngine.java:327) > > at sun.java2d.pipe.AAShapePipe.renderPath(AAShapePipe.java:93) > > at sun.java2d.pipe.AAShapePipe.fill(AAShapePipe.java:65) > > at sun.java2d.pipe.ValidatePipe.fill(ValidatePipe.java:160) > > at sun.java2d.SunGraphics2D.fill(SunGraphics2D.java:2422) > > at org.jfree.chart.plot.Plot.fillBackground(Plot.java:1021) > > [...] > > > > Attached is the workaround that I checked into IcedTea to make this work > > reliably: > > > > 2008-10-27 Mark Wielaard > > > > * patches/icedtea-renderer-crossing.patch: New patch. > > * Makefile.am (ICEDTEA_PATCHES): Add new patch. > > * HACKING: Document new patch. > > > > Cheers, > > > > Mark From Igor.Nekrestyanov at Sun.COM Thu Nov 13 17:33:50 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Thu, 13 Nov 2008 20:33:50 +0300 Subject: [OpenJDK 2D-Dev] Bug in pisces Renderer (uninitialized crossings) In-Reply-To: <1226579411.4563.17.camel@dijkstra.wildebeest.org> References: <1225119212.3329.29.camel@dijkstra.wildebeest.org> <1225791009.3320.4.camel@dijkstra.wildebeest.org> <1226579411.4563.17.camel@dijkstra.wildebeest.org> Message-ID: <491C64FE.4070408@sun.com> Hi Mark, your patch looks ok to me but i am not expert in pisces. Alexey Ushakov, who is our expert in pisces should have returned from vacation today and i think he will review this soon. -igor Mark Wielaard wrote: > Hi, > > On Tue, 2008-11-04 at 10:30 +0100, Mark Wielaard wrote: > >> If anybody would take a look at this fix that would be appreciated. >> > > Anybody? > > >> On Mon, 2008-10-27 at 15:53 +0100, Mark Wielaard wrote: >> >>> There is a bug in the pisces Renderer in crossingListFinished(). Both >>> crossings and crossingIndices might not have been initialized, so have >>> to be checked for being null. They only get initialized if >>> setCrossingsExtents() was called earlier, which might not always be the >>> case when crossingListFinished() is called from _endRendering(). >>> >>> You can see this with for example this applet (you will need to have the >>> IcedTeaPlugin installed): >>> http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer >>> The magnifying glass will not work, and you will get an exception: >>> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException >>> at sun.java2d.pisces.Renderer.crossingListFinished(Renderer.java:778) >>> at sun.java2d.pisces.Renderer._endRendering(Renderer.java:466) >>> at sun.java2d.pisces.Renderer.endRendering(Renderer.java:478) >>> at sun.java2d.pisces.PiscesRenderingEngine.getAATileGenerator(PiscesRenderingEngine.java:327) >>> at sun.java2d.pipe.AAShapePipe.renderPath(AAShapePipe.java:93) >>> at sun.java2d.pipe.AAShapePipe.fill(AAShapePipe.java:65) >>> at sun.java2d.pipe.ValidatePipe.fill(ValidatePipe.java:160) >>> at sun.java2d.SunGraphics2D.fill(SunGraphics2D.java:2422) >>> at org.jfree.chart.plot.Plot.fillBackground(Plot.java:1021) >>> [...] >>> >>> Attached is the workaround that I checked into IcedTea to make this work >>> reliably: >>> >>> 2008-10-27 Mark Wielaard >>> >>> * patches/icedtea-renderer-crossing.patch: New patch. >>> * Makefile.am (ICEDTEA_PATCHES): Add new patch. >>> * HACKING: Document new patch. >>> >>> Cheers, >>> >>> Mark >>> > > From Phil.Race at Sun.COM Fri Nov 14 00:57:03 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 13 Nov 2008 16:57:03 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring In-Reply-To: <1224251121.6734.25.camel@moonlight> References: <1224251121.6734.25.camel@moonlight> Message-ID: <491CCCDF.4040606@sun.com> Some comments (at last) : > this is the big FontManager refactoring patch I already mentioned a > couple of times. It's primary purpose is to make the font implementation > more portable (or: portable at all), allowing alternative/derived > implementations to be plugged in. The general architecture breaks down > as follows: Plugging in alternate architectures is somewhat interesting but the refactoring priority I see is that the FontManager class which has grown too large and needs to be "downsized" This is done, which is OK, and the most important part of how this is done is to separate out the platform, and that's partly handled but, not as much as I'd like. For example : SunFontManager.java : getDefaultPlatformFont() seems like a perfect candidate for pushing down into the platform code. The FontConfigManager class should go with it into the X11 side of the code. It would be nice if each of these new classes had its charter documented at the top, in a class comment. SunFontManager DefaultFontManager X11FontManager Win32FontManager FontConfigManager FontUtiltities FontManagerFactory FontScaler I guess previously we had an X11/Win32GE instance for API reasons, but when the font code was moved out to the FontManager subclasses it maybe wasn't needed to make that also have an instance? Is DefaultFontManager really necessary?? Seems not to me. Also a number of changes appear unrelated, eg : make/java/nio/Makefile make/java/nio/spp.sh src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java make/sun/font/mapfile-vers The disappearance of these seems strange .. 40 Java_sun_font_FontManager_getFont2D; 41 Java_sun_font_FontManager_setFont2D; 42 Java_sun_font_FontManager_isCreatedFont; 43 Java_sun_font_FontManager_setCreatedFont; .. ah, I see these are now using reflection In FontUtilities Hmm. I don't think this change should be made 1) As it stands it'll get a SecurityException 2) I'm very dubious about changing the accessibility of these internal methods Looks like a potential security hole. 3) I'd want to such a change separately anyway to test its relative performance. src/share/classes/java/awt/Component.java, and src/windows/classes/sun/awt/windows/WToolkit.java This was left in for a licensee, I'd be inclined to leave it alone unless removing it has definite benefits. 2770 // REMIND: PlatformFont flag should be obsolete soon... 2771 if (sun.font.FontManager.usePlatformFontMetrics()) { 2772 if (peer != null && 2773 !(peer instanceof LightweightPeer)) { 2774 return peer.getFontMetrics(font); 2775 } 2776 } 2777 return sun We don't need these and similar changes, since they aren't pre-defined constants : isSolaris->IS_SOLARIS, isLinux->IS_LINUX ie all caps is just for pre-defined constants, not ones determined at run time. Cmap.java Please try to keep lines <=80 chars, eg line 411 here : 410 if (FontUtilities.isLogging()) { 411 FontUtilities.getLogger().warning("Cmap subtable overflows buffer."); 412 } 413 } BTW code conventions are at http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html CompositeFont.java 57 private SunFontManager fm = null; I don't see why every comp-font needs a ptr to this singleton. PhysicalStrike.java - 29 import java.awt.GraphicsEnvironment; this isn't used ==== I'm not sure about the movement of addToPool() to TrueTypeFont.java Theoretically its independent of the font format, and could apply to any FileFont subclass. also the file closer shut down hook isn't needed except for created fonts from tmp files, so that shouldn't be started unless needed. FontManager.java has a lot of "TODO" comments Why is FontManagerForSGE needed? ie why cannot SunFontManager be the class in which these are defined. Win32FontManager : 22 // FIXME: Windows build still needs to be abstracted from 23 // SunGraphicEnvironment 24 What does that mean? 25 // please, don't reference sgEnv in any other code in this class 26 // use getGraphicsEnvironment. 27 @Deprecated This doesn't seem an appropriate use of deprecated. 28 private static SunGraphicsEnvironment sgEnv = null; 29 -phil. Roman Kennke wrote: > Hi, > > this is the big FontManager refactoring patch I already mentioned a > couple of times. It's primary purpose is to make the font implementation > more portable (or: portable at all), allowing alternative/derived > implementations to be plugged in. The general architecture breaks down > as follows: > > - FontManager: is now a relatively small interface. This is the part > that the AWT API classes (esp. java.awt.Font) talk to. > - FontManagerForSGE: A subinterface of FontManager. > SunGraphicsEnvironment uses this. If you implement a backend based on > SGE, then you also need to implement this. Otherwise you can go with > plain FontManager. > - SunFontManager: A base implementation of FontManager(ForSGE). This has > all the shared code, a lot of stuff that was previously in FontManager > has been moved there. > - X11FontManager, Win32FontManager: The platform specific stuff went > there. > - FontManagerFactory: Creates FontManager instance according to a > property or default. > - SunGraphicsEnvironment: Almost all font-related code has been moved > out of this class. > - FontUtilities: A new utility class. A couple of things from > FontManager went there, i.e. logging, access tricks (get/setFont2D()), > OS determination and general shared stuff. > > For the most part, this was only moving around code, without changing > functionality. However, in some places it was necessary or seemed useful > to change some things: > > - in sunFont.c we can now call the real isDisplayLocal() on the graphics > environment. > - in TrueTypeFont, the handling of the channel pool has been improved. > Before, the cleanup-hook was only initialized when somebody called > Font.createFont(), now it gets initialized whenever a channel is added > to the pool. Is slightly cleaner than before (although I guess it > doesn't matter much, since modern OSes cleanup resources quite well > anyway). > - the FontManager.usePlatformFontMetrics() for windows flag has been > removed. I don't know if this is feasible, but the comments seemed to > indicate that this was the plan anyway. Might break some obscure apps > that rely on buggy code. > > These are all functional changes I can think of from the top off my > head. > > The webrev for this is here: > > http://kennke.org/~roman/fontmanager/webrev/ > > The raw patch can also be downloaded somewhere in the webrev. > > I'd be happy to hear your comments soon. Note that I did only very basic > testing on Windows. It is hellish to setup a build on windows, > especially when you don't have the resources to buy the necessary > licenses... Would be nice if somebody could test the stuff on Windows a > bit more. I hope that this patch is feasible to be included in OpenJDK > mainline, or that we can make it so... > > Cheers, Roman From roman.kennke at aicas.com Fri Nov 14 10:34:37 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 14 Nov 2008 11:34:37 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring In-Reply-To: <491CCCDF.4040606@sun.com> References: <1224251121.6734.25.camel@moonlight> <491CCCDF.4040606@sun.com> Message-ID: <1226658877.8026.18.camel@moonlight> Hi Phil, > Some comments (at last) : Thanks! > > this is the big FontManager refactoring patch I already mentioned a > > couple of times. It's primary purpose is to make the font implementation > > more portable (or: portable at all), allowing alternative/derived > > implementations to be plugged in. The general architecture breaks down > > as follows: > > Plugging in alternate architectures is somewhat interesting but the refactoring > priority I see is that the FontManager class which has grown too large and > needs to be "downsized" This is done, which is OK, and the most important > part of how this is done is to separate out the platform, and that's partly > handled but, not as much as I'd like. For example : SunFontManager.java : > getDefaultPlatformFont() seems like a perfect candidate for pushing > down into the platform code. Yeah, the refactoring isn't complete at all, but I wanted to push what we have now, so that future (parallel) development in the font code, like what you did back then, doesn't get in the way so much. I think I spent one or two whole days merging your changes into this patch. > The FontConfigManager class should go with it into the X11 side of the code. I agree. > It would be nice if each of these new classes had its charter documented > at the top, in a class comment. > SunFontManager > DefaultFontManager > X11FontManager > Win32FontManager > FontConfigManager > FontUtiltities > FontManagerFactory > FontScaler I'll do that. > I guess previously we had an X11/Win32GE instance for API reasons, but when the > font code was moved out to the FontManager subclasses it maybe wasn't > needed to make that also have an instance? I think I don't understand this question. > Is DefaultFontManager really necessary?? Seems not to me. Not really. I think I introduced it because I didn't like to have native methods in SunFontManager, but those native methods can be moved down to the platform classes just as well. I'll fix this. > Also a number of changes appear unrelated, eg : > make/java/nio/Makefile > make/java/nio/spp.sh > src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java > src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java Oh yeah, those probably slipped in accidentally. I'll remove them. > make/sun/font/mapfile-vers > The disappearance of these seems strange .. > 40 Java_sun_font_FontManager_getFont2D; > 41 Java_sun_font_FontManager_setFont2D; > 42 Java_sun_font_FontManager_isCreatedFont; > 43 Java_sun_font_FontManager_setCreatedFont; > .. ah, I see these are now using reflection In FontUtilities > Hmm. I don't think this change should be made > 1) As it stands it'll get a SecurityException Right. > 2) I'm very dubious about changing the accessibility of these internal methods > Looks like a potential security hole. > 3) I'd want to such a change separately anyway to test its relative performance. Actually, what I really would like to have here is to use the SharedSecrets mechanism to be used here. This has a number of advantages: no reflection/JNI is used at all, we have compile time checking, and performance is most likely optimal (no reflection and no java<->jni transitions). If you agree with that, I'll implement this instead. SharedSecrets can also be used in many other places where reflection or JNI is used at the moment. > src/share/classes/java/awt/Component.java, and > src/windows/classes/sun/awt/windows/WToolkit.java > This was left in for a licensee, I'd be inclined to leave it alone > unless removing it has definite benefits. > 2770 // REMIND: PlatformFont flag should be obsolete soon... > 2771 if (sun.font.FontManager.usePlatformFontMetrics()) { > 2772 if (peer != null && > 2773 !(peer instanceof LightweightPeer)) { > 2774 return peer.getFontMetrics(font); > 2775 } > 2776 } > 2777 return sun Ok, then we'll leave them in. Should we change the comment then to sth like 'we leave this in forever for a licensee'? > We don't need these and similar changes, since they aren't pre-defined constants > : > isSolaris->IS_SOLARIS, isLinux->IS_LINUX > > ie all caps is just for pre-defined constants, not ones determined at run time. Ok, no problem. > Cmap.java > Please try to keep lines <=80 chars, eg line 411 here : > 410 if (FontUtilities.isLogging()) { > 411 FontUtilities.getLogger().warning("Cmap subtable overflows > buffer."); > 412 } > 413 } > > BTW code conventions are at > http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html Ok, no problem. > CompositeFont.java > 57 private SunFontManager fm = null; > > I don't see why every comp-font needs a ptr to this singleton. I think this slipped in during refactoring because we'd get an initialization loop otherwise. I think we can remove this now, but I need to check this. > PhysicalStrike.java > - 29 import java.awt.GraphicsEnvironment; > this isn't used > > ==== Yeah right. > I'm not sure about the movement of addToPool() to TrueTypeFont.java > Theoretically its independent of the font format, and could apply > to any FileFont subclass. I was thinking about where to move this code and since it was only used in TrueTypeFont, I moved it there. What do you think would be a good place? The FontManager interface? Or FontUtilities? Or maybe a new think (FontPool??)? > also the file closer shut down hook isn't needed except for created > fonts from tmp files, so that shouldn't be started unless needed. You sure? We add fonts to the pool also in other cases, for each font we open. We don't want to cleanup this pool? > FontManager.java has a lot of "TODO" comments Ooops. I will fill them in. > Why is FontManagerForSGE needed? > ie why cannot SunFontManager be the class in which these are defined. Then a SunGraphicsEnvironment based graphics impl would require a SunFontManager based font impl. In my own graphics implementation that I'm doing, I want to use SunGraphicsEnvironment, but not SunFontManager, because all the font lookup and handling is completely different there (I need to load fonts from system resources - JAR, Classpath, etc - and not from filesystem, because there is no filesystem on some of my target systems). If you don't mind, I'd like to keep it that way. > Win32FontManager : > 22 // FIXME: Windows build still needs to be abstracted from > 23 // SunGraphicEnvironment > 24 > What does that mean? Good question :-) That's probably already solved and should be removed. > 25 // please, don't reference sgEnv in any other code in this class > 26 // use getGraphicsEnvironment. > 27 @Deprecated > This doesn't seem an appropriate use of deprecated. I agree. I'll see if this can be removed completely. Thanks alot Phil, I'll fix the suggested stuff and post another webrev. Cheers, Roman > 28 private static SunGraphicsEnvironment sgEnv = null; > 29 > > -phil. > Roman Kennke wrote: > > Hi, > > > > this is the big FontManager refactoring patch I already mentioned a > > couple of times. It's primary purpose is to make the font implementation > > more portable (or: portable at all), allowing alternative/derived > > implementations to be plugged in. The general architecture breaks down > > as follows: > > > > - FontManager: is now a relatively small interface. This is the part > > that the AWT API classes (esp. java.awt.Font) talk to. > > - FontManagerForSGE: A subinterface of FontManager. > > SunGraphicsEnvironment uses this. If you implement a backend based on > > SGE, then you also need to implement this. Otherwise you can go with > > plain FontManager. > > - SunFontManager: A base implementation of FontManager(ForSGE). This has > > all the shared code, a lot of stuff that was previously in FontManager > > has been moved there. > > - X11FontManager, Win32FontManager: The platform specific stuff went > > there. > > - FontManagerFactory: Creates FontManager instance according to a > > property or default. > > - SunGraphicsEnvironment: Almost all font-related code has been moved > > out of this class. > > - FontUtilities: A new utility class. A couple of things from > > FontManager went there, i.e. logging, access tricks (get/setFont2D()), > > OS determination and general shared stuff. > > > > For the most part, this was only moving around code, without changing > > functionality. However, in some places it was necessary or seemed useful > > to change some things: > > > > - in sunFont.c we can now call the real isDisplayLocal() on the graphics > > environment. > > - in TrueTypeFont, the handling of the channel pool has been improved. > > Before, the cleanup-hook was only initialized when somebody called > > Font.createFont(), now it gets initialized whenever a channel is added > > to the pool. Is slightly cleaner than before (although I guess it > > doesn't matter much, since modern OSes cleanup resources quite well > > anyway). > > - the FontManager.usePlatformFontMetrics() for windows flag has been > > removed. I don't know if this is feasible, but the comments seemed to > > indicate that this was the plan anyway. Might break some obscure apps > > that rely on buggy code. > > > > These are all functional changes I can think of from the top off my > > head. > > > > The webrev for this is here: > > > > http://kennke.org/~roman/fontmanager/webrev/ > > > > The raw patch can also be downloaded somewhere in the webrev. > > > > I'd be happy to hear your comments soon. Note that I did only very basic > > testing on Windows. It is hellish to setup a build on windows, > > especially when you don't have the resources to buy the necessary > > licenses... Would be nice if somebody could test the stuff on Windows a > > bit more. I hope that this patch is feasible to be included in OpenJDK > > mainline, or that we can make it so... > > > > Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From linuxhippy at gmail.com Tue Nov 18 15:51:35 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 18 Nov 2008 16:51:35 +0100 Subject: [OpenJDK 2D-Dev] Question about Bug ID: 6729351 Message-ID: <194f62550811180751v133899aeh9b420371f16f2f09@mail.gmail.com> Hi, Some months ago I filed a bug that filling small RoundRectangle2Ds sometimes does not give round corners: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6729351 For example: > RoundRectangle2D.Float rect = new RoundRectangle2D.Float(10, 10, 20, 20, 5, 5); > g2d.fill(rect); Gives: http://picasaweb.google.com/linuxhippy/RoundRect#5270021310445748898 The evaluation said: > The behaviour of fill operation was changed within the fix of > 4151279 to match draw operation with the same shape. However fill and draw do not match in that case either: http://picasaweb.google.com/linuxhippy/RoundRect#5270025203431615762 So although I think the evaluation is correct, I am just curious whats the cause of such degenerated RoundRectangles? If I set STROKE_PURE the fill is fine, but draw looks "ugly" ;) Another strange behaviour I saw is that RoundRects are drawn differently, when an argb-color is used: http://picasaweb.google.com/linuxhippy/RoundRect#5270025209337038738 I suppose that shouldn't happen? lg Clenebs From dmitri.trembovetski at sun.com Wed Nov 19 01:24:43 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Wed, 19 Nov 2008 01:24:43 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage Message-ID: <20081119012521.E37E4D680@hg.openjdk.java.net> Changeset: 8eb24fc88242 Author: tdv Date: 2008-11-18 17:16 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8eb24fc88242 6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage Reviewed-by: campbell, flar ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp + test/sun/java2d/DirectX/OpaqueImageToSurfaceBlitTest/OpaqueImageToSurfaceBlitTest.java From dmitri.trembovetski at sun.com Wed Nov 19 02:43:02 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Wed, 19 Nov 2008 02:43:02 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista Message-ID: <20081119024341.9B661D6AE@hg.openjdk.java.net> Changeset: 3fea7e660a8f Author: tdv Date: 2008-11-18 18:32 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3fea7e660a8f 6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp ! src/windows/native/sun/java2d/d3d/D3DContext.cpp From mark at klomp.org Thu Nov 20 17:32:22 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 20 Nov 2008 18:32:22 +0100 Subject: [OpenJDK 2D-Dev] Bug in pisces Renderer (uninitialized crossings) In-Reply-To: <491C64FE.4070408@sun.com> References: <1225119212.3329.29.camel@dijkstra.wildebeest.org> <1225791009.3320.4.camel@dijkstra.wildebeest.org> <1226579411.4563.17.camel@dijkstra.wildebeest.org> <491C64FE.4070408@sun.com> Message-ID: <1227202342.3306.33.camel@dijkstra.wildebeest.org> Hi Igor, On Thu, 2008-11-13 at 20:33 +0300, Igor Nekrestyanov wrote: > your patch looks ok to me but i am not expert in pisces. > > Alexey Ushakov, who is our expert in pisces should have returned from > vacation today > and i think he will review this soon. Thanks for looking at it. If I can help with any review, by clarifying anything, please let me know. Cheers, Mark > >>> Attached is the workaround that I checked into IcedTea to make this work > >>> reliably: > >>> > >>> 2008-10-27 Mark Wielaard > >>> > >>> * patches/icedtea-renderer-crossing.patch: New patch. > >>> * Makefile.am (ICEDTEA_PATCHES): Add new patch. > >>> * HACKING: Document new patch. From mark at klomp.org Fri Nov 21 21:51:54 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 21 Nov 2008 22:51:54 +0100 Subject: [OpenJDK 2D-Dev] Bug in pisces Stroker (div by zero) Message-ID: <1227304315.9475.12.camel@hermans.wildebeest.org> Hi, There is a bug in the pisces Stroker in finish(). When ldx and ldy are so small (zero) that lineLength() will return zero, then you will get a div by zero exception. You can see this with for example this webstart application (you will need to have IcedTeaWebstart [netx] installed): http://linuxhippy.blogspot.com/2008/11/jgears2-rendermark.html java.lang.ArithmeticException: / by zero at sun.java2d.pisces.Stroker.finish(Stroker.java:698) at sun.java2d.pisces.Stroker.close(Stroker.java:592) at sun.java2d.pisces.PiscesRenderingEngine.pathTo(PiscesRenderingEngine.java:248) at sun.java2d.pisces.PiscesRenderingEngine.strokeTo(PiscesRenderingEngine.java:231) at sun.java2d.pisces.PiscesRenderingEngine.strokeTo(PiscesRenderingEngine.java:181) at sun.java2d.pisces.PiscesRenderingEngine.strokeTo(PiscesRenderingEngine.java:145) at sun.java2d.pipe.LoopPipe.getStrokeSpans(LoopPipe.java:274) at sun.java2d.x11.X11Renderer.draw(X11Renderer.java:343) at sun.java2d.pipe.ValidatePipe.draw(ValidatePipe.java:154) at sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2392) at JGears2.renderShape(JGears2.java:244) [...] Attached is the workaround that I checked into IcedTea to make this work reliably: 2008-11-21 Mark Wielaard * patches/icedtea-stroker-finish.patch: New patch. * Makefile.am (ICEDTEA_PATCHES): Add new patch. * HACKING: Document new patch. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-stroker-finish.patch Type: text/x-patch Size: 877 bytes Desc: not available URL: From jennifer.godinez at sun.com Tue Nov 25 22:54:16 2008 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 25 Nov 2008 22:54:16 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6653384: Variable "initialized" in class CUPSPrinter is static by mistake Message-ID: <20081125225434.3974DDC4F@hg.openjdk.java.net> Changeset: be363ea85cb4 Author: jgodinez Date: 2008-11-25 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/be363ea85cb4 6653384: Variable "initialized" in class CUPSPrinter is static by mistake Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PrinterJob/GetMediasTest.java From linuxhippy at gmail.com Wed Nov 26 19:16:50 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Nov 2008 20:16:50 +0100 Subject: [OpenJDK 2D-Dev] Disabling offscreen pixmaps by default? Message-ID: <194f62550811261116g24def2d4jea407e0a5767cd33@mail.gmail.com> Hi, Would it be possible to disable offscreen pixmaps by default when running the X11 pipeline and when the xserver is running locally and does not support SHMPIxmaps? EXA based drivers (radeon/intel/nouveau) in general place pixmaps in VRAM which kills performance and don't support SHMPixmaps. Yes, pmoffscreen is sometimes slower, but it avoids really horrible worst-case scenarious which happen on EXA based drivers. And because even antialiased text causes fallbacks, worst case is quite common. I ran some swing benchmarks, and results are horrible when running on top of EXA based drivers, a 5x slowdown is not uncommon here. All major distributions now enable EXA by default, at least when using the intel-driver. I am not sure about radeon, but their EXA implementation is quite solid too - so sooner or later they will also use Exa by default if they do not already default to it. Finally the latest NVidia-Beta driver disables SHMPixmaps by default - however it has smarter migration heuristics which keep the pixmap in sysmem - only causing a ~2x slowdown. - Clemens From Dmitri.Trembovetski at Sun.COM Wed Nov 26 20:42:26 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 26 Nov 2008 12:42:26 -0800 Subject: [OpenJDK 2D-Dev] Disabling offscreen pixmaps by default? In-Reply-To: <194f62550811261116g24def2d4jea407e0a5767cd33@mail.gmail.com> References: <194f62550811261116g24def2d4jea407e0a5767cd33@mail.gmail.com> Message-ID: <492DB4B2.1090608@Sun.COM> Hi Clemens, Clemens Eisserer wrote: > Hi, > > Would it be possible to disable offscreen pixmaps by default when > running the X11 pipeline and when the xserver is running locally and > does not support SHMPIxmaps? Yes, we may have to do that. It can be done under this bug id: 6708580: Java applications slow when EXA enabled If you would like to contribute the fix, be my guest =) We have the code to detect local x server, and whether the shared memory pixmaps are available - so should be relatively easy to implement.. Thanks, Dmitri > EXA based drivers (radeon/intel/nouveau) in general place pixmaps in > VRAM which kills performance and don't support SHMPixmaps. > > Yes, pmoffscreen is sometimes slower, but it avoids really horrible > worst-case scenarious which happen on EXA based drivers. > And because even antialiased text causes fallbacks, worst case is quite common. > I ran some swing benchmarks, and results are horrible when running on > top of EXA based drivers, a 5x slowdown is not uncommon here. > > All major distributions now enable EXA by default, at least when using > the intel-driver. > I am not sure about radeon, but their EXA implementation is quite > solid too - so sooner or later they will also use Exa by default if > they do not already default to it. > Finally the latest NVidia-Beta driver disables SHMPixmaps by default - > however it has smarter migration heuristics which keep the pixmap in > sysmem - only causing a ~2x slowdown. > > - Clemens From pdoubleya at gmail.com Thu Nov 27 15:01:00 2008 From: pdoubleya at gmail.com (Patrick Wright) Date: Thu, 27 Nov 2008 16:01:00 +0100 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app Message-ID: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> Hi First--if necessary, am glad to file a bug for this, but wanted to check and see if there was something I'm missing. In trying to render a table of characters using their Unicode identifiers, I found that the character \u0DDD crashes my JVM as soon as it is rendered to a Swing component. I'm not particularly interested in that character--I am just trying to print out different characters in different fonts to easily track which glyphs are available per font. I found this by accident. I'm writing to this list as I suspect (but don't know) that it may be an issue with the font system. java -version java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) Ubuntu 8.10 uname -r 2.6.27-7-generic Small app that shows the problem: import javax.swing.*; import javax.swing.border.LineBorder; import java.awt.*; import java.awt.event.ActionEvent; public class TestChar { public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { public void run() { new TestChar().run(); } }); } private void run() { JFrame frame = new JFrame("Test Character"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JPanel panel = new JPanel(); final JLabel label = new JLabel("(empty)"); label.setSize(400, 100); label.setBorder(new LineBorder(Color.black)); JButton button = new JButton("Set Char x0DDD"); button.addActionListener(new AbstractAction() { public void actionPerformed(ActionEvent actionEvent) { label.setText(Character.toString('\u0DDD')); } }); panel.add(button); panel.add(label); frame.getContentPane().add(panel); frame.pack(); frame.setVisible(true); } } Run this, then click the button. On my Ubuntu system, clicking the button causes an immediate crash of the VM. Have also tested on OS X java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) and the VM _did not crash_. Output in the Ubuntu console following the crash is attached. If I should just file a bug for this, please let me know. Thanks! Patrick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bad-char-vm-crash.txt URL: From Igor.Nekrestyanov at Sun.COM Thu Nov 27 17:59:58 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Thu, 27 Nov 2008 20:59:58 +0300 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> Message-ID: <492EE01E.60902@sun.com> Hi, thank you for your report! to simplify testcase please do the following: 1) render to the offscreen bufferedimage, so no swing will be involved 2) iterate through list of font files, we need to find which font exactly causes the problem In other words ideal testcase simply draws single character of particular font into the offscreen buffered image. It might be not possible to get it as simple as this but it would be nice if you can try. It is a bit weird it did not crash with 6u7 but this may happen if different physical fonts were used. -igor Patrick Wright wrote: > Hi > > First--if necessary, am glad to file a bug for this, but wanted to > check and see if there was something I'm missing. > > In trying to render a table of characters using their Unicode > identifiers, I found that the character \u0DDD crashes my JVM as soon > as it is rendered to a Swing component. I'm not particularly > interested in that character--I am just trying to print out different > characters in different fonts to easily track which glyphs are > available per font. I found this by accident. I'm writing to this list > as I suspect (but don't know) that it may be an issue with the font > system. > > java -version > java version "1.6.0_10" > Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) > > Ubuntu 8.10 > uname -r > 2.6.27-7-generic > > Small app that shows the problem: > import javax.swing.*; > import javax.swing.border.LineBorder; > import java.awt.*; > import java.awt.event.ActionEvent; > > public class TestChar { > public static void main(String[] args) { > SwingUtilities.invokeLater(new Runnable() { > public void run() { > new TestChar().run(); > } > }); > } > > private void run() { > JFrame frame = new JFrame("Test Character"); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > JPanel panel = new JPanel(); > final JLabel label = new JLabel("(empty)"); > label.setSize(400, 100); > label.setBorder(new LineBorder(Color.black)); > JButton button = new JButton("Set Char x0DDD"); > button.addActionListener(new AbstractAction() { > public void actionPerformed(ActionEvent actionEvent) { > label.setText(Character.toString('\u0DDD')); > } > }); > panel.add(button); > panel.add(label); > > frame.getContentPane().add(panel); > frame.pack(); > frame.setVisible(true); > } > } > > Run this, then click the button. On my Ubuntu system, clicking the > button causes an immediate crash of the VM. Have also tested on OS X > java -version > java version "1.6.0_07" > Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) > > and the VM _did not crash_. > > Output in the Ubuntu console following the crash is attached. > > If I should just file a bug for this, please let me know. > > Thanks! > Patrick > From pdoubleya at gmail.com Thu Nov 27 20:14:48 2008 From: pdoubleya at gmail.com (Patrick Wright) Date: Thu, 27 Nov 2008 21:14:48 +0100 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <492EE01E.60902@sun.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <492EE01E.60902@sun.com> Message-ID: <64efa1ba0811271214g75ffe530r1a781724b21263df@mail.gmail.com> Hi Igor Thanks for the reply. It will take a bit of time to track it down. >From a quick test: 1) rendering just the single glyph to a buffered image, one image per font, succeeds with Sun Java but fails with OpenJDK (will provide the full details once I'm done testing) 2) testing using the Swing button + label fails with both Sun Java and OpenJDK using the default font (e.g. Swing app with no font specified). I'm not sure how I can make Sun Java 6 fail in the buffered image case. For the buffered image case with OpenJDK, I'll work on pulling out a list of fonts that are failing. Hope this isn't any specific combination of font style and size... Will report back once I have the details. Regards Patrick On Thu, Nov 27, 2008 at 6:59 PM, Igor Nekrestyanov wrote: > Hi, > > thank you for your report! > > to simplify testcase please do the following: > 1) render to the offscreen bufferedimage, so no swing will be involved > 2) iterate through list of font files, we need to find which font exactly > causes the problem > > In other words ideal testcase simply draws single character of particular > font into the offscreen buffered image. > It might be not possible to get it as simple as this but it would be nice if > you can try. > > It is a bit weird it did not crash with 6u7 but this may happen if different > physical fonts were used. > > -igor > > Patrick Wright wrote: >> >> Hi >> >> First--if necessary, am glad to file a bug for this, but wanted to >> check and see if there was something I'm missing. >> >> In trying to render a table of characters using their Unicode >> identifiers, I found that the character \u0DDD crashes my JVM as soon >> as it is rendered to a Swing component. I'm not particularly >> interested in that character--I am just trying to print out different >> characters in different fonts to easily track which glyphs are >> available per font. I found this by accident. I'm writing to this list >> as I suspect (but don't know) that it may be an issue with the font >> system. >> >> java -version >> java version "1.6.0_10" >> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >> >> Ubuntu 8.10 >> uname -r >> 2.6.27-7-generic >> >> Small app that shows the problem: >> import javax.swing.*; >> import javax.swing.border.LineBorder; >> import java.awt.*; >> import java.awt.event.ActionEvent; >> >> public class TestChar { >> public static void main(String[] args) { >> SwingUtilities.invokeLater(new Runnable() { >> public void run() { >> new TestChar().run(); >> } >> }); >> } >> >> private void run() { >> JFrame frame = new JFrame("Test Character"); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> JPanel panel = new JPanel(); >> final JLabel label = new JLabel("(empty)"); >> label.setSize(400, 100); >> label.setBorder(new LineBorder(Color.black)); >> JButton button = new JButton("Set Char x0DDD"); >> button.addActionListener(new AbstractAction() { >> public void actionPerformed(ActionEvent actionEvent) { >> label.setText(Character.toString('\u0DDD')); >> } >> }); >> panel.add(button); >> panel.add(label); >> >> frame.getContentPane().add(panel); >> frame.pack(); >> frame.setVisible(true); >> } >> } >> >> Run this, then click the button. On my Ubuntu system, clicking the >> button causes an immediate crash of the VM. Have also tested on OS X >> java -version >> java version "1.6.0_07" >> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) >> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) >> >> and the VM _did not crash_. >> >> Output in the Ubuntu console following the crash is attached. >> >> If I should just file a bug for this, please let me know. >> >> Thanks! >> Patrick >> > > From Igor.Nekrestyanov at Sun.COM Fri Nov 28 06:37:04 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Fri, 28 Nov 2008 09:37:04 +0300 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <64efa1ba0811271121s32725270ob57d29d945ab8475@mail.gmail.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <492EE01E.60902@sun.com> <64efa1ba0811271121s32725270ob57d29d945ab8475@mail.gmail.com> Message-ID: <492F9190.4000904@sun.com> Hi Patrick, thank you for tracking down this problem. >> to simplify testcase please do the following: >> 1) render to the offscreen bufferedimage, so no swing will be involved >> > > Like this? (in a loop) > BufferedImage bimg = gconf.createCompatibleImage(100, 100); > Graphics g = bimg.getGraphics(); > g.setFont(font); > g.drawString(Character.toString('\u0DDD'), 0, 0); > g.dispose(); > yes, this is fine (or you can use new BufferedImage() - saves few lines of code :) ). Please: 1) make sure that font size and other attributes are reasonable. By default you might be rendering fonts of size 1 and then lots of shortcuts will be taken in the font library code (it does not have sense to be too smart if everything is inside 1 pixel) 2) It is better to use not getAllFonts(). Use Font.createFont() on particular font file. For this test you will need to collect list of .ttf/.ttc/.pfa/.pfb files from your system and use them as input. This will make sure we know exact font file and we can look into the font. I.e. the test gets filename as parameter, tries to render this glyph and exits. And you can run it on each file from the list using simple shell script that also prints filename to be tested. The true goal of this exercise is to spot font file which causes crash and identify the way how we use it. Swing is touching several fonts including logical fonts and this adds some noise. That's why i asked to take Swing out of equation. From your other mails it seems you can reproduce crash on particular font file but with openjdk only. This is actually very good start. It can be either problem in the shared code or bugs in both rasterizers (freetype and t2k). Obviously shared code seems to be more probable :) E.g. this can be memory smash and in case of Sun's Java we are lucky and corruption does not affect important memory areas. Can you send me font file causing problem and your test, so i can try this myself? You may also try to update your Swing test and set component font to one you found explicitly - will it still crash with Sun's JDK? -igor > >> 2) iterate through list of font files, we need to find which font exactly >> causes the problem >> > > Ok, but will need to run from a shell script that iterates over the > font list, as the crash is a hard crash (and on a quick test, caused > by the very first font returned by getAllFonts() :)). > > Let me know if the above is a good way to code that, haven't worked > with those APIs in awhile. > > Thanks > Patrick > From pdoubleya at gmail.com Fri Nov 28 12:01:21 2008 From: pdoubleya at gmail.com (Patrick Wright) Date: Fri, 28 Nov 2008 13:01:21 +0100 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <492F9190.4000904@sun.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <492EE01E.60902@sun.com> <64efa1ba0811271121s32725270ob57d29d945ab8475@mail.gmail.com> <492F9190.4000904@sun.com> Message-ID: <64efa1ba0811280401v32f2a167s23a6c513c157ea5c@mail.gmail.com> Hi Igor Have sent you the output of my tests directly to your mailbox, as I was attaching two files. Let me know if I can help further. Cheers Patrick