From mario.torre at aicas.com Tue Aug 4 13:36:42 2009 From: mario.torre at aicas.com (Mario Torre) Date: Tue, 04 Aug 2009 22:36:42 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KN5008UCPV3Y720@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> <4A423049.8080903@aicas.com> <4A4CCD39.4050003@sun.com> <4A5488EE.3080808@aicas.com> <0KMH008HKOJW5M70@fe-sfbay-09.sun.com> <4A5593C6.1010700@aicas.com> <0KMJ00IXG7AYMA10@fe-sfbay-10.sun.com> <4A5C7EA6.6070404@aicas.com> <0KMS003N4D4KVK70@fe-sfbay-10.sun.com> <4A5DEAEF.1080101@aicas.com> <0KMU00GD5EWNFFH0@fe-sfbay-10.sun.com> <4A65F6A8.20502@aicas.com> <0KN5008UCPV3Y720@fe-sfbay-10.sun.com> Message-ID: <4A789BDA.5030309@aicas.com> Il 22/07/2009 02:11, Jim Graham ha scritto: > It's odd that J2DBench showed a difference since nothing you did should > have affected those benchmarks. I don't think it has any benchmark which > shows the impact of a pipeline validation, so your standalone test is > the only one that I think addresses the issue. > > Rather than setting up a machine for a 72 hour run (not sure a run of > what, though - J2DBench?), I'd rather see either trying to do the check > with a virtual method call (Pipe.needsLoops) or just going back to the > old style of initializing them in the validation branches that we know > need them and we can revisit this mechanism some other time when we have > the time to really figure out how to make it cheap. In particular, I > have some ideas for how to make validation incredibly cheap at the cost > of a few K of lookup tables per SurfaceData, but I think the scale of > that is beyond us for now... > > ...jim Hi Jim, I tried some more of the j2d benchmark but you're right, looks like no one of them causes a revalidate, so they are all useless for this specific case. I implemented the method based approach. What I did was to introduce an interface that all loops implements, this interface consist of a single method that returns a boolean. I made the implementation final everywhere to try to limit the impact of it, although I'm not sure this is 100% correct in all cases, but the impact is still too high. In my opinion we should try to go with the interface approach, it's really less costly and less complex, basically no impact at all in all the tests. I attach two results here. The first run iterates 1000000 times, two times for warm-up, then one more time to do the actual measurement. The second run is more "longish" :) each loop is augmented to 100000000. As I make this test and collect the stats via a script (well, attached, but it's not the coolest script in the world), I didn't make it smart enough to tell you what each JDK actually is, so this is the explanation: OPEN_JDK0 == build 1.7.0-internal-neugens_2009_07_27_18_10-b00 contains the patch in webrew.06 (the one with the methods, linked here) OPEN_JDK1 == build 1.7.0-internal-neugens_2009_07_15_15_31-b00 is a pure JDK build OPEN_JDK2 == build 1.7.0-internal-neugens_2009_07_15_14_30-b00 is the "old" webrew.05 patch (marker interface). Finally, the webrew: http://cr.openjdk.java.net/~neugens/100068/webrev.06/ Please, ignore the ".hgignore" changes in the patch. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ 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-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: whole_run_01.txt Url: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/whole_run_01.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: whole_run_02.txt Url: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/whole_run_02.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.java Type: text/x-java Size: 1987 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/Main.java -------------- next part -------------- A non-text attachment was scrubbed... Name: run_tests.sh Type: application/x-shellscript Size: 1563 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/run_tests.sh From Roman.Kennke at Sun.COM Tue Aug 4 14:08:12 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Tue, 04 Aug 2009 23:08:12 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A789BDA.5030309@aicas.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> <4A423049.8080903@aicas.com> <4A4CCD39.4050003@sun.com> <4A5488EE.3080808@aicas.com> <0KMH008HKOJW5M70@fe-sfbay-09.sun.com> <4A5593C6.1010700@aicas.com> <0KMJ00IXG7AYMA10@fe-sfbay-10.sun.com> <4A5C7EA6.6070404@aicas.com> <0KMS003N4D4KVK70@fe-sfbay-10.sun.com> <4A5DEAEF.1080101@aicas.com> <0KMU00GD5EWNFFH0@fe-sfbay-10.sun.com> <4A65F6A8.20502@aicas.com> <0KN5008UCPV3Y720@fe-sfbay-10.sun.com> <4A789BDA.5030309@aicas.com> Message-ID: <1249420092.13246.19.camel@moonlight> Hi Mario, > I implemented the method based approach. What I did was to introduce an > interface that all loops implements, this interface consist of a single > method that returns a boolean. > > I made the implementation final everywhere to try to limit the impact of > it, although I'm not sure this is 100% correct in all cases, but the > impact is still too high. In my opinion we should try to go with the > interface approach, it's really less costly and less complex, basically > no impact at all in all the tests. .. > Finally, the webrew: > > http://cr.openjdk.java.net/~neugens/100068/webrev.06/ So the short story is the webrev.05 was actually better and we better forget about webrev.06 at this point? Regarding webrev.05, I find the 5x instanceof a bit ugly. I am not sure how to avoid it though. Maybe put the pipe fields in a container. This container could have a (marker) subclass that is instanceof'ed for. Whenever a SD sets up loop based pipes, it uses the subclass. Otherwise it uses the base class. Then you'd only need one instanceof check against the container. But OTOH you would get double field access in a couple of cases, of which I don't know if hotspot optimizes them away somehow. And it's probably not worth thinking about any of this if impact is not noticable already. Maybe the if cascade bails out at the first check already? Maybe it's worth ordering the if cascade so that the most likely case is the first one, etc? > Please, ignore the ".hgignore" changes in the patch. Haha. ;-) Cheers, Roman From Jim.A.Graham at Sun.COM Tue Aug 4 14:50:51 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 04 Aug 2009 14:50:51 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1249420092.13246.19.camel@moonlight> References: <1244588287.3580.53.camel@localhost.localdomain> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> <4A423049.8080903@aicas.com> <4A4CCD39.4050003@sun.com> <4A5488EE.3080808@aicas.com> <0KMH008HKOJW5M70@fe-sfbay-09.sun.com> <4A5593C6.1010700@aicas.com> <0KMJ00IXG7AYMA10@fe-sfbay-10.sun.com> <4A5C7EA6.6070404@aicas.com> <0KMS003N4D4KVK70@fe-sfbay-10.sun.com> <4A5DEAEF.1080101@aicas.com> <0KMU00GD5EWNFFH0@fe-sfbay-10.sun.com> <4A65F6A8.20502@aicas.com> <0KN5008UCPV3Y720@fe-sfbay-10.sun.com> <4A789BDA.5030309@aicas.com> <1249420092.13246.19.camel@moonlight> Message-ID: <0KNV007YIGORMT80@fe-sfbay-10.sun.com> Roman Kennke wrote: >> http://cr.openjdk.java.net/~neugens/100068/webrev.06/ > > So the short story is the webrev.05 was actually better and we better > forget about webrev.06 at this point? It also looks like the webrev.05 is better than a stock JDK - even more promising! > Regarding webrev.05, I find the 5x instanceof a bit ugly. I am not sure > how to avoid it though. Maybe put the pipe fields in a container. This > container could have a (marker) subclass that is instanceof'ed for. > Whenever a SD sets up loop based pipes, it uses the subclass. Otherwise > it uses the base class. Then you'd only need one instanceof check > against the container. But OTOH you would get double field access in a > couple of cases, of which I don't know if hotspot optimizes them away > somehow. And it's probably not worth thinking about any of this if > impact is not noticable already. Maybe the if cascade bails out at the > first check already? Maybe it's worth ordering the if cascade so that > the most likely case is the first one, etc? It's only 5x instanceof in a single place in the code and it makes the entire business of loop validation much cleaner so I'm loving it in a global/general sense even if it is uglier at just that one line of code. However, I would modify the code style for it to move the curly to the following line like this: if (foopipe instanceof blah || blahpipe instanceof blah || barpipe instanceof blah) { sg2d.loops = ...; } This is almost completely in line with our code style guidelines (are those published on the OpenJDK site?) with the only minor variation being the open curly on the line by itself which is a personal preference (that is used through most of java2d) to make the break between multi-line conditionals and body more visible. I(we?) find that otherwise the body looks like another line of conditional tests... ...jim From jennifer.godinez at sun.com Tue Aug 4 17:52:03 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 05 Aug 2009 00:52:03 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6829673: ThinLineTest: A line < 1 pixel disappears. Message-ID: <20090805005227.4E646E11D@hg.openjdk.java.net> Changeset: 7fe0497ee5b5 Author: jgodinez Date: 2009-08-04 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7fe0497ee5b5 6829673: ThinLineTest: A line < 1 pixel disappears. Reviewed-by: igor, prr Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/ThinLineTest.java From mario.torre at aicas.com Wed Aug 5 01:37:09 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 05 Aug 2009 10:37:09 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KNV007YIGORMT80@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> <4A423049.8080903@aicas.com> <4A4CCD39.4050003@sun.com> <4A5488EE.3080808@aicas.com> <0KMH008HKOJW5M70@fe-sfbay-09.sun.com> <4A5593C6.1010700@aicas.com> <0KMJ00IXG7AYMA10@fe-sfbay-10.sun.com> <4A5C7EA6.6070404@aicas.com> <0KMS003N4D4KVK70@fe-sfbay-10.sun.com> <4A5DEAEF.1080101@aicas.com> <0KMU00GD5EWNFFH0@fe-sfbay-10.sun.com> <4A65F6A8.20502@aicas.com> <0KN5008UCPV3Y720@fe-sfbay-10.sun.com> <4A789BDA.5030309@aicas.com> <1249420092.13246.19.camel@moonlight> <0KNV007YIGORMT80@fe-sfbay-10.sun.com> Message-ID: <4A7944B5.8010106@aicas.com> Il 04/08/2009 23:50, Jim Graham ha scritto: > Roman Kennke wrote: >>> http://cr.openjdk.java.net/~neugens/100068/webrev.06/ >> >> So the short story is the webrev.05 was actually better and we better >> forget about webrev.06 at this point? > > It also looks like the webrev.05 is better than a stock JDK - even more > promising! :) Maybe someone with more experience could write a more "dramatic" test case, but yeah, I had the feeling that they are quite similar in the worst case, I find interesting that in 5 run each, sometimes the numbers are quite different. I assume this is a Linux problem, it would be interesting to run this test with a realtime VM on a realtime system :) > It's only 5x instanceof in a single place in the code and it makes the > entire business of loop validation much cleaner so I'm loving it in a > global/general sense even if it is uglier at just that one line of code. To be honest, it would be nice to have annotation do the same as marker interface, and being able to use them directly with instanceof without reflection, that would make everything a bit nicer, but this is really a minor cosmetic change, and doesn't change the ugly instanceof lines. I passed some time on it to find a better way, but could not think of any without the risk adding some overhead, so I gave up. > However, I would modify the code style for it to move the curly to the > following line like this: > > if (foopipe instanceof blah || > blahpipe instanceof blah || > barpipe instanceof blah) > { > sg2d.loops = ...; > } > > This is almost completely in line with our code style guidelines (are > those published on the OpenJDK site?) with the only minor variation > being the open curly on the line by itself which is a personal > preference (that is used through most of java2d) to make the break > between multi-line conditionals and body more visible. I(we?) find that > otherwise the body looks like another line of conditional tests... Sure, that's fine! I was unsure about the coding guidelines, but this makes entirely sense to me. I'll send you an update shortly based on the latest OpenJDK checkout even. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ 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-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Roman.Kennke at Sun.COM Wed Aug 5 16:10:52 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Thu, 06 Aug 2009 01:10:52 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev6 In-Reply-To: <4A3AB7C1.2060008@sun.com> References: <1245289988.5082.5.camel@saturn> <4A3AB7C1.2060008@sun.com> Message-ID: <1249513852.4110.69.camel@moonlight> Hi there, 6th round of the FontManager refactoring. > you aren't using these import in sun.font.FontManager : > 30 import java.util.Locale; > 31 import java.util.TreeMap; > 32 > 33 import javax.swing.plaf.FontUIResource; > > There may be other such cases but its easy to see in this much reduced file. I went over all the files with NetBeans and removed all unused imports. > SunGraphicsEnvironment.java > 173 assert fm instanceof FontManagerForSGE; > 174 return (FontManagerForSGE) fm; > > I don't see the point of the assert here because the cast is > going to tell you if there's a problem whether asserts are on or not. I agree. Removed. > SharedSecrets.java > > I think you can restore the empty line (115) you deleted and remove this > file from the webrev. Done. > FcFontConfiguration.java > > you aren't using the "fm" instance so can remove that line : > 331 SunFontManager fm = SunFontManager.getInstance(); > 332 if (FontUtilities.debugFonts()) { > 333 Logger logger = Logger.getLogger("sun.awt.FontConfiguration"); > 334 logger.warning("Exception identifying Linux distro."); > 335 } > 336 } > 337 } Yeah, I found a couple more instances of this problem and removed all of them. > WPathGraphics.java > > I see you moved the definition of textLayoutIsCompatible in here. > Whilst its used only by this code, its also meaning that updating > that font internal code in the future will affect the printing code. > And the getDirectoryEntry() method isn't public so I'm not sure > how this will work! Ah, I just remembered you said you didn't test > on windows yet. Puzzlement over, this won't build. I'd prefer this > to go back to TrueTypeFont. > Clearly you need to get that windows build tested before you push. > You don't need to set up a windows machine, you can submit a jprt job > now that you have SWAN access. I resolved all windows related problems and verified that it works using Font2DTest and JPRT (excluding an apparently known assertion in awt_Frame.h, line 121). http://cr.openjdk.java.net/~rkennke/fontmanager/webrev.06/ /Roman From Phil.Race at Sun.COM Wed Aug 5 16:17:37 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 05 Aug 2009 16:17:37 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev6 In-Reply-To: <1249513852.4110.69.camel@moonlight> References: <1245289988.5082.5.camel@saturn> <4A3AB7C1.2060008@sun.com> <1249513852.4110.69.camel@moonlight> Message-ID: <4A7A1311.8060904@sun.com> Roman, Roman Kennke wrote: > Hi there, > > 6th round of the FontManager refactoring. Can I assume you changed nothing except what you call out here ? In which case I'm fine except for one thing : >> WPathGraphics.java >> >> I see you moved the definition of textLayoutIsCompatible in here. >> Whilst its used only by this code, its also meaning that updating >> that font internal code in the future will affect the printing code. >> And the getDirectoryEntry() method isn't public so I'm not sure >> how this will work! Ah, I just remembered you said you didn't test >> on windows yet. Puzzlement over, this won't build. I'd prefer this >> to go back to TrueTypeFont. you've resolved this by making getDirectoryEntry() public whereas I asked that you move textLayoutIsCompatible back to the font code where I believe it belongs. -phil. From Roman.Kennke at Sun.COM Fri Aug 7 00:58:47 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Fri, 07 Aug 2009 09:58:47 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev7 In-Reply-To: <4A7A1311.8060904@sun.com> References: <1245289988.5082.5.camel@saturn> <4A3AB7C1.2060008@sun.com> <1249513852.4110.69.camel@moonlight> <4A7A1311.8060904@sun.com> Message-ID: <1249631927.3974.7.camel@moonlight> Hi Phil, > > 6th round of the FontManager refactoring. > > Can I assume you changed nothing except what you call out here ? Yep. > In which case I'm fine except for one thing : > > >> WPathGraphics.java > >> > >> I see you moved the definition of textLayoutIsCompatible in here. > >> Whilst its used only by this code, its also meaning that updating > >> that font internal code in the future will affect the printing code. > >> And the getDirectoryEntry() method isn't public so I'm not sure > >> how this will work! Ah, I just remembered you said you didn't test > >> on windows yet. Puzzlement over, this won't build. I'd prefer this > >> to go back to TrueTypeFont. > > you've resolved this by making getDirectoryEntry() public whereas > I asked that you move textLayoutIsCompatible back to the font code > where I believe it belongs. Ok, you are right. Sorry for not listening ;-) (actually, I just built the stuff on Windows and fixed whatever it complained about, there have been a couple of other minor issues and at the point when I came over this particular issue, I already forgot your advice..) I moved textLayoutIsCompatible() into FontUtilities (as static method) and made getDirectoryEntry() package private again. (I also fixed some warnings in the 3 files I touched, namely unused imports and @Override annotations as flagged by NetBeans.) Ok now to push in? http://cr.openjdk.java.net/~rkennke/fontmanager/webrev.07/ Thanks, Roman From Phil.Race at Sun.COM Fri Aug 7 05:23:16 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 07 Aug 2009 05:23:16 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev7 In-Reply-To: <1249631927.3974.7.camel@moonlight> References: <1245289988.5082.5.camel@saturn> <4A3AB7C1.2060008@sun.com> <1249513852.4110.69.camel@moonlight> <4A7A1311.8060904@sun.com> <1249631927.3974.7.camel@moonlight> Message-ID: <4A7C1CB4.8030308@sun.com> >Ok now to push in? Yes. -phil. Roman Kennke wrote: > Hi Phil, > > >>> 6th round of the FontManager refactoring. >>> >> Can I assume you changed nothing except what you call out here ? >> > > Yep. > > >> In which case I'm fine except for one thing : >> >> >>>> WPathGraphics.java >>>> >>>> I see you moved the definition of textLayoutIsCompatible in here. >>>> Whilst its used only by this code, its also meaning that updating >>>> that font internal code in the future will affect the printing code. >>>> And the getDirectoryEntry() method isn't public so I'm not sure >>>> how this will work! Ah, I just remembered you said you didn't test >>>> on windows yet. Puzzlement over, this won't build. I'd prefer this >>>> to go back to TrueTypeFont. >>>> >> you've resolved this by making getDirectoryEntry() public whereas >> I asked that you move textLayoutIsCompatible back to the font code >> where I believe it belongs. >> > > Ok, you are right. Sorry for not listening ;-) (actually, I just built > the stuff on Windows and fixed whatever it complained about, there have > been a couple of other minor issues and at the point when I came over > this particular issue, I already forgot your advice..) > > I moved textLayoutIsCompatible() into FontUtilities (as static method) > and made getDirectoryEntry() package private again. (I also fixed some > warnings in the 3 files I touched, namely unused imports and @Override > annotations as flagged by NetBeans.) > > Ok now to push in? > > http://cr.openjdk.java.net/~rkennke/fontmanager/webrev.07/ > > Thanks, Roman > > > From roman at kennke.org Fri Aug 7 09:40:17 2009 From: roman at kennke.org (roman at kennke.org) Date: Fri, 07 Aug 2009 16:40:17 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6795908: Refactor FontManager Message-ID: <20090807164100.86FDEE879@hg.openjdk.java.net> Changeset: 64b0c953635d Author: rkennke Date: 2009-08-07 18:31 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/64b0c953635d 6795908: Refactor FontManager Reviewed-by: prr, igor ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CompositeFont.java ! src/share/classes/sun/font/CompositeGlyphMapper.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontDesignMetrics.java ! src/share/classes/sun/font/FontFamily.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontManagerNativeLibrary.java ! src/share/classes/sun/font/FontResolver.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/PhysicalStrike.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/TrueTypeGlyphMapper.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/font/Type1GlyphMapper.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/NativeFont.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WFontConfiguration.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp From roman at kennke.org Fri Aug 7 10:43:09 2009 From: roman at kennke.org (roman at kennke.org) Date: Fri, 07 Aug 2009 17:43:09 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6869705: Missing files of CR6795908, FontManager refactoring Message-ID: <20090807174343.75594E8D1@hg.openjdk.java.net> Changeset: 92607d652d7a Author: rkennke Date: 2009-08-07 19:36 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/92607d652d7a 6869705: Missing files of CR6795908, FontManager refactoring Reviewed-by: prr, igor + src/share/classes/sun/font/FontAccess.java + src/share/classes/sun/font/FontManagerFactory.java + src/share/classes/sun/font/FontManagerForSGE.java + src/share/classes/sun/font/FontUtilities.java + src/share/classes/sun/font/SunFontManager.java + src/solaris/classes/sun/awt/X11FontManager.java + src/solaris/classes/sun/font/FontConfigManager.java + src/windows/classes/sun/awt/Win32FontManager.java From linuxhippy at gmail.com Fri Aug 7 13:01:58 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 7 Aug 2009 16:01:58 -0400 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev7 In-Reply-To: <4A7C1CB4.8030308@sun.com> References: <1245289988.5082.5.camel@saturn> <4A3AB7C1.2060008@sun.com> <1249513852.4110.69.camel@moonlight> <4A7A1311.8060904@sun.com> <1249631927.3974.7.camel@moonlight> <4A7C1CB4.8030308@sun.com> Message-ID: <194f62550908071301s1b25ccf0q4ae4379828bfb9e3@mail.gmail.com> > >Ok now to push in? > > Yes. Cool - congratulations :) - Clemens From neugens.limasoftware at gmail.com Fri Aug 7 15:09:35 2009 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 08 Aug 2009 00:09:35 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev7 In-Reply-To: <194f62550908071301s1b25ccf0q4ae4379828bfb9e3@mail.gmail.com> References: <1245289988.5082.5.camel@saturn> <4A3AB7C1.2060008@sun.com> <1249513852.4110.69.camel@moonlight> <4A7A1311.8060904@sun.com> <1249631927.3974.7.camel@moonlight> <4A7C1CB4.8030308@sun.com> <194f62550908071301s1b25ccf0q4ae4379828bfb9e3@mail.gmail.com> Message-ID: <4A7CA61F.5070006@gmail.com> Il 07/08/2009 22:01, Clemens Eisserer ha scritto: >> >Ok now to push in? >> >> Yes. > > Cool - congratulations :) > > - Clemens Finally!!!! Cheers, Mario From roman at kennke.org Wed Aug 12 08:28:30 2009 From: roman at kennke.org (roman at kennke.org) Date: Wed, 12 Aug 2009 15:28:30 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6870238: Font2DTest fails on Debian after FontManager refactoring Message-ID: <20090812152907.3F094EB60@hg.openjdk.java.net> Changeset: 11b38980893c Author: rkennke Date: 2009-08-12 17:21 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/11b38980893c 6870238: Font2DTest fails on Debian after FontManager refactoring Summary: Use fontManager field instead of querying the FontManagerFactory Reviewed-by: igor, prr ! src/solaris/classes/sun/font/FcFontConfiguration.java From phil.race at sun.com Fri Aug 14 14:36:38 2009 From: phil.race at sun.com (phil.race at sun.com) Date: Fri, 14 Aug 2009 21:36:38 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6867603: sun.font.FontManager.getDefaultPlatformFont throws NPE in OpenJDK on Solaris 10 10/08 Message-ID: <20090814213723.B467FEE56@hg.openjdk.java.net> Changeset: a389af17df10 Author: prr Date: 2009-08-14 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a389af17df10 6867603: sun.font.FontManager.getDefaultPlatformFont throws NPE in OpenJDK on Solaris 10 10/08 Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/native/sun/awt/fontpath.c From jp4work at gmail.com Tue Aug 18 11:49:13 2009 From: jp4work at gmail.com (JIA Pei) Date: Tue, 18 Aug 2009 19:49:13 +0100 Subject: [OpenJDK 2D-Dev] JPEGImageEncoder inquiry... Message-ID: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> Hi, Dear All: I happened to notice there is some differences between SUN JDK and OpenJDK. In fact, I'm using "JPEGImageEncoder", which seems to be supported well by SUN JDK but not by OpenJDK. Especially, the function "setJPEGEncodeParam". So, I'm wondering if JAI+JAI ImageIO can replace the above JPEGImageEncoder ? My purpose is just for .jpeg image saving. Best Regards JIA Pei -- Welcome to Vision Open http://www.visionopen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090818/9d29bc8e/attachment.html From Brian.Burkhalter at Sun.COM Tue Aug 18 12:08:43 2009 From: Brian.Burkhalter at Sun.COM (Brian Burkhalter) Date: Tue, 18 Aug 2009 12:08:43 -0700 Subject: [OpenJDK 2D-Dev] JPEGImageEncoder inquiry... In-Reply-To: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> References: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> Message-ID: <993E25C5-5BDA-4515-9FEF-ACF328D9D238@sun.com> Hello. Assuming you are using at least Java 1.4 should be able to use the Image I/O API: http://java.sun.com/j2se/1.5.0/docs/guide/imageio/ On Aug 18, 2009, at 11:49 AM, JIA Pei wrote: > > Hi, Dear All: > > I happened to notice there is some differences between SUN JDK and > OpenJDK. In fact, I'm using "JPEGImageEncoder", which seems to be > supported well by SUN JDK but not by OpenJDK. Especially, the > function "setJPEGEncodeParam". > > So, I'm wondering if JAI+JAI ImageIO can replace the above > JPEGImageEncoder ? My purpose is just for .jpeg image saving. > > > Best Regards > JIA Pei > > -- > Welcome to Vision Open > http://www.visionopen.com Brian >^..^< >^..^< -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090818/7f527f51/attachment.html From roxton at gmail.com Tue Aug 18 12:32:07 2009 From: roxton at gmail.com (Adam Augusta) Date: Tue, 18 Aug 2009 15:32:07 -0400 Subject: [OpenJDK 2D-Dev] JPEGImageEncoder inquiry... In-Reply-To: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> References: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> Message-ID: <65ef85890908181232h10021d7dwbfb361d02e99bad1@mail.gmail.com> ImageIO has a quantization level, but if you want to use the other features of the Sun encoder like horizontal/vertical subsampling, for example, I think you're out of luck. Sorry. On Tue, Aug 18, 2009 at 2:49 PM, JIA Pei wrote: > > Hi, Dear All: > > I happened to notice there is some differences between SUN JDK and OpenJDK. > In fact, I'm using "JPEGImageEncoder", which seems to be supported well by > SUN JDK but not by OpenJDK. Especially, the function "setJPEGEncodeParam". > > So, I'm wondering if JAI+JAI ImageIO can replace the above JPEGImageEncoder > ? My purpose is just for .jpeg image saving. > > > Best Regards > JIA Pei > > -- > Welcome to Vision Open > http://www.visionopen.com > From Brian.Burkhalter at Sun.COM Tue Aug 18 12:52:49 2009 From: Brian.Burkhalter at Sun.COM (Brian Burkhalter) Date: Tue, 18 Aug 2009 12:52:49 -0700 Subject: [OpenJDK 2D-Dev] JPEGImageEncoder inquiry... In-Reply-To: <65ef85890908181232h10021d7dwbfb361d02e99bad1@mail.gmail.com> References: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> <65ef85890908181232h10021d7dwbfb361d02e99bad1@mail.gmail.com> Message-ID: <9ED02212-3FC2-4BFA-86AB-15C65B983E0C@sun.com> Decimation subsampling may be specified for both readers and writers, using a movable subsampling grid. http://java.sun.com/javase/6/docs/api/javax/imageio/IIOParam.html Specifies a decimation subsampling to apply on I/O. http://java.sun.com/javase/6/docs/api/javax/imageio/IIOParam.html#setSourceSubsampling(int,%20int,%20int,%20int) On Aug 18, 2009, at 12:32 PM, Adam Augusta wrote: > ImageIO has a quantization level, but if you want to use the other > features of the Sun encoder like horizontal/vertical subsampling, for > example, I think you're out of luck. Sorry. > > On Tue, Aug 18, 2009 at 2:49 PM, JIA Pei wrote: >> >> Hi, Dear All: >> >> I happened to notice there is some differences between SUN JDK and >> OpenJDK. >> In fact, I'm using "JPEGImageEncoder", which seems to be supported >> well by >> SUN JDK but not by OpenJDK. Especially, the function >> "setJPEGEncodeParam". >> >> So, I'm wondering if JAI+JAI ImageIO can replace the above >> JPEGImageEncoder >> ? My purpose is just for .jpeg image saving. >> >> >> Best Regards >> JIA Pei >> >> -- >> Welcome to Vision Open >> http://www.visionopen.com >> Brian >^..^< >^..^< From Brian.Burkhalter at Sun.COM Wed Aug 19 09:13:46 2009 From: Brian.Burkhalter at Sun.COM (Brian Burkhalter) Date: Wed, 19 Aug 2009 09:13:46 -0700 Subject: [OpenJDK 2D-Dev] JPEGImageEncoder inquiry... In-Reply-To: <218a26f00908182028u712eff28ua0adcf2a4d5d5110@mail.gmail.com> References: <218a26f00908181149n4ce4586dn717b29f27879677f@mail.gmail.com> <65ef85890908181232h10021d7dwbfb361d02e99bad1@mail.gmail.com> <9ED02212-3FC2-4BFA-86AB-15C65B983E0C@sun.com> <218a26f00908182028u712eff28ua0adcf2a4d5d5110@mail.gmail.com> Message-ID: http://java.sun.com/javase/6/docs/api/javax/imageio/ImageIO.html#write(java.awt.image.RenderedImage,%20java.lang.String,%20java.io.File) On Aug 18, 2009, at 8:28 PM, JIA Pei wrote: > > Hi, Dear Brian Burkhalter: > > Thank you so much for you kind reply. > > May I ask for a simple code from you to save an ".jpg? format image. > > My code is something like: > > > BufferedImage bImage = doRender(width, height); > > RenderedImage fImage = JAI.create("format", bImage, > DataBuffer.TYPE_BYTE); > > JAI.create("filestore", fImage, filename + ".jpg", "jpeg", > null); > > > However, Eclipse notified that the 2nd line is deprecated and there > is a cross line on "create" in the 2nd line (in red). > > What's more, even if the 2nd line is deprecated, I'm still able to > save an image in .jpg format. However, what has been saved can not > be previewed by many software, including "Windows Picture and Fax > Viewer", "Image Magic Display", "Windows Paint", etc. I can only > preview the image by using "QuickTime Picture Viewer". That's not > actually what I expected and I think the saved image should be able > to be previewed by all the popular softwares. > > So, can you please help to give me your code when you tried to > save .jpg files? Thanks in advance. > > > Best Regards > JIA Pei > > > On Tue, Aug 18, 2009 at 8:52 PM, Brian Burkhalter > wrote: > Decimation subsampling may be specified for both readers and > writers, using a movable subsampling grid. > > http://java.sun.com/javase/6/docs/api/javax/imageio/IIOParam.html > > Specifies a decimation subsampling to apply on I/O. > > http://java.sun.com/javase/6/docs/api/javax/imageio/IIOParam.html#setSourceSubsampling(int,%20int,%20int,%20int) > > > On Aug 18, 2009, at 12:32 PM, Adam Augusta wrote: > > ImageIO has a quantization level, but if you want to use the other > features of the Sun encoder like horizontal/vertical subsampling, for > example, I think you're out of luck. Sorry. > > On Tue, Aug 18, 2009 at 2:49 PM, JIA Pei wrote: > > Hi, Dear All: > > I happened to notice there is some differences between SUN JDK and > OpenJDK. > In fact, I'm using "JPEGImageEncoder", which seems to be supported > well by > SUN JDK but not by OpenJDK. Especially, the function > "setJPEGEncodeParam". > > So, I'm wondering if JAI+JAI ImageIO can replace the above > JPEGImageEncoder > ? My purpose is just for .jpeg image saving. > > > Best Regards > JIA Pei > > -- > Welcome to Vision Open > http://www.visionopen.com > > > Brian > > >^..^< >^..^< > > > > > -- > Welcome to Vision Open > http://www.visionopen.com Brian >^..^< >^..^< -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090819/4ac4b456/attachment.html From linuxhippy at gmail.com Thu Aug 20 03:18:32 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 20 Aug 2009 06:18:32 -0400 Subject: [OpenJDK 2D-Dev] XRender pipeline - request for first review Message-ID: <194f62550908200318r365f0819r5c25081179b782b5@mail.gmail.com> Hi, I've just put together a webref of the xrender pipeline-rewrite for a first review. Please ignore the content of the xrender-repo, I finally gave up on using hg for this task. Please take a look at the webref located at: http://78.31.67.79:8080/jxrender/downloads/jxrender_20080820.zip Many things are not as mature/clean as I wished they would be, and some areas are just plain ugly ;) ... but I guess waiting any longer would just increase the risk of missing JDK7. The webref contains two small "fixes" required to make the JDK build on Fedora-Rawhide, please ignore them for now. The "pure-java" backend is for now experimental only and disabled by default, as it is not well tested and requires some enhancements. Thanks, Clemens PS: below you find some kind of status-document with questions inside. would be great if somebody could take a look at the open questions. *Known bugs:* 1. CopyArea GC leak. It seems XRSurfaceDara.flush() is only called for Pixmaps, even when overrriden in XRSurfaceData, is there any way to get a notification when a window is disposed? 2. Sometimes I get bad XID errors for different operations. 3. How can that happen? Only loops for X11 destination surfaces have been registered: Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.xr.XRSurfaceData at sun.java2d.xr.XRPMBlitLoops.cacheToTmpSurface(XRPMBlitLoops.java:154) at sun.java2d.xr.XrSwToPMBlit.Blit(XRPMBlitLoops.java:365) at sun.java2d.pipe.DrawImage.blitSurfaceData(DrawImage.java:953) 4. X11 automatic flush does not work (see e.g. Java2Demo, without antialiasing, high delay). Commands are flushed only when events occur or the output-buffer is full. 5. How does the SW->Surface blit behave, if tmp>source? (interpolation issues??). Possible solution: Simply set up source-rectangle, this will emulate surface boundaries. *TODO: * - D3D pipeline needs adjustments to the new GlyphInfo structure (managed=1) - Proprietary glyph scaler needs to initialize managed-field at GlyphInfo initialition - Implement tracing support (java2d.trace=log/count) *Possible enhancements:* - Improve blit-mask handling to save fillrate (use scaling without modifying the mask contents if possible) - Implement linear gradients using a 1xY temporary pixmap. *System bugs/troubles:* - XPutImage+Composite used for MaskFill is slow, especially on intel - Rendering artifacts for TransformedBlits intel - Uploading multiple glyphs at once crashes the XServer *Open Questions: * - How does pipeline initialization interier with font stuff? Why does it need static initialization instead of how it is done for now? (mark knows more about that, fixed it recently), - How to install an appropriate ColorModel and use it, instead of bit-twiddling with the pixel value we get? - Is there a reliable way of detecting if a glpyh is LCD or grayscale? For zero-width glyphs rowBytes==width doesn't do the trick. For now, I upload a zero-width glyph as lcd, if GlyphList contains other lcd glyphs. Would streamline the code in some cases a bit. - How does the pipeline behave on bgBlits? Does it fallback to sw loops, or simply emulate the behaviour with a two-step operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090820/581fd2f8/attachment.html