From t.landschoff at gmx.de Mon Feb 2 22:54:43 2009 From: t.landschoff at gmx.de (Torsten Landschoff) Date: Mon, 2 Feb 2009 23:54:43 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: References: Message-ID: <20090202225443.GA28471@merzeus.obrandt.org> Hello List, A few days before I ran into bug 4494651, after more than 7 years of its existence. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 I was curious how hard it would be to build a fixed OpenJDK, so I spent half of the saturday to get OpenJDK build and its unit tests running. Turned out that it wasn't that hard so here are my changes for you to consider. The first diff contains a trivial unit test derived from the example code in the bug log. The code should speak for itself. Tracing the bug to its origin, I found the interesting lookup table in BufferedImageGraphicsConfig.java which maps each imageType supported by BufferedImage to a BufferedImageGraphicsConfig. I have no idea why that would be a good idea (apart from performance), so the second diff just removes that feature and creates a new graphics configuration each time it is requested. As the only reason why one would create such a lookup table would be to get around performance problems, I wrote a third patch which caches the graphics configurations already retrieved in a weak hash map. Comments welcome. Feel free to apply my code to the OpenJDK code base, I'd be glad to sign the Sun Contributor Agreement if needed for such a trivial contribution. Thanks for all your work, I really enjoy working with Java (and even more with its virtual machine and great libraries). Greetings, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: 4494651-unittest.diff Type: text/x-diff Size: 3947 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 4494651-trivial-fix.diff Type: text/x-diff Size: 2647 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 4494651-cache-configs.diff Type: text/x-diff Size: 2449 bytes Desc: not available URL: From roman.kennke at aicas.com Tue Feb 3 10:46:04 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 03 Feb 2009 11:46:04 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring In-Reply-To: <497E37C8.6060709@sun.com> References: <1224251121.6734.25.camel@moonlight> <491CCCDF.4040606@sun.com> <1228918417.7001.73.camel@moonlight> <496E8E32.2060001@sun.com> <1232221709.21167.8.camel@moonlight> <4974BC82.5010303@sun.com> <1232394271.9701.97.camel@moonlight> <497E37C8.6060709@sun.com> Message-ID: <1233657964.7203.69.camel@moonlight> Hi Phil and everybody, > > Ok, this makes sense now :-) Now I'm thinking that it's probably best to > > go back to the original implementation, except that it's in > > SunFontManager instead of FontManager. Do you agree? > > > > Yes. Ok, I changed it back to the original behaviour. I still think it's not perfect. I'm coming from the point of view of implementing my own FontManager (this is what I'm doing!). Then I have TrueTypeFont depending on SunFontManager (well, not really depending on, but infact no cleanup if it's not). This is not cool. I have no quick solution to this, but here are some ideas: - Change the FontManager interface from createFont2D(File f, ...) to createFont2D(InputStream i,..), and let the font manager care about everything, including how to deal w/ the InputStream. For example, I'd prefer to read the whole file into memory (direct ByteBuffer) and use this as source for TrueTypeFont, because on the systems I'm working on I don't know if I have tmp space on disk. - Do the cleanup in a FontManager-independent way. The FontChannelPool was a start in right direction, but not so useful. And I don't have time right now to make it perfect. - Fix(?) File.deleteOnExit() so that any open channels on that file get closed before actually deleting the file. I don't know if it's considered a bug in File.deleteOnExit() if it fails when any channels are still open, I'd say yes, because cleaning up temporary files is what this API is made for. Should not be so difficult to implement. Just register all open channels w/ the file deletion hook, if there is one, and close them before deleting, just like we do in our hook. Anyway, here's the new webrev: http://kennke.org/~roman/fontmanager4/webrev/ And the zipped version: http://kennke.org/~roman/fontmanager4.zip Have fun! /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 Jennifer.Godinez at Sun.COM Tue Feb 3 17:25:28 2009 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Tue, 03 Feb 2009 09:25:28 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <20090202225443.GA28471@merzeus.obrandt.org> References: <20090202225443.GA28471@merzeus.obrandt.org> Message-ID: <49887E08.60107@Sun.COM> Hi Torsten, Thank you for submitting a patch. We need you to sign Sun Contributor Agreement before we can start working on your patch. The SCA information can be found here: http://openjdk.java.net/contribute/ Once we get the confirmation we will give you an update on the patch. Sincerely, Jennifer Torsten Landschoff wrote: > Hello List, > > A few days before I ran into bug 4494651, after more than 7 years of its > existence. See > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 > > I was curious how hard it would be to build a fixed OpenJDK, so I spent > half of the saturday to get OpenJDK build and its unit tests running. > > Turned out that it wasn't that hard so here are my changes for you to > consider. > > The first diff contains a trivial unit test derived from the example code > in the bug log. The code should speak for itself. > > Tracing the bug to its origin, I found the interesting lookup table in > BufferedImageGraphicsConfig.java which maps each imageType supported by > BufferedImage to a BufferedImageGraphicsConfig. I have no idea why that > would be a good idea (apart from performance), so the second diff just > removes that feature and creates a new graphics configuration each time > it is requested. > > As the only reason why one would create such a lookup table would be to > get around performance problems, I wrote a third patch which caches > the graphics configurations already retrieved in a weak hash map. > > Comments welcome. Feel free to apply my code to the OpenJDK code base, > I'd be glad to sign the Sun Contributor Agreement if needed for such > a trivial contribution. > > > Thanks for all your work, I really enjoy working with Java (and even > more with its virtual machine and great libraries). > > Greetings, Torsten > From t.landschoff at gmx.net Tue Feb 3 21:04:56 2009 From: t.landschoff at gmx.net (Torsten Landschoff) Date: Tue, 3 Feb 2009 22:04:56 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <49887E08.60107@Sun.COM> References: <20090202225443.GA28471@merzeus.obrandt.org> <49887E08.60107@Sun.COM> Message-ID: <20090203210456.GB30339@merzeus.obrandt.org> Hi Jennifer, On Tue, Feb 03, 2009 at 09:25:28AM -0800, Jennifer Godinez wrote: > Thank you for submitting a patch. We need you to sign Sun Contributor > Agreement before we can start working on your patch. The SCA information > can be found here: http://openjdk.java.net/contribute/ Thanks. I just signed the SCA and sent it as a facsimile to the number listed there. > Once we get the confirmation we will give you an update on the patch. Please note that I will be on vacation starting tomorrow up to sunday. So please excuse missing feedback from my side. Greetings, Torsten From Jennifer.Godinez at Sun.COM Tue Feb 3 21:00:36 2009 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Tue, 03 Feb 2009 13:00:36 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <20090203210456.GB30339@merzeus.obrandt.org> References: <20090202225443.GA28471@merzeus.obrandt.org> <49887E08.60107@Sun.COM> <20090203210456.GB30339@merzeus.obrandt.org> Message-ID: <4988B074.8060300@Sun.COM> Thanks! Jennifer Torsten Landschoff wrote: > Hi Jennifer, > > On Tue, Feb 03, 2009 at 09:25:28AM -0800, Jennifer Godinez wrote: >> Thank you for submitting a patch. We need you to sign Sun Contributor >> Agreement before we can start working on your patch. The SCA information >> can be found here: http://openjdk.java.net/contribute/ > > Thanks. I just signed the SCA and sent it as a facsimile to the number > listed there. > >> Once we get the confirmation we will give you an update on the patch. > > Please note that I will be on vacation starting tomorrow up to sunday. > So please excuse missing feedback from my side. > > Greetings, Torsten From andrew.brygin at sun.com Wed Feb 4 11:19:29 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Wed, 04 Feb 2009 11:19:29 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6799583: LogManager shutdown hook may cause a memory leak. Message-ID: <20090204111953.1DCC212733@hg.openjdk.java.net> Changeset: e0a9038939ee Author: bae Date: 2009-02-04 14:06 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e0a9038939ee 6799583: LogManager shutdown hook may cause a memory leak. Reviewed-by: igor, swamyv ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/ClassLoaderLeakTest.java From andrew.brygin at sun.com Fri Feb 6 18:03:36 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 06 Feb 2009 18:03:36 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6800846: REGRESSION: Printing quality degraded with Java 6 compared to 5.0 Message-ID: <20090206180400.6761112C7C@hg.openjdk.java.net> Changeset: b02162077f24 Author: bae Date: 2009-02-06 20:49 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b02162077f24 6800846: REGRESSION: Printing quality degraded with Java 6 compared to 5.0 Reviewed-by: igor, prr ! src/share/native/sun/awt/image/dither.c + test/sun/awt/image/DrawByteBinary.java From Phil.Race at Sun.COM Tue Feb 10 04:10:09 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 09 Feb 2009 20:10:09 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring In-Reply-To: <1233657964.7203.69.camel@moonlight> References: <1224251121.6734.25.camel@moonlight> <491CCCDF.4040606@sun.com> <1228918417.7001.73.camel@moonlight> <496E8E32.2060001@sun.com> <1232221709.21167.8.camel@moonlight> <4974BC82.5010303@sun.com> <1232394271.9701.97.camel@moonlight> <497E37C8.6060709@sun.com> <1233657964.7203.69.camel@moonlight> Message-ID: <4990FE21.4030901@sun.com> Roman Kennke wrote: > annels on that file get > closed before actually deleting the file. I don't know if it's > considered a bug in File.deleteOnExit() if it fails when any channels > are still open, I'd say yes, because cleaning up temporary files is what > this API is made for. Should not be so difficult to implement. Just > register all open channels w/ the file deletion hook, if there is one, > and close them before deleting, just like we do in our hook. > Well, there's a really, really old bug on this : http://bugs.sun.com/view_bug.do?bug_id=4171239 And whilst its number 15 on the bug parade, and the last update was a plan to fix it in 1.7 that was almost 3 years ago so I wouldn't count on it here. > Anyway, here's the new webrev: > > http://kennke.org/~roman/fontmanager4/webrev/ > BTW did you see the code review server announcement. You could upload the webrev there if you prefer, although zips we can archive are still desired. More later .. -phil. > And the zipped version: > > http://kennke.org/~roman/fontmanager4.zip > > Have fun! > > /Roman > > From linuxhippy at gmail.com Mon Feb 16 19:07:21 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 16 Feb 2009 20:07:21 +0100 Subject: [OpenJDK 2D-Dev] Small fix for 6791612 (OGLBat tests are failed in jdk 7 b42) Message-ID: <194f62550902161107s40f10b7clabe1743a6ff0343e@mail.gmail.com> Hi, I just ran into 6791612 while hacking on RenderBuffer. It seems the symbol is not exported for xawt, but it is for mawt. Just added the export to xawt/mapfile-vers, webrev is attached. Thanks, Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 46448 bytes Desc: not available URL: From yamauchi at google.com Wed Feb 18 00:04:26 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 17 Feb 2009 16:04:26 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug Message-ID: Hi, I think I found a bug in the dashed line rendering (i.e., an incompatibility with Sun JDK) and a fix with a test. The problem was the difference in the interpretation of the float array which defines the pattern of dashed lines. I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. Thanks, Hiroshi ---- fix ---- +++ jdk/src/share/classes/sun/java2d/pisces/Dasher.java 2009-02-17 15:05:18.000000000 -0800 @@ -120,7 +120,7 @@ // Normalize so 0 <= phase < dash[0] int idx = 0; - dashOn = false; + dashOn = true; int d; while (phase >= (d = dash[idx])) { phase -= d; ---- test ---- import java.awt.*; import java.awt.image.*; import javax.imageio.*; import java.io.*; public class DashTest { public static void main(String[] argv) throws Exception { BufferedImage image =new BufferedImage(100, 100, BufferedImage.TYPE_INT_RGB); Graphics2D graphics = image.createGraphics(); graphics.setColor(Color.WHITE); graphics.fillRect(0, 0, 100, 100); graphics.setColor(Color.BLACK); graphics.setStroke(new BasicStroke(2f, BasicStroke.CAP_BUTT, BasicStroke.JOIN_MITER, 10f, new float[] {1f, 4f}, 0f)); graphics.drawRect(10, 10, 80, 80); ImageIO.write(image, "PNG", new File(argv[0])); } } From Dmitri.Trembovetski at Sun.COM Wed Feb 18 02:13:47 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 17 Feb 2009 18:13:47 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <20090202225443.GA28471@merzeus.obrandt.org> References: <20090202225443.GA28471@merzeus.obrandt.org> Message-ID: <499B6EDB.4020109@Sun.COM> Note that this fix may have some performance implications for cases when there are caches based on the graphics configuration of the Graphics object used for rendering - these caches may grow uncontrollably. I don't know of any other solution for this bug, but I'm not sure fixing it would do more harm than good. The bug has only 3 votes after 8 years (all of them in 2001-2002).. Thanks, Dmitri Torsten Landschoff wrote: > Hello List, > > A few days before I ran into bug 4494651, after more than 7 years of its > existence. See > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 > > I was curious how hard it would be to build a fixed OpenJDK, so I spent > half of the saturday to get OpenJDK build and its unit tests running. > > Turned out that it wasn't that hard so here are my changes for you to > consider. > > The first diff contains a trivial unit test derived from the example code > in the bug log. The code should speak for itself. > > Tracing the bug to its origin, I found the interesting lookup table in > BufferedImageGraphicsConfig.java which maps each imageType supported by > BufferedImage to a BufferedImageGraphicsConfig. I have no idea why that > would be a good idea (apart from performance), so the second diff just > removes that feature and creates a new graphics configuration each time > it is requested. > > As the only reason why one would create such a lookup table would be to > get around performance problems, I wrote a third patch which caches > the graphics configurations already retrieved in a weak hash map. > > Comments welcome. Feel free to apply my code to the OpenJDK code base, > I'd be glad to sign the Sun Contributor Agreement if needed for such > a trivial contribution. > > > Thanks for all your work, I really enjoy working with Java (and even > more with its virtual machine and great libraries). > > Greetings, Torsten > From Jim.A.Graham at Sun.COM Wed Feb 18 02:27:43 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 17 Feb 2009 18:27:43 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <499B6EDB.4020109@Sun.COM> References: <20090202225443.GA28471@merzeus.obrandt.org> <499B6EDB.4020109@Sun.COM> Message-ID: <0KF8003O1OMO6650@fe-sfbay-09.sun.com> The width and height of a GraphicsConfig is essentially irrelevant information. If you get the GraphicsConfig of a component, it doesn't tell you how big that component was, so why should the GC of a BufImg bear any relation to the dimensions of the image? If anything, I'd fix it by having it report some fixed bogus (positive, large) dimensions rather than the dimensions of the first image that it was created from... ...jim Dmitri Trembovetski wrote: > > Note that this fix may have some performance > implications for cases when there are caches based on the > graphics configuration of the Graphics object used for > rendering - these caches may grow uncontrollably. > > I don't know of any other solution for this bug, but I'm > not sure fixing it would do more harm than good. > The bug has only 3 votes after 8 years (all of them > in 2001-2002).. > > Thanks, > Dmitri > > > Torsten Landschoff wrote: >> Hello List, >> >> A few days before I ran into bug 4494651, after more than 7 years of >> its existence. See >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 >> >> I was curious how hard it would be to build a fixed OpenJDK, so I >> spent half of the saturday to get OpenJDK build and its unit tests >> running. >> >> Turned out that it wasn't that hard so here are my changes for you to >> consider. >> >> The first diff contains a trivial unit test derived from the example >> code in the bug log. The code should speak for itself. >> >> Tracing the bug to its origin, I found the interesting lookup table in >> BufferedImageGraphicsConfig.java which maps each imageType supported >> by BufferedImage to a BufferedImageGraphicsConfig. I have no idea why >> that would be a good idea (apart from performance), so the second diff >> just removes that feature and creates a new graphics configuration >> each time it is requested. >> >> As the only reason why one would create such a lookup table would be >> to get around performance problems, I wrote a third patch which caches >> the graphics configurations already retrieved in a weak hash map. >> >> Comments welcome. Feel free to apply my code to the OpenJDK code base, >> I'd be glad to sign the Sun Contributor Agreement if needed for such a >> trivial contribution. >> >> >> Thanks for all your work, I really enjoy working with Java (and even >> more with its virtual machine and great libraries). >> >> Greetings, Torsten >> From Jim.A.Graham at Sun.COM Wed Feb 18 02:30:36 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 17 Feb 2009 18:30:36 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <499B6EDB.4020109@Sun.COM> References: <20090202225443.GA28471@merzeus.obrandt.org> <499B6EDB.4020109@Sun.COM> Message-ID: <0KF8002TJPN0I650@fe-sfbay-10.sun.com> Note that, per my previous email - this could easily be just closed as "not a bug", though it might be nice to change it so the bounds were completely unrelated to any specific image rather than randomly set to the first image that was queried. In other words, I'd rewrite the bug synopsis as something like: GC reports random bounds (that happen to match first img) and then hardcode some interesting bounds instead (perhaps the maximum supported image bounds - which we've never implemented or documented, but perhaps it would be a good way to introduce this concept for the future?)... ...jim Dmitri Trembovetski wrote: > > Note that this fix may have some performance > implications for cases when there are caches based on the > graphics configuration of the Graphics object used for > rendering - these caches may grow uncontrollably. > > I don't know of any other solution for this bug, but I'm > not sure fixing it would do more harm than good. > The bug has only 3 votes after 8 years (all of them > in 2001-2002).. > > Thanks, > Dmitri > > > Torsten Landschoff wrote: >> Hello List, >> >> A few days before I ran into bug 4494651, after more than 7 years of >> its existence. See >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 >> >> I was curious how hard it would be to build a fixed OpenJDK, so I >> spent half of the saturday to get OpenJDK build and its unit tests >> running. >> >> Turned out that it wasn't that hard so here are my changes for you to >> consider. >> >> The first diff contains a trivial unit test derived from the example >> code in the bug log. The code should speak for itself. >> >> Tracing the bug to its origin, I found the interesting lookup table in >> BufferedImageGraphicsConfig.java which maps each imageType supported >> by BufferedImage to a BufferedImageGraphicsConfig. I have no idea why >> that would be a good idea (apart from performance), so the second diff >> just removes that feature and creates a new graphics configuration >> each time it is requested. >> >> As the only reason why one would create such a lookup table would be >> to get around performance problems, I wrote a third patch which caches >> the graphics configurations already retrieved in a weak hash map. >> >> Comments welcome. Feel free to apply my code to the OpenJDK code base, >> I'd be glad to sign the Sun Contributor Agreement if needed for such a >> trivial contribution. >> >> >> Thanks for all your work, I really enjoy working with Java (and even >> more with its virtual machine and great libraries). >> >> Greetings, Torsten >> From Jim.A.Graham at Sun.COM Wed Feb 18 02:39:44 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 17 Feb 2009 18:39:44 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <0KF8002TJPN0I650@fe-sfbay-10.sun.com> References: <20090202225443.GA28471@merzeus.obrandt.org> <499B6EDB.4020109@Sun.COM> <0KF8002TJPN0I650@fe-sfbay-10.sun.com> Message-ID: <0KF8003J2P6O6690@fe-sfbay-09.sun.com> In fact, I've just updated the synopsis and evaluated the bug along these lines... ;-) ...jim Jim Graham wrote: > Note that, per my previous email - this could easily be just closed as > "not a bug", though it might be nice to change it so the bounds were > completely unrelated to any specific image rather than randomly set to > the first image that was queried. > > In other words, I'd rewrite the bug synopsis as something like: > > GC reports random bounds (that happen to match first img) > > and then hardcode some interesting bounds instead (perhaps the maximum > supported image bounds - which we've never implemented or documented, > but perhaps it would be a good way to introduce this concept for the > future?)... > > ...jim > > Dmitri Trembovetski wrote: >> >> Note that this fix may have some performance >> implications for cases when there are caches based on the >> graphics configuration of the Graphics object used for >> rendering - these caches may grow uncontrollably. >> >> I don't know of any other solution for this bug, but I'm >> not sure fixing it would do more harm than good. >> The bug has only 3 votes after 8 years (all of them >> in 2001-2002).. >> >> Thanks, >> Dmitri >> >> >> Torsten Landschoff wrote: >>> Hello List, >>> >>> A few days before I ran into bug 4494651, after more than 7 years of >>> its existence. See >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 >>> >>> I was curious how hard it would be to build a fixed OpenJDK, so I >>> spent half of the saturday to get OpenJDK build and its unit tests >>> running. >>> >>> Turned out that it wasn't that hard so here are my changes for you to >>> consider. >>> >>> The first diff contains a trivial unit test derived from the example >>> code in the bug log. The code should speak for itself. >>> >>> Tracing the bug to its origin, I found the interesting lookup table >>> in BufferedImageGraphicsConfig.java which maps each imageType >>> supported by BufferedImage to a BufferedImageGraphicsConfig. I have >>> no idea why that would be a good idea (apart from performance), so >>> the second diff just removes that feature and creates a new graphics >>> configuration each time it is requested. >>> >>> As the only reason why one would create such a lookup table would be >>> to get around performance problems, I wrote a third patch which >>> caches the graphics configurations already retrieved in a weak hash map. >>> >>> Comments welcome. Feel free to apply my code to the OpenJDK code >>> base, I'd be glad to sign the Sun Contributor Agreement if needed for >>> such a trivial contribution. >>> >>> >>> Thanks for all your work, I really enjoy working with Java (and even >>> more with its virtual machine and great libraries). >>> >>> Greetings, Torsten >>> From mark at klomp.org Wed Feb 18 10:32:59 2009 From: mark at klomp.org (Mark Wielaard) Date: Wed, 18 Feb 2009 11:32:59 +0100 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: References: Message-ID: <1234953179.2322.25.camel@fedora.wildebeest.org> Hi Hiroshi, On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: > I think I found a bug in the dashed line rendering (i.e., an > incompatibility with Sun JDK) and a fix with a test. > The problem was the difference in the interpretation of the float > array which defines the pattern of dashed lines. > I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. You might have found the same issue that Omair tried to fix a while ago: http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html I thought that patch did go in recently, but the thread seems inconclusive about whether or not someone reviewed it. Cheers, Mark From omajid at redhat.com Wed Feb 18 15:08:33 2009 From: omajid at redhat.com (Omair Majid) Date: Wed, 18 Feb 2009 10:08:33 -0500 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: <1234953179.2322.25.camel@fedora.wildebeest.org> References: <1234953179.2322.25.camel@fedora.wildebeest.org> Message-ID: <499C2471.30209@redhat.com> Mark Wielaard wrote: > Hi Hiroshi, > > On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >> I think I found a bug in the dashed line rendering (i.e., an >> incompatibility with Sun JDK) and a fix with a test. >> The problem was the difference in the interpretation of the float >> array which defines the pattern of dashed lines. >> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. > > You might have found the same issue that Omair tried to fix a while ago: > http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html > > I thought that patch did go in recently, but the thread seems > inconclusive about whether or not someone reviewed it. Jennifer Godinez was kind enough to review the patch and write up a jtreg test for it. Cheers, Omair From Phil.Race at Sun.COM Wed Feb 18 17:17:47 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 18 Feb 2009 09:17:47 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: <499C2471.30209@redhat.com> References: <1234953179.2322.25.camel@fedora.wildebeest.org> <499C2471.30209@redhat.com> Message-ID: <499C42BB.1030308@sun.com> Yes, its the same bug. http://bugs.sun.com/view_bug.do?bug_id=6793344 Its fixed in the 2D repo on openjdk, but isn't yet integrated into jdk7 master. -phil. Omair Majid wrote: > Mark Wielaard wrote: >> Hi Hiroshi, >> >> On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >>> I think I found a bug in the dashed line rendering (i.e., an >>> incompatibility with Sun JDK) and a fix with a test. >>> The problem was the difference in the interpretation of the float >>> array which defines the pattern of dashed lines. >>> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. >> >> You might have found the same issue that Omair tried to fix a while ago: >> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html >> >> I thought that patch did go in recently, but the thread seems >> inconclusive about whether or not someone reviewed it. > > Jennifer Godinez was kind enough to review the patch and write up a > jtreg test for it. > > Cheers, > Omair From Phil.Race at Sun.COM Wed Feb 18 20:20:35 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 18 Feb 2009 12:20:35 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: References: <1234953179.2322.25.camel@fedora.wildebeest.org> <499C2471.30209@redhat.com> <499C42BB.1030308@sun.com> Message-ID: <499C6D93.30104@sun.com> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000651.html -phil. Hiroshi Yamauchi wrote: > Aha. Can someone point me to the Mercurial changeset URL of the patch? > I'd like to use the existing patch. > > Thanks! > > On Wed, Feb 18, 2009 at 9:17 AM, Phil Race wrote: >> Yes, its the same bug. http://bugs.sun.com/view_bug.do?bug_id=6793344 >> >> Its fixed in the 2D repo on openjdk, but isn't yet integrated into jdk7 >> master. >> >> -phil. >> >> Omair Majid wrote: >>> Mark Wielaard wrote: >>>> Hi Hiroshi, >>>> >>>> On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >>>>> I think I found a bug in the dashed line rendering (i.e., an >>>>> incompatibility with Sun JDK) and a fix with a test. >>>>> The problem was the difference in the interpretation of the float >>>>> array which defines the pattern of dashed lines. >>>>> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. >>>> You might have found the same issue that Omair tried to fix a while ago: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html >>>> >>>> I thought that patch did go in recently, but the thread seems >>>> inconclusive about whether or not someone reviewed it. >>> Jennifer Godinez was kind enough to review the patch and write up a jtreg >>> test for it. >>> >>> Cheers, >>> Omair From yamauchi at google.com Wed Feb 18 22:04:52 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 18 Feb 2009 14:04:52 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: <499C6D93.30104@sun.com> References: <1234953179.2322.25.camel@fedora.wildebeest.org> <499C2471.30209@redhat.com> <499C42BB.1030308@sun.com> <499C6D93.30104@sun.com> Message-ID: Thanks, Phil. On Wed, Feb 18, 2009 at 12:20 PM, Phil Race wrote: > http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000651.html > > -phil. > > Hiroshi Yamauchi wrote: >> >> Aha. Can someone point me to the Mercurial changeset URL of the patch? >> I'd like to use the existing patch. >> >> Thanks! >> >> On Wed, Feb 18, 2009 at 9:17 AM, Phil Race wrote: >>> >>> Yes, its the same bug. http://bugs.sun.com/view_bug.do?bug_id=6793344 >>> >>> Its fixed in the 2D repo on openjdk, but isn't yet integrated into jdk7 >>> master. >>> >>> -phil. >>> >>> Omair Majid wrote: >>>> >>>> Mark Wielaard wrote: >>>>> >>>>> Hi Hiroshi, >>>>> >>>>> On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >>>>>> >>>>>> I think I found a bug in the dashed line rendering (i.e., an >>>>>> incompatibility with Sun JDK) and a fix with a test. >>>>>> The problem was the difference in the interpretation of the float >>>>>> array which defines the pattern of dashed lines. >>>>>> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. >>>>> >>>>> You might have found the same issue that Omair tried to fix a while >>>>> ago: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html >>>>> >>>>> I thought that patch did go in recently, but the thread seems >>>>> inconclusive about whether or not someone reviewed it. >>>> >>>> Jennifer Godinez was kind enough to review the patch and write up a >>>> jtreg >>>> test for it. >>>> >>>> Cheers, >>>> Omair > From yamauchi at google.com Wed Feb 18 22:04:52 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 18 Feb 2009 14:04:52 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: <499C6D93.30104@sun.com> References: <1234953179.2322.25.camel@fedora.wildebeest.org> <499C2471.30209@redhat.com> <499C42BB.1030308@sun.com> <499C6D93.30104@sun.com> Message-ID: Thanks, Phil. On Wed, Feb 18, 2009 at 12:20 PM, Phil Race wrote: > http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000651.html > > -phil. > > Hiroshi Yamauchi wrote: >> >> Aha. Can someone point me to the Mercurial changeset URL of the patch? >> I'd like to use the existing patch. >> >> Thanks! >> >> On Wed, Feb 18, 2009 at 9:17 AM, Phil Race wrote: >>> >>> Yes, its the same bug. http://bugs.sun.com/view_bug.do?bug_id=6793344 >>> >>> Its fixed in the 2D repo on openjdk, but isn't yet integrated into jdk7 >>> master. >>> >>> -phil. >>> >>> Omair Majid wrote: >>>> >>>> Mark Wielaard wrote: >>>>> >>>>> Hi Hiroshi, >>>>> >>>>> On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >>>>>> >>>>>> I think I found a bug in the dashed line rendering (i.e., an >>>>>> incompatibility with Sun JDK) and a fix with a test. >>>>>> The problem was the difference in the interpretation of the float >>>>>> array which defines the pattern of dashed lines. >>>>>> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. >>>>> >>>>> You might have found the same issue that Omair tried to fix a while >>>>> ago: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html >>>>> >>>>> I thought that patch did go in recently, but the thread seems >>>>> inconclusive about whether or not someone reviewed it. >>>> >>>> Jennifer Godinez was kind enough to review the patch and write up a >>>> jtreg >>>> test for it. >>>> >>>> Cheers, >>>> Omair > From yamauchi at google.com Wed Feb 18 19:58:53 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 18 Feb 2009 11:58:53 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: <499C42BB.1030308@sun.com> References: <1234953179.2322.25.camel@fedora.wildebeest.org> <499C2471.30209@redhat.com> <499C42BB.1030308@sun.com> Message-ID: Aha. Can someone point me to the Mercurial changeset URL of the patch? I'd like to use the existing patch. Thanks! On Wed, Feb 18, 2009 at 9:17 AM, Phil Race wrote: > Yes, its the same bug. http://bugs.sun.com/view_bug.do?bug_id=6793344 > > Its fixed in the 2D repo on openjdk, but isn't yet integrated into jdk7 > master. > > -phil. > > Omair Majid wrote: >> >> Mark Wielaard wrote: >>> >>> Hi Hiroshi, >>> >>> On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >>>> >>>> I think I found a bug in the dashed line rendering (i.e., an >>>> incompatibility with Sun JDK) and a fix with a test. >>>> The problem was the difference in the interpretation of the float >>>> array which defines the pattern of dashed lines. >>>> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. >>> >>> You might have found the same issue that Omair tried to fix a while ago: >>> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html >>> >>> I thought that patch did go in recently, but the thread seems >>> inconclusive about whether or not someone reviewed it. >> >> Jennifer Godinez was kind enough to review the patch and write up a jtreg >> test for it. >> >> Cheers, >> Omair > From Dmitri.Trembovetski at Sun.COM Wed Feb 18 23:39:03 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 18 Feb 2009 15:39:03 -0800 Subject: [OpenJDK 2D-Dev] Dashed line bug In-Reply-To: References: <1234953179.2322.25.camel@fedora.wildebeest.org> <499C2471.30209@redhat.com> <499C42BB.1030308@sun.com> Message-ID: <499C9C17.50401@Sun.COM> Hiroshi Yamauchi wrote: > Aha. Can someone point me to the Mercurial changeset URL of the patch? > I'd like to use the existing patch. As per earlier Phil's email which pointed to this post: http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000651.html the revision is http://hg.openjdk.java.net/jdk7/2d/jdk/rev/65cada5a8497 Dmitri > > Thanks! > > On Wed, Feb 18, 2009 at 9:17 AM, Phil Race wrote: >> Yes, its the same bug. http://bugs.sun.com/view_bug.do?bug_id=6793344 >> >> Its fixed in the 2D repo on openjdk, but isn't yet integrated into jdk7 >> master. >> >> -phil. >> >> Omair Majid wrote: >>> Mark Wielaard wrote: >>>> Hi Hiroshi, >>>> >>>> On Tue, 2009-02-17 at 16:04 -0800, Hiroshi Yamauchi wrote: >>>>> I think I found a bug in the dashed line rendering (i.e., an >>>>> incompatibility with Sun JDK) and a fix with a test. >>>>> The problem was the difference in the interpretation of the float >>>>> array which defines the pattern of dashed lines. >>>>> I confirmed that this bug exists in openjdk6 b11 and openjdk7 b47. >>>> You might have found the same issue that Omair tried to fix a while ago: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2009-January/000620.html >>>> >>>> I thought that patch did go in recently, but the thread seems >>>> inconclusive about whether or not someone reviewed it. >>> Jennifer Godinez was kind enough to review the patch and write up a jtreg >>> test for it. >>> >>> Cheers, >>> Omair From yamauchi at google.com Thu Feb 19 04:28:14 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 18 Feb 2009 20:28:14 -0800 Subject: [OpenJDK 2D-Dev] miter line join bug Message-ID: Hi, Here's a miter bugfix, and a test. Thanks, Hiroshi ---- bug ---- The miter line join decoration isn't rendered properly. ---- fix ---- +++ jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java 2009-02-18 17:14:05.000000000 -0800 @@ -245,6 +245,7 @@ FloatToS15_16(coords[1])); break; case PathIterator.SEG_CLOSE: + lsink.lineJoin(); lsink.close(); break; default: ---- test ---- public class JoinMiterTest { public static void main(String[] args) throws Exception { BufferedImage image = new BufferedImage(200, 200, BufferedImage.TYPE_INT_RGB); Graphics2D g = image.createGraphics(); g.setPaint(Color.WHITE); g.fill(new Rectangle(image.getWidth(), image.getHeight())); g.translate(25, 100); g.setPaint(Color.BLACK); g.setStroke(new BasicStroke(20, BasicStroke.CAP_BUTT, BasicStroke.JOIN_MITER)); g.draw(new Polygon(new int[] {0, 150, 0}, new int[] {75, 0, -75}, 3)); ImageIO.write(image, "PNG", new File(args[0])); } } From Phil.Race at Sun.COM Thu Feb 19 05:48:17 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 18 Feb 2009 21:48:17 -0800 Subject: [OpenJDK 2D-Dev] miter line join bug In-Reply-To: References: Message-ID: <499CF2A1.5040606@sun.com> Without verifying the proposed fix itself, the problem I see here is that this test doesn't appear to be automated. See the one for the dashed line bug for ideas on automation. For the record: we require that tests be provided and automated if at all feasible, or there must be a justification why its not provided or feasible be provided. Fixes which don't provide this will be pended once this is noted. Reviewers will likewise reject fixes that don't conform. The reason for this requirement is that its then possible to test the fix on all platforms with minimal effort. A fix that isn't automated likely won't be tested and isn't worth much. -phil. Hiroshi Yamauchi wrote: > Hi, > > Here's a miter bugfix, and a test. > > Thanks, > Hiroshi > > ---- bug ---- > The miter line join decoration isn't rendered properly. > > ---- fix ---- > +++ jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java 2009-02-18 > 17:14:05.000000000 -0800 > @@ -245,6 +245,7 @@ > FloatToS15_16(coords[1])); > break; > case PathIterator.SEG_CLOSE: > + lsink.lineJoin(); > lsink.close(); > break; > default: > > ---- test ---- > public class JoinMiterTest { > public static void main(String[] args) throws Exception { > BufferedImage image = new BufferedImage(200, 200, > BufferedImage.TYPE_INT_RGB); > Graphics2D g = image.createGraphics(); > g.setPaint(Color.WHITE); > g.fill(new Rectangle(image.getWidth(), image.getHeight())); > g.translate(25, 100); > g.setPaint(Color.BLACK); > g.setStroke(new BasicStroke(20, BasicStroke.CAP_BUTT, > BasicStroke.JOIN_MITER)); > g.draw(new Polygon(new int[] {0, 150, 0}, new int[] {75, 0, -75}, > 3)); > ImageIO.write(image, "PNG", new File(args[0])); > } > } > From t.landschoff at gmx.net Sun Feb 22 01:00:19 2009 From: t.landschoff at gmx.net (Torsten Landschoff) Date: Sun, 22 Feb 2009 02:00:19 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <499B6EDB.4020109@Sun.COM> References: <20090202225443.GA28471@merzeus.obrandt.org> <499B6EDB.4020109@Sun.COM> Message-ID: <20090222010019.GA6453@merzeus.obrandt.org> Hi Dmitri, On Tue, Feb 17, 2009 at 06:13:47PM -0800, Dmitri Trembovetski wrote: > > Note that this fix may have some performance > implications for cases when there are caches based on the > graphics configuration of the Graphics object used for > rendering - these caches may grow uncontrollably. I don't see how this could happen with either of my patches: a) The trivial approach will create a new GraphicsConfiguration instance on each call to Graphics2D#getDeviceConfiguration. Which I would expect as the JavaDoc states that it "Returns the device configuration associated with this Graphics2D.". Reference: http://java.sun.com/javase/6/docs/api/java/awt/Graphics2D.html#getDeviceConfiguration() b) My second patch uses a WeakHashMap to cache the already retrieved graphics configuration instances. I would expect it to be faster for very few instances cached and slower when many instances are cached. So I don't think it's worth the effort. Anyway, assuming that the WeakHashMap will clean up left-over keys, this implementation should keep at most as many graphics configuration instances as there are Graphics2D instances referring to BufferedImages, for which getDeviceConfiguration was called. What am I missing? > I don't know of any other solution for this bug, but I'm > not sure fixing it would do more harm than good. > The bug has only 3 votes after 8 years (all of them > in 2001-2002).. Is it better to leave a known bug unfixed for fears of performance regressions? While this bug goes unnoticed for long time, actually finding it (even though it is recorded) can consume a lot of developer time. Greetings, Torsten From t.landschoff at gmx.net Sun Feb 22 01:37:37 2009 From: t.landschoff at gmx.net (Torsten Landschoff) Date: Sun, 22 Feb 2009 02:37:37 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <0KF8003J2P6O6690@fe-sfbay-09.sun.com> References: <20090202225443.GA28471@merzeus.obrandt.org> <499B6EDB.4020109@Sun.COM> <0KF8002TJPN0I650@fe-sfbay-10.sun.com> <0KF8003J2P6O6690@fe-sfbay-09.sun.com> Message-ID: <20090222013737.GB6453@merzeus.obrandt.org> Hi Jim, On Tue, Feb 17, 2009 at 06:27:43PM -0800, Jim Graham wrote: > The width and height of a GraphicsConfig is essentially irrelevant > information. If you get the GraphicsConfig of a component, it doesn't Why is there a method then to query irrelevant information? > tell you how big that component was, so why should the GC of a BufImg > bear any relation to the dimensions of the image? Why would the graphics configuration contain the size of the component? Quoting the docs: "The GraphicsConfiguration class describes the characteristics of a graphics destination such as a printer or monitor." Therefore I would expect the bounds to match the size of the screen I am painting to, not the size of the component. The use case for me was to fix a drawing routine which made two passes over the input data to have the second pass paint over the first. This turned out to be quite slow with the main time going into loading the data. So I optimized it to paint in one pass, by using a BufferedImage to paint the overlay data and merge it later. The only object that could give me the size of the output Graphics device was - surprise - the Graphics2D instance. This works fine when drawing directly to the screen, but unfortunately not when double buffering is used. I think this is a very valid use case. > If anything, I'd fix it by having it report some fixed bogus (positive, > large) dimensions rather than the dimensions of the first image that it > was created from... Why? Code calling it will only fall over with that, perhaps even worse than the status quo when expecting valid values. Using negative dimensions for example would clearly mark the data as invalid, but in my case would lead to IllegalArgumentException in the BufferedImage constructor (as I take the sizes at face value). If you really want to disable usable functionality in an update to the JDK, I'd suggest to use UnsupportedOperationException so that the caller at least knows what is going on. Anyway, I don't understand the fuss about such a simple code change. Maybe it will eat some cycles and a bit of memory, but there is not even a comment in the original BufferedImageGraphicsConfig code why that hack there is really needed. I find it curious that all but the indexed image type configurations are cached and it seems not be a problem there: 47 private static final int numconfigs = BufferedImage.TYPE_BYTE_BINARY; ==> the highest image type is public static final int TYPE_BYTE_INDEXED = 13; 48 private static BufferedImageGraphicsConfig configs[] = 49 new BufferedImageGraphicsConfig[numconfigs]; 50 51 public static BufferedImageGraphicsConfig getConfig(BufferedImage bImg) { 52 BufferedImageGraphicsConfig ret; 53 int type = bImg.getType(); 54 if (type > 0 && type < numconfigs) { 55 ret = configs[type]; 56 if (ret != null) { On Tue, Feb 17, 2009 at 06:30:36PM -0800, Jim Graham wrote: > Note that, per my previous email - this could easily be just closed as > "not a bug", though it might be nice to change it so the bounds were > completely unrelated to any specific image rather than randomly set to > the first image that was queried. The Java API docs state that getBounds() will return the bounds in device coordinates. You say that information is irrelevant, so it is not a bug? What value do the API docs have then? > In other words, I'd rewrite the bug synopsis as something like: > > GC reports random bounds (that happen to match first img) > > and then hardcode some interesting bounds instead (perhaps the maximum > supported image bounds - which we've never implemented or documented, > but perhaps it would be a good way to introduce this concept for the > future?)... I think that would be a slippery slope as this could depend on the amount of virtual memory - which is hard to measure, and even then nobody would like to have the crawling speed. On Tue, Feb 17, 2009 at 06:39:44PM -0800, Jim Graham wrote: > In fact, I've just updated the synopsis and evaluated the bug along > these lines... ;-) Where can I read the updated bug entry? The URL known to me is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 and its content did not change (apart from some CSS hickups the last few days). Greetings, Torsten From yamauchi at google.com Mon Feb 23 21:59:21 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 23 Feb 2009 13:59:21 -0800 Subject: [OpenJDK 2D-Dev] miter line join bug In-Reply-To: <499CF2A1.5040606@sun.com> References: <499CF2A1.5040606@sun.com> Message-ID: Here's an automated test. import java.awt.*; import java.awt.image.BufferedImage; public class JoinMiterTest { public static void main(String[] args) throws Exception { BufferedImage image = new BufferedImage(200, 200, BufferedImage.TYPE_INT_RGB); Graphics2D g = image.createGraphics(); g.setPaint(Color.WHITE); g.fill(new Rectangle(image.getWidth(), image.getHeight())); g.translate(25, 100); g.setPaint(Color.BLACK); g.setStroke(new BasicStroke(20, BasicStroke.CAP_BUTT, BasicStroke.JOIN_MITER)); g.draw(new Polygon(new int[] {0, 150, 0}, new int[] {75, 0, -75}, 3)); if (image.getRGB(15, 9) == Color.WHITE.getRGB()) { throw new RuntimeException("Miter is not rendered."); } } } On Wed, Feb 18, 2009 at 9:48 PM, Phil Race wrote: > Without verifying the proposed fix itself, the problem I see here is that > this test doesn't appear to be automated. See the one for the dashed line > bug for ideas on automation. > > For the record: we require that tests be provided and automated if at all > feasible, or there > must be a justification why its not provided or feasible be provided. Fixes > which don't > provide this will be pended once this is noted. > Reviewers will likewise reject fixes that don't conform. > > The reason for this requirement is that its then possible to test the fix on > all platforms with minimal effort. > A fix that isn't automated likely won't be tested and isn't worth much. > > -phil. > > Hiroshi Yamauchi wrote: >> >> Hi, >> >> Here's a miter bugfix, and a test. >> >> Thanks, >> Hiroshi >> >> ---- bug ---- >> The miter line join decoration isn't rendered properly. >> >> ---- fix ---- >> +++ jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java >> 2009-02-18 >> 17:14:05.000000000 -0800 >> @@ -245,6 +245,7 @@ >> FloatToS15_16(coords[1])); >> break; >> case PathIterator.SEG_CLOSE: >> + lsink.lineJoin(); >> lsink.close(); >> break; >> default: >> >> ---- test ---- >> public class JoinMiterTest { >> public static void main(String[] args) throws Exception { >> BufferedImage image = new BufferedImage(200, 200, >> BufferedImage.TYPE_INT_RGB); >> Graphics2D g = image.createGraphics(); >> g.setPaint(Color.WHITE); >> g.fill(new Rectangle(image.getWidth(), image.getHeight())); >> g.translate(25, 100); >> g.setPaint(Color.BLACK); >> g.setStroke(new BasicStroke(20, BasicStroke.CAP_BUTT, >> BasicStroke.JOIN_MITER)); >> g.draw(new Polygon(new int[] {0, 150, 0}, new int[] {75, 0, -75}, >> 3)); >> ImageIO.write(image, "PNG", new File(args[0])); >> } >> } >> > > From mbana.lists at googlemail.com Sun Feb 22 15:18:40 2009 From: mbana.lists at googlemail.com (Mohamed Bana) Date: Sun, 22 Feb 2009 15:18:40 +0000 Subject: [OpenJDK 2D-Dev] Freetype on linux Message-ID: Hello, Which version of the Sun JRE uses Freetype on Linux, I'm aware that on Windows, with a recent JRE, Cleartype is being used. Mohamed -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Mon Feb 23 23:21:25 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 24 Feb 2009 00:21:25 +0100 Subject: [OpenJDK 2D-Dev] Freetype on linux In-Reply-To: References: Message-ID: <194f62550902231521v1e242eefie6138ea152e994c7@mail.gmail.com> Hi, > Which version of the Sun JRE uses Freetype on Linux, I'm aware that on > Windows, with a recent JRE, Cleartype is being used. As far as I know, no version of "Sun JRE" (the "official" version) does use Freetype, but OpenJDK does. - Clemens From Jim.A.Graham at Sun.COM Mon Feb 23 23:55:02 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 23 Feb 2009 15:55:02 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 4494651: Wrong width and height in BufferedImage GraphicsConfiguration objects In-Reply-To: <20090222013737.GB6453@merzeus.obrandt.org> References: <20090202225443.GA28471@merzeus.obrandt.org> <499B6EDB.4020109@Sun.COM> <0KF8002TJPN0I650@fe-sfbay-10.sun.com> <0KF8003J2P6O6690@fe-sfbay-09.sun.com> <20090222013737.GB6453@merzeus.obrandt.org> Message-ID: <0KFJ001VXMFLRSF0@fe-sfbay-09.sun.com> Torsten Landschoff wrote: > Hi Jim, > > On Tue, Feb 17, 2009 at 06:27:43PM -0800, Jim Graham wrote: >> The width and height of a GraphicsConfig is essentially irrelevant >> information. If you get the GraphicsConfig of a component, it doesn't > > Why is there a method then to query irrelevant information? The size of a GC is very relevant for screen GCs - it defines the size of the device that the component is being rendered on. Therefore the GC.getBounds method is somewhat useful for those GCs. That was the use case for which the method was created. The GCs from BufferedImages are another story. There is no real "device" associated with a BufferedImage and any virtual device that you can conceive for it doesn't necessarily have a "size". The closest thing to a "size of the destination device" you might have would be "as big as you have memory" or "the limits (if any) that the rendering engine's algorithms have". In particular, that method is not defined as returning the size of the "thing it came from", it is defined as returning the size of the "universe in/on which the thing it came from lives" and the size of the BufferedImage is not a relevant or analogous piece of information. The return value of GC.getBounds() had a use in mind when it was created - it just doesn't happen to be the use that it looks like you want to make of it. >> tell you how big that component was, so why should the GC of a BufImg >> bear any relation to the dimensions of the image? > > Why would the graphics configuration contain the size of the component? It doesn't contain it. That is what I said and you quoted. The GC from a component is not tied to the size of the component. The GC from a BufferedImage should therefore not be tied to the size of the image. > The use case for me was to fix a drawing routine which made two passes > over the input data to have the second pass paint over the first. This > turned out to be quite slow with the main time going into loading the > data. So I optimized it to paint in one pass, by using a BufferedImage > to paint the overlay data and merge it later. The only object that > could give me the size of the output Graphics device was - surprise - > the Graphics2D instance. > > This works fine when drawing directly to the screen, but unfortunately > not when double buffering is used. I think this is a very valid use case. I think I see your case point here, but I think it is a red herring. You say that the G2D tells you the size of the output screen device. I suppose that is true, but that information does not tell you how big the component on that screen is. So, I suppose if you are rendering full screen then a by-product of the GC returning the size of the device is that it also tells you the size of the thing you are rendering to, but if you are rendering to just a window or component, that information is not useful since you really need to know the bounds of the component/widget/window and it doesn't give you that. So, a universally useful piece of information that tells you the size of the "thing" you are rendering to should come from somewhere other than the size of the GC in a Graphics2D. Note that we "sort of" provide that information in another form. When your paint(), or paintComponent() method is called, we have set the clip to the bounds of the component and so doing a Graphics.getClipBounds() will give you the information you want. Unfortunately, I don't think the clip is set if you call Component.getGraphics() or Image.getGraphics() and there is no relevant and related Graphics.getDeviceBounds(), though maybe there should be? Historically, the bounds of a GC of a BufferedImage has never reliably returned similar information, and I don't think attempting to overload that method on GC is a good way to start providing this information. Thus, I do not wish to pursue any further any attempts to make the GC a useful item for describing the dimensions of a particular Graphics2D's destination. >> If anything, I'd fix it by having it report some fixed bogus (positive, >> large) dimensions rather than the dimensions of the first image that it >> was created from... > > Why? Code calling it will only fall over with that, perhaps even worse > than the status quo when expecting valid values. Why would such code fall over? What use have developers been making of this, essentially "random" (random for BufferedImages) data in the past? This information hasn't been useful in the past, so changing it will not break any correctly written programs. The bounds information for a GC has not been semantically tied to the dimensions of a Graphics2D destination in the past, but it has had cases where it coincidentally returned bounds that happened to meet that need (i.e. full screen rendering). The coincidence there was not by design and it cannot be extended to all cases so that accidental synergy of that one use case should not be turned into a specification. > Using negative dimensions for example would clearly mark the data as > invalid, but in my case would lead to IllegalArgumentException in the > BufferedImage constructor (as I take the sizes at face value). You should not be using this information to create BufferedImages, therefore I am not interested in how it would negatively impact your code. > If you really want to disable usable functionality in an update to the > JDK, I'd suggest to use UnsupportedOperationException so that the > caller at least knows what is going on. I can see some sense in that, but I think that max bounds or a definitive "the renderer cannot support bounds greater than X by Y" would make more sense. I think an exception or error would make more sense if "no image" could be allocated, rather than "any image". > Anyway, I don't understand the fuss about such a simple code change. > Maybe it will eat some cycles and a bit of memory, but there is not > even a comment in the original BufferedImageGraphicsConfig code why > that hack there is really needed. The fuss is: - It wastes objects - It does not match the spec for the method (which isn't very well documented, but the various code samples in the javadocs combined with the doc comment on the method collectively indicate that the bounds of a GC are not tied to a specific destination). - It sets a precedence of returning information which seems useful from a context that was not designed to return such information. - It takes a direction which is not only different from other existing uses of the same class (i.e. Component.getGC.getBounds()), but is also a direction that they cannot and will not follow, creating a schism in how these objects would be used. - We've long needed an API that is specifically designed to return the information you want and we should create just such a specific API for that purpose, rather than to start side-effecting some other API to help out in some cases. > I find it curious that all but the indexed image type configurations > are cached and it seems not be a problem there: Indexed images are not typically used as rendering destinations so this method is much less likely to be called on them. Inherent in their "configuration" is the need to match their colormodel, which depends on their color palette and so they cannot be cached. It would be nice if they could be, but they can't. The fact that they can't should not be interpreted as open season for removing all other caches, especially given the practical difference in how they tend to be used. > On Tue, Feb 17, 2009 at 06:30:36PM -0800, Jim Graham wrote: >> Note that, per my previous email - this could easily be just closed as >> "not a bug", though it might be nice to change it so the bounds were >> completely unrelated to any specific image rather than randomly set to >> the first image that was queried. > > The Java API docs state that getBounds() will return the bounds in device > coordinates. You say that information is irrelevant, so it is not a bug? > What value do the API docs have then? The method returns the bounds of the *GraphicsConfiguration* in the device coordinates. It does not return the bounds of a specific drawable object created on that configuration. The value of the bounds it does return is useful for finding where to place a window (among other uses). The value of the API docs are to explain to users wanting to perform that task how to do it. The value of this method was never intended to be to explain how to allocate rendering buffers for a specific destination and so the value of these docs are not for explaining that usage. >> In other words, I'd rewrite the bug synopsis as something like: >> >> GC reports random bounds (that happen to match first img) >> >> and then hardcode some interesting bounds instead (perhaps the maximum >> supported image bounds - which we've never implemented or documented, >> but perhaps it would be a good way to introduce this concept for the >> future?)... > > I think that would be a slippery slope as this could depend on the amount of > virtual memory - which is hard to measure, and even then nobody would like > to have the crawling speed. But, if the renderer flat-out fails if any dimension is more than, say 2^24 whether or not you've run out of memory, then that would be good information to have, no? That information seems closer to the way it is used for screen components - "things larger than that created for this GC will exceed the maximum supported bounds of the device they live in" - where, in the case of BufferedImages, the device would be defined as the memory and dimensions within that memory that the software can correctly support rendering to. It wouldn't be a guarantee that creating an image of those dimensions would succeed, but a warning that images of larger dimension won't work right. > On Tue, Feb 17, 2009 at 06:39:44PM -0800, Jim Graham wrote: >> In fact, I've just updated the synopsis and evaluated the bug along >> these lines... ;-) > > Where can I read the updated bug entry? The URL known to me is > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494651 > > and its content did not change (apart from some CSS hickups the last > few days). It must be taking some time to percolate to the external bug view... ...jim From yamauchi at google.com Tue Feb 24 01:32:48 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Mon, 23 Feb 2009 17:32:48 -0800 Subject: [OpenJDK 2D-Dev] More incompatibilities Message-ID: Hi all, We found four more 2D rendering OpenJDK incompatibilities (the examples are attached): 1. ScaleTest: A circle is rendered in a 'C' shape. 2. ThinLineTest: A line < 1 pixel disappears. 3. NotANumberTest: Double.NaN isn't handled gracefully. 4. StrokeShapeTest: createStrokedShape() behaves differently. Some of the examples may be caused by a single bug. I don't have an idea what the causes are. By any chance, have any of the them already fixed? Thanks, Hiroshi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ScaleTest.java Type: application/octet-stream Size: 1186 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ThinLineTest.java Type: application/octet-stream Size: 1269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NotANumberTest.java Type: application/octet-stream Size: 1325 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: StrokeShapeTest.java Type: application/octet-stream Size: 1508 bytes Desc: not available URL: From yamauchi at google.com Tue Feb 24 19:40:23 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 24 Feb 2009 11:40:23 -0800 Subject: [OpenJDK 2D-Dev] More incompatibilities In-Reply-To: References: Message-ID: The following change appears to make the ThinLineTest pass. I tried a couple of variations of it, with and without antialiasing, with and without scaling, and with different scaling factors and line widths. The looked okay. Btw, bear with me as I am not really a Java 2D person and I may not know what I'm talking about :) But I got the feeling that the 'thin' logic (to do with the thin boolean parameter to PiscesRenderingEngine.strokeTo() and the logic in SunGraphics2D.validateBasicStroke()) isn't compatible with Stroker.computeOffset(). +++ jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java 2009-02-24 11:17:48.000000000 -0800 @@ -169,7 +169,7 @@ LineSink lsink) { float lw; - if (thin) { + if (false && thin) { if (antialias) { lw = 0.5f; } else { On Mon, Feb 23, 2009 at 5:32 PM, Hiroshi Yamauchi wrote: > Hi all, > > We found four more 2D rendering OpenJDK incompatibilities (the examples are > attached): > > 1. ScaleTest: A circle is rendered in a 'C' shape. > 2. ThinLineTest: A line < 1 pixel disappears. > 3. NotANumberTest: Double.NaN isn't handled gracefully. > 4. StrokeShapeTest: createStrokedShape() behaves differently. > > Some of the examples may be caused by a single bug. I don't have an idea > what the causes are. > By any chance, have any of the them already fixed? > > Thanks, > Hiroshi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jennifer.godinez at sun.com Tue Feb 24 22:46:08 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 24 Feb 2009 22:46:08 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6750383: 2D_PrintingTiger\PrintDocOrientationTest fails, wrong orientated images are printed Message-ID: <20090224224630.40080E0CE@hg.openjdk.java.net> Changeset: ff2afd0551c9 Author: jgodinez Date: 2009-02-24 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ff2afd0551c9 6750383: 2D_PrintingTiger\PrintDocOrientationTest fails, wrong orientated images are printed Reviewed-by: campbell, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java From dmitri.trembovetski at sun.com Thu Feb 26 21:43:46 2009 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Thu, 26 Feb 2009 21:43:46 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6791612: OGLBat tests are failed in jdk 7 b42 Message-ID: <20090226214417.51CC8E1EA@hg.openjdk.java.net> Changeset: 0c856354b669 Author: tdv Date: 2009-02-26 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0c856354b669 6791612: OGLBat tests are failed in jdk 7 b42 Reviewed-by: tdv Contributed-by: ceisserer ! make/sun/xawt/mapfile-vers