From alexey.ivanov at oracle.com Wed May 2 09:52:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 2 May 2018 10:52:12 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows Message-ID: Hi, Could you please review the following fix for jdk11? bug: https://bugs.openjdk.java.net/browse/JDK-8202476 webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ This is a follow-up fix for JDK-8201226 which enabled building JDK for 32 bit Windows, its code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html I found this issue: http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html This fix removes JNICALL modifiers from exported functions in medialib. After the fix, the failing tests in test/jdk/java/awt/image pass. Thank you in advance. Regards, Alexey From matthias.baesken at sap.com Wed May 2 10:09:36 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 May 2018 10:09:36 +0000 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: References: Message-ID: Hi Alexey, looks good to me (not a Reviewer however). Thanks, Matthias > -----Original Message----- > From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > Sent: Mittwoch, 2. Mai 2018 11:52 > To: 2d-dev <2d-dev at openjdk.java.net> > Cc: build-dev ; Baesken, Matthias > > Subject: [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows > > Hi, > > Could you please review the following fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202476 > webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ > > This is a follow-up fix for JDK-8201226 which enabled building JDK for > 32 bit Windows, its code review: > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html > > I found this issue: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html > > > This fix removes JNICALL modifiers from exported functions in medialib. > After the fix, the failing tests in test/jdk/java/awt/image pass. > > > Thank you in advance. > > Regards, > Alexey From magnus.ihse.bursie at oracle.com Wed May 2 12:03:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 May 2018 14:03:48 +0200 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: References: Message-ID: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> Looks good to me, but you should have a reviewer from the client team as well. /Magnus > 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : > > Hi, > > Could you please review the following fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202476 > webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ > > This is a follow-up fix for JDK-8201226 which enabled building JDK for 32 bit Windows, its code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html > > I found this issue: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html > > > This fix removes JNICALL modifiers from exported functions in medialib. > After the fix, the failing tests in test/jdk/java/awt/image pass. > > > Thank you in advance. > > Regards, > Alexey From philip.race at oracle.com Wed May 2 16:28:29 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 2 May 2018 09:28:29 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> Message-ID: <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> So ... the original change that removed the mapfiles broke the 32 bit build because of inconsistency between declarations + definitions of some functions. It did not affect 64 bit build because JNICALL is a no-op there. The next change (8201226) added JNICALL to make it consistent, but was not reviewed on 2d and was pushed without such review and may have fixed build issues but did NOT fix the product. This change now removes JNICALL where it is not needed and fixes the product and does not break any builds! Please confirm that you've run 64+32 bit builds through the build system AND run imaging tests on both of those. After that is confirmed you have my OK. -phil. On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: > Looks good to me, but you should have a reviewer from the client team as well. > > /Magnus > >> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >> >> Hi, >> >> Could you please review the following fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >> >> This is a follow-up fix for JDK-8201226 which enabled building JDK for 32 bit Windows, its code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >> >> I found this issue: >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >> >> >> This fix removes JNICALL modifiers from exported functions in medialib. >> After the fix, the failing tests in test/jdk/java/awt/image pass. >> >> >> Thank you in advance. >> >> Regards, >> Alexey From alexey.ivanov at oracle.com Wed May 2 18:24:32 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 2 May 2018 19:24:32 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> Message-ID: <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> Hi Phil, Thank you for your review. On 02/05/2018 17:28, Phil Race wrote: > So ... the original change that removed the mapfiles broke the 32 bit > build > because of inconsistency between declarations + definitions of some > functions. > It did not affect 64 bit build because JNICALL is a no-op there. > > The next change (8201226) added JNICALL to make it consistent, but > was not reviewed on 2d and was pushed without such review > and may have fixed build issues but did NOT fix the product. Yes, you're right. It made the product buildable but it did not fix the product. > > This change now removes JNICALL where it is not needed and fixes the > product and does not break > any builds! > > Please confirm that you've run 64+32 bit builds through the build > system AND run imaging tests > on both of those. Yes, I ran 64 builds through the build system and ran 32 bit Windows build on my laptop. I ran regression tests from test/jdk/java/awt/image with both 64 and 32 bit builds on Windows. No failures. Regards, Alexey > > After that is confirmed you have my OK. > > -phil. > > On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >> Looks good to me, but you should have a reviewer from the client team >> as well. >> >> /Magnus >> >>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>> >>> Hi, >>> >>> Could you please review the following fix for jdk11? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>> >>> This is a follow-up fix for JDK-8201226 which enabled building JDK >>> for 32 bit Windows, its code review: >>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>> >>> I found this issue: >>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>> >>> >>> This fix removes JNICALL modifiers from exported functions in medialib. >>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey > From srl295 at gmail.com Wed May 2 18:26:52 2018 From: srl295 at gmail.com (Steven R. Loomis) Date: Wed, 2 May 2018 11:26:52 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors (Resend) In-Reply-To: References: Message-ID: I added a screenshot to https://bugs.openjdk.java.net/browse/JDK-8187100 if anyone wants to see what the impact of this fix is On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis wrote: > (Retrying as actual text) > > Support Unicode Variation Selectors. > > Code by my colleague Toshio Nakamura, I added a simple test, and include > a test that was part of JDK 8187100. (Both tests are run manually.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > > > Hello > > > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > > and Swing components. > > (This proposal was posted to i18n-dev first, and I got a suggestion to > > discuss > > in 2d-dev.) > > > > This proposal changed the following files: > > src/java.desktop/share/classes/sun/font/CMap.java > > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > > src/java.desktop/share/classes/sun/font/Font2D.java > > src/java.desktop/share/classes/sun/font/FontRunIterator.java > > src/java.desktop/share/classes/sun/font/FontUtilities.java > > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > > src/java.desktop/share/native/common/font/sunfontids.h > > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > src/java.desktop/share/native/libfontmanager/sunFont.c > > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > > 542 lines will be changed. > > > > There are three parts. > > 1) Adding CMap format 14 support > > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > > 3) Swing text component's DEL and BS key operations change > > > > > > How would I go about obtaining a sponsor? > > > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > > Chapter 23.4 Variation Selectors > > > > Best regards, > > > > Toshio Nakamura > > IBM Japan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 2 21:19:19 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 2 May 2018 14:19:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8196572: Tests ColConvCCMTest.java and MTColConvTest.java fail Message-ID: <8ecb91e2-4c03-76cd-1b31-07ab8d94c556@oracle.com> Need to update the tolerances allowed in color conversion after LCMS 2.9 upgrade The CIEXYZ overall result is actually much better but the test will fail on a single difference of a color component for a single pixel. More details in the bug report. Bug: https://bugs.openjdk.java.net/browse/JDK-8196572 Webrev: http://cr.openjdk.java.net/~prr/8196572/ -phil. From Sergey.Bylokhov at oracle.com Wed May 2 21:41:26 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 May 2018 14:41:26 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8196572: Tests ColConvCCMTest.java and MTColConvTest.java fail In-Reply-To: <8ecb91e2-4c03-76cd-1b31-07ab8d94c556@oracle.com> References: <8ecb91e2-4c03-76cd-1b31-07ab8d94c556@oracle.com> Message-ID: <49709dd9-2a65-ae46-45ec-795bd864daed@oracle.com> +1 On 02/05/2018 14:19, Phil Race wrote: > Need to update the tolerances allowed in color conversion after LCMS 2.9 > upgrade > The CIEXYZ overall result is actually much better but the test will fail > on a single > difference of a color component for a single pixel. More details in the > bug report. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196572 > Webrev: http://cr.openjdk.java.net/~prr/8196572/ > > -phil. -- Best regards, Sergey. From bourges.laurent at gmail.com Fri May 4 12:30:48 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 4 May 2018 14:30:48 +0200 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application Message-ID: Sergey, Please review this simple fix to the Dasher problem: JBS: https://bugs.openjdk.java.net/browse/JDK-8202580 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8202580.0/ Changes: - (D)Dasher.init: the given dash array is dirty as MarlinRenderingEngine got it from XxxArrayCache (Unsafe.allocateUninitializedArray) when calling copyDashArray(). The fix consists in using the correct part [0; dashLen[ as it was the case in jdk9 - added test that detects wrong dashed rectangle: jtreg fails on jdk10/11 without patch Notes: - the thread may hang in init() if the dirty part contains negative values (normalization loop never exits), but it is very difficult to reproduce and test. - My Apologies: I introduced the bug in dec 2016 when I merged MarlinFX / Marlin2D. Finally, the proposed fix should be backported to JDK10 and also to OpenJFX 10/11. I can propose a patch to OpenJFX11 soon. Could somebody else manage the backport process (JDK-update 10, OpenJFX10) ? Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Fri May 4 17:45:37 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 4 May 2018 18:45:37 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> Message-ID: <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> Hi Phil, Just to confirm: do you approve the change? Thank you, Alexey On 02/05/2018 19:24, Alexey Ivanov wrote: > Hi Phil, > > Thank you for your review. > > On 02/05/2018 17:28, Phil Race wrote: >> So ... the original change that removed the mapfiles broke the 32 bit >> build >> because of inconsistency between declarations + definitions of some >> functions. >> It did not affect 64 bit build because JNICALL is a no-op there. >> >> The next change (8201226) added JNICALL to make it consistent, but >> was not reviewed on 2d and was pushed without such review >> and may have fixed build issues but did NOT fix the product. > > Yes, you're right. It made the product buildable but it did not fix > the product. > >> >> This change now removes JNICALL where it is not needed and fixes the >> product and does not break >> any builds! >> >> Please confirm that you've run 64+32 bit builds through the build >> system AND run imaging tests >> on both of those. > > Yes, I ran 64 builds through the build system and ran 32 bit Windows > build on my laptop. > > I ran regression tests from test/jdk/java/awt/image with both 64 and > 32 bit builds on Windows. No failures. > > > Regards, > Alexey > >> >> After that is confirmed you have my OK. >> >> -phil. >> >> On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >>> Looks good to me, but you should have a reviewer from the client >>> team as well. >>> >>> /Magnus >>> >>>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>>> >>>> Hi, >>>> >>>> Could you please review the following fix for jdk11? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>>> >>>> This is a follow-up fix for JDK-8201226 which enabled building JDK >>>> for 32 bit Windows, its code review: >>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>> >>>> >>>> I found this issue: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>>> >>>> >>>> This fix removes JNICALL modifiers from exported functions in >>>> medialib. >>>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>>> >>>> >>>> Thank you in advance. >>>> >>>> Regards, >>>> Alexey >> > From philip.race at oracle.com Fri May 4 17:53:43 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 4 May 2018 10:53:43 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> Message-ID: <509389b9-ca45-98b6-dbdd-798cb6c1ebcd@oracle.com> Yes, your confirmation on the testing was all that was needed. -phil. On 5/4/2018 10:45 AM, Alexey Ivanov wrote: > Hi Phil, > > Just to confirm: do you approve the change? > > Thank you, > Alexey > > On 02/05/2018 19:24, Alexey Ivanov wrote: >> Hi Phil, >> >> Thank you for your review. >> >> On 02/05/2018 17:28, Phil Race wrote: >>> So ... the original change that removed the mapfiles broke the 32 >>> bit build >>> because of inconsistency between declarations + definitions of some >>> functions. >>> It did not affect 64 bit build because JNICALL is a no-op there. >>> >>> The next change (8201226) added JNICALL to make it consistent, but >>> was not reviewed on 2d and was pushed without such review >>> and may have fixed build issues but did NOT fix the product. >> >> Yes, you're right. It made the product buildable but it did not fix >> the product. >> >>> >>> This change now removes JNICALL where it is not needed and fixes the >>> product and does not break >>> any builds! >>> >>> Please confirm that you've run 64+32 bit builds through the build >>> system AND run imaging tests >>> on both of those. >> >> Yes, I ran 64 builds through the build system and ran 32 bit Windows >> build on my laptop. >> >> I ran regression tests from test/jdk/java/awt/image with both 64 and >> 32 bit builds on Windows. No failures. >> >> >> Regards, >> Alexey >> >>> >>> After that is confirmed you have my OK. >>> >>> -phil. >>> >>> On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >>>> Looks good to me, but you should have a reviewer from the client >>>> team as well. >>>> >>>> /Magnus >>>> >>>>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>>>> >>>>> Hi, >>>>> >>>>> Could you please review the following fix for jdk11? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>>>> >>>>> This is a follow-up fix for JDK-8201226 which enabled building JDK >>>>> for 32 bit Windows, its code review: >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>> >>>>> >>>>> I found this issue: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>>>> >>>>> >>>>> This fix removes JNICALL modifiers from exported functions in >>>>> medialib. >>>>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>>>> >>>>> >>>>> Thank you in advance. >>>>> >>>>> Regards, >>>>> Alexey >>> >> > From alexey.ivanov at oracle.com Fri May 4 17:52:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 4 May 2018 18:52:12 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <509389b9-ca45-98b6-dbdd-798cb6c1ebcd@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> <509389b9-ca45-98b6-dbdd-798cb6c1ebcd@oracle.com> Message-ID: Thank you! -- Alexey On 04/05/2018 18:53, Phil Race wrote: > Yes, your confirmation on the testing was all that was needed. > > -phil. > > On 5/4/2018 10:45 AM, Alexey Ivanov wrote: >> Hi Phil, >> >> Just to confirm: do you approve the change? >> >> Thank you, >> Alexey >> >> On 02/05/2018 19:24, Alexey Ivanov wrote: >>> Hi Phil, >>> >>> Thank you for your review. >>> >>> On 02/05/2018 17:28, Phil Race wrote: >>>> So ... the original change that removed the mapfiles broke the 32 >>>> bit build >>>> because of inconsistency between declarations + definitions of some >>>> functions. >>>> It did not affect 64 bit build because JNICALL is a no-op there. >>>> >>>> The next change (8201226) added JNICALL to make it consistent, but >>>> was not reviewed on 2d and was pushed without such review >>>> and may have fixed build issues but did NOT fix the product. >>> >>> Yes, you're right. It made the product buildable but it did not fix >>> the product. >>> >>>> >>>> This change now removes JNICALL where it is not needed and fixes >>>> the product and does not break >>>> any builds! >>>> >>>> Please confirm that you've run 64+32 bit builds through the build >>>> system AND run imaging tests >>>> on both of those. >>> >>> Yes, I ran 64 builds through the build system and ran 32 bit Windows >>> build on my laptop. >>> >>> I ran regression tests from test/jdk/java/awt/image with both 64 and >>> 32 bit builds on Windows. No failures. >>> >>> >>> Regards, >>> Alexey >>> >>>> >>>> After that is confirmed you have my OK. >>>> >>>> -phil. >>>> >>>> On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >>>>> Looks good to me, but you should have a reviewer from the client >>>>> team as well. >>>>> >>>>> /Magnus >>>>> >>>>>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could you please review the following fix for jdk11? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>>>>> >>>>>> This is a follow-up fix for JDK-8201226 which enabled building >>>>>> JDK for 32 bit Windows, its code review: >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>> >>>>>> >>>>>> I found this issue: >>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>>>>> >>>>>> >>>>>> This fix removes JNICALL modifiers from exported functions in >>>>>> medialib. >>>>>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>>>>> >>>>>> >>>>>> Thank you in advance. >>>>>> >>>>>> Regards, >>>>>> Alexey >>>> >>> >> > From philip.race at oracle.com Sat May 5 23:11:05 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 05 May 2018 16:11:05 -0700 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application In-Reply-To: References: Message-ID: <5AEE3A09.4060104@oracle.com> Looks fine to me. Did you run the rendering related regression tests ? I am not sure if a backport to 10 will be approved under the new guidelines : http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-April/000102.html -phil. On 5/4/18, 5:30 AM, Laurent Bourg?s wrote: > Sergey, > > Please review this simple fix to the Dasher problem: > JBS: https://bugs.openjdk.java.net/browse/JDK-8202580 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8202580.0/ > > > Changes: > - (D)Dasher.init: the given dash array is dirty as > MarlinRenderingEngine got it from XxxArrayCache > (Unsafe.allocateUninitializedArray) when calling copyDashArray(). The > fix consists in using the correct part [0; dashLen[ as it was the case > in jdk9 > - added test that detects wrong dashed rectangle: jtreg fails on > jdk10/11 without patch > > Notes: > - the thread may hang in init() if the dirty part contains negative > values (normalization loop never exits), but it is very difficult to > reproduce and test. > - My Apologies: I introduced the bug in dec 2016 when I merged > MarlinFX / Marlin2D. > > > Finally, the proposed fix should be backported to JDK10 and also to > OpenJFX 10/11. I can propose a patch to OpenJFX11 soon. > > Could somebody else manage the backport process (JDK-update 10, > OpenJFX10) ? > > Regards, > Laurent From bourges.laurent at gmail.com Mon May 7 16:27:31 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 07 May 2018 16:27:31 +0000 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application In-Reply-To: <5AEE3A09.4060104@oracle.com> References: <5AEE3A09.4060104@oracle.com> Message-ID: Phil, Le dim. 6 mai 2018 ? 01:11, Philip Race a ?crit : > Looks fine to me. Did you run the rendering related regression tests ? > I ran all tests in sun/java2d/marlin. What other tests should I run ? This fix is very low risk as it fixes only the dash array usage. > > I am not sure if a backport to 10 will be approved under the new > guidelines : > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-April/000102.html Agreed, it is not P1 but the reporter mentioned his swing app was hanging in some case at startup so this bug causes some stability problems. It depends on your opinions if it is worth to be fixed asap or not. Sergey, what do you think ? Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon May 7 16:39:25 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 07 May 2018 09:39:25 -0700 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application In-Reply-To: References: <5AEE3A09.4060104@oracle.com> Message-ID: <5AF0813D.7010608@oracle.com> On 5/7/18, 9:27 AM, Laurent Bourg?s wrote: > Phil, > > Le dim. 6 mai 2018 ? 01:11, Philip Race > a ?crit : > > Looks fine to me. Did you run the rendering related regression tests ? > > > I ran all tests in sun/java2d/marlin. What other tests should I run ? > This fix is very low risk as it fixes only the dash array usage. That's OK. We'll run more tests in our nightly once it is pushed. > > I am not sure if a backport to 10 will be approved under the new > guidelines : > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-April/000102.html > > > Agreed, it is not P1 but the reporter mentioned his swing app was > hanging in some case at startup so this bug causes some stability > problems. > > It depends on your opinions if it is worth to be fixed asap or not. Step 1 is to get it pushed to 11. It needs to bake before we can ask if we decide we should. -phil. > Sergey, what do you think ? > > Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon May 7 18:57:33 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 7 May 2018 11:57:33 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8176510: java/awt/font/GlyphVector/TestLayoutFlags.java fails with OpenJDK Message-ID: <9250055b-3f2f-fcc5-c000-ee431fef143b@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8176510 Webrev: http://cr.openjdk.java.net/~prr/8176510/ This test has been a bit flaky as part of what it tests is font dependent. It relied on knowing it could find Lucida Sans and what the JDK's opentype font layout library did when it is applied to specific text and that font. I've updated the test to (a) not rely on Lucida Sans, and to just skip specific sub-tests if it can't find a suitable font. (b) be more flexible about what flags it might expect are set. In particular layout of the Arabic text used here might set RTL, or it might set COMPLEX_GLYPHS .. or it may even set both I've run this on our nightly test system and it passed on all platforms there. -phil From Sergey.Bylokhov at oracle.com Mon May 7 19:20:51 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 May 2018 12:20:51 -0700 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application In-Reply-To: <5AF0813D.7010608@oracle.com> References: <5AEE3A09.4060104@oracle.com> <5AF0813D.7010608@oracle.com> Message-ID: Looks fine. On 07/05/2018 09:39, Philip Race wrote: >> Sergey, what do you think ? We can request a backport after the push to jdk11, if no new issues will be found. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon May 7 19:44:11 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 May 2018 12:44:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8176510: java/awt/font/GlyphVector/TestLayoutFlags.java fails with OpenJDK In-Reply-To: <9250055b-3f2f-fcc5-c000-ee431fef143b@oracle.com> References: <9250055b-3f2f-fcc5-c000-ee431fef143b@oracle.com> Message-ID: +1 On 07/05/2018 11:57, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8176510 > Webrev: http://cr.openjdk.java.net/~prr/8176510/ > > This test has been a bit flaky as part of what it tests is font dependent. > It relied on knowing it could find Lucida Sans and what the JDK's opentype > font layout library did when it is applied to specific text and that font. > > I've updated the test to > (a) not rely on Lucida Sans, and to just skip specific sub-tests if it > can't find a suitable font. > (b) be more flexible about what flags it might expect are set. > In particular layout of the Arabic text used here might set RTL, > or it might set COMPLEX_GLYPHS .. or it may even set both > > I've run this on our nightly test system and it passed on all platforms > there. > > -phil > > -- Best regards, Sergey. From kevin.rushforth at oracle.com Mon May 7 20:15:33 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 7 May 2018 13:15:33 -0700 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application In-Reply-To: References: Message-ID: <21025614-aac2-4f4a-711e-b248fc5c33e3@oracle.com> I filed https://bugs.openjdk.java.net/browse/JDK-8202743 to track getting this fix into JavaFX. -- Kevin On 5/4/2018 5:30 AM, Laurent Bourg?s wrote: > Sergey, > > Please review this simple fix to the Dasher problem: > JBS: https://bugs.openjdk.java.net/browse/JDK-8202580 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8202580.0/ > > > Changes: > - (D)Dasher.init: the given dash array is dirty as > MarlinRenderingEngine got it from XxxArrayCache > (Unsafe.allocateUninitializedArray) when calling copyDashArray(). The > fix consists in using the correct part [0; dashLen[ as it was the case > in jdk9 > - added test that detects wrong dashed rectangle: jtreg fails on > jdk10/11 without patch > > Notes: > - the thread?may hang in init() if the dirty part contains negative > values (normalization loop never exits), but it is very difficult to > reproduce and test. > - My Apologies: I introduced the bug in dec 2016 when I merged > MarlinFX / Marlin2D. > > > Finally, the proposed fix should be backported to JDK10 and also to > OpenJFX 10/11. I can propose a patch to OpenJFX11 soon. > > Could somebody else manage the backport process (JDK-update 10, > OpenJFX10) ? > > Regards, > Laurent From bourges.laurent at gmail.com Mon May 7 21:20:36 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 07 May 2018 21:20:36 +0000 Subject: [OpenJDK 2D-Dev] RFR [11] JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application In-Reply-To: References: <5AEE3A09.4060104@oracle.com> <5AF0813D.7010608@oracle.com> Message-ID: Thanks Phil & Sergey for your reviews. I will push tomorrow morning (FR)... Thanks Kevin for submitting the jfx11 bug. FYI I am finalizing marlinFX 0.9.1 patch too (ClipShapeTest adapted) Laurent Le 7 mai 2018 9:20 PM, "Sergey Bylokhov" a ?crit : Looks fine. On 07/05/2018 09:39, Philip Race wrote: >> Sergey, what do you think ? We can request a backport after the push to jdk11, if no new issues will be found. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue May 8 15:32:54 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 8 May 2018 08:32:54 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8202767 : java/awt/font/GlyphVector/TestLayoutFlags.java is missing null check Message-ID: <663ca2e3-ea0b-4333-4bdb-552de761b8a9@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8202767 webrev : http://cr.openjdk.java.net/~prr/8202767/ On a system without fonts that support this test, findFont returns null which in turn makes makeGlyphVector return null. The test needs to catch this else it will NPE -phil. From Sergey.Bylokhov at oracle.com Tue May 8 17:24:52 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 8 May 2018 10:24:52 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8202767 : java/awt/font/GlyphVector/TestLayoutFlags.java is missing null check In-Reply-To: <663ca2e3-ea0b-4333-4bdb-552de761b8a9@oracle.com> References: <663ca2e3-ea0b-4333-4bdb-552de761b8a9@oracle.com> Message-ID: <6161c9f0-e60e-194f-bc0d-41693e63d591@oracle.com> +1 On 08/05/2018 08:32, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8202767 > webrev : http://cr.openjdk.java.net/~prr/8202767/ > > On a system without fonts that support this test, findFont returns null > which in turn makes makeGlyphVector return null. > The test needs to catch this else it will NPE > > -phil. -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed May 9 06:21:03 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 8 May 2018 23:21:03 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete In-Reply-To: References: <6f63be23-a3dc-482e-b234-8c423a2a1755@default> <676add25-8585-406b-96fc-66da4dab48dc@default> <2c6644c3-4d76-4931-85ae-df1482e0284e@default> Message-ID: <65011645-ec21-46ac-befb-d436b6e3fe1d@default> Hi Jay, Here are my observations/questions: 1. I see that the fix is to update the bKGD_colorType for Background color child. However, don't you need to do the same thing for paletted images as well? 2. As for the test case, I'm not sure how ImageReaders and ImageWriters work. I see that you query them from ImageIO, so the question is, do you need to get a new ImageReader/ImageWriter for each image read/write operation? If so, then, there is a potential problem when you call VerifyNativeRGBValuesFromBKGDChunk() and VerifyStandardRGBValuesFromBKGDChunk() in succession, since each in turn calls writeAndReadMetaData() and the writer is disposed. On the other hand, if querying for the reader/writer for once is enough, then you can initialize the image reader/writer in the static block itself, and then run the whole test. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, April 18, 2018 3:34 PM To: 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Hello All, Since changes related to JDK-6574555 is pushed. Please find new webrev which captures test case changes over JDK-6574555. http://cr.openjdk.java.net/~jdv/5109146/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, April 17, 2018 3:34 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-5109146 Webrev : http://cr.openjdk.java.net/~jdv/5109146/webrev.00/ Issue: PNGMetadata.mergeStandardTree() function doesn't set proper bKGD colortype. Solution: When bKGD R, G, B values are unique we need to store appropriate bKGD colortype in metadata. Note : Test case which is present as part of review in JDK-6574555 is only updated to handle regression scenario for this bug also. Regression scenario between this bug and JDK-6574555 differ only in what type(native/standard) metadata we use to merge bKGD RGB values. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed May 9 12:43:31 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 9 May 2018 05:43:31 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete In-Reply-To: <65011645-ec21-46ac-befb-d436b6e3fe1d@default> References: <6f63be23-a3dc-482e-b234-8c423a2a1755@default> <676add25-8585-406b-96fc-66da4dab48dc@default> <2c6644c3-4d76-4931-85ae-df1482e0284e@default> <65011645-ec21-46ac-befb-d436b6e3fe1d@default> Message-ID: <328b0c24-2f7c-4e9e-a120-aacbf4e647f9@default> Hi Krishna, Thanks for the review. 1. I see that the fix is to update the bKGD_colorType for Background color child. However, don't you need to do the same thing for paletted images as well? We are not updating bKGD_colorType, we are adding missing bKGD_colorType when user wants to specify background color. In standard metadata if user wants to provide color palette and with corresponding background color index then he should specify palette using Chroma->Palette node and background index using Chroma-> BackgroundIndex node. 1. As for the test case, I'm not sure how ImageReaders and ImageWriters work. I see that you query them from ImageIO, so the question is, do you need to get a new ImageReader/ImageWriter for each image read/write operation? If so, then, there is a potential problem when you call VerifyNativeRGBValuesFromBKGDChunk() and VerifyStandardRGBValuesFromBKGDChunk() in succession, since each in turn calls writeAndReadMetaData() and the writer is disposed. On the other hand, if querying for the reader/writer for once is enough, then you can initialize the image reader/writer in the static block itself, and then run the whole test. We don't need multiple instances of writer/reader.I have changed the code to create ImageReader & Writer instance only once. Also PNGImageWriter/Reader doesn't override dispose() method present in super class which is just empty method, that is the reason why we didn't get NPE when writer was getting disposed and used again previously. I have still kept writer & reader dispose() calls at the end in test case which will be used if we plan to override these methods in future. Also I noticed that test case was not failing even without fix. This was happening because of usage of common metadata between VerifyNativeRGBValuesFromBKGDChunk() & VerifyStandardRGBValuesFromBKGDChunk(). I have updated the test case to create independent metadata variables for VerifyNativeRGBValuesFromBKGDChunk() & VerifyStandardRGBValuesFromBKGDChunk(). Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/5109146/webrev.02/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, May 09, 2018 11:51 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Hi Jay, Here are my observations/questions: 1. I see that the fix is to update the bKGD_colorType for Background color child. However, don't you need to do the same thing for paletted images as well? 2. As for the test case, I'm not sure how ImageReaders and ImageWriters work. I see that you query them from ImageIO, so the question is, do you need to get a new ImageReader/ImageWriter for each image read/write operation? If so, then, there is a potential problem when you call VerifyNativeRGBValuesFromBKGDChunk() and VerifyStandardRGBValuesFromBKGDChunk() in succession, since each in turn calls writeAndReadMetaData() and the writer is disposed. On the other hand, if querying for the reader/writer for once is enough, then you can initialize the image reader/writer in the static block itself, and then run the whole test. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, April 18, 2018 3:34 PM To: 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Hello All, Since changes related to JDK-6574555 is pushed. Please find new webrev which captures test case changes over JDK-6574555. http://cr.openjdk.java.net/~jdv/5109146/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, April 17, 2018 3:34 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-5109146 Webrev : http://cr.openjdk.java.net/~jdv/5109146/webrev.00/ Issue: PNGMetadata.mergeStandardTree() function doesn't set proper bKGD colortype. Solution: When bKGD R, G, B values are unique we need to store appropriate bKGD colortype in metadata. Note : Test case which is present as part of review in JDK-6574555 is only updated to handle regression scenario for this bug also. Regression scenario between this bug and JDK-6574555 differ only in what type(native/standard) metadata we use to merge bKGD RGB values. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 11 19:24:31 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 11 May 2018 12:24:31 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8198991: Move Java2D demo to the open repository Message-ID: <5AF5EDEF.2060503@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8198991 Webrev: http://cr.openjdk.java.net/~prr/8198991/ This moves the Java 2D demo from "closed" to "open". It is now called "J2Ddemo" to avoid any trademark questions. This has already been reviewed internally and the images here are OK to keep. -phil. From Sergey.Bylokhov at oracle.com Fri May 11 20:49:55 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2018 13:49:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8198991: Move Java2D demo to the open repository In-Reply-To: <5AF5EDEF.2060503@oracle.com> References: <5AF5EDEF.2060503@oracle.com> Message-ID: +1 On 11/05/2018 12:24, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8198991 > Webrev: http://cr.openjdk.java.net/~prr/8198991/ > > This moves the Java 2D demo from "closed" to "open". > It is now called "J2Ddemo" to avoid any trademark questions. > This has already been reviewed internally and the images here are OK to > keep. > > -phil. -- Best regards, Sergey. From linuxhippy at gmail.com Fri May 11 20:40:26 2018 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 11 May 2018 22:40:26 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8198991: Move Java2D demo to the open repository In-Reply-To: <5AF5EDEF.2060503@oracle.com> References: <5AF5EDEF.2060503@oracle.com> Message-ID: Hi, > This moves the Java 2D demo from "closed" to "open". > It is now called "J2Ddemo" to avoid any trademark questions. > This has already been reviewed internally and the images here are OK to > keep. This is awesome news :) Java2Demo is such a handy tool to visually check various features provided by Java2D. Br, Clemens From philip.race at oracle.com Fri May 11 21:46:20 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 14:46:20 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8198412 : MonospacedGlyphWidthTest.java may fail on Solaris Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8198412 webrev: http://cr.openjdk.java.net/~prr/8198412/ Updates the test to make sure we even support ascii as monospaced before testing the other ranges. Also makes sure the code points it is testing are supported else the test may not be valid either. -phil. From Sergey.Bylokhov at oracle.com Fri May 11 21:58:26 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2018 14:58:26 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8198412 : MonospacedGlyphWidthTest.java may fail on Solaris In-Reply-To: References: Message-ID: <5c901f71-b479-29d0-5dd1-6cea8c1dc5e1@oracle.com> Looks fine, Note that the problem list should be updated. On 11/05/2018 14:46, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8198412 > webrev: http://cr.openjdk.java.net/~prr/8198412/ > > Updates the test to make sure we even support ascii as monospaced before > testing the other ranges. Also makes sure the code points it is testing are > supported else the test? may not be valid either. > > -phil. -- Best regards, Sergey. From philip.race at oracle.com Sat May 12 04:00:39 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 11 May 2018 21:00:39 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8198412 : MonospacedGlyphWidthTest.java may fail on Solaris In-Reply-To: <5c901f71-b479-29d0-5dd1-6cea8c1dc5e1@oracle.com> References: <5c901f71-b479-29d0-5dd1-6cea8c1dc5e1@oracle.com> Message-ID: <5AF666E7.5070709@oracle.com> On 5/11/18, 2:58 PM, Sergey Bylokhov wrote: > Looks fine, > Note that the problem list should be updated. Yes, I remembered that after sending out the webrev. Fixed in the push. -phil. > > On 11/05/2018 14:46, Phil Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8198412 >> webrev: http://cr.openjdk.java.net/~prr/8198412/ >> >> Updates the test to make sure we even support ascii as monospaced before >> testing the other ranges. Also makes sure the code points it is >> testing are >> supported else the test may not be valid either. >> >> -phil. > > From TOSHIONA at jp.ibm.com Mon May 14 08:28:40 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 14 May 2018 17:28:40 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend) In-Reply-To: References: Message-ID: Could someone review our proposal to support Unicode Variation Selectors? > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ Toshio Nakamura > From: "Steven R. Loomis" > To: 2d-dev <2d-dev at openjdk.java.net> > Date: 2018/05/03 03:27 > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation > Selectors (Resend) > Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> > > I added a screenshot to?https://bugs.openjdk.java.net/browse/JDK-8187100 > if anyone wants to see what the impact of this fix is > > On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis wrote: > (Retrying as actual text) > > Support Unicode Variation Selectors. > > Code by my colleague Toshio Nakamura, ?I added a simple test, and > include a test that was part of JDK 8187100. (Both tests are run manually.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > > > Hello > > > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > > and Swing components. > > (This proposal was posted to i18n-dev first, and I got a suggestion to > > discuss > > ?in 2d-dev.) > > > > This proposal changed the following files: > > src/java.desktop/share/classes/sun/font/CMap.java > > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > > src/java.desktop/share/classes/sun/font/Font2D.java > > src/java.desktop/share/classes/sun/font/FontRunIterator.java > > src/java.desktop/share/classes/sun/font/FontUtilities.java > > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > > src/java.desktop/share/native/common/font/sunfontids.h > > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > src/java.desktop/share/native/libfontmanager/sunFont.c > > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > > 542 lines will be changed. > > > > There are three parts. > > 1) Adding CMap format 14 support > > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > > 3) Swing text component's DEL and BS key operations change > > > > > > How would I go about obtaining a sponsor? > > > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > > ? ? ?Chapter 23.4 Variation Selectors > > > > Best regards, > > > > Toshio Nakamura > > IBM Japan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Mon May 14 10:06:26 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 14 May 2018 11:06:26 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> Message-ID: Hi Phil, Would an acceptable compromise be to deliver the source code change and send the code to the upstream community, allowing them to include the fix if/when they are able? I believe Magnus was advocating this idea as well. See below. Best Regards Adam Farley > Same here. I would like to have this fix in, but do not want to go > over Phils head. > > I think Phil was the main objector, maybe he could reconsider?` > > Thanks, Thomas > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > wrote: > > I don't object, but it's not build code so I don't have the final say. > > > > /Magnus > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > Hi All, > > > > Does anyone have an objection to pushing this tiny change in? > > > > It doesn't break anything, it fixes a build break on two supported > > platforms, and it seems > > like we never refresh the code from upstream. > > > > - Adam > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > >> of logic required > >> to properly analyse the toolchain version string. > >> > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > >> and Make doesn't > >> seem to do substring stuff unless you mess around with shells. > >> > >> Plus, as people have said, it's better to solve problem x (or work around > >> a specific > >> instance of x) than to ignore the exception, even if the ignoring code is > >> toolchain- > >> specific. > >> > >> - Adam Farley > >> > >> > On 2018-03-27 18:44, Phil Race wrote: > >> > > >> >> As I said I prefer the make file change, since this is a change to an > >> >> upstream library. > >> > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > >> > reviewer. :) > >> > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > >> > complaint seems reasonable, and disabling it might cause us to miss other > >> > future errors. > >> > > >> > Why can't we push the source code fix, and also submit it upstream? > >> > > >> > /Magnus > >> > > >> > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > >> > 6b, so this code > >> > seems to have stood the test of time. I'm also unclear why the compiler > >> > would > >> > complain about that and not the one a few lines later > >> > > >> > > >> > 819 while (bits[i] == 0) /* find largest codelength still in > >> > use */ > >> > 820 i--; > >> > > >> > A push to jchuff.c will get blown away if/when we upgrade. > >> > A tool-chain specific fix in the makefile with an appropriate comment is > >> > more targeted. > >> > >> Phil, > >> > >> Returning to this. > >> > >> While I understand your reluctance to patch upstream code, let me point > >> out that we have not updated libjpeg a single time since the JDK was open > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page > >> on libjpeg, and this is the latest "uncontroversial" version of the source. > >> Versions 7 and up have proprietary extensions, which in turn has resulted in > >> multiple forks of libjpeg. As it stands, it seems unlikely that we will ever > >> replace libjpeg 6b with a simple upgrade from upstream. > >> > >> I therefore maintain my position that a source code fix would be the best > >> way forward here. > >> > >> /Magnus > >> > >> > > >> > > >> > -phil. > >> > > >> > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > >> > > >> > Hi all, > >> > > >> > > >> > just a friendly reminder. I would like to push this tiny fix because > >> > tripping over this on our linux s390x builds is annoying (yes, we can > >> > maintain patch queues, but this is a constant error source). > >> > > >> > > >> > I will wait for 24 more hours until a reaction. If no serious objections > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph > >> > langer are both Reviewers). > >> > > >> > > >> > Thanks! Thomas > >> > > >> > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > >> > wrote: > >> > > >> > Hi all, > >> > > >> > > >> > may I please have another review for this really trivial change. It > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix > >> > this. > >> > > >> > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > >> > webrev: > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > >> > > >> > > >> > This was contributed by Adam Farley at IBM. > >> > > >> > > >> > I already reviewed this. I also test-built on zlinux and it works. > >> > > >> > > >> > Thanks, Thomas > >> > > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >> > >> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon May 14 16:49:20 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 14 May 2018 09:49:20 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete In-Reply-To: <328b0c24-2f7c-4e9e-a120-aacbf4e647f9@default> References: <6f63be23-a3dc-482e-b234-8c423a2a1755@default> <676add25-8585-406b-96fc-66da4dab48dc@default> <2c6644c3-4d76-4931-85ae-df1482e0284e@default> <65011645-ec21-46ac-befb-d436b6e3fe1d@default> <328b0c24-2f7c-4e9e-a120-aacbf4e647f9@default> Message-ID: <9192cc60-fe95-2db2-91c0-ea0de296c695@oracle.com> +1 from me. -phil. On 05/09/2018 05:43 AM, Jayathirth D V wrote: > > Hi Krishna, > > Thanks for the review. > > 1.I see that the fix is to update the bKGD_colorType for Background > color child. However, don?t you need to do the same thing for paletted > images as well? > > /We are not updating bKGD_colorType, we are adding missing > bKGD_colorType when user wants to specify background color. In > standard metadata if user wants to provide color palette and with > corresponding background color index then he should specify palette > using Chroma->Palette node and background index using Chroma-> > //BackgroundIndex node./ > > 1.As for the test case, I?m not sure how ImageReaders and ImageWriters > work. > > I see that you query them from ImageIO, so the question is, do you > need to get a new ImageReader/ImageWriter for each image read/write > operation? > > If so, then, there is a potential problem when you call > VerifyNativeRGBValuesFromBKGDChunk() and > VerifyStandardRGBValuesFromBKGDChunk() in succession, since each in > turn calls writeAndReadMetaData() and the writer is disposed. > > On the other hand, if querying for the reader/writer for once is > enough, then you can initialize the image reader/writer in the static > block itself, and then run the whole test. > > /We don?t need multiple instances of writer/reader.I have changed the > code to create ImageReader & Writer instance only once. Also > PNGImageWriter/Reader doesn?t override dispose() method present in > super class which is just empty method, that is the reason why we > didn?t get NPE when writer was getting disposed and used again > previously. I have still kept writer & reader dispose() calls at the > end in test case which will be used if we plan to override these > methods in future./ > > Also I noticed that test case was not failing even without fix. This > was happening because of usage of common metadata between > VerifyNativeRGBValuesFromBKGDChunk() & > VerifyStandardRGBValuesFromBKGDChunk(). I have updated the test case > to create independent metadata variables for > VerifyNativeRGBValuesFromBKGDChunk() & > VerifyStandardRGBValuesFromBKGDChunk(). > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/5109146/webrev.02/ > > > Thanks, > > Jay > > *From:* Krishna Addepalli > *Sent:* Wednesday, May 09, 2018 11:51 AM > *To:* 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata > Background color initialization from standard metadata is incomplete > > Hi Jay, > > Here are my observations/questions: > > 1.I see that the fix is to update the bKGD_colorType for Background > color child. However, don?t you need to do the same thing for paletted > images as well? > > 2.As for the test case, I?m not sure how ImageReaders and ImageWriters > work. > > I see that you query them from ImageIO, so the question is, do you > need to get a new ImageReader/ImageWriter for each image read/write > operation? > > If so, then, there is a potential problem when you call > VerifyNativeRGBValuesFromBKGDChunk() and > VerifyStandardRGBValuesFromBKGDChunk() in succession, since each in > turn calls writeAndReadMetaData() and the writer is disposed. > > On the other hand, if querying for the reader/writer for once is > enough, then you can initialize the image reader/writer in the static > block itself, and then run the whole test. > > Thanks, > > Krishna > > *From:* Jayathirth D V > *Sent:* Wednesday, April 18, 2018 3:34 PM > *To:* 2d-dev > *Subject:* RE: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata > Background color initialization from standard metadata is incomplete > > Hello All, > > Since changes related to JDK-6574555 is pushed. > > Please find new webrev which captures test case changes over JDK-6574555. > > http://cr.openjdk.java.net/~jdv/5109146/webrev.01/ > > > Thanks, > > Jay > > *From:* Jayathirth D V > *Sent:* Tuesday, April 17, 2018 3:34 PM > *To:* 2d-dev > *Subject:* [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata > Background color initialization from standard metadata is incomplete > > Hello All, > > Please review the following fix in JDK11 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-5109146 > > Webrev : http://cr.openjdk.java.net/~jdv/5109146/webrev.00/ > > > _Issue:_ PNGMetadata.mergeStandardTree() function doesn?t set proper > bKGD colortype. > > _Solution:_ When bKGD R, G, B values are unique we need to store > appropriate bKGD colortype in metadata. > > _Note_ : Test case which is present as part of review in JDK-6574555 > is only updated to handle regression scenario for this bug also. > Regression scenario between this bug and JDK-6574555 differ only in > what type(native/standard) metadata we use to merge bKGD RGB values. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed May 16 15:16:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2018 08:16:16 -0700 Subject: [OpenJDK 2D-Dev] [11] Review Request: 8199150 and 8150156 Message-ID: <91d14378-516e-9fe9-f6e8-97a6fff2e8d6@oracle.com> Hello. Please review the fix for jdk11, which fixed some accessibility issues in the specification. Bug: https://bugs.openjdk.java.net/browse/JDK-8199150 https://bugs.openjdk.java.net/browse/JDK-8150156 Fix: http://cr.openjdk.java.net/~serb/8199150/webrev.01 Description: - The links to "bugs.sun.com" were replaced by "bugs.java.com" - To most of our doc-files the "
" tag is added. - In some files the numbers in "H" tag are renumbered to h1/h2/h3 - In JTextComponent the tag was removed, this line was missed in JDK-8184219 - The accessibility checkers report that the red color on the white/gray background has "Insufficient contrast", so I replaced red to blue color -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 16 21:00:26 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2018 14:00:26 -0700 Subject: [OpenJDK 2D-Dev] [11] Review Request: 8203027 Open source tests for "java.awt.geom" Message-ID: <40c848ab-abc6-fe2a-d2a6-65e7f23fa34c@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203027 Webrev: http://cr.openjdk.java.net/~serb/8203027/webrev.00 This is a request to move the tests for "java.awt.geom" to the open repo. Most of the tests copied as-is(but in some cases some small cleanup was done). -- Best regards, Sergey. From philip.race at oracle.com Wed May 16 22:16:00 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 May 2018 15:16:00 -0700 Subject: [OpenJDK 2D-Dev] [11] Review Request: 8203027 Open source tests for "java.awt.geom" In-Reply-To: <40c848ab-abc6-fe2a-d2a6-65e7f23fa34c@oracle.com> References: <40c848ab-abc6-fe2a-d2a6-65e7f23fa34c@oracle.com> Message-ID: <7e76eabd-2721-5d51-c655-37a640191a00@oracle.com> +1 from me. -phil. On 05/16/2018 02:00 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203027 > Webrev: http://cr.openjdk.java.net/~serb/8203027/webrev.00 > > This is a request to move the tests for "java.awt.geom" to the open > repo. Most of the tests copied as-is(but in some cases some small > cleanup was done). > > From philip.race at oracle.com Wed May 16 22:52:17 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 May 2018 15:52:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources Message-ID: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> Webrev: http://cr.openjdk.java.net/~prr/8191522/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 The Lucida fonts have never been part of OpenJDK but many places in the code and tests reference them. There are even a couple of stray fonts.dir files that probably should not have been in there. This fix cleans up as much of this as we are also intending to no longer ship these fonts with Oracle JDK as it converges with OpenJDK. There is one minor build change in here, so I've included the build list. -phil. From erik.joelsson at oracle.com Wed May 16 23:08:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 May 2018 16:08:40 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources In-Reply-To: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> References: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> Message-ID: Build changes look good. /Erik On 2018-05-16 15:52, Phil Race wrote: > Webrev: http://cr.openjdk.java.net/~prr/8191522/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 > > The Lucida fonts have never been part of OpenJDK but many places in > the code > and tests reference them. There are even a couple of stray fonts.dir > files that > probably should not have been in there. > > This fix cleans up as much of this as we are also intending to no > longer ship > these fonts with Oracle JDK as it converges with OpenJDK. > > There is one minor build change in here, so I've included the build list. > > -phil. > From philip.race at oracle.com Thu May 17 00:20:16 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 May 2018 17:20:16 -0700 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> Message-ID: <5AFCCAC0.6000706@oracle.com> Hi, OK .. if you can convince upstream this is worth doing, then we can accept it as we would not regress when updating. As I noted previously : http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html this is still an issue in the currently being developed 9c train. -phil. On 5/14/18, 3:06 AM, Adam Farley8 wrote: > Hi Phil, > > Would an acceptable compromise be to deliver the source code change > and send the code to the upstream community, allowing them to include > the fix if/when they are able? > > I believe Magnus was advocating this idea as well. See below. > > Best Regards > > Adam Farley > > > Same here. I would like to have this fix in, but do not want to go > > over Phils head. > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > Thanks, Thomas > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > wrote: > > > I don't object, but it's not build code so I don't have the final say. > > > > > > /Magnus > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > Hi All, > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > It doesn't break anything, it fixes a build break on two supported > > > platforms, and it seems > > > like we never refresh the code from upstream. > > > > > > - Adam > > > > > >> I also advocate the source code fix, as Make isn't meant to use > the sort > > >> of logic required > > >> to properly analyse the toolchain version string. > > >> > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using > 4.8.6, > > >> and Make doesn't > > >> seem to do substring stuff unless you mess around with shells. > > >> > > >> Plus, as people have said, it's better to solve problem x (or work > around > > >> a specific > > >> instance of x) than to ignore the exception, even if the ignoring > code is > > >> toolchain- > > >> specific. > > >> > > >> - Adam Farley > > >> > > >> > On 2018-03-27 18:44, Phil Race wrote: > > >> > > > >> >> As I said I prefer the make file change, since this is a change > to an > > >> >> upstream library. > > >> > > > >> > Newtons fourth law: For every reviewer, there's an equal and > opposite > > >> > reviewer. :) > > >> > > > >> > Here I am, advocating a source code fix. As Thomas says, the > compiler > > >> > complaint seems reasonable, and disabling it might cause us to > miss other > > >> > future errors. > > >> > > > >> > Why can't we push the source code fix, and also submit it upstream? > > >> > > > >> > /Magnus > > >> > > > >> > > > >> > I've looked at jpeg-9c and it still looks identical to what we > have in > > >> > 6b, so this code > > >> > seems to have stood the test of time. I'm also unclear why the > compiler > > >> > would > > >> > complain about that and not the one a few lines later > > >> > > > >> > > > >> > 819 while (bits[i] == 0) /* find largest codelength > still in > > >> > use */ > > >> > 820 i--; > > >> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > >> > A tool-chain specific fix in the makefile with an appropriate > comment is > > >> > more targeted. > > >> > > >> Phil, > > >> > > >> Returning to this. > > >> > > >> While I understand your reluctance to patch upstream code, let me > point > > >> out that we have not updated libjpeg a single time since the JDK > was open > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > Wikipedia page > > >> on libjpeg, and this is the latest "uncontroversial" version of > the source. > > >> Versions 7 and up have proprietary extensions, which in turn has > resulted in > > >> multiple forks of libjpeg. As it stands, it seems unlikely that we > will ever > > >> replace libjpeg 6b with a simple upgrade from upstream. > > >> > > >> I therefore maintain my position that a source code fix would be > the best > > >> way forward here. > > >> > > >> /Magnus > > >> > > >> > > > >> > > > >> > -phil. > > >> > > > >> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > just a friendly reminder. I would like to push this tiny fix > because > > >> > tripping over this on our linux s390x builds is annoying (yes, > we can > > >> > maintain patch queues, but this is a constant error source). > > >> > > > >> > > > >> > I will wait for 24 more hours until a reaction. If no serious > objections > > >> > are forcoming, I want to push it (tier1 tests ran thru, and me > and Christoph > > >> > langer are both Reviewers). > > >> > > > >> > > > >> > Thanks! Thomas > > >> > > > >> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > >> > wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > may I please have another review for this really trivial change. It > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good > idea to fix > > >> > this. > > >> > > > >> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > >> > webrev: > > >> > > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > > >> > > > >> > > > >> > This was contributed by Adam Farley at IBM. > > >> > > > >> > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > >> > > > >> > > > >> > Thanks, Thomas > > >> > > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > >> > > >> > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu May 17 23:58:29 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 17 May 2018 16:58:29 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources In-Reply-To: References: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> Message-ID: <5AFE1725.7080609@oracle.com> http://cr.openjdk.java.net/~prr/8191522.1 uploaded. Adding .. the removal of .. a couple of uses of lucida - sanity check of lucida in font config files is no longer needed. - J2DBench demo opts change from lucida to dialog. Not sure why it had lucida anyway .. -phil. On 5/16/18, 4:08 PM, Erik Joelsson wrote: > Build changes look good. > > /Erik > > > On 2018-05-16 15:52, Phil Race wrote: >> Webrev: http://cr.openjdk.java.net/~prr/8191522/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 >> >> The Lucida fonts have never been part of OpenJDK but many places in >> the code >> and tests reference them. There are even a couple of stray fonts.dir >> files that >> probably should not have been in there. >> >> This fix cleans up as much of this as we are also intending to no >> longer ship >> these fonts with Oracle JDK as it converges with OpenJDK. >> >> There is one minor build change in here, so I've included the build >> list. >> >> -phil. >> > From Sergey.Bylokhov at oracle.com Fri May 18 02:01:21 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 May 2018 19:01:21 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources In-Reply-To: <5AFE1725.7080609@oracle.com> References: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> <5AFE1725.7080609@oracle.com> Message-ID: <0dd5e94b-0be4-4be7-fe9d-67fc30a714aa@oracle.com> Looks fine. On 17/05/2018 16:58, Philip Race wrote: > http://cr.openjdk.java.net/~prr/8191522.1 uploaded. > Adding .. the removal of .. a couple of uses of lucida > - sanity check of lucida in font config files is no longer needed. > - J2DBench demo opts change from lucida to dialog. Not sure why it had > lucida anyway .. > > -phil. > > On 5/16/18, 4:08 PM, Erik Joelsson wrote: >> Build changes look good. >> >> /Erik >> >> >> On 2018-05-16 15:52, Phil Race wrote: >>> Webrev: http://cr.openjdk.java.net/~prr/8191522/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 >>> >>> The Lucida fonts have never been part of OpenJDK but many places in >>> the code >>> and tests reference them. There are even a couple of stray fonts.dir >>> files that >>> probably should not have been in there. >>> >>> This fix cleans up as much of this as we are also intending to no >>> longer ship >>> these fonts with Oracle JDK as it converges with OpenJDK. >>> >>> There is one minor build change in here, so I've included the build >>> list. >>> >>> -phil. >>> >> -- Best regards, Sergey. From philip.race at oracle.com Fri May 18 04:39:35 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 17 May 2018 21:39:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend) In-Reply-To: References: Message-ID: <5AFE5907.7050909@oracle.com> There's a lot to think about here but I have some requests to first clean up the proposed code to conform to coding standards. I see lots of lines > 80 chars. Please fix I see if(foo){ and else{ which should be "if (foo) {" and "else {" Basically always have a space before { and after ) and around "=" and "==" One line that WAS 51 hb_codepoint_t u = (variation_selector==0) ? unicode : variation_selector; has no spaces around "==" almost certainly to avoid going over 80 chars. Now you've broken the line you can fix that. Eliminate all wild card imports and import exactly what is needed. Maybe this is only about the test. remove what looks like SCCS style comments on the @test line. Make the test simply print a warning if the person didn't install fonts where you expected. Why? Because @ignore defaults to .. not being ignored. For the JNI methods calls read the spec and see if calling them may throw an exception I'm looking at sequences like env->SetIntArrayRegion(unicodes, 0, 2, tmp); 71 env->CallVoidMethod(font2D, sunFontIDs.f2dCharsToGlyphsMID, 2, unicodes, results); 72 env->GetIntArrayRegion(results, 0, 2, tmp); 73 *glyph = tmp[0]; 74 cleanup: 75 if (unicodes != NULL) env->DeleteLocalRef(unicodes); 76 if (results != NULL) env->DeleteLocalRef(results); If call GetIntArrayRegion may leave a pending exception it needs to be checked and cleared before you make another call. Look at the performance implications of things like the extra work done now in FontUtilities.isSimpleChar() and see how to minimise it since it could affect all text rendering in a way that is measurable in at least some way. I idly wonder if public static boolean isBaseChar(int charCode){ ... might be more cleanly or efficiently implemented with a switch ? Not sure. -phil. On 5/14/18, 1:28 AM, Toshio 5 Nakamura wrote: > > Could someone review our proposal to support Unicode Variation Selectors? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > > Toshio Nakamura > > > From: "Steven R. Loomis" > > To: 2d-dev <2d-dev at openjdk.java.net> > > Date: 2018/05/03 03:27 > > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation > > Selectors (Resend) > > Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> > > > > I added a screenshot to https://bugs.openjdk.java.net/browse/JDK-8187100 > > if anyone wants to see what the impact of this fix is > > > > On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis > wrote: > > (Retrying as actual text) > > > > Support Unicode Variation Selectors. > > > > Code by my colleague Toshio Nakamura, I added a simple test, and > > include a test that was part of JDK 8187100. (Both tests are run > manually.) > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > > > > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > > > > > Hello > > > > > > IBM would like to propose Unicode Variation Selector[1] capability > to AWT > > > and Swing components. > > > (This proposal was posted to i18n-dev first, and I got a > suggestion to > > > discuss > > > in 2d-dev.) > > > > > > This proposal changed the following files: > > > src/java.desktop/share/classes/sun/font/CMap.java > > > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > > > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > > > src/java.desktop/share/classes/sun/font/Font2D.java > > > src/java.desktop/share/classes/sun/font/FontRunIterator.java > > > src/java.desktop/share/classes/sun/font/FontUtilities.java > > > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > > > src/java.desktop/share/native/common/font/sunfontids.h > > > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > > src/java.desktop/share/native/libfontmanager/sunFont.c > > > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > > > 542 lines will be changed. > > > > > > There are three parts. > > > 1) Adding CMap format 14 support > > > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > > > 3) Swing text component's DEL and BS key operations change > > > > > > > > > How would I go about obtaining a sponsor? > > > > > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > > > Chapter 23.4 Variation Selectors > > > > > > Best regards, > > > > > > Toshio Nakamura > > > IBM Japan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri May 18 06:49:07 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 18 May 2018 06:49:07 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] - 8203355 : MITSHM define guarding missing Message-ID: <2257c3d8d49c4e1ea46015908b5b9614@sap.com> Please review this minor change that adds a missing #ifdef MITSHM Compile time guarding to X11SurfaceData.c http://cr.openjdk.java.net/~mbaesken/webrevs/8203355.0/ https://bugs.openjdk.java.net/browse/JDK-8203355 Usually one would not run into any problems because of the double-guarding by "HEADLESS", but in case that MITSHM in not defined (we do this for a special build here locally) we run into issues . So the added ifdef check cleans up this minor issue . Thanks and regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Fri May 18 15:23:35 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 18 May 2018 16:23:35 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: <5AFCCAC0.6000706@oracle.com> References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: Hi, I tried to use the IJG's contact page, but no joy. Seems broken; there a spinning icon when you hit "send", but nothing happens. http://jpegclub.org/reference/contact/ So I used a slightly older mailing list on sourceforge. The request to update their code has been sent, and I hope it will appear on the mailing list soon. https://sourceforge.net/p/libjpeg/mailman/libjpeg-devel-6x/ However, that list seems fairly idle too. Does anyone know of another method we can use to communicate this fix upstream? Best Regards Adam > Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.cPhilip Race to: Adam Farley8 17/05/2018 03:32 > Cc: 2d-dev, Andrew Leonard, build-dev, Magnus Ihse Bursie, "Thomas St?fe" > From: Philip Race > To: Adam Farley8 > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard , build-dev , Magnus Ihse Bursie , "Thomas St?fe" > > > Hi, > > OK .. if you can convince upstream this is worth doing, then we can accept it > as we would not regress when updating. As I noted previously : > http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html > this is still an issue in the currently being developed 9c train. > > -phil. > > On 5/14/18, 3:06 AM, Adam Farley8 wrote: > Hi Phil, > > Would an acceptable compromise be to deliver the source code change > and send the code to the upstream community, allowing them to include > the fix if/when they are able? > > I believe Magnus was advocating this idea as well. See below. > > Best Regards > > Adam Farley > > > Same here. I would like to have this fix in, but do not want to go > > over Phils head. > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > Thanks, Thomas > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > wrote: > > > I don't object, but it's not build code so I don't have the final say. > > > > > > /Magnus > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > Hi All, > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > It doesn't break anything, it fixes a build break on two supported > > > platforms, and it seems > > > like we never refresh the code from upstream. > > > > > > - Adam > > > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > > >> of logic required > > >> to properly analyse the toolchain version string. > > >> > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > > >> and Make doesn't > > >> seem to do substring stuff unless you mess around with shells. > > >> > > >> Plus, as people have said, it's better to solve problem x (or work around > > >> a specific > > >> instance of x) than to ignore the exception, even if the ignoring code is > > >> toolchain- > > >> specific. > > >> > > >> - Adam Farley > > >> > > >> > On 2018-03-27 18:44, Phil Race wrote: > > >> > > > >> >> As I said I prefer the make file change, since this is a change to an > > >> >> upstream library. > > >> > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > >> > reviewer. :) > > >> > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > >> > complaint seems reasonable, and disabling it might cause us to miss other > > >> > future errors. > > >> > > > >> > Why can't we push the source code fix, and also submit it upstream? > > >> > > > >> > /Magnus > > >> > > > >> > > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > > >> > 6b, so this code > > >> > seems to have stood the test of time. I'm also unclear why the compiler > > >> > would > > >> > complain about that and not the one a few lines later > > >> > > > >> > > > >> > 819 while (bits[i] == 0) /* find largest codelength still in > > >> > use */ > > >> > 820 i--; > > >> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > >> > A tool-chain specific fix in the makefile with an appropriate comment is > > >> > more targeted. > > >> > > >> Phil, > > >> > > >> Returning to this. > > >> > > >> While I understand your reluctance to patch upstream code, let me point > > >> out that we have not updated libjpeg a single time since the JDK was open > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page > > >> on libjpeg, and this is the latest "uncontroversial" version of the source. > > >> Versions 7 and up have proprietary extensions, which in turn has resulted in > > >> multiple forks of libjpeg. As it stands, it seems unlikely that we will ever > > >> replace libjpeg 6b with a simple upgrade from upstream. > > >> > > >> I therefore maintain my position that a source code fix would be the best > > >> way forward here. > > >> > > >> /Magnus > > >> > > >> > > > >> > > > >> > -phil. > > >> > > > >> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > just a friendly reminder. I would like to push this tiny fix because > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > >> > maintain patch queues, but this is a constant error source). > > >> > > > >> > > > >> > I will wait for 24 more hours until a reaction. If no serious objections > > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph > > >> > langer are both Reviewers). > > >> > > > >> > > > >> > Thanks! Thomas > > >> > > > >> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > >> > wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > may I please have another review for this really trivial change. It > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix > > >> > this. > > >> > > > >> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > >> > webrev: > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > >> > > > >> > > > >> > This was contributed by Adam Farley at IBM. > > >> > > > >> > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > >> > > > >> > > > >> > Thanks, Thomas > > >> > > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > >> > > >> > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 18 15:37:20 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 18 May 2018 08:37:20 -0700 Subject: [OpenJDK 2D-Dev] RFR [XS] - 8203355 : MITSHM define guarding missing In-Reply-To: <2257c3d8d49c4e1ea46015908b5b9614@sap.com> References: <2257c3d8d49c4e1ea46015908b5b9614@sap.com> Message-ID: Looks fine. -phil. On 05/17/2018 11:49 PM, Baesken, Matthias wrote: > > Please review this minor change that adds a missing #ifdef MITSHM > > Compile time guarding to X11SurfaceData.c > > http://cr.openjdk.java.net/~mbaesken/webrevs/8203355.0/ > > > https://bugs.openjdk.java.net/browse/JDK-8203355 > > Usually one would not run into any problems because of the > double-guarding by ?HEADLESS?, but in case that MITSHM in */not/* > defined (we do this for a special build here locally) > > we run into issues . So the added ifdef check cleans up this minor > issue . > > Thanks and regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Fri May 18 16:16:50 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Sat, 19 May 2018 01:16:50 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend) In-Reply-To: <5AFE5907.7050909@oracle.com> References: <5AFE5907.7050909@oracle.com> Message-ID: Thank you for your review, Phil. I'm working to handle your points. Toshio Nakamura Philip Race wrote on 2018/05/18 13:39:35: > From: Philip Race > To: Toshio 5 Nakamura > Cc: 2d-dev <2d-dev at openjdk.java.net> > Date: 2018/05/18 13:39 > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation > Selectors(Resend) > > There's a lot to think about here but I have some requests to first > clean up the proposed code to conform to coding standards. > > I see lots of lines > 80 chars. Please fix > > I see if(foo){ and else{ which should be "if (foo) {" and "else {" > > Basically always have a space before { and after ) and around "=" and "==" > > One line that WAS > 51 hb_codepoint_t u = (variation_selector==0) ? unicode : > variation_selector; > > has no spaces around "==" almost certainly to avoid going over 80 chars. > Now you've broken the line you can fix that. > > Eliminate all wild card imports and import exactly what is needed. > Maybe this is only about the test. > > remove what looks like SCCS style comments on the @test line. > Make the test simply print a warning if the person didn't install > fonts where you expected. > Why? Because @ignore defaults to .. not being ignored. > > For the JNI methods calls read the spec and see if calling them may > throw an exception > > I'm looking at sequences like > env->SetIntArrayRegion(unicodes, 0, 2, tmp); > 71 env->CallVoidMethod(font2D, > sunFontIDs.f2dCharsToGlyphsMID, 2, unicodes, results); > 72 env->GetIntArrayRegion(results, 0, 2, tmp); > 73 *glyph = tmp[0]; > 74 cleanup: > 75 if (unicodes != NULL) env->DeleteLocalRef(unicodes); > 76 if (results != NULL) env->DeleteLocalRef(results); > > If call GetIntArrayRegion may leave a pending exception it needs to > be checked and cleared > before you make another call. > > Look at the performance implications of things like the extra > work done now in FontUtilities.isSimpleChar() and see how to minimise > it since it could affect all text rendering in a way that is measurable > in at least some way. > > I idly wonder if > > > public static boolean isBaseChar(int charCode){ ... > > might be more cleanly or efficiently implemented with a switch ? > > Not sure. > > -phil. > > On 5/14/18, 1:28 AM, Toshio 5 Nakamura wrote: > Could someone review our proposal to support Unicode Variation Selectors? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > Toshio Nakamura > > > From: "Steven R. Loomis" > > To: 2d-dev <2d-dev at openjdk.java.net> > > Date: 2018/05/03 03:27 > > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation > > Selectors (Resend) > > Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> > > > > I added a screenshot to https://bugs.openjdk.java.net/browse/JDK-8187100 > > if anyone wants to see what the impact of this fix is > > > > On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis wrote: > > (Retrying as actual text) > > > > Support Unicode Variation Selectors. > > > > Code by my colleague Toshio Nakamura, I added a simple test, and > > include a test that was part of JDK 8187100. (Both tests are run manually.) > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > > > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > > > > > Hello > > > > > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > > > and Swing components. > > > (This proposal was posted to i18n-dev first, and I got a suggestion to > > > discuss > > > in 2d-dev.) > > > > > > This proposal changed the following files: > > > src/java.desktop/share/classes/sun/font/CMap.java > > > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > > > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > > > src/java.desktop/share/classes/sun/font/Font2D.java > > > src/java.desktop/share/classes/sun/font/FontRunIterator.java > > > src/java.desktop/share/classes/sun/font/FontUtilities.java > > > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > > > src/java.desktop/share/native/common/font/sunfontids.h > > > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > > src/java.desktop/share/native/libfontmanager/sunFont.c > > > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > > > 542 lines will be changed. > > > > > > There are three parts. > > > 1) Adding CMap format 14 support > > > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > > > 3) Swing text component's DEL and BS key operations change > > > > > > > > > How would I go about obtaining a sponsor? > > > > > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > > > Chapter 23.4 Variation Selectors > > > > > > Best regards, > > > > > > Toshio Nakamura > > > IBM Japan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri May 18 17:09:21 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 18 May 2018 19:09:21 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: I admire your perseverance :) but I think this is a fools errand. The amount of work you have to put into this far outbalances the amount of work the OpenJDK maintainers would have to spend when (if ever) they were to merge down upstream libjpeg. Note that we have a lot of experience with downstream work, since we are downstream from OpenJDK - and Oracle JDK before that - since like 14 years. Merging upstream with downstream-local patches is part of our daily business. That is why I also think that it is quite normal to keep local changes downstream and to merge, not just to replace, upstream changes. But to do that differently is Oracle's prerogative. I for now am resigned to live with local patches (the irony :-) to the s390 build. It is annoying but no big deal breaker. Thanks & best Regards, Thomas On Fri, May 18, 2018 at 5:23 PM, Adam Farley8 wrote: > Hi, > > I tried to use the IJG's contact page, but no joy. Seems broken; there a > spinning icon when you hit "send", but nothing happens. > > http://jpegclub.org/reference/contact/ > > So I used a slightly older mailing list on sourceforge. The request to > update their code has been sent, and I hope it will appear on the mailing > list soon. > > https://sourceforge.net/p/libjpeg/mailman/libjpeg-devel-6x/ > > However, that list seems fairly idle too. > > Does anyone know of another method we can use to communicate this fix > upstream? > > Best Regards > > Adam > >> Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning >> in jchuff.cPhilip Race to: Adam Farley8 17/05/2018 03:32 >> Cc: 2d-dev, Andrew Leonard, build-dev, Magnus Ihse Bursie, "Thomas St?fe" >> From: Philip Race >> To: Adam Farley8 >> Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard >> , build-dev , >> Magnus Ihse Bursie , "Thomas St?fe" >> >> >> >> Hi, >> >> OK .. if you can convince upstream this is worth doing, then we can accept >> it >> as we would not regress when updating. As I noted previously : >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html >> this is still an issue in the currently being developed 9c train. >> >> -phil. >> >> On 5/14/18, 3:06 AM, Adam Farley8 wrote: >> Hi Phil, >> >> Would an acceptable compromise be to deliver the source code change >> and send the code to the upstream community, allowing them to include >> the fix if/when they are able? >> >> I believe Magnus was advocating this idea as well. See below. >> >> Best Regards >> >> Adam Farley >> >> > Same here. I would like to have this fix in, but do not want to go >> > over Phils head. >> > >> > I think Phil was the main objector, maybe he could reconsider?` >> > >> > Thanks, Thomas >> > >> > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie >> > wrote: >> > > I don't object, but it's not build code so I don't have the final say. >> > > >> > > /Magnus >> > > >> > > >> > > On 2018-04-25 17:43, Adam Farley8 wrote: >> > > >> > > Hi All, >> > > >> > > Does anyone have an objection to pushing this tiny change in? >> > > >> > > It doesn't break anything, it fixes a build break on two supported >> > > platforms, and it seems >> > > like we never refresh the code from upstream. >> > > >> > > - Adam >> > > >> > >> I also advocate the source code fix, as Make isn't meant to use the >> > >> sort >> > >> of logic required >> > >> to properly analyse the toolchain version string. >> > >> >> > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using >> > >> 4.8.6, >> > >> and Make doesn't >> > >> seem to do substring stuff unless you mess around with shells. >> > >> >> > >> Plus, as people have said, it's better to solve problem x (or work >> > >> around >> > >> a specific >> > >> instance of x) than to ignore the exception, even if the ignoring >> > >> code is >> > >> toolchain- >> > >> specific. >> > >> >> > >> - Adam Farley >> > >> >> > >> > On 2018-03-27 18:44, Phil Race wrote: >> > >> > >> > >> >> As I said I prefer the make file change, since this is a change to >> > >> >> an >> > >> >> upstream library. >> > >> > >> > >> > Newtons fourth law: For every reviewer, there's an equal and >> > >> > opposite >> > >> > reviewer. :) >> > >> > >> > >> > Here I am, advocating a source code fix. As Thomas says, the >> > >> > compiler >> > >> > complaint seems reasonable, and disabling it might cause us to miss >> > >> > other >> > >> > future errors. >> > >> > >> > >> > Why can't we push the source code fix, and also submit it upstream? >> > >> > >> > >> > /Magnus >> > >> > >> > >> > >> > >> > I've looked at jpeg-9c and it still looks identical to what we have >> > >> > in >> > >> > 6b, so this code >> > >> > seems to have stood the test of time. I'm also unclear why the >> > >> > compiler >> > >> > would >> > >> > complain about that and not the one a few lines later >> > >> > >> > >> > >> > >> > 819 while (bits[i] == 0) /* find largest codelength >> > >> > still in >> > >> > use */ >> > >> > 820 i--; >> > >> > >> > >> > A push to jchuff.c will get blown away if/when we upgrade. >> > >> > A tool-chain specific fix in the makefile with an appropriate >> > >> > comment is >> > >> > more targeted. >> > >> >> > >> Phil, >> > >> >> > >> Returning to this. >> > >> >> > >> While I understand your reluctance to patch upstream code, let me >> > >> point >> > >> out that we have not updated libjpeg a single time since the JDK was >> > >> open >> > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the >> > >> Wikipedia page >> > >> on libjpeg, and this is the latest "uncontroversial" version of the >> > >> source. >> > >> Versions 7 and up have proprietary extensions, which in turn has >> > >> resulted in >> > >> multiple forks of libjpeg. As it stands, it seems unlikely that we >> > >> will ever >> > >> replace libjpeg 6b with a simple upgrade from upstream. >> > >> >> > >> I therefore maintain my position that a source code fix would be the >> > >> best >> > >> way forward here. >> > >> >> > >> /Magnus >> > >> >> > >> > >> > >> > >> > >> > -phil. >> > >> > >> > >> > >> > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: >> > >> > >> > >> > Hi all, >> > >> > >> > >> > >> > >> > just a friendly reminder. I would like to push this tiny fix >> > >> > because >> > >> > tripping over this on our linux s390x builds is annoying (yes, we >> > >> > can >> > >> > maintain patch queues, but this is a constant error source). >> > >> > >> > >> > >> > >> > I will wait for 24 more hours until a reaction. If no serious >> > >> > objections >> > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and >> > >> > Christoph >> > >> > langer are both Reviewers). >> > >> > >> > >> > >> > >> > Thanks! Thomas >> > >> > >> > >> > >> > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe >> > >> > >> > >> > wrote: >> > >> > >> > >> > Hi all, >> > >> > >> > >> > >> > >> > may I please have another review for this really trivial change. It >> > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good >> > >> > idea to fix >> > >> > this. >> > >> > >> > >> > >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 >> > >> > webrev: >> > >> > >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ >> > >> > >> > >> > >> > >> > This was contributed by Adam Farley at IBM. >> > >> > >> > >> > >> > >> > I already reviewed this. I also test-built on zlinux and it works. >> > >> > >> > >> > >> > >> > Thanks, Thomas >> > >> > >> > >> >> > >> Unless stated otherwise above: >> > >> IBM United Kingdom Limited - Registered in England and Wales with >> > >> number >> > >> 741598. >> > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> > >> PO6 3AU >> > >> >> > >> >> > > >> > > Unless stated otherwise above: >> > > IBM United Kingdom Limited - Registered in England and Wales with >> > > number >> > > 741598. >> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> > > 3AU >> > > >> > > >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Mon May 21 08:51:48 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 21 May 2018 09:51:48 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: Thanks for the compliment, but I plan to leave this open for a little while longer. I have already heard back from the 6x community, and they say they are no longer associated with the IJG group (jpegclub.org) that creates 9x. Unless we see the potential for an upstream merge from the sourceforge 6x group, I'll be concentrating exclusively on pushing the change to the IJG 9x group. I found some email addresses on the IJG "Site Notice" page, and have already emailed the most likely one to try and push the change. In the meantime, I recommend getting the change into our local copy of the code to fix the bug. Phil, your thoughts? Best Regards Adam > I admire your perseverance :) but I think this is a fools errand. > > The amount of work you have to put into this far outbalances the > amount of work the OpenJDK maintainers would have to spend when (if > ever) they were to merge down upstream libjpeg. > > Note that we have a lot of experience with downstream work, since we > are downstream from OpenJDK - and Oracle JDK before that - since like > 14 years. Merging upstream with downstream-local patches is part of > our daily business. That is why I also think that it is quite normal > to keep local changes downstream and to merge, not just to replace, > upstream changes. But to do that differently is Oracle's prerogative. > > I for now am resigned to live with local patches (the irony :-) to the > s390 build. It is annoying but no big deal breaker. > > Thanks & best Regards, Thomas > > > On Fri, May 18, 2018 at 5:23 PM, Adam Farley8 wrote: > > Hi, > > > > I tried to use the IJG's contact page, but no joy. Seems broken; there a > > spinning icon when you hit "send", but nothing happens. > > > > http://jpegclub.org/reference/contact/ > > > > So I used a slightly older mailing list on sourceforge. The request to > > update their code has been sent, and I hope it will appear on the mailing > > list soon. > > > > https://sourceforge.net/p/libjpeg/mailman/libjpeg-devel-6x/ > > > > However, that list seems fairly idle too. > > > > Does anyone know of another method we can use to communicate this fix > > upstream? > > > > Best Regards > > > > Adam > > > >> Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning > >> in jchuff.cPhilip Race to: Adam Farley8 17/05/2018 03:32 > >> Cc: 2d-dev, Andrew Leonard, build-dev, Magnus Ihse Bursie, "Thomas St?fe" > >> From: Philip Race > >> To: Adam Farley8 > >> Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > >> , build-dev , > >> Magnus Ihse Bursie , "Thomas St?fe" > >> > >> > >> > >> Hi, > >> > >> OK .. if you can convince upstream this is worth doing, then we can accept > >> it > >> as we would not regress when updating. As I noted previously : > >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html > >> this is still an issue in the currently being developed 9c train. > >> > >> -phil. > >> > >> On 5/14/18, 3:06 AM, Adam Farley8 wrote: > >> Hi Phil, > >> > >> Would an acceptable compromise be to deliver the source code change > >> and send the code to the upstream community, allowing them to include > >> the fix if/when they are able? > >> > >> I believe Magnus was advocating this idea as well. See below. > >> > >> Best Regards > >> > >> Adam Farley > >> > >> > Same here. I would like to have this fix in, but do not want to go > >> > over Phils head. > >> > > >> > I think Phil was the main objector, maybe he could reconsider?` > >> > > >> > Thanks, Thomas > >> > > >> > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > >> > wrote: > >> > > I don't object, but it's not build code so I don't have the final say. > >> > > > >> > > /Magnus > >> > > > >> > > > >> > > On 2018-04-25 17:43, Adam Farley8 wrote: > >> > > > >> > > Hi All, > >> > > > >> > > Does anyone have an objection to pushing this tiny change in? > >> > > > >> > > It doesn't break anything, it fixes a build break on two supported > >> > > platforms, and it seems > >> > > like we never refresh the code from upstream. > >> > > > >> > > - Adam > >> > > > >> > >> I also advocate the source code fix, as Make isn't meant to use the > >> > >> sort > >> > >> of logic required > >> > >> to properly analyse the toolchain version string. > >> > >> > >> > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using > >> > >> 4.8.6, > >> > >> and Make doesn't > >> > >> seem to do substring stuff unless you mess around with shells. > >> > >> > >> > >> Plus, as people have said, it's better to solve problem x (or work > >> > >> around > >> > >> a specific > >> > >> instance of x) than to ignore the exception, even if the ignoring > >> > >> code is > >> > >> toolchain- > >> > >> specific. > >> > >> > >> > >> - Adam Farley > >> > >> > >> > >> > On 2018-03-27 18:44, Phil Race wrote: > >> > >> > > >> > >> >> As I said I prefer the make file change, since this is a change to > >> > >> >> an > >> > >> >> upstream library. > >> > >> > > >> > >> > Newtons fourth law: For every reviewer, there's an equal and > >> > >> > opposite > >> > >> > reviewer. :) > >> > >> > > >> > >> > Here I am, advocating a source code fix. As Thomas says, the > >> > >> > compiler > >> > >> > complaint seems reasonable, and disabling it might cause us to miss > >> > >> > other > >> > >> > future errors. > >> > >> > > >> > >> > Why can't we push the source code fix, and also submit it upstream? > >> > >> > > >> > >> > /Magnus > >> > >> > > >> > >> > > >> > >> > I've looked at jpeg-9c and it still looks identical to what we have > >> > >> > in > >> > >> > 6b, so this code > >> > >> > seems to have stood the test of time. I'm also unclear why the > >> > >> > compiler > >> > >> > would > >> > >> > complain about that and not the one a few lines later > >> > >> > > >> > >> > > >> > >> > 819 while (bits[i] == 0) /* find largest codelength > >> > >> > still in > >> > >> > use */ > >> > >> > 820 i--; > >> > >> > > >> > >> > A push to jchuff.c will get blown away if/when we upgrade. > >> > >> > A tool-chain specific fix in the makefile with an appropriate > >> > >> > comment is > >> > >> > more targeted. > >> > >> > >> > >> Phil, > >> > >> > >> > >> Returning to this. > >> > >> > >> > >> While I understand your reluctance to patch upstream code, let me > >> > >> point > >> > >> out that we have not updated libjpeg a single time since the JDK was > >> > >> open > >> > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > >> > >> Wikipedia page > >> > >> on libjpeg, and this is the latest "uncontroversial" version of the > >> > >> source. > >> > >> Versions 7 and up have proprietary extensions, which in turn has > >> > >> resulted in > >> > >> multiple forks of libjpeg. As it stands, it seems unlikely that we > >> > >> will ever > >> > >> replace libjpeg 6b with a simple upgrade from upstream. > >> > >> > >> > >> I therefore maintain my position that a source code fix would be the > >> > >> best > >> > >> way forward here. > >> > >> > >> > >> /Magnus > >> > >> > >> > >> > > >> > >> > > >> > >> > -phil. > >> > >> > > >> > >> > > >> > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > >> > >> > > >> > >> > Hi all, > >> > >> > > >> > >> > > >> > >> > just a friendly reminder. I would like to push this tiny fix > >> > >> > because > >> > >> > tripping over this on our linux s390x builds is annoying (yes, we > >> > >> > can > >> > >> > maintain patch queues, but this is a constant error source). > >> > >> > > >> > >> > > >> > >> > I will wait for 24 more hours until a reaction. If no serious > >> > >> > objections > >> > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and > >> > >> > Christoph > >> > >> > langer are both Reviewers). > >> > >> > > >> > >> > > >> > >> > Thanks! Thomas > >> > >> > > >> > >> > > >> > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > >> > >> > > >> > >> > wrote: > >> > >> > > >> > >> > Hi all, > >> > >> > > >> > >> > > >> > >> > may I please have another review for this really trivial change. It > >> > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good > >> > >> > idea to fix > >> > >> > this. > >> > >> > > >> > >> > > >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > >> > >> > webrev: > >> > >> > > >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > >> > >> > > >> > >> > > >> > >> > This was contributed by Adam Farley at IBM. > >> > >> > > >> > >> > > >> > >> > I already reviewed this. I also test-built on zlinux and it works. > >> > >> > > >> > >> > > >> > >> > Thanks, Thomas > >> > >> > > >> > >> > >> > >> Unless stated otherwise above: > >> > >> IBM United Kingdom Limited - Registered in England and Wales with > >> > >> number > >> > >> 741598. > >> > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >> > >> PO6 3AU > >> > >> > >> > >> > >> > > > >> > > Unless stated otherwise above: > >> > > IBM United Kingdom Limited - Registered in England and Wales with > >> > > number > >> > > 741598. > >> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >> > > 3AU > >> > > > >> > > > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue May 22 03:28:27 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 21 May 2018 20:28:27 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] Review Request: 8203027 Open source tests for "java.awt.geom" In-Reply-To: <7e76eabd-2721-5d51-c655-37a640191a00@oracle.com> References: <40c848ab-abc6-fe2a-d2a6-65e7f23fa34c@oracle.com> <7e76eabd-2721-5d51-c655-37a640191a00@oracle.com> Message-ID: <2796d210-4a68-4852-9c7c-46e628f6857c@default> Hi Sergey, +1. In NotConvexPieTest.java please add space between words for "String failText" before pushing. No need for another webrev. Thanks, Jay -----Original Message----- From: Phil Race Sent: Thursday, May 17, 2018 3:46 AM To: Sergey Bylokhov; 2d-dev; Jayathirth D v Subject: Re: [11] Review Request: 8203027 Open source tests for "java.awt.geom" +1 from me. -phil. On 05/16/2018 02:00 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203027 > Webrev: http://cr.openjdk.java.net/~serb/8203027/webrev.00 > > This is a request to move the tests for "java.awt.geom" to the open > repo. Most of the tests copied as-is(but in some cases some small > cleanup was done). > > From matthias.baesken at sap.com Tue May 22 06:33:42 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 22 May 2018 06:33:42 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] - 8203355 : MITSHM define guarding missing In-Reply-To: References: <2257c3d8d49c4e1ea46015908b5b9614@sap.com> Message-ID: <79606398bca7418db659b6ea28e97154@sap.com> Hi Phil, thanks for looking into it. Can I get a second review ? Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Freitag, 18. Mai 2018 17:37 To: Baesken, Matthias ; 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] RFR [XS] - 8203355 : MITSHM define guarding missing Looks fine. -phil. On 05/17/2018 11:49 PM, Baesken, Matthias wrote: Please review this minor change that adds a missing #ifdef MITSHM Compile time guarding to X11SurfaceData.c http://cr.openjdk.java.net/~mbaesken/webrevs/8203355.0/ https://bugs.openjdk.java.net/browse/JDK-8203355 Usually one would not run into any problems because of the double-guarding by "HEADLESS", but in case that MITSHM in not defined (we do this for a special build here locally) we run into issues . So the added ifdef check cleans up this minor issue . Thanks and regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue May 22 12:37:32 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 22 May 2018 14:37:32 +0200 Subject: [OpenJDK 2D-Dev] RFR [XS] - 8203355 : MITSHM define guarding missing In-Reply-To: <79606398bca7418db659b6ea28e97154@sap.com> References: <2257c3d8d49c4e1ea46015908b5b9614@sap.com> <79606398bca7418db659b6ea28e97154@sap.com> Message-ID: Hi Matthias, Looks good. Best Regards, Thomas On Tue, May 22, 2018 at 8:33 AM, Baesken, Matthias wrote: > Hi Phil, thanks for looking into it. > > > > Can I get a second review ? > > > > Best regards, Matthias > > > > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Freitag, 18. Mai 2018 17:37 > To: Baesken, Matthias ; 2d-dev > <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR [XS] - 8203355 : MITSHM define guarding > missing > > > > Looks fine. > > -phil. > > On 05/17/2018 11:49 PM, Baesken, Matthias wrote: > > Please review this minor change that adds a missing #ifdef MITSHM > > Compile time guarding to X11SurfaceData.c > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8203355.0/ > > > > https://bugs.openjdk.java.net/browse/JDK-8203355 > > > > > > Usually one would not run into any problems because of the > double-guarding by ?HEADLESS?, but in case that MITSHM in not defined > (we do this for a special build here locally) > > we run into issues . So the added ifdef check cleans up this minor issue > . > > > > Thanks and regards, Matthias > > > > From abrygin at azul.com Tue May 22 15:50:43 2018 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 22 May 2018 15:50:43 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8203485: [freetype] text rotated on 180 degrees is too narrow Message-ID: <38E4AA41-CBC2-45F3-80EA-114E976388DB@azul.com> Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203485 With freetype, text rotated on 180 or 270 degrees is too narrow. Attached test case and screenshots demonstrate the problem. The problem is caused by the rounding applied to the cases of vertical and horizontal text, see freetypeScaler.c, lines 768 and 773: http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l768 http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l773 The rounding routine is defined as ROUND(x) ((int) (x+0.5)) (see line 48), and it gives incorrect results for negative arguments. For example, say glyph advance is 8, and we render it without rotation, and with rotation on 180 degrees. In these cases, we get ROUND(8) = 8, whereas for 180 degrees we get ROUND(-8) = -7. This rounding error leads to decrease of the width of the rendered text. For the case of integer metrics, we can expect that FT26.6 advances produced by freetype are integer, i.e. fractional part (lower 6 bits) is zero. So, we can convert them to glyph info values without floating point division, just by using integer shift. In this case, there is no need to round the floating point value to integer, and there is no need to care about sign of the argument. Thanks, Andrew From philip.race at oracle.com Tue May 22 16:26:40 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 22 May 2018 09:26:40 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8203485: [freetype] text rotated on 180 degrees is too narrow In-Reply-To: <38E4AA41-CBC2-45F3-80EA-114E976388DB@azul.com> References: <38E4AA41-CBC2-45F3-80EA-114E976388DB@azul.com> Message-ID: <5B0444C0.1040800@oracle.com> Fix sounds good. The test has a bug 47 static final Font fnt = new Font("Time New Roamn", Font.PLAIN, 1).deriveFont(12.0f); "Roamn" should be "Roman". But since Linux is very unlikely to have that font, I think you should use Font.SERIF instead. Actually I am unclear why you need to use deriveFont and can't test this with the constructor taking int of 12. -phil On 5/22/18, 8:50 AM, Andrew Brygin wrote: > Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8203485 > > With freetype, text rotated on 180 or 270 degrees is too narrow. > Attached test case and screenshots demonstrate the problem. > > The problem is caused by the rounding applied to the cases of vertical > and horizontal text, see freetypeScaler.c, lines 768 and 773: > http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l768 > http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l773 > > The rounding routine is defined as ROUND(x) ((int) (x+0.5)) (see line 48), > and it gives incorrect results for negative arguments. > > For example, say glyph advance is 8, and we render it without rotation, > and with rotation on 180 degrees. In these cases, we get ROUND(8) = 8, > whereas for 180 degrees we get ROUND(-8) = -7. This rounding error > leads to decrease of the width of the rendered text. > > For the case of integer metrics, we can expect that FT26.6 advances > produced by freetype are integer, i.e. fractional part (lower 6 bits) > is zero. So, we can convert them to glyph info values without floating > point division, just by using integer shift. In this case, there is no > need to round the floating point value to integer, and there is no need > to care about sign of the argument. > > Thanks, > Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From abrygin at azul.com Tue May 22 16:40:59 2018 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 22 May 2018 16:40:59 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8203485: [freetype] text rotated on 180 degrees is too narrow In-Reply-To: <5B0444C0.1040800@oracle.com> References: <38E4AA41-CBC2-45F3-80EA-114E976388DB@azul.com> <5B0444C0.1040800@oracle.com> Message-ID: <2494C492-561B-41EE-BAA9-C3A340AB7CB5@azul.com> corrected: 47 static final Font fnt = new Font(Font.SERIF, Font.PLAIN, 12); Updated webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.01/ Thanks, Andrew > On May 22, 2018, at 7:26 PM, Philip Race wrote: > > Fix sounds good. > > The test has a bug > 47 static final Font fnt = new Font("Time New Roamn", Font.PLAIN, 1).deriveFont(12.0f); > > "Roamn" should be "Roman?. > > But since Linux is very unlikely to have that font, I think you should use Font.SERIF instead. > > Actually I am unclear why you need to use deriveFont and can't > test this with the constructor taking int of 12. > > -phil > > On 5/22/18, 8:50 AM, Andrew Brygin wrote: >> Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8203485 >> >> >> With freetype, text rotated on 180 or 270 degrees is too narrow. >> Attached test case and screenshots demonstrate the problem. >> >> The problem is caused by the rounding applied to the cases of vertical >> and horizontal text, see freetypeScaler.c, lines 768 and 773: >> >> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l768 >> >> >> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l773 >> >> >> The rounding routine is defined as ROUND(x) ((int) (x+0.5)) (see line 48), >> and it gives incorrect results for negative arguments. >> >> For example, say glyph advance is 8, and we render it without rotation, >> and with rotation on 180 degrees. In these cases, we get ROUND(8) = 8, >> whereas for 180 degrees we get ROUND(-8) = -7. This rounding error >> leads to decrease of the width of the rendered text. >> >> For the case of integer metrics, we can expect that FT26.6 advances >> produced by freetype are integer, i.e. fractional part (lower 6 bits) >> is zero. So, we can convert them to glyph info values without floating >> point division, just by using integer shift. In this case, there is no >> need to round the floating point value to integer, and there is no need >> to care about sign of the argument. >> >> Thanks, >> Andrew >> From philip.race at oracle.com Tue May 22 16:56:58 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 22 May 2018 09:56:58 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8203485: [freetype] text rotated on 180 degrees is too narrow In-Reply-To: <2494C492-561B-41EE-BAA9-C3A340AB7CB5@azul.com> References: <38E4AA41-CBC2-45F3-80EA-114E976388DB@azul.com> <5B0444C0.1040800@oracle.com> <2494C492-561B-41EE-BAA9-C3A340AB7CB5@azul.com> Message-ID: <5B044BDA.6070304@oracle.com> +1 (approved) from me. -phil. On 5/22/18, 9:40 AM, Andrew Brygin wrote: > corrected: > > 47 static final Font fnt = new Font(Font.SERIF, Font.PLAIN, 12); > > Updated webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.01/ > > Thanks, > Andrew > >> On May 22, 2018, at 7:26 PM, Philip Race wrote: >> >> Fix sounds good. >> >> The test has a bug >> 47 static final Font fnt = new Font("Time New Roamn", Font.PLAIN, 1).deriveFont(12.0f); >> >> "Roamn" should be "Roman?. >> >> But since Linux is very unlikely to have that font, I think you should use Font.SERIF instead. >> >> Actually I am unclear why you need to use deriveFont and can't >> test this with the constructor taking int of 12. >> >> -phil >> >> On 5/22/18, 8:50 AM, Andrew Brygin wrote: >>> Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8203485 >>> >>> >>> With freetype, text rotated on 180 or 270 degrees is too narrow. >>> Attached test case and screenshots demonstrate the problem. >>> >>> The problem is caused by the rounding applied to the cases of vertical >>> and horizontal text, see freetypeScaler.c, lines 768 and 773: >>> >>> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l768 >>> >>> >>> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l773 >>> >>> >>> The rounding routine is defined as ROUND(x) ((int) (x+0.5)) (see line 48), >>> and it gives incorrect results for negative arguments. >>> >>> For example, say glyph advance is 8, and we render it without rotation, >>> and with rotation on 180 degrees. In these cases, we get ROUND(8) = 8, >>> whereas for 180 degrees we get ROUND(-8) = -7. This rounding error >>> leads to decrease of the width of the rendered text. >>> >>> For the case of integer metrics, we can expect that FT26.6 advances >>> produced by freetype are integer, i.e. fractional part (lower 6 bits) >>> is zero. So, we can convert them to glyph info values without floating >>> point division, just by using integer shift. In this case, there is no >>> need to round the floating point value to integer, and there is no need >>> to care about sign of the argument. >>> >>> Thanks, >>> Andrew >>> From Sergey.Bylokhov at oracle.com Thu May 24 19:25:51 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 May 2018 12:25:51 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8203485: [freetype] text rotated on 180 degrees is too narrow In-Reply-To: <5B044BDA.6070304@oracle.com> References: <38E4AA41-CBC2-45F3-80EA-114E976388DB@azul.com> <5B0444C0.1040800@oracle.com> <2494C492-561B-41EE-BAA9-C3A340AB7CB5@azul.com> <5B044BDA.6070304@oracle.com> Message-ID: <74b93017-5c6d-6b03-8ca1-166b9869a54e@oracle.com> looks fine. On 22/05/2018 09:56, Philip Race wrote: > +1 (approved) from me. > > -phil. > > On 5/22/18, 9:40 AM, Andrew Brygin wrote: >> corrected: >> >> ? 47???? static final Font fnt = new Font(Font.SERIF, Font.PLAIN, 12); >> >> Updated webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.01/ >> >> Thanks, >> Andrew >> >>> On May 22, 2018, at 7:26 PM, Philip Race? wrote: >>> >>> Fix sounds good. >>> >>> The test has a bug >>> ?? 47???? static final Font fnt = new Font("Time New Roamn", >>> Font.PLAIN, 1).deriveFont(12.0f); >>> >>> "Roamn" should be "Roman?. >>> >>> But since Linux is very unlikely to have that font, I think you >>> should use Font.SERIF instead. >>> >>> Actually I am unclear why you need to use deriveFont and can't >>> test this with the constructor taking int of 12. >>> >>> -phil >>> >>> On 5/22/18, 8:50 AM, Andrew Brygin wrote: >>>> Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8203485 >>>> >>>> >>>> With freetype, text rotated on 180 or 270 degrees is too narrow. >>>> Attached test case and screenshots demonstrate the problem. >>>> >>>> The problem is caused by the rounding applied to the cases of vertical >>>> and horizontal text, see freetypeScaler.c, lines 768 and 773: >>>> >>>> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l768 >>>> >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l773 >>>> >>>> >>>> >>>> The rounding routine is defined as ROUND(x) ((int) (x+0.5)) (see >>>> line 48), >>>> and it gives incorrect results for negative arguments. >>>> >>>> For example, say glyph advance is 8, and we render it without rotation, >>>> and with rotation on 180 degrees. In these cases, we get ROUND(8) = 8, >>>> whereas for 180 degrees we get ROUND(-8) = -7. This rounding error >>>> leads to decrease of the width of the rendered text. >>>> >>>> For the case of integer metrics, we can expect that FT26.6 advances >>>> produced by freetype are integer, i.e. fractional part (lower 6 bits) >>>> is zero. So, we can convert them to glyph info values without floating >>>> point division, just by using integer shift. In this case, there is no >>>> need to round the floating point value to integer, and there is no need >>>> to care about sign of the argument. >>>> >>>> Thanks, >>>> Andrew >>>> -- Best regards, Sergey. From philip.race at oracle.com Fri May 25 18:04:12 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 May 2018 11:04:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8203796: Define API to support specifying ownership of print dialogs. Message-ID: This defines a new class "DialogOwner" implementing PrintRequestAttribute which allows an application to specify that a Print or Page dialog be one of 1) owned by an application specified AWT window 2) owned by an application specified foreign (non-AWT) window 3) use AWT's alwaysOnTop functionality where supported. JDK bug: https://bugs.openjdk.java.net/browse/JDK-8203796 CSR : https://bugs.openjdk.java.net/browse/JDK-8203834 JDK webrev : http://cr.openjdk.java.net/~prr/8203796/ Please review the webrev and the CSR. The webrev will show that this functionality was already mostly available but only as internal API. To help applications be able to query what is supported, the various PrintService implementation classes needed to be updated, for example "ID" is reported as unsupported unless specifying using the native dialog on windows. That actually pointed out that back in JDK 7 when we added DialogTypeSelection to be able to choose native or Swing there was no query support for that to be added. It was not a problem though as if it was not supported it really just meant that applications would have to live with what dialog was provided, as before. But it made a test for this new API more difficult .. so I added code needed for that. The test is manual. An automated test might be possible, but probably very flaky. But the test only makes you run through the scenarios that we know are supportable. The motivation for this new public API is to help OpenJFX since it uses the Java 2D PrinterJob class to implement its own printing, so there is also an FX side to switch to using this instead of the earlier internal API which it can not access when it is outside the JDK : FX bug : https://bugs.openjdk.java.net/browse/JDK-8195808 FX webrev: http://cr.openjdk.java.net/~prr/8195808/ -phil. From adam.farley at uk.ibm.com Tue May 29 10:54:01 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 29 May 2018 11:54:01 +0100 Subject: [OpenJDK 2D-Dev] Question about splashscreen lib Message-ID: Hi All, Does anyone know why png.c does not include png.h? This tripped me up recently, and I don't understand why png.c would not include png.h. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue May 29 13:23:21 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 29 May 2018 06:23:21 -0700 Subject: [OpenJDK 2D-Dev] Question about splashscreen lib In-Reply-To: References: Message-ID: <5B0D5449.7060404@oracle.com> So far as I can see it does, just indirectly. png.c includes pngpriv.h which includes png.h Not including the declarations of the exported API in the file that defines them would be a problem waiting to happen. -phil. On 5/29/18, 3:54 AM, Adam Farley8 wrote: > Hi All, > > Does anyone know why png.c does not include png.h? > > This tripped me up recently, and I don't understand why png.c would > not include png.h. > > Best Regards > > Adam Farley > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Wed May 30 11:16:39 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 30 May 2018 12:16:39 +0100 Subject: [OpenJDK 2D-Dev] Question about splashscreen lib In-Reply-To: <5B0D5449.7060404@oracle.com> References: <5B0D5449.7060404@oracle.com> Message-ID: Thanks Philip. The whole thing with PNG_DLL_EXPORT not being defined in png.h or png.c is still confusing to me (pngpriv defines it), especially since png.h ends up using it post-pre-processing, but I don't know if that would bother people outside the minority that inspect the pre-processed code. I'll leave this here as a thought for any committer bothered by this, though I won't be pushing it. ---- png.h ---- + #ifndef PNG_DLL_EXPORT + #define PNG_DLL_EXPORT + #endif Best Regards Adam Farley Philip Race wrote on 29/05/2018 14:23:21: > From: Philip Race > To: Adam Farley8 > Cc: 2d-dev <2d-dev at openjdk.java.net> > Date: 29/05/2018 14:23 > Subject: Re: [OpenJDK 2D-Dev] Question about splashscreen lib > > So far as I can see it does, just indirectly. > png.c includes pngpriv.h which includes png.h > > Not including the declarations of the exported API in the file that > defines them would be a problem waiting to happen. > > -phil. > > On 5/29/18, 3:54 AM, Adam Farley8 wrote: > Hi All, > > Does anyone know why png.c does not include png.h? > > This tripped me up recently, and I don't understand why png.c would > not include png.h. > > Best Regards > > Adam Farley > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed May 30 13:32:46 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 May 2018 13:32:46 +0000 Subject: [OpenJDK 2D-Dev] [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp Message-ID: <153e7628a0284f0e941720c904e76860@sap.com> Hi could I please get reviews for this very small change : In java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp , function GDIWindowSurfaceData_GetComp, we might print pointer pData in uninitialized state. This occurs in case localObj == NULL , then we would print pData without initialization. The small fix adds initialization to pData : Bug: https://bugs.openjdk.java.net/browse/JDK-8204085 change : http://cr.openjdk.java.net/~mbaesken/webrevs/8204085/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed May 30 13:51:29 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 May 2018 06:51:29 -0700 Subject: [OpenJDK 2D-Dev] [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp In-Reply-To: <153e7628a0284f0e941720c904e76860@sap.com> References: <153e7628a0284f0e941720c904e76860@sap.com> Message-ID: <49c72c77-32f2-1a93-40ad-2d3a071d193e@oracle.com> Looks fine. On 30/05/2018 06:32, Baesken, Matthias wrote: > Hi could I please get reviews for this very small change : > > In > java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp > , function GDIWindowSurfaceData_GetComp, > > we might print pointer pData in uninitialized state. > > This occurs in case localObj == NULL , then we would? print pData > without initialization. > > The small fix adds initialization to? pData? : > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8204085 > > change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8204085/ > > Thanks, Matthias > -- Best regards, Sergey. From thomas.stuefe at gmail.com Wed May 30 13:52:37 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 30 May 2018 15:52:37 +0200 Subject: [OpenJDK 2D-Dev] [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp In-Reply-To: <153e7628a0284f0e941720c904e76860@sap.com> References: <153e7628a0284f0e941720c904e76860@sap.com> Message-ID: Hi Matthias, looks reasonable. Best Regards, Thomas On Wed, May 30, 2018 at 3:32 PM, Baesken, Matthias wrote: > Hi could I please get reviews for this very small change : > > > > In > java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp , > function GDIWindowSurfaceData_GetComp, > > we might print pointer pData in uninitialized state. > > > > This occurs in case localObj == NULL , then we would print pData without > initialization. > > > > The small fix adds initialization to pData : > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8204085 > > > > change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8204085/ > > > > > > Thanks, Matthias > > From christoph.langer at sap.com Wed May 30 14:01:21 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 May 2018 14:01:21 +0000 Subject: [OpenJDK 2D-Dev] [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp In-Reply-To: <153e7628a0284f0e941720c904e76860@sap.com> References: <153e7628a0284f0e941720c904e76860@sap.com> Message-ID: <16fcc1fa4a4d4f8abd16e2b51f3c364a@sap.com> Hi Matthias, maybe the code would become nicer if you do it like this: ... jobject localObj = env->NewLocalRef(wsdo->peer); PDATA pData = localObj == NULL ? NULL : JNI_GET_PDATA(localObj); if (pData == NULL) { ... But the change is very trivial and I would be fine with it, as you did in the webrev. Do whatever is more convenient to you, no need for another webrev. And make sure you push it to the client repo... Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 30. Mai 2018 15:33 To: 2d-dev <2d-dev at openjdk.java.net> Cc: Langer, Christoph Subject: [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp Hi could I please get reviews for this very small change : In java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp , function GDIWindowSurfaceData_GetComp, we might print pointer pData in uninitialized state. This occurs in case localObj == NULL , then we would print pData without initialization. The small fix adds initialization to pData : Bug: https://bugs.openjdk.java.net/browse/JDK-8204085 change : http://cr.openjdk.java.net/~mbaesken/webrevs/8204085/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed May 30 14:11:58 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 May 2018 14:11:58 +0000 Subject: [OpenJDK 2D-Dev] [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp In-Reply-To: <16fcc1fa4a4d4f8abd16e2b51f3c364a@sap.com> References: <153e7628a0284f0e941720c904e76860@sap.com> <16fcc1fa4a4d4f8abd16e2b51f3c364a@sap.com> Message-ID: Hi Christoph, Sergey and Thomas , thanks for the reviews . * And make sure you push it to the client repo... * Thanks for pointing this out, otherwise I would have taken the normal jdk repo . Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 30. Mai 2018 16:01 To: Baesken, Matthias ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp Hi Matthias, maybe the code would become nicer if you do it like this: ... jobject localObj = env->NewLocalRef(wsdo->peer); PDATA pData = localObj == NULL ? NULL : JNI_GET_PDATA(localObj); if (pData == NULL) { ... But the change is very trivial and I would be fine with it, as you did in the webrev. Do whatever is more convenient to you, no need for another webrev. And make sure you push it to the client repo... Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 30. Mai 2018 15:33 To: 2d-dev <2d-dev at openjdk.java.net> Cc: Langer, Christoph > Subject: [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp Hi could I please get reviews for this very small change : In java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp , function GDIWindowSurfaceData_GetComp, we might print pointer pData in uninitialized state. This occurs in case localObj == NULL , then we would print pData without initialization. The small fix adds initialization to pData : Bug: https://bugs.openjdk.java.net/browse/JDK-8204085 change : http://cr.openjdk.java.net/~mbaesken/webrevs/8204085/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 30 14:25:14 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 30 May 2018 07:25:14 -0700 Subject: [OpenJDK 2D-Dev] [XS] RFR : JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp In-Reply-To: References: <153e7628a0284f0e941720c904e76860@sap.com> <16fcc1fa4a4d4f8abd16e2b51f3c364a@sap.com> Message-ID: <5B0EB44A.5080009@oracle.com> Yes, please. And it looks fine. We have an internal static code analysis tool which should catch this sort of thing but it is weakest on Windows .. -phil. On 5/30/18, 7:11 AM, Baesken, Matthias wrote: > > Hi Christoph, Sergey and Thomas , thanks for the reviews . > > * And make sure you push it to the client repo... > * > > Thanks for pointing this out, otherwise I would have taken the normal > jdk repo . > > Best regards, Matthias > > *From:*Langer, Christoph > *Sent:* Mittwoch, 30. Mai 2018 16:01 > *To:* Baesken, Matthias ; 2d-dev > <2d-dev at openjdk.java.net> > *Subject:* RE: [XS] RFR : JDK-8204085: avoid printing uninitialized > pointer in > java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp > > Hi Matthias, > > maybe the code would become nicer if you do it like this: > > ... > > jobject localObj = env->NewLocalRef(wsdo->peer); > > PDATA pData = localObj == NULL ? NULL : JNI_GET_PDATA(localObj); > > if (pData == NULL) { > > ... > > But the change is very trivial and I would be fine with it, as you did > in the webrev. Do whatever is more convenient to you, no need for > another webrev. > > And make sure you push it to the client repo... > > Best regards > > Christoph > > *From:*Baesken, Matthias > *Sent:* Mittwoch, 30. Mai 2018 15:33 > *To:* 2d-dev <2d-dev at openjdk.java.net > > *Cc:* Langer, Christoph > > *Subject:* [XS] RFR : JDK-8204085: avoid printing uninitialized > pointer in > java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp > > Hi could I please get reviews for this very small change : > > In > java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp > , function GDIWindowSurfaceData_GetComp, > > we might print pointer pData in uninitialized state. > > This occurs in case localObj == NULL , then we would print pData > without initialization. > > The small fix adds initialization to pData : > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8204085 > > change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8204085/ > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed May 30 15:08:48 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 May 2018 15:08:48 +0000 Subject: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc Message-ID: <976f2b8bfe394ed7b9e39ce88f9e411c@sap.com> Hello , there is still some java2d coding where SAFE_SIZE_ARRAY_ALLOC / safe_Malloc is used and the (potentially occurring) exception is not handled . This leads to CL warnings (when enabled ) like " function assumed not to throw an exception but does ; The function is extern "C" and /EHc was specified" Example : java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp static POINT *TransformPoly() ..... if (outpoints > POLYTEMPSIZE) { pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc, sizeof(POINT), outpoints); } Should we add exception handling here ? Similar fixes were done in the change 8039394: Compiler warnings about C++ exceptions in windows printing code https://bugs.openjdk.java.net/browse/JDK-8039394 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42 Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed May 30 15:37:07 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 30 May 2018 17:37:07 +0200 Subject: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc In-Reply-To: <976f2b8bfe394ed7b9e39ce88f9e411c@sap.com> References: <976f2b8bfe394ed7b9e39ce88f9e411c@sap.com> Message-ID: Letting c++ exceptions escape from extern "C" functions is UB and may (and probably will) crash the process. This should be fixed. Approach taken by JDK-8039394 is fine (I would probably catch every C++ exception with catch(...), not just bad_alloc, just to be safe). Best Regards, Thomas On Wed, May 30, 2018 at 5:08 PM, Baesken, Matthias wrote: > Hello , there is still some java2d coding where SAFE_SIZE_ARRAY_ALLOC / > safe_Malloc is used and the (potentially occurring) exception is not > handled . > > > > This leads to CL warnings (when enabled ) like > > > > " function assumed not to throw an exception but does ; The function is > extern "C" and /EHc was specified" > > > > Example : > > > > java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp > > > > static POINT *TransformPoly() > > ?.. > > if (outpoints > POLYTEMPSIZE) { > > pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc, > sizeof(POINT), outpoints); > > } > > > > > > Should we add exception handling here ? > > > > Similar fixes were done in the change 8039394: Compiler warnings about C++ > exceptions in windows printing code > > > > https://bugs.openjdk.java.net/browse/JDK-8039394 > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/823387e2bf42 > > > > > > Best regards, Matthias > > > > From adam.farley at uk.ibm.com Wed May 30 16:08:08 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 30 May 2018 17:08:08 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c Message-ID: Hi Phil, I spoke with the jpegclub rep "Guido", and he was very helpful. He agreed to accept a code change, but recommended an error instead of a while check. ------------------------------ Line 808: < while (bits[j] == 0) < j--; --- > while (bits[j] == 0) { > if (j == 0) > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > j--; > } ------------------------------ This makes sense to me, and I verified that it prevents the error. He says: @@@@@@@@@@@@ For the release version I would replace the specific JERR_HUFF_CLEN_OVERFLOW by the more general JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this requires a change in jerror.h: -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out of bounds") The next version (9d) is planned for release in January 2020. A pre-release package will be provided in 2019 on http://jpegclub.org/reference/reference-sources/, I will send you a notification. @@@@@@@@@@@@ While we *could* make the jerror.h change, I suggest we don't for now. If we merge from upstream in January 2020, we'll get that change anyway when the time comes. So what do you say to including the dashed change referenced above to fix our problem now, safe in the knowledge that upstream will be similarly modified (except with the new error type). Best Regards Adam Farley P.S. I'm holding off on giving Guido the green light until after people say if they're happy with the error-enabled version of the fix. Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > From: Adam Farley8/UK/IBM > To: Phil Race > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > , build-dev dev at openjdk.java.net>, Magnus Ihse Bursie > , "Thomas St?fe" > Date: 14/05/2018 11:06 > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > compile warning in jchuff.c > > Hi Phil, > > Would an acceptable compromise be to deliver the source code change > and send the code to the upstream community, allowing them to include > the fix if/when they are able? > > I believe Magnus was advocating this idea as well. See below. > > Best Regards > > Adam Farley > > > Same here. I would like to have this fix in, but do not want to go > > over Phils head. > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > Thanks, Thomas > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > wrote: > > > I don't object, but it's not build code so I don't have the final say. > > > > > > /Magnus > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > Hi All, > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > It doesn't break anything, it fixes a build break on two supported > > > platforms, and it seems > > > like we never refresh the code from upstream. > > > > > > - Adam > > > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > > >> of logic required > > >> to properly analyse the toolchain version string. > > >> > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > > >> and Make doesn't > > >> seem to do substring stuff unless you mess around with shells. > > >> > > >> Plus, as people have said, it's better to solve problem x (or work around > > >> a specific > > >> instance of x) than to ignore the exception, even if the ignoring code is > > >> toolchain- > > >> specific. > > >> > > >> - Adam Farley > > >> > > >> > On 2018-03-27 18:44, Phil Race wrote: > > >> > > > >> >> As I said I prefer the make file change, since this is a change to an > > >> >> upstream library. > > >> > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > >> > reviewer. :) > > >> > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > >> > complaint seems reasonable, and disabling it might cause us > to miss other > > >> > future errors. > > >> > > > >> > Why can't we push the source code fix, and also submit it upstream? > > >> > > > >> > /Magnus > > >> > > > >> > > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > > >> > 6b, so this code > > >> > seems to have stood the test of time. I'm also unclear why the compiler > > >> > would > > >> > complain about that and not the one a few lines later > > >> > > > >> > > > >> > 819 while (bits[i] == 0) /* find largest > codelength still in > > >> > use */ > > >> > 820 i--; > > >> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > >> > A tool-chain specific fix in the makefile with an appropriatecomment is > > >> > more targeted. > > >> > > >> Phil, > > >> > > >> Returning to this. > > >> > > >> While I understand your reluctance to patch upstream code, let me point > > >> out that we have not updated libjpeg a single time since the JDK was open > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > Wikipedia page > > >> on libjpeg, and this is the latest "uncontroversial" version of > the source. > > >> Versions 7 and up have proprietary extensions, which in turn > has resulted in > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > we will ever > > >> replace libjpeg 6b with a simple upgrade from upstream. > > >> > > >> I therefore maintain my position that a source code fix would be the best > > >> way forward here. > > >> > > >> /Magnus > > >> > > >> > > > >> > > > >> > -phil. > > >> > > > >> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > just a friendly reminder. I would like to push this tiny fix because > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > >> > maintain patch queues, but this is a constant error source). > > >> > > > >> > > > >> > I will wait for 24 more hours until a reaction. If no seriousobjections > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > me and Christoph > > >> > langer are both Reviewers). > > >> > > > >> > > > >> > Thanks! Thomas > > >> > > > >> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > >> > wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > may I please have another review for this really trivial change. It > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > good idea to fix > > >> > this. > > >> > > > >> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > >> > webrev: > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > warning-in-jchuff.c/webrev.00/webrev/ > > >> > > > >> > > > >> > This was contributed by Adam Farley at IBM. > > >> > > > >> > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > >> > > > >> > > > >> > Thanks, Thomas > > >> > > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > >> > > >> > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 30 16:12:37 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 09:12:37 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8203367 : Upgrade to freetype 2.9.1 Message-ID: <5c51bc20-c54d-edfb-a73e-af42b8ea3e0f@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8203367 webrev: http://cr.openjdk.java.net/~prr/8203367/ This is an incremental update from 2.9, imported in February, to 2.9.1 which was released earlier this month, before we enter RDP for JDK11. It has been built on all platforms via our internal build system - making sure to specify --with-freetype=bundled. One new warning was seen on Linux but the code had not changed. I suspect the gcc toolchain upgrade sparked the new warning which is not usually seen since the default on linux is --with-freetype=system (ie don't build or use this source). -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 30 17:06:19 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 10:06:19 -0700 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: Message-ID: <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com> Thank you for persevering with this. Please submit a webrev with this change .. I think you can leave out the change to jerror.h in the jpeg6b case. -phil. On 05/30/2018 09:08 AM, Adam Farley8 wrote: > Hi Phil, > > I spoke with the jpegclub rep "Guido", and he was very helpful. > > He agreed to accept a code change, but recommended an error instead of > a while check. > > ------------------------------ Line 808: > < while (bits[j] == 0) > < j--; > --- > > while (bits[j] == 0) { > > if (j == 0) > > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > > j--; > > } > ------------------------------ > > This makes sense to me, and I verified that it prevents the error. > > He says: > @@@@@@@@@@@@ > For the release version I would replace the specific > JERR_HUFF_CLEN_OVERFLOW by the more general JERR_HUFF_CLEN_OUTOFBOUNDS > so that it suits both cases, this requires a change in jerror.h: > > -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") > +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out of > bounds") > > The next version (9d) is planned for release in January 2020. > A pre-release package will be provided in 2019 on > _http://jpegclub.org/reference/reference-sources/_, I will send you a > notification. > @@@@@@@@@@@@ > > While we *could* make the jerror.h change, I suggest we don't for now. > If we merge from upstream in January 2020, we'll get that change > anyway when the time comes. > > So what do you say to including the dashed change referenced above to > fix our problem now, safe in the knowledge that upstream will be > similarly modified (except with the new error type). > > Best Regards > > Adam Farley > > P.S. I'm holding off on giving Guido the green light until after > people say if they're happy with the error-enabled version of the fix. > > Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > > > From: Adam Farley8/UK/IBM > > To: Phil Race > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > , build-dev > dev at openjdk.java.net>, Magnus Ihse Bursie > > , "Thomas St?fe" > > > Date: 14/05/2018 11:06 > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > compile warning in jchuff.c > > > > Hi Phil, > > > > Would an acceptable compromise be to deliver the source code change > > and send the code to the upstream community, allowing them to include > > the fix if/when they are able? > > > > I believe Magnus was advocating this idea as well. See below. > > > > Best Regards > > > > Adam Farley > > > > > Same here. I would like to have this fix in, but do not want to go > > > over Phils head. > > > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > > > Thanks, Thomas > > > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > > wrote: > > > > I don't object, but it's not build code so I don't have the final say. > > > > > > > > /Magnus > > > > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > > > Hi All, > > > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > > > It doesn't break anything, it fixes a build break on two supported > > > > platforms, and it seems > > > > like we never refresh the code from upstream. > > > > > > > > - Adam > > > > > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > > > >> of logic required > > > >> to properly analyse the toolchain version string. > > > >> > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > > > >> and Make doesn't > > > >> seem to do substring stuff unless you mess around with shells. > > > >> > > > >> Plus, as people have said, it's better to solve problem x (or work around > > > >> a specific > > > >> instance of x) than to ignore the exception, even if the ignoring code is > > > >> toolchain- > > > >> specific. > > > >> > > > >> - Adam Farley > > > >> > > > >> > On 2018-03-27 18:44, Phil Race wrote: > > > >> > > > > >> >> As I said I prefer the make file change, since this is a change to an > > > >> >> upstream library. > > > >> > > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > > >> > reviewer. :) > > > >> > > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > > >> > complaint seems reasonable, and disabling it might cause us > > to miss other > > > >> > future errors. > > > >> > > > > >> > Why can't we push the source code fix, and also submit it upstream? > > > >> > > > > >> > /Magnus > > > >> > > > > >> > > > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > > > >> > 6b, so this code > > > >> > seems to have stood the test of time. I'm also unclear why the compiler > > > >> > would > > > >> > complain about that and not the one a few lines later > > > >> > > > > >> > > > > >> > 819 while (bits[i] == 0) /* find largest > > codelength still in > > > >> > use */ > > > >> > 820 i--; > > > >> > > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > > >> > A tool-chain specific fix in the makefile with an appropriatecomment is > > > >> > more targeted. > > > >> > > > >> Phil, > > > >> > > > >> Returning to this. > > > >> > > > >> While I understand your reluctance to patch upstream code, let me point > > > >> out that we have not updated libjpeg a single time since the JDK was open > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > > Wikipedia page > > > >> on libjpeg, and this is the latest "uncontroversial" version of > > the source. > > > >> Versions 7 and up have proprietary extensions, which in turn > > has resulted in > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > > we will ever > > > >> replace libjpeg 6b with a simple upgrade from upstream. > > > >> > > > >> I therefore maintain my position that a source code fix would be the best > > > >> way forward here. > > > >> > > > >> /Magnus > > > >> > > > >> > > > > >> > > > > >> > -phil. > > > >> > > > > >> > > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > >> > > > > >> > Hi all, > > > >> > > > > >> > > > > >> > just a friendly reminder. I would like to push this tiny fix because > > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > > >> > maintain patch queues, but this is a constant error source). > > > >> > > > > >> > > > > >> > I will wait for 24 more hours until a reaction. If no seriousobjections > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > > me and Christoph > > > >> > langer are both Reviewers). > > > >> > > > > >> > > > > >> > Thanks! Thomas > > > >> > > > > >> > > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > >> > wrote: > > > >> > > > > >> > Hi all, > > > >> > > > > >> > > > > >> > may I please have another review for this really trivial change. It > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > > good idea to fix > > > >> > this. > > > >> > > > > >> > > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > > >> > webrev: > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > > > warning-in-jchuff.c/webrev.00/webrev/ > > > >> > > > > >> > > > > >> > This was contributed by Adam Farley at IBM. > > > >> > > > > >> > > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > > >> > > > > >> > > > > >> > Thanks, Thomas > > > >> > > > > >> > > > >> Unless stated otherwise above: > > > >> IBM United Kingdom Limited - Registered in England and Wales with number > > > >> 741598. > > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > >> > > > >> > > > > > > > > Unless stated otherwise above: > > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > > 741598. > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 30 17:07:39 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 10:07:39 -0700 Subject: [OpenJDK 2D-Dev] Question about splashscreen lib In-Reply-To: References: <5B0D5449.7060404@oracle.com> Message-ID: I think PNG_DLL_EXPORT is not intended to be used directly. I am not sure what problem this causes but it is just the way this library is written ... -phil. On 05/30/2018 04:16 AM, Adam Farley8 wrote: > Thanks Philip. > > The whole thing with PNG_DLL_EXPORT not being defined in png.h or > png.c is still confusing to me > (pngpriv defines it), especially since png.h ends up using it > post-pre-processing, but I don't know if > that would bother people outside the minority that inspect the > pre-processed code. > > I'll leave this here as a thought for any committer bothered by this, > though I won't be pushing it. > > ---- png.h ---- > + #ifndef PNG_DLL_EXPORT > + #define PNG_DLL_EXPORT > + #endif > > Best Regards > > Adam Farley > > > Philip Race wrote on 29/05/2018 14:23:21: > > > From: Philip Race > > To: Adam Farley8 > > Cc: 2d-dev <2d-dev at openjdk.java.net> > > Date: 29/05/2018 14:23 > > Subject: Re: [OpenJDK 2D-Dev] Question about splashscreen lib > > > > So far as I can see it does, just indirectly. > > png.c includes pngpriv.h which includes png.h > > > > Not including the declarations of the exported API in the file that > > defines them would be a problem waiting to happen. > > > > -phil. > > > > On 5/29/18, 3:54 AM, Adam Farley8 wrote: > > Hi All, > > > > Does anyone know why png.c does not include png.h? > > > > This tripped me up recently, and I don't understand why png.c would > > not include png.h. > > > > Best Regards > > > > Adam Farley > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed May 30 17:14:17 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 May 2018 10:14:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8203367 : Upgrade to freetype 2.9.1 In-Reply-To: <5c51bc20-c54d-edfb-a73e-af42b8ea3e0f@oracle.com> References: <5c51bc20-c54d-edfb-a73e-af42b8ea3e0f@oracle.com> Message-ID: <356a13c8-36b1-995e-f328-28b08c359fa6@oracle.com> Looks fine. On 30/05/2018 09:12, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8203367 > webrev: http://cr.openjdk.java.net/~prr/8203367/ > > This is an incremental update from 2.9, imported in February, > to 2.9.1 which was released earlier this month, before we enter RDP for > JDK11. > > It has been built on all platforms via our internal build system - > making sure > to specify --with-freetype=bundled. > One new warning was seen on Linux but the code had not changed. > I suspect the gcc toolchain upgrade sparked the new warning which is not > usually seen since the default on linux is --with-freetype=system (ie don't > build or use this source). > > -phil. -- Best regards, Sergey. From philip.race at oracle.com Wed May 30 17:44:37 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 10:44:37 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8199530 : Upgrade to harfbuzz 1.7.6 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8199530 Webrev: http://cr.openjdk.java.net/~prr/8199530/ We are currently using harfbuzz 1.7.1. This change updates to use 1.7.6 -phil. From Sergey.Bylokhov at oracle.com Wed May 30 18:08:15 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 May 2018 11:08:15 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8199530 : Upgrade to harfbuzz 1.7.6 In-Reply-To: References: Message-ID: <909fe59e-ad8e-c4d5-f5d4-c7d221eb8037@oracle.com> Looks fine. On 30/05/2018 10:44, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8199530 > Webrev: http://cr.openjdk.java.net/~prr/8199530/ > > We are currently using harfbuzz 1.7.1. This change updates to use 1.7.6 > > -phil. > -- Best regards, Sergey. From philip.race at oracle.com Wed May 30 18:50:58 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 11:50:58 -0700 Subject: [OpenJDK 2D-Dev] [11] Review Request: 8199150 and 8150156 In-Reply-To: <91d14378-516e-9fe9-f6e8-97a6fff2e8d6@oracle.com> References: <91d14378-516e-9fe9-f6e8-97a6fff2e8d6@oracle.com> Message-ID: +1 -phil. On 05/16/2018 08:16 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11, which fixed some accessibility issues > in the specification. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199150 > https://bugs.openjdk.java.net/browse/JDK-8150156 > Fix: http://cr.openjdk.java.net/~serb/8199150/webrev.01 > > Description: > - The links to "bugs.sun.com" were replaced by "bugs.java.com" > - To most of our doc-files the "
" tag is added. > - In some files the numbers in "H" tag are renumbered to h1/h2/h3 > - In JTextComponent the tag was removed, this line was missed in > JDK-8184219 > - The accessibility checkers report that the red color on the > white/gray background has "Insufficient contrast", so I replaced red > to blue color > From srl at icu-project.org Wed May 30 19:06:21 2018 From: srl at icu-project.org (Steven R. Loomis) Date: Wed, 30 May 2018 12:06:21 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8199530 : Upgrade to harfbuzz 1.7.6 In-Reply-To: <909fe59e-ad8e-c4d5-f5d4-c7d221eb8037@oracle.com> References: <909fe59e-ad8e-c4d5-f5d4-c7d221eb8037@oracle.com> Message-ID: +1 On Wed, May 30, 2018 at 11:08 AM, Sergey Bylokhov < Sergey.Bylokhov at oracle.com> wrote: > Looks fine. > > > On 30/05/2018 10:44, Phil Race wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199530 >> Webrev: http://cr.openjdk.java.net/~prr/8199530/ >> >> We are currently using harfbuzz 1.7.1. This change updates to use 1.7.6 >> >> -phil. >> >> > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 30 22:04:43 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 15:04:43 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8204122: Update harfbuzz.md Message-ID: <87de4459-dcff-ff66-6419-fd82de315563@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8204122 I pushed harfbuzz 1.7.6 without updating the version in the legal file. The diff is trivial so I am including inline here : --- a/src/java.desktop/share/legal/harfbuzz.md +++ b/src/java.desktop/share/legal/harfbuzz.md @@ -1,4 +1,4 @@ -## Harfbuzz v1.7.1 +## Harfbuzz v1.7.6 I checked the rest of the text in that file does not need to change. -phil. From srl at icu-project.org Wed May 30 22:11:05 2018 From: srl at icu-project.org (Steven R. Loomis) Date: Wed, 30 May 2018 15:11:05 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8204122: Update harfbuzz.md In-Reply-To: <87de4459-dcff-ff66-6419-fd82de315563@oracle.com> References: <87de4459-dcff-ff66-6419-fd82de315563@oracle.com> Message-ID: LGTM On Wed, May 30, 2018 at 3:04 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8204122 > > I pushed harfbuzz 1.7.6 without updating the version in the legal file. > The diff is trivial so I am including inline here : > > --- a/src/java.desktop/share/legal/harfbuzz.md > +++ b/src/java.desktop/share/legal/harfbuzz.md > @@ -1,4 +1,4 @@ > -## Harfbuzz v1.7.1 > +## Harfbuzz v1.7.6 > > > I checked the rest of the text in that file does not need to change. > > -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Thu May 31 11:17:02 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 31 May 2018 12:17:02 +0100 Subject: [OpenJDK 2D-Dev] Question about splashscreen lib In-Reply-To: References: <5B0D5449.7060404@oracle.com> Message-ID: Hi Phil, As long as anyone using png.h also includes pngpriv, it's not a problem. If you don't include pngpriv, the pre-process output resolves the extern lines to be extern PNG_DLL_EXPORT [function] because it appears to use the string literally if the macro hasn't been defined. Right now this isn't a bug, just a quirk I was mentioning. Best Regards Adam Farley Phil Race wrote on 30/05/2018 18:07:39: > From: Phil Race > To: Adam Farley8 > Cc: 2d-dev <2d-dev at openjdk.java.net> > Date: 30/05/2018 18:08 > Subject: Re: [OpenJDK 2D-Dev] Question about splashscreen lib > > I think PNG_DLL_EXPORT is not intended to be used directly. > I am not sure what problem this causes but it is just the way this > library is written ... > > -phil. > On 05/30/2018 04:16 AM, Adam Farley8 wrote: > Thanks Philip. > > The whole thing with PNG_DLL_EXPORT not being defined in png.h or > png.c is still confusing to me > (pngpriv defines it), especially since png.h ends up using it post- > pre-processing, but I don't know if > that would bother people outside the minority that inspect the pre- > processed code. > > I'll leave this here as a thought for any committer bothered by > this, though I won't be pushing it. > > ---- png.h ---- > + #ifndef PNG_DLL_EXPORT > + #define PNG_DLL_EXPORT > + #endif > > Best Regards > > Adam Farley > > > Philip Race wrote on 29/05/2018 14:23:21: > > > From: Philip Race > > To: Adam Farley8 > > Cc: 2d-dev <2d-dev at openjdk.java.net> > > Date: 29/05/2018 14:23 > > Subject: Re: [OpenJDK 2D-Dev] Question about splashscreen lib > > > > So far as I can see it does, just indirectly. > > png.c includes pngpriv.h which includes png.h > > > > Not including the declarations of the exported API in the file that > > defines them would be a problem waiting to happen. > > > > -phil. > > > > On 5/29/18, 3:54 AM, Adam Farley8 wrote: > > Hi All, > > > > Does anyone know why png.c does not include png.h? > > > > This tripped me up recently, and I don't understand why png.c would > > not include png.h. > > > > Best Regards > > > > Adam Farley > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu May 31 17:33:46 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 31 May 2018 10:33:46 -0700 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com> Message-ID: <64b546b2-c33a-dafd-f284-a2aedac8d730@oracle.com> I've grabbed the bug from Thomas and re-opened it https://bugs.openjdk.java.net/browse/ Your webrev was stripped so I've uploaded here : http://cr.openjdk.java.net/~prr/8200052/ It looks fine to me but I am a bit hazy about who to give attribution for the fix .. It is small enough to not require an OCA so there's no issue there if we attribute it to the IJG guy. -phil. On 05/31/2018 06:31 AM, Adam Farley8 wrote: > An attachment in the email has been found to contain executable code > and has been removed. > > File removed : webrev.zip, zip,html,js > ------------------------------------------------------------------------ > Hi Phil, > > As requested: > > > > FYI: I've also contacted Guido, confirmed that the fix worked, and asked > him to go ahead with merging the fix into his code base. > > Best Regards > > Adam Farley > > > Phil Race wrote on 30/05/2018 18:06:19: > > > From: Phil Race > > To: Adam Farley8 > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > , build-dev > dev at openjdk.java.net>, Magnus Ihse Bursie > > , "Thomas St?fe" > > > Date: 30/05/2018 18:07 > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > compile warning in jchuff.c > > > > Thank you for persevering with this. Please submit a webrev with this > > change .. I think you can leave out the change to jerror.h in the > jpeg6b case. > > > > -phil. > > > On 05/30/2018 09:08 AM, Adam Farley8 wrote: > > Hi Phil, > > > > I spoke with the jpegclub rep "Guido", and he was very helpful. > > > > He agreed to accept a code change, but recommended an error instead > > of a while check. > > > > ------------------------------ Line 808: > > < while (bits[j] == 0) > > < j--; > > --- > > > while (bits[j] == 0) { > > > if (j == 0) > > > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > > > j--; > > > } > > ------------------------------ > > > > This makes sense to me, and I verified that it prevents the error. > > > > He says: > > @@@@@@@@@@@@ > > For the release version I would replace the specific > > JERR_HUFF_CLEN_OVERFLOW by the more general > > JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this > > requires a change in jerror.h: > > > > -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") > > +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out > of bounds") > > > > The next version (9d) is planned for release in January 2020. > > A pre-release package will be provided in 2019 on http:// > > jpegclub.org/reference/reference-sources/, I will send you a > notification. > > @@@@@@@@@@@@ > > > > While we *could* make the jerror.h change, I suggest we don't for > > now. If we merge from upstream in January 2020, we'll get that > > change anyway when the time comes. > > > > So what do you say to including the dashed change referenced above > > to fix our problem now, safe in the knowledge that upstream will be > > similarly modified (except with the new error type). > > > > Best Regards > > > > Adam Farley > > > > P.S. I'm holding off on giving Guido the green light until after > > people say if they're happy with the error-enabled version of the fix. > > > > Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > > > > > From: Adam Farley8/UK/IBM > > > To: Phil Race > > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > > , build-dev > > dev at openjdk.java.net>, Magnus Ihse Bursie > > > , "Thomas St?fe" > > > > Date: 14/05/2018 11:06 > > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > > compile warning in jchuff.c > > > > > > Hi Phil, > > > > > > Would an acceptable compromise be to deliver the source code change > > > and send the code to the upstream community, allowing them to include > > > the fix if/when they are able? > > > > > > I believe Magnus was advocating this idea as well. See below. > > > > > > Best Regards > > > > > > Adam Farley > > > > > > > Same here. I would like to have this fix in, but do not want to go > > > > over Phils head. > > > > > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > > > > > Thanks, Thomas > > > > > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > > > wrote: > > > > > I don't object, but it's not build code so I don't have the > final say. > > > > > > > > > > /Magnus > > > > > > > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > > > > > Hi All, > > > > > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > > > > > It doesn't break anything, it fixes a build break on two > supported > > > > > platforms, and it seems > > > > > like we never refresh the code from upstream. > > > > > > > > > > - Adam > > > > > > > > > >> I also advocate the source code fix, as Make isn't meant to > > use the sort > > > > >> of logic required > > > > >> to properly analyse the toolchain version string. > > > > >> > > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is > > using 4.8.6, > > > > >> and Make doesn't > > > > >> seem to do substring stuff unless you mess around with shells. > > > > >> > > > > >> Plus, as people have said, it's better to solve problem x (or > > work around > > > > >> a specific > > > > >> instance of x) than to ignore the exception, even if the > > ignoring code is > > > > >> toolchain- > > > > >> specific. > > > > >> > > > > >> - Adam Farley > > > > >> > > > > >> > On 2018-03-27 18:44, Phil Race wrote: > > > > >> > > > > > >> >> As I said I prefer the make file change, since this is a > > change to an > > > > >> >> upstream library. > > > > >> > > > > > >> > Newtons fourth law: For every reviewer, there's an equal > and opposite > > > > >> > reviewer. :) > > > > >> > > > > > >> > Here I am, advocating a source code fix. As Thomas says, > the compiler > > > > >> > complaint seems reasonable, and disabling it might cause us > > > to miss other > > > > >> > future errors. > > > > >> > > > > > >> > Why can't we push the source code fix, and also submit it > upstream? > > > > >> > > > > > >> > /Magnus > > > > >> > > > > > >> > > > > > >> > I've looked at jpeg-9c and it still looks identical to > whatwe have in > > > > >> > 6b, so this code > > > > >> > seems to have stood the test of time. I'm also unclear why > > the compiler > > > > >> > would > > > > >> > complain about that and not the one a few lines later > > > > >> > > > > > >> > > > > > >> > 819 while (bits[i] == 0) /* find largest > > > codelength still in > > > > >> > use */ > > > > >> > 820 i--; > > > > >> > > > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > > > >> > A tool-chain specific fix in the makefile with an > > appropriatecomment is > > > > >> > more targeted. > > > > >> > > > > >> Phil, > > > > >> > > > > >> Returning to this. > > > > >> > > > > >> While I understand your reluctance to patch upstream code, > let me point > > > > >> out that we have not updated libjpeg a single time since the > > JDK was open > > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > > > Wikipedia page > > > > >> on libjpeg, and this is the latest "uncontroversial" version of > > > the source. > > > > >> Versions 7 and up have proprietary extensions, which in turn > > > has resulted in > > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > > > we will ever > > > > >> replace libjpeg 6b with a simple upgrade from upstream. > > > > >> > > > > >> I therefore maintain my position that a source code fix would > > be the best > > > > >> way forward here. > > > > >> > > > > >> /Magnus > > > > >> > > > > >> > > > > > >> > > > > > >> > -phil. > > > > >> > > > > > >> > > > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > > >> > > > > > >> > Hi all, > > > > >> > > > > > >> > > > > > >> > just a friendly reminder. I would like to push this tiny > fix because > > > > >> > tripping over this on our linux s390x builds is annoying > (yes, we can > > > > >> > maintain patch queues, but this is a constant error source). > > > > >> > > > > > >> > > > > > >> > I will wait for 24 more hours until a reaction. If no > > seriousobjections > > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > > > me and Christoph > > > > >> > langer are both Reviewers). > > > > >> > > > > > >> > > > > > >> > Thanks! Thomas > > > > >> > > > > > >> > > > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > > > > >> > wrote: > > > > >> > > > > > >> > Hi all, > > > > >> > > > > > >> > > > > > >> > may I please have another review for this really trivial > change. It > > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > > > good idea to fix > > > > >> > this. > > > > >> > > > > > >> > > > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > > > >> > webrev: > > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > > > > warning-in-jchuff.c/webrev.00/webrev/ > > > > >> > > > > > >> > > > > > >> > This was contributed by Adam Farley at IBM. > > > > >> > > > > > >> > > > > > >> > I already reviewed this. I also test-built on zlinux and it > works. > > > > >> > > > > > >> > > > > > >> > Thanks, Thomas > > > > >> > > > > > >> > > > > >> Unless stated otherwise above: > > > > >> IBM United Kingdom Limited - Registered in England and Wales > > with number > > > > >> 741598. > > > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > > > Hampshire PO6 3AU > > > > >> > > > > >> > > > > > > > > > > Unless stated otherwise above: > > > > > IBM United Kingdom Limited - Registered in England and Wales > with number > > > > > 741598. > > > > > Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > > > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > > > number 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From srl at icu-project.org Thu May 31 22:19:19 2018 From: srl at icu-project.org (Steven R. Loomis) Date: Thu, 31 May 2018 15:19:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend) In-Reply-To: References: <5AFE5907.7050909@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.01/ On Fri, May 18, 2018 at 9:16 AM, Toshio 5 Nakamura wrote: > Thank you for your review, Phil. > I'm working to handle your points. > > Toshio Nakamura > > Philip Race wrote on 2018/05/18 13:39:35: > > > From: Philip Race > > To: Toshio 5 Nakamura > > Cc: 2d-dev <2d-dev at openjdk.java.net> > > Date: 2018/05/18 13:39 > > > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation > > Selectors(Resend) > > > > There's a lot to think about here but I have some requests to first > > clean up the proposed code to conform to coding standards. > > > > I see lots of lines > 80 chars. Please fix > > > > I see if(foo){ and else{ which should be "if (foo) {" and "else {" > > > > Basically always have a space before { and after ) and around "=" and > "==" > > > > One line that WAS > > 51 hb_codepoint_t u = (variation_selector==0) ? unicode : > > variation_selector; > > > > has no spaces around "==" almost certainly to avoid going over 80 chars. > > Now you've broken the line you can fix that. > > > > > Eliminate all wild card imports and import exactly what is needed. > > Maybe this is only about the test. > > > > remove what looks like SCCS style comments on the @test line. > > Make the test simply print a warning if the person didn't install > > fonts where you expected. > > Why? Because @ignore defaults to .. not being ignored. > > > > For the JNI methods calls read the spec and see if calling them may > > throw an exception > > > > I'm looking at sequences like > > env->SetIntArrayRegion(unicodes, 0, 2, tmp); > > 71 env->CallVoidMethod(font2D, > > sunFontIDs.f2dCharsToGlyphsMID, 2, unicodes, results); > > 72 env->GetIntArrayRegion(results, 0, 2, tmp); > > 73 *glyph = tmp[0]; > > 74 cleanup: > > 75 if (unicodes != NULL) env->DeleteLocalRef(unicodes); > > 76 if (results != NULL) env->DeleteLocalRef(results); > > > > > If call GetIntArrayRegion may leave a pending exception it needs to > > be checked and cleared > > before you make another call. > > > > Look at the performance implications of things like the extra > > work done now in FontUtilities.isSimpleChar() and see how to minimise > > it since it could affect all text rendering in a way that is measurable > > in at least some way. > > > > I idly wonder if > > > > > > public static boolean isBaseChar(int charCode){ ... > > > > might be more cleanly or efficiently implemented with a switch ? > > > > Not sure. > > > > -phil. > > > > On 5/14/18, 1:28 AM, Toshio 5 Nakamura wrote: > > Could someone review our proposal to support Unicode Variation Selectors? > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > > > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > > > Toshio Nakamura > > > > > From: "Steven R. Loomis" > > > To: 2d-dev <2d-dev at openjdk.java.net> > > > Date: 2018/05/03 03:27 > > > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation > > > Selectors (Resend) > > > Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> > > > > > > I added a screenshot to https://bugs.openjdk.java.net/ > browse/JDK-8187100 > > > if anyone wants to see what the impact of this fix is > > > > > > On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis > wrote: > > > (Retrying as actual text) > > > > > > Support Unicode Variation Selectors. > > > > > > Code by my colleague Toshio Nakamura, I added a simple test, and > > > include a test that was part of JDK 8187100. (Both tests are run > manually.) > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 > > > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ > > > > > > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > > > > > > > Hello > > > > > > > > IBM would like to propose Unicode Variation Selector[1] capability > to AWT > > > > and Swing components. > > > > (This proposal was posted to i18n-dev first, and I got a suggestion > to > > > > discuss > > > > in 2d-dev.) > > > > > > > > This proposal changed the following files: > > > > src/java.desktop/share/classes/sun/font/CMap.java > > > > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > > > > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > > > > src/java.desktop/share/classes/sun/font/Font2D.java > > > > src/java.desktop/share/classes/sun/font/FontRunIterator.java > > > > src/java.desktop/share/classes/sun/font/FontUtilities.java > > > > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > > > > src/java.desktop/share/native/common/font/sunfontids.h > > > > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > > > src/java.desktop/share/native/libfontmanager/sunFont.c > > > > src/java.desktop/share/classes/javax/swing/text/ > DefaultEditorKit.java > > > > 542 lines will be changed. > > > > > > > > There are three parts. > > > > 1) Adding CMap format 14 support > > > > 2) Adding CharsToGlyphs functions support Variation Selector > Sequences > > > > 3) Swing text component's DEL and BS key operations change > > > > > > > > > > > > How would I go about obtaining a sponsor? > > > > > > > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > > > > Chapter 23.4 Variation Selectors > > > > > > > > Best regards, > > > > > > > > Toshio Nakamura > > > > IBM Japan > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: