From dmitry.markov at oracle.com Mon Sep 3 09:50:49 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 3 Sep 2018 10:50:49 +0100 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right Message-ID: Hello, Could you review a fix for jdk8u, please? bug: https://bugs.openjdk.java.net/browse/JDK-8201801 webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ Problem description: The fix for 7162125 [1] enabled font tables processing on OSX. However there is a lack of support for RTL languages in ICU layout engine. Quote from ICU guide: ??The AAT processing in the LayoutEngine is relatively basic as it only applies the default features in left-to-right text. This processing has been tested for Devanagari text. Since AAT processing is not script-specific, it might not work for other scripts??, more details at http://userguide.icu-project.org/layoutengine As a result all RTL languages on OSX are incorrectly laid out, (i.e. the letters are reversely presented). Fix: Skip font tables for RTL languages on OSX platform. Thanks, Dmitry [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Sep 3 10:33:19 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 3 Sep 2018 16:03:19 +0530 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: References: Message-ID: Hi Dmitry, Not going into technicalities of the fix, but it seems it will break non-macos build as you are checking for CFont in a shared class? Also, if it's the issue still exists, then why you are fixing only in 8u and not in jdk12? Regards Prasanta On 9/3/2018 3:20 PM, Dmitry Markov wrote: > Hello, > > Could you review a fix for jdk8u, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8201801 > webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ > > > Problem description: > The fix for 7162125 [1] enabled font tables processing on OSX. However > there is a lack of support for RTL languages in ICU layout engine. > Quote from ICU guide: ??The AAT processing in the LayoutEngine is > relatively basic as it only applies the default features in > left-to-right text. This processing has been tested for Devanagari > text. Since AAT processing is not script-specific, it might not work > for other scripts??, more details at > http://userguide.icu-project.org/layoutengine > As a result all RTL languages on OSX are incorrectly laid out, (i.e. > the letters are reversely presented). > > Fix: > Skip font tables for RTL languages on OSX platform. > > Thanks, > Dmitry > > [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Mon Sep 3 12:54:54 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 3 Sep 2018 13:54:54 +0100 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: References: Message-ID: Hi Prasanta, Thank you for the feedback. I missed the usage of OSX specific class in shared code for some reasons. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ I replaced the usage of CFont with a new private method which tests either a font is AAT or not. The issue is jdk8u (ICU) specific. It does not take place on jdk12 because starting from jdk9 we use Harfbuzz as default layout engine. Thanks, Dmitry > On 3 Sep 2018, at 11:33, Prasanta Sadhukhan wrote: > > Hi Dmitry, > Not going into technicalities of the fix, but it seems it will break non-macos build as you are checking for CFont in a shared class? > Also, if it's the issue still exists, then why you are fixing only in 8u and not in jdk12? > > Regards > Prasanta > On 9/3/2018 3:20 PM, Dmitry Markov wrote: >> Hello, >> >> Could you review a fix for jdk8u, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >> webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >> >> Problem description: >> The fix for 7162125 [1] enabled font tables processing on OSX. However there is a lack of support for RTL languages in ICU layout engine. Quote from ICU guide: ??The AAT processing in the LayoutEngine is relatively basic as it only applies the default features in left-to-right text. This processing has been tested for Devanagari text. Since AAT processing is not script-specific, it might not work for other scripts??, more details at http://userguide.icu-project.org/layoutengine >> As a result all RTL languages on OSX are incorrectly laid out, (i.e. the letters are reversely presented). >> >> Fix: >> Skip font tables for RTL languages on OSX platform. >> >> Thanks, >> Dmitry >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Sep 3 18:42:04 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 03 Sep 2018 11:42:04 -0700 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: References: Message-ID: <5B8D807C.7070209@oracle.com> > it will break non-macos build as you are checking for CFont in a shared class? Indeed. And on top of that, the apparent assumption that all Apple platform fonts are AAT fonts is wrong. Even if we agreed with this approach, which needs thought, it should only apply to AAT fonts > Also, if it's the issue still exists, then why you are fixing only in 8u and not in jdk12? ICU is not in 12 .. or even 11 .. it was removed in 10. -phil. On 9/3/18, 3:33 AM, Prasanta Sadhukhan wrote: > > Hi Dmitry, > > Not going into technicalities of the fix, but it seems it will break > non-macos build as you are checking for CFont in a shared class? > Also, if it's the issue still exists, then why you are fixing only in > 8u and not in jdk12? > > Regards > Prasanta > On 9/3/2018 3:20 PM, Dmitry Markov wrote: >> Hello, >> >> Could you review a fix for jdk8u, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >> webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >> >> >> Problem description: >> The fix for 7162125 [1] enabled font tables processing on OSX. >> However there is a lack of support for RTL languages in ICU layout >> engine. Quote from ICU guide: ??The AAT processing in the >> LayoutEngine is relatively basic as it only applies the default >> features in left-to-right text. This processing has been tested for >> Devanagari text. Since AAT processing is not script-specific, it >> might not work for other scripts??, more details at >> http://userguide.icu-project.org/layoutengine >> As a result all RTL languages on OSX are incorrectly laid out, (i.e. >> the letters are reversely presented). >> >> Fix: >> Skip font tables for RTL languages on OSX platform. >> >> Thanks, >> Dmitry >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Tue Sep 4 10:11:14 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 4 Sep 2018 11:11:14 +0100 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com> References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com> Message-ID: Hi Brian/Goetz, Yes, that seems sensible. I have created a new webrev with fdlibm compiler option disabled, and mediaLib code fixed: http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. Are we good to go? Thanks Andrew hg export: # HG changeset patch # User aleonard # Date 1536055438 -3600 # Tue Sep 04 11:03:58 2018 +0100 # Node ID c2523f285c503e8f82f1212b38de1cb54093255e # Parent 3ee91722550680c18b977f0e00b1013323b5c9ef 8209786: JDK12 fails to build on s390x with gcc 7.3 diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk --- a/make/lib/CoreLibraries.gmk Tue Sep 04 14:47:55 2018 +0800 +++ b/make/lib/CoreLibraries.gmk Tue Sep 04 11:03:58 2018 +0100 @@ -68,7 +68,7 @@ CFLAGS_linux_ppc64le := -ffp-contract=off, \ CFLAGS_linux_s390x := -ffp-contract=off, \ CFLAGS_linux_aarch64 := -ffp-contract=off, \ - DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \ + DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-bounds, \ DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ ARFLAGS := $(ARFLAGS), \ OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \ diff -r 3ee917225506 -r c2523f285c50 src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c Tue Sep 04 14:47:55 2018 +0800 +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c Tue Sep 04 11:03:58 2018 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -259,18 +259,18 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); #else - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask); #else /* _NO_LONGLONG */ #ifdef _LITTLE_ENDIAN - mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); + mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); #else - mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); + mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | (((mlib_u64*)da)[0] &~ emask); @@ -395,9 +395,9 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); #else - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); @@ -413,9 +413,9 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); + emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); #else - emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); + emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); @@ -565,9 +565,9 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); #else - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ da[0] = (dd & emask) | (da[0] &~ emask); } Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Brian Burkhalter To: Magnus Ihse Bursie Cc: Andrew Leonard , "Lindenmaier, Goetz" , 2d-dev <2d-dev at openjdk.java.net>, build-dev , core-libs-dev , Philip Race Date: 31/08/2018 15:44 Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" ? Note that this decision can be different for the two libraries. I'd argue that the maintainer of each library decides. And if so, it seems to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image. I think we can safely say ?disable compiler errors? for fdlibm as indicated by Joe Darcy?s comment in the issue (he owns fdlibm), and source code change for mediaLib as Phil indicated in e-mail. Thanks, Brian 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 magnus.ihse.bursie at oracle.com Tue Sep 4 15:38:45 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Sep 2018 17:38:45 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com> Message-ID: <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com> Looks good to me. /Magnus > 4 sep. 2018 kl. 12:11 skrev Andrew Leonard : > > Hi Brian/Goetz, > Yes, that seems sensible. I have created a new webrev with fdlibm compiler option disabled, and mediaLib code fixed: > http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ > I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. > > Are we good to go? > Thanks > Andrew > > hg export: > # HG changeset patch > # User aleonard > # Date 1536055438 -3600 > # Tue Sep 04 11:03:58 2018 +0100 > # Node ID c2523f285c503e8f82f1212b38de1cb54093255e > # Parent 3ee91722550680c18b977f0e00b1013323b5c9ef > 8209786: JDK12 fails to build on s390x with gcc 7.3 > > diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Tue Sep 04 14:47:55 2018 +0800 > +++ b/make/lib/CoreLibraries.gmk Tue Sep 04 11:03:58 2018 +0100 > @@ -68,7 +68,7 @@ > CFLAGS_linux_ppc64le := -ffp-contract=off, \ > CFLAGS_linux_s390x := -ffp-contract=off, \ > CFLAGS_linux_aarch64 := -ffp-contract=off, \ > - DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \ > + DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-bounds, \ > DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ > ARFLAGS := $(ARFLAGS), \ > OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \ > diff -r 3ee917225506 -r c2523f285c50 src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c > --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c Tue Sep 04 14:47:55 2018 +0800 > +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c Tue Sep 04 11:03:58 2018 +0100 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -259,18 +259,18 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); > #else > - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask); > > #else /* _NO_LONGLONG */ > > #ifdef _LITTLE_ENDIAN > - mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); > + mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); > #else > - mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); > + mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > > ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | (((mlib_u64*)da)[0] &~ emask); > @@ -395,9 +395,9 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); > #else > - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); > > @@ -413,9 +413,9 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); > + emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); > #else > - emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); > + emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); > > @@ -565,9 +565,9 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); > #else > - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > da[0] = (dd & emask) | (da[0] &~ emask); > } > > > > > > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Brian Burkhalter > To: Magnus Ihse Bursie > Cc: Andrew Leonard , "Lindenmaier, Goetz" , 2d-dev <2d-dev at openjdk.java.net>, build-dev , core-libs-dev , Philip Race > Date: 31/08/2018 15:44 > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux > > > > > On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie wrote: > > Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" ? > > Note that this decision can be different for the two libraries. I'd argue that the maintainer of each library decides. And if so, it seems to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image. > > I think we can safely say ?disable compiler errors? for fdlibm as indicated by Joe Darcy?s comment in the issue (he owns fdlibm), and source code change for mediaLib as Phil indicated in e-mail. > > Thanks, > > Brian > > > > 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 Sep 4 19:34:19 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 4 Sep 2018 12:34:19 -0700 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: References: Message-ID: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> I see you noticed the problem with it not necessarily being an AAT font. It seems this method is a copy/paste of the method added in JDK 9. So this will work but looking at it, I think in JDK 9 I should have made this more efficient. Probably it was a detail in the larger work, that I never came back to. On MacOS where it calls through the PhysicalFont interface, since CFont is not a TrueTypeFont, it will be retrieving all the data in the table from native to Java on every call to layout. That will be expensive. You can mitigate this in your case by reversing the order here + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { to + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { So it will only take the hit for RTL text which will save a lot of cases ... I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 which I will fix for 12. Up to you whether you also want to wait for that fix, or just update as I have suggested and maybe take a follow-on fix later. Note that whilst your fix will at least make sure text reads in the correct direction, it means it will be using default built-in shaping rules of ICU and so may miss at least some features provided by the font. -phil. On 09/03/2018 05:54 AM, Dmitry Markov wrote: > Hi Prasanta, > > Thank you for the feedback. I missed the usage of OSX specific class > in shared code for some reasons. Please find the updated webrev here: > http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ > > I replaced the usage of CFont with a new private method which tests > either a font is AAT or not. > > The issue is jdk8u (ICU) specific. It does not take place on jdk12 > because starting from jdk9 we use Harfbuzz as default layout engine. > > Thanks, > Dmitry > >> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan >> > > wrote: >> >> Hi Dmitry, >> >> Not going into technicalities of the fix, but it seems it will break >> non-macos build as you are checking for CFont in a shared class? >> Also, if it's the issue still exists, then why you are fixing only in >> 8u and not in jdk12? >> >> Regards >> Prasanta >> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>> Hello, >>> >>> Could you review a fix for jdk8u, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>> >>> >>> Problem description: >>> The fix for 7162125 [1] enabled font tables processing on OSX. >>> However there is a lack of support for RTL languages in ICU layout >>> engine. Quote from ICU guide: ??The AAT processing in the >>> LayoutEngine is relatively basic as it only applies the default >>> features in left-to-right text. This processing has been tested for >>> Devanagari text. Since AAT processing is not script-specific, it >>> might not work for other scripts??, more details at >>> http://userguide.icu-project.org/layoutengine >>> As a result all RTL languages on OSX are incorrectly laid out, (i.e. >>> the letters are reversely presented). >>> >>> Fix: >>> Skip font tables for RTL languages on OSX platform. >>> >>> Thanks, >>> Dmitry >>> >>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Tue Sep 4 20:45:42 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 4 Sep 2018 22:45:42 +0200 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors Message-ID: Please review this bug fix for the Marlin renderer (introduced in 10): JBS: https://bugs.openjdk.java.net/browse/JDK-8210335 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8210335.0/ Changes: - clipping rectangle is adjusted to take into account the inverse transform (scale/shear) - MarlinRenderingEngine: prepare once the clip with small margin + renderer offset - TransformingPathConsumer2D: - missing min < max in adjustClipScale() if scale < 0 - compute mean inverse scale factor to be used in CurveClipSplitter to perform proper length checks to avoid too many subdivision PS: What is the process to ask for backport to JDK11 updates ? Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 5 00:40:29 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 04 Sep 2018 17:40:29 -0700 Subject: [OpenJDK 2D-Dev] RFR: 7017058: Malayalam glyph substitution is failing for Malayalam with Windows Kartika font. Message-ID: <5B8F25FD.1000606@oracle.com> This fixes 3 submitted bugs https://bugs.openjdk.java.net/browse/JDK-7017058 : the Malayalam bug above And also https://bugs.openjdk.java.net/browse/JDK-8191130 : Sinhala text rendering problem with C+VIRAMA+ZWJ+RA/YA+V and https://bugs.openjdk.java.net/browse/JDK-8195836: opentype:Bengali: "Khanda Ta" shaping issue with U+09A4 TA, U+09CD virama, U+200D ZWJ Webrev: http://cr.openjdk.java.net/~prr/7017058/ As discussed in the evaluation of 7017058, this is because of some code which always maps several unicode formatting characters to the invisible glyph to ensure it is never rendered as a missing glyph box. But if the opentype tables in a font have glyph substitution looks ups that depend on that font's actual mapping of those glyphs then they are broken. We have had several reports of this (above) and also complaints this breaks Emoji family ligature substitution. The fix changes this to first consult the font to see if it does map these codepoints. If it does not then we still will map to the empty glyph in which case clearly the font can't have any lookup that depends on it. The variable origCharCode is added because several of the methods mutate charCode and we avoid risk with this approach. The tab, NL and CR code points are still always mapped to the empty glyph since they are never going to be used by layout in this way and some fonts map TAB to a space char which is not what we want. -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Wed Sep 5 11:27:45 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 5 Sep 2018 12:27:45 +0100 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> References: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> Message-ID: Hi Phil, Thank you for the comments. You are right the invocation of isAAT() method might be too expensive especially on OSX. I have changed the if-statement as you suggested. Please find the new webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ Also I will be happy to port the fix for JDK-8210384 to 8u once it is ready. Thanks, Dmitry > On 4 Sep 2018, at 20:34, Phil Race wrote: > > I see you noticed the problem with it not necessarily being an AAT font. > It seems this method is a copy/paste of the method added in JDK 9. > So this will work but looking at it, I think in JDK 9 I should have made this more efficient. > Probably it was a detail in the larger work, that I never came back to. > On MacOS where it calls through the PhysicalFont interface, since CFont is not a TrueTypeFont, > it will be retrieving all the data in the table from native to Java on every call to layout. That will be expensive. > > You can mitigate this in your case by reversing the order here > + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { > > to > + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { > > So it will only take the hit for RTL text which will save a lot of cases ... > I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 which I will fix for 12. > > Up to you whether you also want to wait for that fix, or just update as I have suggested > and maybe take a follow-on fix later. > > Note that whilst your fix will at least make sure text reads in the correct direction, it > means it will be using default built-in shaping rules of ICU and so may miss at least > some features provided by the font. > > -phil. > > On 09/03/2018 05:54 AM, Dmitry Markov wrote: >> Hi Prasanta, >> >> Thank you for the feedback. I missed the usage of OSX specific class in shared code for some reasons. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ >> I replaced the usage of CFont with a new private method which tests either a font is AAT or not. >> >> The issue is jdk8u (ICU) specific. It does not take place on jdk12 because starting from jdk9 we use Harfbuzz as default layout engine. >> >> Thanks, >> Dmitry >> >>> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan > wrote: >>> >>> Hi Dmitry, >>> Not going into technicalities of the fix, but it seems it will break non-macos build as you are checking for CFont in a shared class? >>> Also, if it's the issue still exists, then why you are fixing only in 8u and not in jdk12? >>> >>> Regards >>> Prasanta >>> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>>> Hello, >>>> >>>> Could you review a fix for jdk8u, please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>>> >>>> Problem description: >>>> The fix for 7162125 [1] enabled font tables processing on OSX. However there is a lack of support for RTL languages in ICU layout engine. Quote from ICU guide: ??The AAT processing in the LayoutEngine is relatively basic as it only applies the default features in left-to-right text. This processing has been tested for Devanagari text. Since AAT processing is not script-specific, it might not work for other scripts??, more details at http://userguide.icu-project.org/layoutengine >>>> As a result all RTL languages on OSX are incorrectly laid out, (i.e. the letters are reversely presented). >>>> >>>> Fix: >>>> Skip font tables for RTL languages on OSX platform. >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 5 23:39:22 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 05 Sep 2018 16:39:22 -0700 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: References: Message-ID: <5B90692A.2070302@oracle.com> This looks good to me. I've run all our automated tests + done some manual testing as well as building on all platforms and reviewing the source changes. > PS: What is the process to ask for backport to JDK11 updates ? If you think this important enough to backport, then this is the process : http://openjdk.java.net/projects/jdk-updates/approval.html -phil. On 9/4/18, 1:45 PM, Laurent Bourg?s wrote: > Please review this bug fix for the Marlin renderer (introduced in 10): > JBS: https://bugs.openjdk.java.net/browse/JDK-8210335 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8210335.0/ > > > Changes: > - clipping rectangle is adjusted to take into account the inverse > transform (scale/shear) > - MarlinRenderingEngine: prepare once the clip with small margin + > renderer offset > - TransformingPathConsumer2D: > - missing min < max in adjustClipScale() if scale < 0 > - compute mean inverse scale factor to be used in CurveClipSplitter > to perform proper length checks to avoid too many subdivision > > PS: What is the process to ask for backport to JDK11 updates ? > > Cheers, > Laurent From bourges.laurent at gmail.com Thu Sep 6 07:31:35 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 6 Sep 2018 09:31:35 +0200 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: <5B90692A.2070302@oracle.com> References: <5B90692A.2070302@oracle.com> Message-ID: Phil, Thanks for your review. Le jeu. 6 sept. 2018 ? 01:39, Philip Race a ?crit : > This looks good to me. > I've run all our automated tests + done some manual testing > as well as building on all platforms and reviewing the source changes. > Do you have more closed-source tests that could be opened in OpenJDK ? > > > PS: What is the process to ask for backport to JDK11 updates ? > > If you think this important enough to backport, then this is the process : > > http://openjdk.java.net/projects/jdk-updates/approval.html I fixed these bugs as I was contacted on the Marlin mailing list by an end user testing the migration of its Map viewer app from jdk8 to OpenJDK11. I made this patch as small as possible that is compatible with OpenJDK 11/12 and is well tested: low risk. For 12, I will propose a more important patch later to upgrade to Marlin 0.9.3 As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it is worth fixing it in 11 too. Any other opinion ? PS: I will fix OpenJFX 11/12 soon Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Thu Sep 6 10:29:27 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 6 Sep 2018 11:29:27 +0100 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com> References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com> <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com> Message-ID: Thanks Magnus, Hi Goetz, we have agreement from both library owners, so I think we're good now? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Magnus Ihse Bursie To: Andrew Leonard Cc: Brian Burkhalter , 2d-dev <2d-dev at openjdk.java.net>, build-dev , core-libs-dev , "Lindenmaier, Goetz" , Philip Race Date: 04/09/2018 16:41 Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux Looks good to me. /Magnus 4 sep. 2018 kl. 12:11 skrev Andrew Leonard : Hi Brian/Goetz, Yes, that seems sensible. I have created a new webrev with fdlibm compiler option disabled, and mediaLib code fixed: http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. Are we good to go? Thanks Andrew hg export: # HG changeset patch # User aleonard # Date 1536055438 -3600 # Tue Sep 04 11:03:58 2018 +0100 # Node ID c2523f285c503e8f82f1212b38de1cb54093255e # Parent 3ee91722550680c18b977f0e00b1013323b5c9ef 8209786: JDK12 fails to build on s390x with gcc 7.3 diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk --- a/make/lib/CoreLibraries.gmk Tue Sep 04 14:47:55 2018 +0800 +++ b/make/lib/CoreLibraries.gmk Tue Sep 04 11:03:58 2018 +0100 @@ -68,7 +68,7 @@ CFLAGS_linux_ppc64le := -ffp-contract=off, \ CFLAGS_linux_s390x := -ffp-contract=off, \ CFLAGS_linux_aarch64 := -ffp-contract=off, \ - DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \ + DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-bounds, \ DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ ARFLAGS := $(ARFLAGS), \ OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \ diff -r 3ee917225506 -r c2523f285c50 src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c Tue Sep 04 14:47:55 2018 +0800 +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c Tue Sep 04 11:03:58 2018 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -259,18 +259,18 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); #else - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask); #else /* _NO_LONGLONG */ #ifdef _LITTLE_ENDIAN - mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); + mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); #else - mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); + mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | (((mlib_u64*)da)[0] &~ emask); @@ -395,9 +395,9 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); #else - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); @@ -413,9 +413,9 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); + emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); #else - emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); + emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); @@ -565,9 +565,9 @@ } #ifdef _LITTLE_ENDIAN - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); #else - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); #endif /* _LITTLE_ENDIAN */ da[0] = (dd & emask) | (da[0] &~ emask); } Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Brian Burkhalter To: Magnus Ihse Bursie Cc: Andrew Leonard , "Lindenmaier, Goetz" , 2d-dev <2d-dev at openjdk.java.net>, build-dev , core-libs-dev < core-libs-dev at openjdk.java.net>, Philip Race Date: 31/08/2018 15:44 Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" ? Note that this decision can be different for the two libraries. I'd argue that the maintainer of each library decides. And if so, it seems to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image. I think we can safely say ?disable compiler errors? for fdlibm as indicated by Joe Darcy?s comment in the issue (he owns fdlibm), and source code change for mediaLib as Phil indicated in e-mail. Thanks, Brian 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 goetz.lindenmaier at sap.com Thu Sep 6 11:02:14 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 6 Sep 2018 11:02:14 +0000 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com> <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com> Message-ID: Yes, that's fine. I can sponsor it tomorrow. I'm not in the office today. Best regards, Goetz. > -----Original Message----- > From: Andrew Leonard > Sent: Donnerstag, 6. September 2018 12:29 > To: Magnus Ihse Bursie ; Lindenmaier, Goetz > > Cc: 2d-dev <2d-dev at openjdk.java.net>; Brian Burkhalter > ; build-dev ; core- > libs-dev ; Philip Race > > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on > zLinux > > Thanks Magnus, > > Hi Goetz, we have agreement from both library owners, so I think we're good > now? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Magnus Ihse Bursie > To: Andrew Leonard > Cc: Brian Burkhalter , 2d-dev <2d- > dev at openjdk.java.net>, build-dev , core-libs-dev > , "Lindenmaier, Goetz" > , Philip Race > Date: 04/09/2018 16:41 > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on > zLinux > > ________________________________ > > > > > Looks good to me. > > /Magnus > > 4 sep. 2018 kl. 12:11 skrev Andrew Leonard >: > > Hi Brian/Goetz, > Yes, that seems sensible. I have created a new webrev with fdlibm compiler > option disabled, and mediaLib code fixed: > http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ > > I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. > > Are we good to go? > Thanks > Andrew > > hg export: > # HG changeset patch > # User aleonard > # Date 1536055438 -3600 > # Tue Sep 04 11:03:58 2018 +0100 > # Node ID c2523f285c503e8f82f1212b38de1cb54093255e > # Parent 3ee91722550680c18b977f0e00b1013323b5c9ef > 8209786: JDK12 fails to build on s390x with gcc 7.3 > > diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Tue Sep 04 14:47:55 2018 +0800 > +++ b/make/lib/CoreLibraries.gmk Tue Sep 04 11:03:58 2018 +0100 > @@ -68,7 +68,7 @@ > CFLAGS_linux_ppc64le := -ffp-contract=off, \ > CFLAGS_linux_s390x := -ffp-contract=off, \ > CFLAGS_linux_aarch64 := -ffp-contract=off, \ > - DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \ > + DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array- > bounds, \ > DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ > ARFLAGS := $(ARFLAGS), \ > OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \ > diff -r 3ee917225506 -r c2523f285c50 > src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c > --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c > Tue Sep 04 14:47:55 2018 +0800 > +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c > Tue Sep 04 11:03:58 2018 +0100 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -259,18 +259,18 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); > #else > - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask); > > #else /* _NO_LONGLONG */ > > #ifdef _LITTLE_ENDIAN > - mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); > + mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); > #else > - mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); > + mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > > ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | > (((mlib_u64*)da)[0] &~ emask); > @@ -395,9 +395,9 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); > #else > - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); > > @@ -413,9 +413,9 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); > + emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); > #else > - emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); > + emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); > > @@ -565,9 +565,9 @@ > } > > #ifdef _LITTLE_ENDIAN > - emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); > #else > - emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); > + emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); > #endif /* _LITTLE_ENDIAN */ > da[0] = (dd & emask) | (da[0] &~ emask); > } > > > > > > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > > From: Brian Burkhalter > > To: Magnus Ihse Bursie > > Cc: Andrew Leonard >, "Lindenmaier, Goetz" > >, 2d-dev > <2d-dev at openjdk.java.net >, build-dev > >, core-libs- > dev > >, Philip Race > > Date: 31/08/2018 15:44 > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on > zLinux > > ________________________________ > > > > > > On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie > > > wrote: > > Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" > ? > > Note that this decision can be different for the two libraries. I'd argue that the > maintainer of each library decides. And if so, it seems to be "compiler fix" for > libfdlibm, and "source fix" for libmlib_image. > > I think we can safely say ?disable compiler errors? for fdlibm as indicated by Joe > Darcy?s comment in the issue (he owns fdlibm), and source code change for > mediaLib as Phil indicated in e-mail. > > Thanks, > > Brian > > > > 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 philip.race at oracle.com Thu Sep 6 16:58:06 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 6 Sep 2018 09:58:06 -0700 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: References: <5B90692A.2070302@oracle.com> Message-ID: <5b60f435-a25a-4f90-00b4-c658454d2adf@oracle.com> On 09/06/2018 12:31 AM, Laurent Bourg?s wrote: > Phil, > Thanks for your review. > > Le jeu. 6 sept. 2018 ? 01:39, Philip Race > a ?crit : > > This looks good to me. > I've run all our automated tests + done some manual testing > as well as building on all platforms and reviewing the source changes. > > > Do you have more closed-source tests that could be opened in OpenJDK ? I ran the closed source tests not because there were critical tests there so much as it would be stupid not to when it is easier than not running them :-) There are still many client closed source test that could be open sourced although only a tiny fraction might be applicable here. We open source these as we find time .. > > > PS: What is the process to ask for backport to JDK11 updates ? > > If you think this important enough to backport, then this is the > process : > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > I fixed these bugs as I was contacted on the Marlin mailing list by an > end user testing the migration of its Map viewer app from jdk8 to > OpenJDK11. > > I made this patch as small as possible that is compatible with OpenJDK > 11/12 and is well tested: low risk. > For 12, I will propose a more important patch later to upgrade to > Marlin 0.9.3 > > As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think > it is worth fixing it in 11 too. > > Any other opinion ? I am fine with it. But it is the 11 updates maintainers who need to approve. -phil. > > PS: I will fix OpenJFX 11/12 soon > > Cheers, > Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Thu Sep 6 18:10:37 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 6 Sep 2018 20:10:37 +0200 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: <5b60f435-a25a-4f90-00b4-c658454d2adf@oracle.com> References: <5B90692A.2070302@oracle.com> <5b60f435-a25a-4f90-00b4-c658454d2adf@oracle.com> Message-ID: Another reviewer, please ? Le jeu. 6 sept. 2018 ? 18:59, Phil Race a ?crit : > > > On 09/06/2018 12:31 AM, Laurent Bourg?s wrote: > > Phil, > Thanks for your review. > > Le jeu. 6 sept. 2018 ? 01:39, Philip Race a > ?crit : > >> This looks good to me. >> I've run all our automated tests + done some manual testing >> as well as building on all platforms and reviewing the source changes. >> > > Do you have more closed-source tests that could be opened in OpenJDK ? > > > > I ran the closed source tests not because there were critical tests there > so much > as it would be stupid not to when it is easier than not running them :-) > > There are still many client closed source test that could be open sourced > although > only a tiny fraction might be applicable here. We open source these as we > find time .. > > > >> > PS: What is the process to ask for backport to JDK11 updates ? >> >> If you think this important enough to backport, then this is the process : >> >> http://openjdk.java.net/projects/jdk-updates/approval.html > > > I fixed these bugs as I was contacted on the Marlin mailing list by an end > user testing the migration of its Map viewer app from jdk8 to OpenJDK11. > > I made this patch as small as possible that is compatible with OpenJDK > 11/12 and is well tested: low risk. > For 12, I will propose a more important patch later to upgrade to Marlin > 0.9.3 > > As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it > is worth fixing it in 11 too. > > Any other opinion ? > > > I am fine with it. But it is the 11 updates maintainers who need to > approve. > > -phil. > > > PS: I will fix OpenJFX 11/12 soon > > Cheers, > Laurent > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat Sep 8 19:51:53 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 08 Sep 2018 12:51:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8210384: SunLayoutEngine.isAAT() font is expensive on MacOS Message-ID: <5B942859.6050302@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8210384 webrev: http://cr.openjdk.java.net/~prr/8210384/ AAT is the Apple alternative to OpenType layout. Calls to the Harfbuzz layout engine need to pass a flag which says whether the font is an AAT font because we need to set up transforms differently. It is also looking like it is needed for JDK 8 with ICU because of problems handling AAT fonts there. The current way of doing this via checking if there is a morx table is really expensive. So this fix adds a low-cost cache of the result. No regression test because it is a performance fix but I did check the effect. In a quick test rendering about 15 strings which broke up into 132 different runs, this reduced overall rendering time by 50% (and that includes the time to draw the glyphs, so it is an even bigger component of layout). -phil. From ebakke at ultorg.com Sat Sep 8 20:55:48 2018 From: ebakke at ultorg.com (Eirik Bakke) Date: Sat, 8 Sep 2018 20:55:48 +0000 Subject: [OpenJDK 2D-Dev] LineBreakMeasurer 7-70x slower on Java 10 compared to Java 8 Message-ID: Hi, 2D-dev. Switching from Java 1.8.0_172 to Java 10.0.2, at least on Windows 10, it has become very expensive to call LineBreakMeasurer.nextLayout--it takes about 0.8ms to render any string, even if it's just a single character. That's between 7 and 70(!) times slower than on Java 8, depending on how many strings you need to render. See the following performance test (my results pasted at the end): https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 This is a problem in our visualization app, which uses LineBreakMeasurer to produce a TextLayout once for every cell in a large spreadsheet-like data layout. Operations that were previously quick or instantaneous now introduce bad latencies in the user interface. I saw the related bug https://bugs.openjdk.java.net/browse/JDK-8186317 and its duplicate https://bugs.openjdk.java.net/browse/JDK-8196666, but they are both closed. Is this a known regression, and are there any plans to fix it? -- Eirik -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat Sep 8 22:02:57 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 08 Sep 2018 15:02:57 -0700 Subject: [OpenJDK 2D-Dev] LineBreakMeasurer 7-70x slower on Java 10 compared to Java 8 In-Reply-To: References: Message-ID: <5B944711.1070803@oracle.com> You missed https://bugs.openjdk.java.net/browse/JDK-8202131 It is on my to-do list .. -phil. On 9/8/18, 1:55 PM, Eirik Bakke wrote: > > Hi, 2D-dev. > > Switching from Java 1.8.0_172 to Java 10.0.2, at least on Windows 10, > it has become very expensive to call LineBreakMeasurer.nextLayout--it > takes about 0.8ms to render any string, even if it's just a single > character. That's between 7 and 70(!) times slower than on Java 8, > depending on how many strings you need to render. See the following > performance test (my results pasted at the end): > > https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 > > This is a problem in our visualization app, which uses > LineBreakMeasurer to produce a TextLayout once for every cell in a > large spreadsheet-like data layout. Operations that were previously > quick or instantaneous now introduce bad latencies in the user interface. > > I saw the related bug https://bugs.openjdk.java.net/browse/JDK-8186317 > and its duplicate https://bugs.openjdk.java.net/browse/JDK-8196666, > but they are both closed. > > Is this a known regression, and are there any plans to fix it? > > -- Eirik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebakke at ultorg.com Sun Sep 9 00:23:30 2018 From: ebakke at ultorg.com (Eirik Bakke) Date: Sun, 9 Sep 2018 00:23:30 +0000 Subject: [OpenJDK 2D-Dev] LineBreakMeasurer 7-70x slower on Java 10 compared to Java 8 In-Reply-To: References: <5B944711.1070803@oracle.com> Message-ID: Ah, yes, I missed that one--thank you! Great to hear. (Otherwise very happy to get a shiny new font shaping engine in Java--thanks for your efforts!) -- Eirik From: Philip Race Sent: Saturday, September 8, 2018 6:03 PM To: Eirik Bakke Cc: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] LineBreakMeasurer 7-70x slower on Java 10 compared to Java 8 You missed https://bugs.openjdk.java.net/browse/JDK-8202131 It is on my to-do list .. -phil. On 9/8/18, 1:55 PM, Eirik Bakke wrote: Hi, 2D-dev. Switching from Java 1.8.0_172 to Java 10.0.2, at least on Windows 10, it has become very expensive to call LineBreakMeasurer.nextLayout--it takes about 0.8ms to render any string, even if it's just a single character. That's between 7 and 70(!) times slower than on Java 8, depending on how many strings you need to render. See the following performance test (my results pasted at the end): https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 This is a problem in our visualization app, which uses LineBreakMeasurer to produce a TextLayout once for every cell in a large spreadsheet-like data layout. Operations that were previously quick or instantaneous now introduce bad latencies in the user interface. I saw the related bug https://bugs.openjdk.java.net/browse/JDK-8186317 and its duplicate https://bugs.openjdk.java.net/browse/JDK-8196666, but they are both closed. Is this a known regression, and are there any plans to fix it? -- Eirik -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Sun Sep 9 02:57:39 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Sun, 9 Sep 2018 08:27:39 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8210384: SunLayoutEngine.isAAT() font is expensive on MacOS In-Reply-To: <5B942859.6050302@oracle.com> References: <5B942859.6050302@oracle.com> Message-ID: Looks good to me! Thanks Krishna > On 09-Sep-2018, at 1:21 AM, Philip Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8210384 > webrev: http://cr.openjdk.java.net/~prr/8210384/ > > AAT is the Apple alternative to OpenType layout. > > Calls to the Harfbuzz layout engine need to pass a flag which says whether the font is an AAT font > because we need to set up transforms differently. It is also looking like it is needed for JDK 8 > with ICU because of problems handling AAT fonts there. > The current way of doing this via checking if there is a morx table is really expensive. > So this fix adds a low-cost cache of the result. > No regression test because it is a performance fix but I did check the effect. > In a quick test rendering about 15 strings which broke up into 132 different runs, > this reduced overall rendering time by 50% (and that includes the time to draw the glyphs, > so it is an even bigger component of layout). > > -phil. > > > > From dmitry.markov at oracle.com Sun Sep 9 09:55:59 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sun, 9 Sep 2018 10:55:59 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8210384: SunLayoutEngine.isAAT() font is expensive on MacOS In-Reply-To: <5B942859.6050302@oracle.com> References: <5B942859.6050302@oracle.com> Message-ID: The fix looks good to me. These changes will be useful for JDK 8u too. So I will back-port them once https://bugs.openjdk.java.net/browse/JDK-8201801 is integrated. Thanks, Dmitry > On 8 Sep 2018, at 20:51, Philip Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8210384 > webrev: http://cr.openjdk.java.net/~prr/8210384/ > > AAT is the Apple alternative to OpenType layout. > > Calls to the Harfbuzz layout engine need to pass a flag which says whether the font is an AAT font > because we need to set up transforms differently. It is also looking like it is needed for JDK 8 > with ICU because of problems handling AAT fonts there. > The current way of doing this via checking if there is a morx table is really expensive. > So this fix adds a low-cost cache of the result. > No regression test because it is a performance fix but I did check the effect. > In a quick test rendering about 15 strings which broke up into 132 different runs, > this reduced overall rendering time by 50% (and that includes the time to draw the glyphs, > so it is an even bigger component of layout). > > -phil. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Mon Sep 10 08:18:17 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 10 Sep 2018 09:18:17 +0100 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: References: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> Message-ID: <46845D7E-036A-49CD-8D61-A735293AEA5A@oracle.com> Phil, Prasanta, Any thoughts/concerns regarding the latest webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ Thanks, Dmitry > On 5 Sep 2018, at 12:27, Dmitry Markov wrote: > > Hi Phil, > > Thank you for the comments. You are right the invocation of isAAT() method might be too expensive especially on OSX. I have changed the if-statement as you suggested. Please find the new webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ > > Also I will be happy to port the fix for JDK-8210384 to 8u once it is ready. > > Thanks, > Dmitry > >> On 4 Sep 2018, at 20:34, Phil Race > wrote: >> >> I see you noticed the problem with it not necessarily being an AAT font. >> It seems this method is a copy/paste of the method added in JDK 9. >> So this will work but looking at it, I think in JDK 9 I should have made this more efficient. >> Probably it was a detail in the larger work, that I never came back to. >> On MacOS where it calls through the PhysicalFont interface, since CFont is not a TrueTypeFont, >> it will be retrieving all the data in the table from native to Java on every call to layout. That will be expensive. >> >> You can mitigate this in your case by reversing the order here >> + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { >> >> to >> + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { >> >> So it will only take the hit for RTL text which will save a lot of cases ... >> I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 which I will fix for 12. >> >> Up to you whether you also want to wait for that fix, or just update as I have suggested >> and maybe take a follow-on fix later. >> >> Note that whilst your fix will at least make sure text reads in the correct direction, it >> means it will be using default built-in shaping rules of ICU and so may miss at least >> some features provided by the font. >> >> -phil. >> >> On 09/03/2018 05:54 AM, Dmitry Markov wrote: >>> Hi Prasanta, >>> >>> Thank you for the feedback. I missed the usage of OSX specific class in shared code for some reasons. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ >>> I replaced the usage of CFont with a new private method which tests either a font is AAT or not. >>> >>> The issue is jdk8u (ICU) specific. It does not take place on jdk12 because starting from jdk9 we use Harfbuzz as default layout engine. >>> >>> Thanks, >>> Dmitry >>> >>>> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan > wrote: >>>> >>>> Hi Dmitry, >>>> Not going into technicalities of the fix, but it seems it will break non-macos build as you are checking for CFont in a shared class? >>>> Also, if it's the issue still exists, then why you are fixing only in 8u and not in jdk12? >>>> >>>> Regards >>>> Prasanta >>>> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>>>> Hello, >>>>> >>>>> Could you review a fix for jdk8u, please? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>>>> >>>>> Problem description: >>>>> The fix for 7162125 [1] enabled font tables processing on OSX. However there is a lack of support for RTL languages in ICU layout engine. Quote from ICU guide: ??The AAT processing in the LayoutEngine is relatively basic as it only applies the default features in left-to-right text. This processing has been tested for Devanagari text. Since AAT processing is not script-specific, it might not work for other scripts??, more details at http://userguide.icu-project.org/layoutengine >>>>> As a result all RTL languages on OSX are incorrectly laid out, (i.e. the letters are reversely presented). >>>>> >>>>> Fix: >>>>> Skip font tables for RTL languages on OSX platform. >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Sep 11 00:56:20 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Sep 2018 17:56:20 -0700 Subject: [OpenJDK 2D-Dev] RFR: 7017058: Malayalam glyph substitution is failing for Malayalam with Windows Kartika font. In-Reply-To: <5B8F25FD.1000606@oracle.com> References: <5B8F25FD.1000606@oracle.com> Message-ID: <8ef6402b-b8cb-cb02-73c8-dff8eba87818@oracle.com> Looks fine. On 04/09/2018 17:40, Philip Race wrote: > This fixes 3 submitted bugs > https://bugs.openjdk.java.net/browse/JDK-7017058 : the Malayalam bug above > And also > https://bugs.openjdk.java.net/browse/JDK-8191130 : > Sinhala text rendering problem with C+VIRAMA+ZWJ+RA/YA+V > and > https://bugs.openjdk.java.net/browse/JDK-8195836: > opentype:Bengali: "Khanda Ta" shaping issue with U+09A4 TA, U+09CD > virama, U+200D ZWJ > > Webrev: http://cr.openjdk.java.net/~prr/7017058/ > > As discussed in the evaluation of 7017058, this is because of some code > which > always maps several unicode formatting characters to the invisible glyph to > ensure it is never rendered as a missing glyph box. > But if the opentype tables in a font have glyph substitution looks ups that > depend on that font's actual mapping of those glyphs then they are broken. > We have had several reports of this (above) and also complaints this breaks > Emoji family ligature substitution. > > The fix changes this to first consult the font to see if it does map > these codepoints. > If it does not then we still will map to the empty glyph in which case > clearly the > font can't have any lookup that depends on it. > > The variable origCharCode is added because several of the methods mutate > charCode > and we avoid risk with this approach. > > The tab, NL and CR code points are still always mapped to the empty glyph > since they are never going to be used by layout in this way and some fonts > map TAB to a space char which is not what we want. > > -phil. > > -- Best regards, Sergey. From bourges.laurent at gmail.com Tue Sep 11 06:55:31 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 11 Sep 2018 08:55:31 +0200 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: References: <5B90692A.2070302@oracle.com> Message-ID: Hi, Can I have a second review, please ? I would like to make a jdk11 updates fix request asap... Laurent Le jeu. 6 sept. 2018 ? 09:31, Laurent Bourg?s a ?crit : > Phil, > Thanks for your review. > > Le jeu. 6 sept. 2018 ? 01:39, Philip Race a > ?crit : > >> This looks good to me. >> I've run all our automated tests + done some manual testing >> as well as building on all platforms and reviewing the source changes. >> > > Do you have more closed-source tests that could be opened in OpenJDK ? > >> >> > PS: What is the process to ask for backport to JDK11 updates ? >> >> If you think this important enough to backport, then this is the process : >> >> http://openjdk.java.net/projects/jdk-updates/approval.html > > > I fixed these bugs as I was contacted on the Marlin mailing list by an end > user testing the migration of its Map viewer app from jdk8 to OpenJDK11. > > I made this patch as small as possible that is compatible with OpenJDK > 11/12 and is well tested: low risk. > For 12, I will propose a more important patch later to upgrade to Marlin > 0.9.3 > > As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it > is worth fixing it in 11 too. > > Any other opinion ? > > PS: I will fix OpenJFX 11/12 soon > > Cheers, > Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Sep 11 16:57:38 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 11 Sep 2018 09:57:38 -0700 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: <46845D7E-036A-49CD-8D61-A735293AEA5A@oracle.com> References: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> <46845D7E-036A-49CD-8D61-A735293AEA5A@oracle.com> Message-ID: <301051a7-ea26-e08a-326c-183c21617415@oracle.com> fine by me. -phil. On 9/10/2018 1:18 AM, Dmitry Markov wrote: > Phil, Prasanta, > > Any thoughts/concerns regarding the latest webrev: > http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ > > > Thanks, > Dmitry > >> On 5 Sep 2018, at 12:27, Dmitry Markov > > wrote: >> >> Hi Phil, >> >> Thank you for the comments. You are right the invocation of isAAT() >> method might be too expensive especially on OSX. I have changed the >> if-statement as you suggested. Please find the new webrev here: >> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >> >> >> Also I will be happy to port the fix for JDK-8210384 to 8u once it is >> ready. >> >> Thanks, >> Dmitry >> >>> On 4 Sep 2018, at 20:34, Phil Race >> > wrote: >>> >>> I see you noticed the problem with it not necessarily being an AAT font. >>> It seems this method is a copy/paste of the method added in JDK 9. >>> So this will work but looking at it, I think in JDK 9 I should have >>> made this more efficient. >>> Probably it was a detail in the larger work, that I never came back to. >>> On MacOS where it calls through the PhysicalFont interface, since >>> CFont is not a TrueTypeFont, >>> it will be retrieving all the data in the table from native to Java >>> on every call to layout. That will be expensive. >>> >>> You can mitigate this in your case by reversing the order here >>> + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { >>> >>> to >>> + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { >>> >>> So it will only take the hit for RTL text which will save a lot of >>> cases? ... >>> I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 which >>> I will fix for 12. >>> >>> Up to you whether you also want to wait for that fix, or just update >>> as I have suggested >>> and maybe take a follow-on fix later. >>> >>> Note that whilst your fix will at least make sure text reads in the >>> correct direction, it >>> means it will be using default built-in shaping rules of ICU and so >>> may miss at least >>> some features provided by the font. >>> >>> -phil. >>> >>> On 09/03/2018 05:54 AM, Dmitry Markov wrote: >>>> Hi Prasanta, >>>> >>>> Thank you for the feedback. I missed the usage of OSX specific >>>> class in shared code for some reasons. Please find the updated >>>> webrev here: >>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ >>>> >>>> I replaced the usage of CFont with a new private method which tests >>>> either a font is AAT or not. >>>> >>>> The issue is jdk8u (ICU) specific. It does not take place on jdk12 >>>> because starting from jdk9 we use Harfbuzz as default layout engine. >>>> >>>> Thanks, >>>> Dmitry >>>> >>>>> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan >>>>> >>>> > wrote: >>>>> >>>>> Hi Dmitry, >>>>> >>>>> Not going into technicalities of the fix, but it seems it will >>>>> break non-macos build as you are checking for CFont in a shared class? >>>>> Also, if it's the issue still exists, then why you are fixing only >>>>> in 8u and not in jdk12? >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you review a fix for jdk8u, please? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>>>>> >>>>>> >>>>>> Problem description: >>>>>> The fix for 7162125 [1] enabled font tables processing on OSX. >>>>>> However there is a lack of support for RTL languages in ICU >>>>>> layout engine. Quote from ICU guide: ??The AAT processing in the >>>>>> LayoutEngine is relatively basic as it only applies the default >>>>>> features in left-to-right text. This processing has been tested >>>>>> for Devanagari text. Since AAT processing is not script-specific, >>>>>> it might not work for other scripts??, more details at >>>>>> http://userguide.icu-project.org/layoutengine >>>>>> As a result all RTL languages on OSX are incorrectly laid out, >>>>>> (i.e. the letters are reversely presented). >>>>>> >>>>>> Fix: >>>>>> Skip font tables for RTL languages on OSX platform. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >>>>> >>>> >>> >> > From prasanta.sadhukhan at oracle.com Wed Sep 12 06:09:52 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 12 Sep 2018 11:39:52 +0530 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: <301051a7-ea26-e08a-326c-183c21617415@oracle.com> References: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> <46845D7E-036A-49CD-8D61-A735293AEA5A@oracle.com> <301051a7-ea26-e08a-326c-183c21617415@oracle.com> Message-ID: <27444f38-1919-9e6d-2d6f-7be34c41e5ae@oracle.com> I guess we could check for if (((typo_flags & 0x80000000) != 0) && isAAT(font)) before and could save on calling font.getLayoutTableCache() In present condition, it overwrites layoutTables to 0 making calling getLayoutTableCache meaningless. Maybe , do something like long layoutTables = 0; if !(((typo_flags & 0x80000000) != 0) && isAAT(font)) { layoutTables = font.getLayoutTableCache(); } BTW, please correct the indentation of l156 and l160. Regards Prasanta On 11-Sep-18 10:27 PM, Phil Race wrote: > fine by me. > > -phil. > > On 9/10/2018 1:18 AM, Dmitry Markov wrote: >> Phil, Prasanta, >> >> Any thoughts/concerns regarding the latest webrev: >> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >> >> >> Thanks, >> Dmitry >> >>> On 5 Sep 2018, at 12:27, Dmitry Markov >> > wrote: >>> >>> Hi Phil, >>> >>> Thank you for the comments. You are right the invocation of isAAT() >>> method might be too expensive especially on OSX. I have changed the >>> if-statement as you suggested. Please find the new webrev here: >>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >>> >>> >>> Also I will be happy to port the fix for JDK-8210384 to 8u once it >>> is ready. >>> >>> Thanks, >>> Dmitry >>> >>>> On 4 Sep 2018, at 20:34, Phil Race >>> > wrote: >>>> >>>> I see you noticed the problem with it not necessarily being an AAT >>>> font. >>>> It seems this method is a copy/paste of the method added in JDK 9. >>>> So this will work but looking at it, I think in JDK 9 I should have >>>> made this more efficient. >>>> Probably it was a detail in the larger work, that I never came back >>>> to. >>>> On MacOS where it calls through the PhysicalFont interface, since >>>> CFont is not a TrueTypeFont, >>>> it will be retrieving all the data in the table from native to Java >>>> on every call to layout. That will be expensive. >>>> >>>> You can mitigate this in your case by reversing the order here >>>> + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { >>>> >>>> to >>>> + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { >>>> >>>> So it will only take the hit for RTL text which will save a lot of >>>> cases? ... >>>> I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 which >>>> I will fix for 12. >>>> >>>> Up to you whether you also want to wait for that fix, or just >>>> update as I have suggested >>>> and maybe take a follow-on fix later. >>>> >>>> Note that whilst your fix will at least make sure text reads in the >>>> correct direction, it >>>> means it will be using default built-in shaping rules of ICU and so >>>> may miss at least >>>> some features provided by the font. >>>> >>>> -phil. >>>> >>>> On 09/03/2018 05:54 AM, Dmitry Markov wrote: >>>>> Hi Prasanta, >>>>> >>>>> Thank you for the feedback. I missed the usage of OSX specific >>>>> class in shared code for some reasons. Please find the updated >>>>> webrev here: >>>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ >>>>> >>>>> I replaced the usage of CFont with a new private method which >>>>> tests either a font is AAT or not. >>>>> >>>>> The issue is jdk8u (ICU) specific. It does not take place on jdk12 >>>>> because starting from jdk9 we use Harfbuzz as default layout engine. >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>>> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi Dmitry, >>>>>> >>>>>> Not going into technicalities of the fix, but it seems it will >>>>>> break non-macos build as you are checking for CFont in a shared >>>>>> class? >>>>>> Also, if it's the issue still exists, then why you are fixing >>>>>> only in 8u and not in jdk12? >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you review a fix for jdk8u, please? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Problem description: >>>>>>> The fix for 7162125 [1] enabled font tables processing on OSX. >>>>>>> However there is a lack of support for RTL languages in ICU >>>>>>> layout engine. Quote from ICU guide: ??The AAT processing in the >>>>>>> LayoutEngine is relatively basic as it only applies the default >>>>>>> features in left-to-right text. This processing has been tested >>>>>>> for Devanagari text. Since AAT processing is not >>>>>>> script-specific, it might not work for other scripts??, more >>>>>>> details at http://userguide.icu-project.org/layoutengine >>>>>>> As a result all RTL languages on OSX are incorrectly laid out, >>>>>>> (i.e. the letters are reversely presented). >>>>>>> >>>>>>> Fix: >>>>>>> Skip font tables for RTL languages on OSX platform. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Wed Sep 12 14:27:58 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 12 Sep 2018 15:27:58 +0100 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: <27444f38-1919-9e6d-2d6f-7be34c41e5ae@oracle.com> References: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> <46845D7E-036A-49CD-8D61-A735293AEA5A@oracle.com> <301051a7-ea26-e08a-326c-183c21617415@oracle.com> <27444f38-1919-9e6d-2d6f-7be34c41e5ae@oracle.com> Message-ID: Hi Prasanta, I have updated the fix based on your recommendations. The new webrev is located at http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.03/ Thanks, Dmitry > On 12 Sep 2018, at 07:09, Prasanta Sadhukhan wrote: > > I guess we could check for > > if (((typo_flags & 0x80000000) != 0) && isAAT(font)) > before and could save on calling > > font.getLayoutTableCache() > In present condition, it overwrites layoutTables to 0 making calling getLayoutTableCache meaningless. Maybe , do something like > long layoutTables = 0; > if !(((typo_flags & 0x80000000) != 0) && isAAT(font)) { > layoutTables = font.getLayoutTableCache(); > } > BTW, please correct the indentation of l156 and l160. > Regards > Prasanta > On 11-Sep-18 10:27 PM, Phil Race wrote: >> fine by me. >> >> -phil. >> >> On 9/10/2018 1:18 AM, Dmitry Markov wrote: >>> Phil, Prasanta, >>> >>> Any thoughts/concerns regarding the latest webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >>> >>> Thanks, >>> Dmitry >>> >>>> On 5 Sep 2018, at 12:27, Dmitry Markov > wrote: >>>> >>>> Hi Phil, >>>> >>>> Thank you for the comments. You are right the invocation of isAAT() method might be too expensive especially on OSX. I have changed the if-statement as you suggested. Please find the new webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >>>> >>>> Also I will be happy to port the fix for JDK-8210384 to 8u once it is ready. >>>> >>>> Thanks, >>>> Dmitry >>>> >>>>> On 4 Sep 2018, at 20:34, Phil Race > wrote: >>>>> >>>>> I see you noticed the problem with it not necessarily being an AAT font. >>>>> It seems this method is a copy/paste of the method added in JDK 9. >>>>> So this will work but looking at it, I think in JDK 9 I should have made this more efficient. >>>>> Probably it was a detail in the larger work, that I never came back to. >>>>> On MacOS where it calls through the PhysicalFont interface, since CFont is not a TrueTypeFont, >>>>> it will be retrieving all the data in the table from native to Java on every call to layout. That will be expensive. >>>>> >>>>> You can mitigate this in your case by reversing the order here >>>>> + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { >>>>> >>>>> to >>>>> + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { >>>>> >>>>> So it will only take the hit for RTL text which will save a lot of cases ... >>>>> I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 which I will fix for 12. >>>>> >>>>> Up to you whether you also want to wait for that fix, or just update as I have suggested >>>>> and maybe take a follow-on fix later. >>>>> >>>>> Note that whilst your fix will at least make sure text reads in the correct direction, it >>>>> means it will be using default built-in shaping rules of ICU and so may miss at least >>>>> some features provided by the font. >>>>> >>>>> -phil. >>>>> >>>>> On 09/03/2018 05:54 AM, Dmitry Markov wrote: >>>>>> Hi Prasanta, >>>>>> >>>>>> Thank you for the feedback. I missed the usage of OSX specific class in shared code for some reasons. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ >>>>>> I replaced the usage of CFont with a new private method which tests either a font is AAT or not. >>>>>> >>>>>> The issue is jdk8u (ICU) specific. It does not take place on jdk12 because starting from jdk9 we use Harfbuzz as default layout engine. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>>> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan > wrote: >>>>>>> >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Not going into technicalities of the fix, but it seems it will break non-macos build as you are checking for CFont in a shared class? >>>>>>> Also, if it's the issue still exists, then why you are fixing only in 8u and not in jdk12? >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review a fix for jdk8u, please? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>>>>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>>>>>>> >>>>>>>> Problem description: >>>>>>>> The fix for 7162125 [1] enabled font tables processing on OSX. However there is a lack of support for RTL languages in ICU layout engine. Quote from ICU guide: ??The AAT processing in the LayoutEngine is relatively basic as it only applies the default features in left-to-right text. This processing has been tested for Devanagari text. Since AAT processing is not script-specific, it might not work for other scripts??, more details at http://userguide.icu-project.org/layoutengine >>>>>>>> As a result all RTL languages on OSX are incorrectly laid out, (i.e. the letters are reversely presented). >>>>>>>> >>>>>>>> Fix: >>>>>>>> Skip font tables for RTL languages on OSX platform. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitry >>>>>>>> >>>>>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Sep 13 06:12:07 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 13 Sep 2018 11:42:07 +0530 Subject: [OpenJDK 2D-Dev] [8u] RFR 8201801: RTL language (Hebrew) is presented from left to right In-Reply-To: References: <660d9356-85d0-8b8c-838d-c805ae37b17e@oracle.com> <46845D7E-036A-49CD-8D61-A735293AEA5A@oracle.com> <301051a7-ea26-e08a-326c-183c21617415@oracle.com> <27444f38-1919-9e6d-2d6f-7be34c41e5ae@oracle.com> Message-ID: looks good to me. Regards Prasanta On 12-Sep-18 7:57 PM, Dmitry Markov wrote: > Hi Prasanta, > > I have updated the fix based on your recommendations. The new webrev > is located at > http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.03/ > > > Thanks, > Dmitry > >> On 12 Sep 2018, at 07:09, Prasanta Sadhukhan >> > > wrote: >> >> I guess we could check for >> >> if (((typo_flags & 0x80000000) != 0) && isAAT(font)) >> >> before and could save on calling >> >> font.getLayoutTableCache() >> >> In present condition, it overwrites layoutTables to 0 making calling >> getLayoutTableCache meaningless. Maybe , do something like >> >> long layoutTables = 0; >> if !(((typo_flags & 0x80000000) != 0) && isAAT(font)) { layoutTables = font.getLayoutTableCache(); >> } >> >> BTW, please correct the indentation of l156 and l160. >> >> Regards >> Prasanta >> On 11-Sep-18 10:27 PM, Phil Race wrote: >>> fine by me. >>> >>> -phil. >>> >>> On 9/10/2018 1:18 AM, Dmitry Markov wrote: >>>> Phil, Prasanta, >>>> >>>> Any thoughts/concerns regarding the latest webrev: >>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >>>> >>>> >>>> Thanks, >>>> Dmitry >>>> >>>>> On 5 Sep 2018, at 12:27, Dmitry Markov >>>> > wrote: >>>>> >>>>> Hi Phil, >>>>> >>>>> Thank you for the comments. You are right the invocation of >>>>> isAAT() method might be too expensive especially on OSX. I have >>>>> changed the if-statement as you suggested. Please find the new >>>>> webrev here: >>>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.02/ >>>>> >>>>> >>>>> Also I will be happy to port the fix for JDK-8210384 to 8u once it >>>>> is ready. >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>>> On 4 Sep 2018, at 20:34, Phil Race >>>>> > wrote: >>>>>> >>>>>> I see you noticed the problem with it not necessarily being an >>>>>> AAT font. >>>>>> It seems this method is a copy/paste of the method added in JDK 9. >>>>>> So this will work but looking at it, I think in JDK 9 I should >>>>>> have made this more efficient. >>>>>> Probably it was a detail in the larger work, that I never came >>>>>> back to. >>>>>> On MacOS where it calls through the PhysicalFont interface, since >>>>>> CFont is not a TrueTypeFont, >>>>>> it will be retrieving all the data in the table from native to >>>>>> Java on every call to layout. That will be expensive. >>>>>> >>>>>> You can mitigate this in your case by reversing the order here >>>>>> + if (isAAT(font) && (typo_flags & 0x80000000) != 0) { >>>>>> >>>>>> to >>>>>> + if (((typo_flags & 0x80000000) != 0) && isAAT(font)) { >>>>>> >>>>>> So it will only take the hit for RTL text which will save a lot >>>>>> of cases? ... >>>>>> I have filed https://bugs.openjdk.java.net/browse/JDK-8210384 >>>>>> which I will fix for 12. >>>>>> >>>>>> Up to you whether you also want to wait for that fix, or just >>>>>> update as I have suggested >>>>>> and maybe take a follow-on fix later. >>>>>> >>>>>> Note that whilst your fix will at least make sure text reads in >>>>>> the correct direction, it >>>>>> means it will be using default built-in shaping rules of ICU and >>>>>> so may miss at least >>>>>> some features provided by the font. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 09/03/2018 05:54 AM, Dmitry Markov wrote: >>>>>>> Hi Prasanta, >>>>>>> >>>>>>> Thank you for the feedback. I missed the usage of OSX specific >>>>>>> class in shared code for some reasons. Please find the updated >>>>>>> webrev here: >>>>>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.01/ >>>>>>> >>>>>>> I replaced the usage of CFont with a new private method which >>>>>>> tests either a font is AAT or not. >>>>>>> >>>>>>> The issue is jdk8u (ICU) specific. It does not take place on >>>>>>> jdk12 because starting from jdk9 we use Harfbuzz as default >>>>>>> layout engine. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>>> On 3 Sep 2018, at 11:33, Prasanta Sadhukhan >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> Not going into technicalities of the fix, but it seems it will >>>>>>>> break non-macos build as you are checking for CFont in a shared >>>>>>>> class? >>>>>>>> Also, if it's the issue still exists, then why you are fixing >>>>>>>> only in 8u and not in jdk12? >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 9/3/2018 3:20 PM, Dmitry Markov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review a fix for jdk8u, please? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201801 >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8201801/jdk8u/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem description: >>>>>>>>> The fix for 7162125 [1] enabled font tables processing on OSX. >>>>>>>>> However there is a lack of support for RTL languages in ICU >>>>>>>>> layout engine. Quote from ICU guide: ??The AAT processing in >>>>>>>>> the LayoutEngine is relatively basic as it only applies the >>>>>>>>> default features in left-to-right text. This processing has >>>>>>>>> been tested for Devanagari text. Since AAT processing is not >>>>>>>>> script-specific, it might not work for other scripts??, more >>>>>>>>> details at http://userguide.icu-project.org/layoutengine >>>>>>>>> As a result all RTL languages on OSX are incorrectly laid out, >>>>>>>>> (i.e. the letters are reversely presented). >>>>>>>>> >>>>>>>>> Fix: >>>>>>>>> Skip font tables for RTL languages on OSX platform. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitry >>>>>>>>> >>>>>>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-7162125 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Sep 13 06:13:01 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 13 Sep 2018 11:43:01 +0530 Subject: [OpenJDK 2D-Dev] RFR: 7017058: Malayalam glyph substitution is failing for Malayalam with Windows Kartika font. In-Reply-To: <5B8F25FD.1000606@oracle.com> References: <5B8F25FD.1000606@oracle.com> Message-ID: <136c112c-41ae-5c62-b4d1-b482743cf4cb@oracle.com> +1 Regards Prasanta On 05-Sep-18 6:10 AM, Philip Race wrote: > This fixes 3 submitted bugs > https://bugs.openjdk.java.net/browse/JDK-7017058 : the Malayalam bug above > And also > https://bugs.openjdk.java.net/browse/JDK-8191130 : > Sinhala text rendering problem with C+VIRAMA+ZWJ+RA/YA+V > and > https://bugs.openjdk.java.net/browse/JDK-8195836: > opentype:Bengali: "Khanda Ta" shaping issue with U+09A4 TA, U+09CD > virama, U+200D ZWJ > > Webrev: http://cr.openjdk.java.net/~prr/7017058/ > > As discussed in the evaluation of 7017058, this is because of some > code which > always maps several unicode formatting characters to the invisible > glyph to > ensure it is never rendered as a missing glyph box. > But if the opentype tables in a font have glyph substitution looks ups > that > depend on that font's actual mapping of those glyphs then they are broken. > We have had several reports of this (above) and also complaints this > breaks > Emoji family ligature substitution. > > The fix changes this to first consult the font to see if it does map > these codepoints. > If it does not then we still will map to the empty glyph in which case > clearly the > font can't have any lookup that depends on it. > > The variable origCharCode is added because several of the methods > mutate charCode > and we avoid risk with this approach. > > The tab, NL and CR code points are still always mapped to the empty glyph > since they are never going to be used by layout in this way and some fonts > map TAB to a space char which is not what we want. > > -phil. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Fri Sep 14 01:15:44 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Fri, 14 Sep 2018 10:15:44 +0900 Subject: [OpenJDK 2D-Dev] JDK-8210707: Some line shaped characters are not displayed without Anti Aliasing Message-ID: Hello, I reported JDK-8210707: Some line shaped characters are not displayed without Anti Aliasing [1]. With some specific conditions (For example, OpenSans light font, 22points, U+007C VERTICAL LINE), the character is not displayed on AWT. I understood it's not JDK issue, and reported it to FreeType [2]. But, they stated > We lack motivation to track it down because the monochrome rasterizer is not very popular these days. I've explained my situation to them, but I'm worried about stagnating this problem. I appreciate any advice or support. (I'm considering Phil's suggestion to work with Redhat since the environment is Redhat Enterprise Linux. This problem occurs with FreeType libraries of the latest, RHEL bundled, and OpenJDK bundled.) [1] https://bugs.openjdk.java.net/browse/JDK-8210707 [2] https://savannah.nongnu.org/bugs/index.php?54589 Best regards, Toshio Nakamura -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Sep 14 02:00:08 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 13 Sep 2018 19:00:08 -0700 Subject: [OpenJDK 2D-Dev] JDK-8210707: Some line shaped characters are not displayed without Anti Aliasing In-Reply-To: References: Message-ID: <5B9B1628.1040005@oracle.com> Hi, So I believe we have concluded this is a core freetype problem since it manifests with multiple fonts even outside the JDK. In which case I don't know why you are posting this here. Whilst I sympathise with the problem, the right place to discuss it is on the freetype list, or submit a support ticket to RedHat. So long as JDK defers to the platform installed rasteriser there is nothing we can do. Even if I investigated and fixed it (which I am not going to) in freetype, that does nothing to get it into a RH patch update. The response you got from freetype devs is disappointing but it doesn't change that this is the wrong place. It makes no more sense to discuss it here, than if you found a compiler bug in Visual Studio to report it to build-dev .. you might as well report it to thousands of other products that compile for windows using VS C++. -phil. On 9/13/18, 6:15 PM, Toshio 5 Nakamura wrote: > > Hello, > > I reported JDK-8210707: Some line shaped characters are not displayed > without Anti Aliasing [1]. > With some specific conditions (For example, OpenSans light font, > 22points, U+007C VERTICAL LINE), the character is not displayed on AWT. > > I understood it's not JDK issue, and reported it to FreeType [2]. > But, they stated > > We lack motivation to track it down because the monochrome > rasterizer is not very popular these days. > I've explained my situation to them, but I'm worried about stagnating > this problem. > > I appreciate any advice or support. > > (I'm considering Phil's suggestion to work with Redhat since the > environment is Redhat Enterprise Linux. > This problem occurs with FreeType libraries of the latest, RHEL > bundled, and OpenJDK bundled.) > > [1] https://bugs.openjdk.java.net/browse/JDK-8210707 > [2] https://savannah.nongnu.org/bugs/index.php?54589 > > Best regards, > Toshio Nakamura > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Tue Sep 18 07:22:01 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 18 Sep 2018 09:22:01 +0200 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors Message-ID: Hi, Please could a second reviewer have a look ? Phil approved 2 weeks ago. I would like this bug done asap. I will propose for review the javafx patch (almost the same fix) in a moment. Cheers, Laurent Le mar. 11 sept. 2018 ? 08:55, Laurent Bourg?s a ?crit : > Hi, > Can I have a second review, please ? > > I would like to make a jdk11 updates fix request asap... > > Laurent > > Le jeu. 6 sept. 2018 ? 09:31, Laurent Bourg?s > a ?crit : > >> Phil, >> Thanks for your review. >> >> Le jeu. 6 sept. 2018 ? 01:39, Philip Race a >> ?crit : >> >>> This looks good to me. >>> I've run all our automated tests + done some manual testing >>> as well as building on all platforms and reviewing the source changes. >>> >> >> Do you have more closed-source tests that could be opened in OpenJDK ? >> >>> >>> > PS: What is the process to ask for backport to JDK11 updates ? >>> >>> If you think this important enough to backport, then this is the process >>> : >>> >>> http://openjdk.java.net/projects/jdk-updates/approval.html >> >> >> I fixed these bugs as I was contacted on the Marlin mailing list by an >> end user testing the migration of its Map viewer app from jdk8 to OpenJDK11. >> >> I made this patch as small as possible that is compatible with OpenJDK >> 11/12 and is well tested: low risk. >> For 12, I will propose a more important patch later to upgrade to Marlin >> 0.9.3 >> >> As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I think it >> is worth fixing it in 11 too. >> >> Any other opinion ? >> >> PS: I will fix OpenJFX 11/12 soon >> >> Cheers, >> Laurent >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Sep 20 15:52:22 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Sep 2018 08:52:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8209548: Unused and incorrect calls to FT_Get_Char_Index Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8209548 webrev: http://cr.openjdk.java.net/~prr/8209548/ Clean up of some pointless and incorrect code in freetypescaler.c -phil From krishna.addepalli at oracle.com Thu Sep 20 16:02:09 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 20 Sep 2018 09:02:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8209548: Unused and incorrect calls to FT_Get_Char_Index In-Reply-To: References: Message-ID: <70183C1F-53C3-432A-8D7F-2319FD8A2B24@oracle.com> Looks fine! > On 20-Sep-2018, at 8:52 AM, Phil Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8209548 > webrev: http://cr.openjdk.java.net/~prr/8209548/ > > Clean up of some pointless and incorrect code in freetypescaler.c > > -phil From prasanta.sadhukhan at oracle.com Fri Sep 21 11:37:19 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 21 Sep 2018 17:07:19 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8209548: Unused and incorrect calls to FT_Get_Char_Index In-Reply-To: References: Message-ID: +1 Regards Prasanta On 20-Sep-18 9:22 PM, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8209548 > webrev: http://cr.openjdk.java.net/~prr/8209548/ > > Clean up of some pointless and incorrect code in freetypescaler.c > > -phil From Sergey.Bylokhov at oracle.com Sun Sep 23 07:21:10 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 23 Sep 2018 00:21:10 -0700 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: References: Message-ID: <7f7028ff-a91a-7df2-5376-c8a9250b7111@oracle.com> Looks fine. On 18/09/2018 00:22, Laurent Bourg?s wrote: > Hi, > > Please could a second reviewer have a look ? > Phil approved 2 weeks ago. > I would like this bug done asap. > > I will propose for review the javafx patch (almost the same fix) in a > moment. > > Cheers, > Laurent > > Le mar. 11 sept. 2018 ? 08:55, Laurent Bourg?s > > a ?crit?: > > Hi, > Can I have a second review, please ? > > I would like to make a jdk11 updates fix request asap... > > Laurent > > Le jeu. 6 sept. 2018 ? 09:31, Laurent Bourg?s > > a ?crit?: > > Phil, > Thanks for your review. > > Le jeu. 6 sept. 2018 ? 01:39, Philip Race > > a ?crit?: > > This looks good to me. > I've run all our automated tests + done some manual testing > as well as building on all platforms and reviewing the > source changes. > > > Do you have more closed-source tests that could be opened in > OpenJDK ? > > > ?>? PS: What is the process to ask for backport to JDK11 > updates ? > > If you think this important enough to backport, then this is > the process : > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > I fixed these bugs as I was contacted on the Marlin mailing list > by an end user testing the migration of its Map viewer app from > jdk8 to OpenJDK11. > > I made this patch as small as possible that is compatible with > OpenJDK 11/12 and is well tested: low risk. > For 12, I will propose a more important patch later to upgrade > to Marlin 0.9.3 > > As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I > think it is worth fixing it in 11 too. > > Any other opinion ? > > PS: I will fix OpenJFX 11/12 soon > > Cheers, > Laurent > -- Best regards, Sergey. From mailto.woden at gmail.com Wed Sep 26 05:42:48 2018 From: mailto.woden at gmail.com (Daniel Persson) Date: Wed, 26 Sep 2018 07:42:48 +0200 Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK Message-ID: Hi everyone, We render a lot of images with PDFBox with Java 1.8.0 and we want to upgrade to the current OpenJDK 11 but sadly we see some performance degradation switching over to OpenJDK. Anyone have a suggestion to remedy this issue, or can explain why it is slower? Using the PDFBox app current release downloadable from http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar Running the command java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf We see the following result --------------------------------------------------------- java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) Rendered 1 page in 2762ms --------------------------------------------------------- openjdk version "9.0.4" OpenJDK Runtime Environment (build 9.0.4+11) OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode) Rendered 1 page in 8034ms --------------------------------------------------------- openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) Rendered 1 page in 4255ms --------------------------------------------------------- openjdk version "11" 2018-09-25 OpenJDK Runtime Environment 18.9 (build 11+28) OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) Rendered 1 page in 4275ms --------------------------------------------------------- openjdk version "12-ea" 2019-03-19 OpenJDK Runtime Environment 19.3 (build 12-ea+11) OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode) Rendered 1 page in 4399ms The pdf file used in this example can be downloaded from https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing Best regards Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Sep 26 07:03:11 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 26 Sep 2018 09:03:11 +0200 Subject: [OpenJDK 2D-Dev] RFR [12] Clipping problems with complex affine transforms: negative scaling factors or small scaling factors In-Reply-To: <7f7028ff-a91a-7df2-5376-c8a9250b7111@oracle.com> References: <7f7028ff-a91a-7df2-5376-c8a9250b7111@oracle.com> Message-ID: Hi, I pushed this patch and asked for jdk11u backport: I added label and comment to the jbs bug. Is it enough ? Or should I send an email to jdk updates .... Laurent Le dim. 23 sept. 2018 ? 09:21, Sergey Bylokhov a ?crit : > Looks fine. > > On 18/09/2018 00:22, Laurent Bourg?s wrote: > > Hi, > > > > Please could a second reviewer have a look ? > > Phil approved 2 weeks ago. > > I would like this bug done asap. > > > > I will propose for review the javafx patch (almost the same fix) in a > > moment. > > > > Cheers, > > Laurent > > > > Le mar. 11 sept. 2018 ? 08:55, Laurent Bourg?s > > > a ?crit : > > > > Hi, > > Can I have a second review, please ? > > > > I would like to make a jdk11 updates fix request asap... > > > > Laurent > > > > Le jeu. 6 sept. 2018 ? 09:31, Laurent Bourg?s > > > a > ?crit : > > > > Phil, > > Thanks for your review. > > > > Le jeu. 6 sept. 2018 ? 01:39, Philip Race > > > a > ?crit : > > > > This looks good to me. > > I've run all our automated tests + done some manual testing > > as well as building on all platforms and reviewing the > > source changes. > > > > > > Do you have more closed-source tests that could be opened in > > OpenJDK ? > > > > > > > PS: What is the process to ask for backport to JDK11 > > updates ? > > > > If you think this important enough to backport, then this is > > the process : > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > I fixed these bugs as I was contacted on the Marlin mailing list > > by an end user testing the migration of its Map viewer app from > > jdk8 to OpenJDK11. > > > > I made this patch as small as possible that is compatible with > > OpenJDK 11/12 and is well tested: low risk. > > For 12, I will propose a more important patch later to upgrade > > to Marlin 0.9.3 > > > > As JDK11 is LTS and this bug is a regression (P3 ?) since 10, I > > think it is worth fixing it in 11 too. > > > > Any other opinion ? > > > > PS: I will fix OpenJFX 11/12 soon > > > > Cheers, > > Laurent > > > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Sep 26 11:38:33 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 26 Sep 2018 17:08:33 +0530 Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8211055:Provide print to a file (PDF) feature even when printer was not connected Message-ID: <8af8c638-c259-d5c5-111b-3df2e8cc20ce@oracle.com> Hi All, Please review a fix for an issue where it is seen that if we do not have any printer installed and we try to save the printjob to a file via "Save as PDF" option in mac, it was throwing PrinterExcetion:no printer service found. This is a regression of JDK-8132988 where a check was added to make sure PrinterException is thrown if there is no printer installed. Proposed fix is to find out if user is selecting "Save as PDF" option in native print dialog which will cause NSPrintInfo's jobDisposition value to be |NSPrintSaveJob [https://developer.apple.com/documentation/appkit/nsprintinfo/1528717-jobdisposition?language=objc] |In that case, the previous "no-printer" check is amended to also check if the print operation is saving to a file, in which case do not throw PrinterException and proceed with Save-File operation. JDK-8132988? testcase also works ok after this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8211055 webrev: http://cr.openjdk.java.net/~psadhukhan/8211055/webrev.0/ Regards Prasanta || -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 26 16:18:50 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 26 Sep 2018 09:18:50 -0700 Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8211055:Provide print to a file (PDF) feature even when printer was not connected In-Reply-To: <8af8c638-c259-d5c5-111b-3df2e8cc20ce@oracle.com> References: <8af8c638-c259-d5c5-111b-3df2e8cc20ce@oracle.com> Message-ID: <07241a48-10e7-3073-4ea6-40f70ab41071@oracle.com> This is all MacOS specific changes - and functionality - but the test seems to be cross-platform. Shouldn't it at least have an @requires macos tag ? And I think the test should verify there are no printers and say it can't be run if you have any ... and exit ... Can we set & retrieve the file as a Destination attribute ? Then we can verify the file was saved without the user's help 123 " 4. Another dialog opends prompting for filename, enter any filename and press \"Save\".\r\n" + opends -> opens -phil. On 09/26/2018 04:38 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that if we do not > have any printer installed and we try to save the printjob to a file > via "Save as PDF" option in mac, it was throwing PrinterExcetion:no > printer service found. > > This is a regression of JDK-8132988 where a check was added to make > sure PrinterException is thrown if there is no printer installed. > Proposed fix is to find out if user is selecting "Save as PDF" option > in native print dialog which will cause NSPrintInfo's jobDisposition > value to be |NSPrintSaveJob > [https://developer.apple.com/documentation/appkit/nsprintinfo/1528717-jobdisposition?language=objc] > > |In that case, the previous "no-printer" check is amended to also > check if the print operation is saving to a file, in which case do not > throw PrinterException and proceed with Save-File operation. > JDK-8132988 testcase also works ok after this fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211055 > webrev: http://cr.openjdk.java.net/~psadhukhan/8211055/webrev.0/ > > Regards > Prasanta > || -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Wed Sep 26 16:40:45 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 26 Sep 2018 17:40:45 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8211165: License header is absent in a few J2Ddemo source code files Message-ID: <4a91b1c2-1187-2c75-50ce-354c2ed2eee7@oracle.com> Hello, Could you please review the following fix which adds two blocks of source code comments to two files. Bug: https://bugs.openjdk.java.net/browse/JDK-8211165 Webrev: http://cr.openjdk.java.net/~alitvinov/8211165/jdk12/webrev.00 Thank you, Anton From philip.race at oracle.com Wed Sep 26 16:50:24 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 26 Sep 2018 09:50:24 -0700 Subject: [OpenJDK 2D-Dev] [12] Review request for 8211165: License header is absent in a few J2Ddemo source code files In-Reply-To: <4a91b1c2-1187-2c75-50ce-354c2ed2eee7@oracle.com> References: <4a91b1c2-1187-2c75-50ce-354c2ed2eee7@oracle.com> Message-ID: <4613733e-4cf1-1b9e-cc30-a1edc57d79a1@oracle.com> Looks good to me. Not sure if including 2018 is strictly needed since the only change in 2018 is to add the legal notice itself :-) -phill On 09/26/2018 09:40 AM, Anton Litvinov wrote: > Hello, > > Could you please review the following fix which adds two blocks of > source code comments to two files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211165 > Webrev: http://cr.openjdk.java.net/~alitvinov/8211165/jdk12/webrev.00 > > Thank you, > Anton From iris.clark at oracle.com Wed Sep 26 16:58:28 2018 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 26 Sep 2018 09:58:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [12] Review request for 8211165: License header is absent in a few J2Ddemo source code files In-Reply-To: <4a91b1c2-1187-2c75-50ce-354c2ed2eee7@oracle.com> References: <4a91b1c2-1187-2c75-50ce-354c2ed2eee7@oracle.com> Message-ID: <21276d93-d7b9-4236-baa0-65df98d85438@default> Hi, Anton. > Bug: https://bugs.openjdk.java.net/browse/JDK-8211165 > Webrev: http://cr.openjdk.java.net/~alitvinov/8211165/jdk12/webrev.00 Your change looks good. I've verified that you have the correct copyright format, copyright year range, and license. Thank you for taking care of this! iris -----Original Message----- From: Anton Litvinov Sent: Wednesday, September 26, 2018 9:41 AM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [12] Review request for 8211165: License header is absent in a few J2Ddemo source code files Hello, Could you please review the following fix which adds two blocks of source code comments to two files. Bug: https://bugs.openjdk.java.net/browse/JDK-8211165 Webrev: http://cr.openjdk.java.net/~alitvinov/8211165/jdk12/webrev.00 Thank you, Anton From anton.litvinov at oracle.com Wed Sep 26 17:08:46 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 26 Sep 2018 18:08:46 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8211165: License header is absent in a few J2Ddemo source code files In-Reply-To: <4613733e-4cf1-1b9e-cc30-a1edc57d79a1@oracle.com> References: <4a91b1c2-1187-2c75-50ce-354c2ed2eee7@oracle.com> <4613733e-4cf1-1b9e-cc30-a1edc57d79a1@oracle.com> Message-ID: Hello Phil, Thank you very much for approval of this fix. I will push the fix immediately. I think that for this particular case it is better to include also "2018,", because we add the header itself in 2018 and it will not look good, if we introduce the header and change the file now and leave just "2015,"? sub-string. Thank you, Anton On 26/09/2018 17:50, Phil Race wrote: > Looks good to me. > > Not sure if including 2018 is strictly needed since the only change in > 2018 is to add > the legal notice itself :-) > > -phill > > On 09/26/2018 09:40 AM, Anton Litvinov wrote: >> Hello, >> >> Could you please review the following fix which adds two blocks of >> source code comments to two files. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211165 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8211165/jdk12/webrev.00 >> >> Thank you, >> Anton > From philip.race at oracle.com Wed Sep 26 17:33:40 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 26 Sep 2018 10:33:40 -0700 Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK In-Reply-To: References: Message-ID: <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com> Multiple pieces are changing across these releases. Is it the JPEG writing ? Is it freetype vs t2k (font performance) is it harfbuzz vs icu (text layout), is it marlin vs ductus (rasterization) ? So it is very hard to say with any certainty what the cause of the difference is .. or why 10 got so much better than 9 .. even if still not back to JDK 8. Please file a bug at java.com. -phil. On 09/25/2018 10:42 PM, Daniel Persson wrote: > Hi everyone, > > We render a lot of images with PDFBox with Java 1.8.0 and we want to > upgrade to the current OpenJDK 11 but sadly we see some performance > degradation switching over to OpenJDK. Anyone have a suggestion to > remedy this issue, or can explain why it is slower? > > Using the PDFBox app current release downloadable from > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar > > Running the command > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf > > We see the following result > > --------------------------------------------------------- > java version "1.8.0_181" > Java(TM) SE Runtime Environment (build 1.8.0_181-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) > Rendered 1 page in 2762ms > --------------------------------------------------------- > openjdk version "9.0.4" > OpenJDK Runtime Environment (build 9.0.4+11) > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode) > Rendered 1 page in 8034ms > --------------------------------------------------------- > openjdk version "10.0.2" 2018-07-17 > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) > Rendered 1 page in 4255ms > --------------------------------------------------------- > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) > Rendered 1 page in 4275ms > --------------------------------------------------------- > openjdk version "12-ea" 2019-03-19 > OpenJDK Runtime Environment 19.3 (build 12-ea+11) > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode) > Rendered 1 page in 4399ms > > The pdf file used in this example can be downloaded from > https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing > > Best regards > Daniel From mailto.woden at gmail.com Wed Sep 26 18:08:05 2018 From: mailto.woden at gmail.com (Daniel Persson) Date: Wed, 26 Sep 2018 20:08:05 +0200 Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK In-Reply-To: <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com> References: <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com> Message-ID: Hi Phil What the PDFBox team told me it could have something to do with color mapping. And my quick profiling shows that the code spends 29% of the time inside of java.awt.image.ColorConvertOp.filter on java 11 But I'll open a issue. Best regards Daniel On Wed, Sep 26, 2018, 19:33 Phil Race wrote: > Multiple pieces are changing across these releases. > > Is it the JPEG writing ? Is it freetype vs t2k (font performance) > is it harfbuzz vs icu (text layout), is it marlin vs ductus > (rasterization) ? > > So it is very hard to say with any certainty what the cause of the > difference is .. or > why 10 got so much better than 9 .. even if still not back to JDK 8. > > Please file a bug at java.com. > > -phil. > > On 09/25/2018 10:42 PM, Daniel Persson wrote: > > Hi everyone, > > > > We render a lot of images with PDFBox with Java 1.8.0 and we want to > > upgrade to the current OpenJDK 11 but sadly we see some performance > > degradation switching over to OpenJDK. Anyone have a suggestion to > > remedy this issue, or can explain why it is slower? > > > > Using the PDFBox app current release downloadable from > > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar > > > > Running the command > > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf > > > > We see the following result > > > > --------------------------------------------------------- > > java version "1.8.0_181" > > Java(TM) SE Runtime Environment (build 1.8.0_181-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) > > Rendered 1 page in 2762ms > > --------------------------------------------------------- > > openjdk version "9.0.4" > > OpenJDK Runtime Environment (build 9.0.4+11) > > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode) > > Rendered 1 page in 8034ms > > --------------------------------------------------------- > > openjdk version "10.0.2" 2018-07-17 > > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) > > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) > > Rendered 1 page in 4255ms > > --------------------------------------------------------- > > openjdk version "11" 2018-09-25 > > OpenJDK Runtime Environment 18.9 (build 11+28) > > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) > > Rendered 1 page in 4275ms > > --------------------------------------------------------- > > openjdk version "12-ea" 2019-03-19 > > OpenJDK Runtime Environment 19.3 (build 12-ea+11) > > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode) > > Rendered 1 page in 4399ms > > > > The pdf file used in this example can be downloaded from > > > https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing > > > > Best regards > > Daniel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 26 18:20:13 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 26 Sep 2018 11:20:13 -0700 Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK In-Reply-To: References: <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com> Message-ID: <5BABCDDD.5080403@oracle.com> Interesting and I assume that it was somewhat less in JD8u ? Off the top of my head that is one thing that didn't change in any big way since JDK 8u. Perhaps something has changed so that it is now [considered] needed whereas before it was not? So did it go from zero percent to 29% or from 10% to 29% ? But even that doesn't on it own account for everything. 29% of 8 seconds would be about 2.5 seconds and doesn't explain going from < 3 seconds to 8 seconds .. we are still missing at least 2.5 seconds .. -phil. On 9/26/18, 11:08 AM, Daniel Persson wrote: > Hi Phil > > What the PDFBox team told me it could have something to do with color > mapping. > > And my quick profiling shows that the code spends 29% of the time > inside of java.awt.image.ColorConvertOp.filter on java 11 > > But I'll open a issue. > > Best regards > Daniel > > On Wed, Sep 26, 2018, 19:33 Phil Race > wrote: > > Multiple pieces are changing across these releases. > > Is it the JPEG writing ? Is it freetype vs t2k (font performance) > is it harfbuzz vs icu (text layout), is it marlin vs ductus > (rasterization) ? > > So it is very hard to say with any certainty what the cause of the > difference is .. or > why 10 got so much better than 9 .. even if still not back to JDK 8. > > Please file a bug at java.com . > > -phil. > > On 09/25/2018 10:42 PM, Daniel Persson wrote: > > Hi everyone, > > > > We render a lot of images with PDFBox with Java 1.8.0 and we > want to > > upgrade to the current OpenJDK 11 but sadly we see some performance > > degradation switching over to OpenJDK. Anyone have a suggestion to > > remedy this issue, or can explain why it is slower? > > > > Using the PDFBox app current release downloadable from > > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar > > > > Running the command > > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf > > > > We see the following result > > > > --------------------------------------------------------- > > java version "1.8.0_181" > > Java(TM) SE Runtime Environment (build 1.8.0_181-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) > > Rendered 1 page in 2762ms > > --------------------------------------------------------- > > openjdk version "9.0.4" > > OpenJDK Runtime Environment (build 9.0.4+11) > > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode) > > Rendered 1 page in 8034ms > > --------------------------------------------------------- > > openjdk version "10.0.2" 2018-07-17 > > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) > > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) > > Rendered 1 page in 4255ms > > --------------------------------------------------------- > > openjdk version "11" 2018-09-25 > > OpenJDK Runtime Environment 18.9 (build 11+28) > > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) > > Rendered 1 page in 4275ms > > --------------------------------------------------------- > > openjdk version "12-ea" 2019-03-19 > > OpenJDK Runtime Environment 19.3 (build 12-ea+11) > > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode) > > Rendered 1 page in 4399ms > > > > The pdf file used in this example can be downloaded from > > > https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing > > > > Best regards > > Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Sep 27 06:24:53 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 27 Sep 2018 11:54:53 +0530 Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8211055:Provide print to a file (PDF) feature even when printer was not connected In-Reply-To: <07241a48-10e7-3073-4ea6-40f70ab41071@oracle.com> References: <8af8c638-c259-d5c5-111b-3df2e8cc20ce@oracle.com> <07241a48-10e7-3073-4ea6-40f70ab41071@oracle.com> Message-ID: I have added @requires tag and also did an initial check of existing printers and exit if there is any. Regarding setting,retrieving Destination attribute, if we do not show the print dialog and ask user to select file and ok, it will not set call nsPrintInfoToJavaPrinterJob which is called from showDialog() and so NSPrintJobDispositionValuewill not be set up and setPrintToFile() will not be called. I checked in jdk8GA too, it fails if we set Destination and try to print. I guess existing customer issue is about not printing if user manually selects "Save as PDF". I guess I can work on that issue as a separate bug. Modified test webrev:http://cr.openjdk.java.net/~psadhukhan/8211055/webrev.1/ Regards Prasanta On 26-Sep-18 9:48 PM, Phil Race wrote: > This is all MacOS specific changes - and functionality - but the test > seems > to be cross-platform. Shouldn't it at least have an @requires macos tag ? > > And I think the test should verify there are no printers and say it can't > be run if you have any ... and exit ... > > Can we set? & retrieve the file as a Destination attribute ? > Then we can verify the file was saved without the user's help > > > 123 " 4. Another dialog opends prompting for filename, enter any filename and press \"Save\".\r\n" + > > opends -> opens > > -phil. > > On 09/26/2018 04:38 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that if we do not >> have any printer installed and we try to save the printjob to a file >> via "Save as PDF" option in mac, it was throwing PrinterExcetion:no >> printer service found. >> >> This is a regression of JDK-8132988 where a check was added to make >> sure PrinterException is thrown if there is no printer installed. >> Proposed fix is to find out if user is selecting "Save as PDF" option >> in native print dialog which will cause NSPrintInfo's jobDisposition >> value to be |NSPrintSaveJob >> [https://developer.apple.com/documentation/appkit/nsprintinfo/1528717-jobdisposition?language=objc] >> >> |In that case, the previous "no-printer" check is amended to also >> check if the print operation is saving to a file, in which case do >> not throw PrinterException and proceed with Save-File operation. >> JDK-8132988? testcase also works ok after this fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211055 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8211055/webrev.0/ >> >> Regards >> Prasanta >> || > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Thu Sep 27 07:19:53 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 27 Sep 2018 09:19:53 +0200 Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK In-Reply-To: <5BABCDDD.5080403@oracle.com> References: <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com> <5BABCDDD.5080403@oracle.com> Message-ID: Hi, FYI I will run profilers on this test case to compare Oracle JDK8 vs OpenJDK11... Will then give you my analysis. Cheers, Laurent Le mer. 26 sept. 2018 ? 23:51, Philip Race a ?crit : > Interesting and I assume that it was somewhat less in JD8u ? > Off the top of my head that is one thing that didn't change in any big way > since JDK 8u. > > Perhaps something has changed so that it is now [considered] needed > whereas before > it was not? So did it go from zero percent to 29% or from 10% to 29% ? > > But even that doesn't on it own account for everything. > 29% of 8 seconds would be about 2.5 seconds and doesn't explain going from > < 3 seconds to 8 seconds .. we are still missing at least 2.5 seconds .. > > > -phil. > > On 9/26/18, 11:08 AM, Daniel Persson wrote: > > Hi Phil > > What the PDFBox team told me it could have something to do with color > mapping. > > And my quick profiling shows that the code spends 29% of the time inside > of java.awt.image.ColorConvertOp.filter on java 11 > > But I'll open a issue. > > Best regards > Daniel > > On Wed, Sep 26, 2018, 19:33 Phil Race wrote: > >> Multiple pieces are changing across these releases. >> >> Is it the JPEG writing ? Is it freetype vs t2k (font performance) >> is it harfbuzz vs icu (text layout), is it marlin vs ductus >> (rasterization) ? >> >> So it is very hard to say with any certainty what the cause of the >> difference is .. or >> why 10 got so much better than 9 .. even if still not back to JDK 8. >> >> Please file a bug at java.com. >> >> -phil. >> >> On 09/25/2018 10:42 PM, Daniel Persson wrote: >> > Hi everyone, >> > >> > We render a lot of images with PDFBox with Java 1.8.0 and we want to >> > upgrade to the current OpenJDK 11 but sadly we see some performance >> > degradation switching over to OpenJDK. Anyone have a suggestion to >> > remedy this issue, or can explain why it is slower? >> > >> > Using the PDFBox app current release downloadable from >> > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar >> > >> > Running the command >> > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf >> > >> > We see the following result >> > >> > --------------------------------------------------------- >> > java version "1.8.0_181" >> > Java(TM) SE Runtime Environment (build 1.8.0_181-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) >> > Rendered 1 page in 2762ms >> > --------------------------------------------------------- >> > openjdk version "9.0.4" >> > OpenJDK Runtime Environment (build 9.0.4+11) >> > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode) >> > Rendered 1 page in 8034ms >> > --------------------------------------------------------- >> > openjdk version "10.0.2" 2018-07-17 >> > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) >> > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) >> > Rendered 1 page in 4255ms >> > --------------------------------------------------------- >> > openjdk version "11" 2018-09-25 >> > OpenJDK Runtime Environment 18.9 (build 11+28) >> > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >> > Rendered 1 page in 4275ms >> > --------------------------------------------------------- >> > openjdk version "12-ea" 2019-03-19 >> > OpenJDK Runtime Environment 19.3 (build 12-ea+11) >> > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode) >> > Rendered 1 page in 4399ms >> > >> > The pdf file used in this example can be downloaded from >> > >> https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing >> > >> > Best regards >> > Daniel >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: