From dmitry.batrak at jetbrains.com Mon Apr 1 07:44:29 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Mon, 1 Apr 2019 10:44:29 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: <5C9937BF.9010500@oracle.com> References: <5C81B594.6060209@oracle.com> <5C9937BF.9010500@oracle.com> Message-ID: > Sorry for the delay. I've now finished verifying this and it is a +1 from me. Thanks! Anyone else, please? A second reviewer is required. On Mon, Mar 25, 2019 at 11:19 PM Philip Race wrote: > Sorry for the delay. I've now finished verifying this and it is a +1 from > me. > > -phil. > > On 3/12/19, 1:32 AM, Dmitry Batrak wrote: > > > This looks good to me, if I understand correctly that we now create > > the face on first use and cache it fin Java or as long as the Font2D is > > alive. > > And the JNIEnv is always found on > That's correct. The assumption is that HarfBuzz doesn't create its own > threads, > so HarfBuzz-related native code will always be invoked from a Java thread > (as part of 'shape' call), and so JNIEnv will be available in that context. > > I've updated the webrev by including a stress test for multi-threaded > behaviour > testing. Apart from the test, webrev also has some cosmetic differences > from the previous version (like a comment fix or parameter order changing), > appeared during 'splitting' process. To simplify the review, I'm also > providing > the links to the 'split' version of the same webrev - three parts that > produce > the same result when combined. I've not tested the changes separately > (except basic compilation check). > > Complete change: > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ > Part 1 (caching hb_face_t): > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ > Part 2 (tables caching removal): > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ > Part 3 (scaler pointer passing removal): > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ > > Best regards, > Dmitry Batrak > > On Fri, Mar 8, 2019 at 3:21 AM Philip Race wrote: > >> This looks good to me, if I understand correctly that we now create >> the face on first use and cache it fin Java or as long as the Font2D is >> alive. >> And the JNIEnv is always found on >> >> I think you are right that we don't need the caching of the tables since >> now the face will do it. The unfortunate thing is that the removal of >> this code is >> well over half the changes and as such it greatly muddied finding the >> changes >> that make the performance difference so my review was harder and less >> certain >> because of that. >> It could have been separated into a follow-on change I think so that it >> would have >> been easier to review the important change. >> >> The pScaler parameter looks like it is unused these days which is why I >> expect you removed it but also not directly relevant. >> >> I have run builds + some tests - but I'm not in a position to run more >> tests >> for a couple of weeks. >> >> A (mild) stress test re-using the same font from multiple threads >> eachmaking >> multiple calls into layout would be a good addition here. That should >> help tell >> us if there are any MT or re-entrancy problems. Can you provide such a >> test ? >> It will be a good thing to have automatically run to catch any problems >> introduced later either on the Java side or by an update to harfbuzz. >> >> -phil. >> >> >> >> On 3/6/19, 5:45 PM, Dmitry Batrak wrote: >> > Hello, >> > >> > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so >> > I'll need someone to sponsor this change. >> > >> > The proposed approach is used without known issues in OpenJDK-based >> > JetBrains Runtime for almost three years now. I've mentioned it >> > previously on this mailing list >> > (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html >> ). >> > The change has been refactored as compared to the version mentioned >> > above (the logic has been moved to SunLayoutEngine), and includes the >> > removal of font tables caching (JDK-8186317). The latter, I believe, >> > becomes redundant with this fix. >> > >> > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 >> > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ >> > >> > >> > Best regards, >> > Dmitry Batrak >> > >> > > > -- Dmitry Batrak Senior Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ushakov at jetbrains.com Mon Apr 1 09:12:38 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Mon, 1 Apr 2019 12:12:38 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: <5C81B594.6060209@oracle.com> <5C9937BF.9010500@oracle.com> Message-ID: Looks good for me. Best Regards, Alexey On Mon, Apr 1, 2019 at 10:46 AM Dmitry Batrak wrote: > > Sorry for the delay. I've now finished verifying this and it is a +1 > from me. > Thanks! > > Anyone else, please? A second reviewer is required. > > On Mon, Mar 25, 2019 at 11:19 PM Philip Race > wrote: > >> Sorry for the delay. I've now finished verifying this and it is a +1 from >> me. >> >> -phil. >> >> On 3/12/19, 1:32 AM, Dmitry Batrak wrote: >> >> > This looks good to me, if I understand correctly that we now create >> > the face on first use and cache it fin Java or as long as the Font2D is >> > alive. >> > And the JNIEnv is always found on >> That's correct. The assumption is that HarfBuzz doesn't create its own >> threads, >> so HarfBuzz-related native code will always be invoked from a Java thread >> (as part of 'shape' call), and so JNIEnv will be available in that >> context. >> >> I've updated the webrev by including a stress test for multi-threaded >> behaviour >> testing. Apart from the test, webrev also has some cosmetic differences >> from the previous version (like a comment fix or parameter order >> changing), >> appeared during 'splitting' process. To simplify the review, I'm also >> providing >> the links to the 'split' version of the same webrev - three parts that >> produce >> the same result when combined. I've not tested the changes separately >> (except basic compilation check). >> >> Complete change: >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ >> Part 1 (caching hb_face_t): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ >> Part 2 (tables caching removal): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ >> Part 3 (scaler pointer passing removal): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ >> >> Best regards, >> Dmitry Batrak >> >> On Fri, Mar 8, 2019 at 3:21 AM Philip Race >> wrote: >> >>> This looks good to me, if I understand correctly that we now create >>> the face on first use and cache it fin Java or as long as the Font2D is >>> alive. >>> And the JNIEnv is always found on >>> >>> I think you are right that we don't need the caching of the tables since >>> now the face will do it. The unfortunate thing is that the removal of >>> this code is >>> well over half the changes and as such it greatly muddied finding the >>> changes >>> that make the performance difference so my review was harder and less >>> certain >>> because of that. >>> It could have been separated into a follow-on change I think so that it >>> would have >>> been easier to review the important change. >>> >>> The pScaler parameter looks like it is unused these days which is why I >>> expect you removed it but also not directly relevant. >>> >>> I have run builds + some tests - but I'm not in a position to run more >>> tests >>> for a couple of weeks. >>> >>> A (mild) stress test re-using the same font from multiple threads >>> eachmaking >>> multiple calls into layout would be a good addition here. That should >>> help tell >>> us if there are any MT or re-entrancy problems. Can you provide such a >>> test ? >>> It will be a good thing to have automatically run to catch any problems >>> introduced later either on the Java side or by an update to harfbuzz. >>> >>> -phil. >>> >>> >>> >>> On 3/6/19, 5:45 PM, Dmitry Batrak wrote: >>> > Hello, >>> > >>> > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so >>> > I'll need someone to sponsor this change. >>> > >>> > The proposed approach is used without known issues in OpenJDK-based >>> > JetBrains Runtime for almost three years now. I've mentioned it >>> > previously on this mailing list >>> > ( >>> https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). >>> > The change has been refactored as compared to the version mentioned >>> > above (the logic has been moved to SunLayoutEngine), and includes the >>> > removal of font tables caching (JDK-8186317). The latter, I believe, >>> > becomes redundant with this fix. >>> > >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 >>> > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ >>> > >>> > >>> > Best regards, >>> > Dmitry Batrak >>> > >>> >> >> >> > > -- > Dmitry Batrak > Senior Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Mon Apr 1 12:08:37 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 1 Apr 2019 13:08:37 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> Message-ID: <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> On 29/03/2019 20:35, Sergey Bylokhov wrote: > But it looks like an overkill to wait 8 minutes for one test, isn't it? I agree 8 minutes seem too much. However, I admit it might take even more time to setup a network printer. > Probably we can force the less timeout by the > "sun.java2d.print.minRefreshTime"? That's a good option. Unix uses 2 minutes' interval for polling. We can make minRefreshTime equal to 2 minutes but leave the default refresh time of 4 minutes. Does it sound good? This way the time of waiting for two refresh cycles would be reduced to 4 minutes only. > On 29/03/2019 08:28, Alexey Ivanov wrote: >> Please take a look at the updated webrev where I've removed @ignore >> tag from the test: >> http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ >> >> On 29/03/2019 01:09, Philip Race wrote: >>> Are you looking for a reason other than that the implementation >>> is set to refresh the printer list every 4 minutes ? >> >> Yes, remote printer list is refreshed every 4 minutes on Windows. >> >> The reason why I added step 6 is that the user has no way of knowing >> when the refresh occurred. The refresh could happen just before the >> printer is added. Waiting for another refresh is to prevent false >> failures. If the list isn't updated in two refresh cycles, likely it >> won't be updated. In this case, the user will click Fail. >> >> Regards, >> Alexey >> >>> >>> -phil. >>> >>> >>> On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >>>> Hi, Alexey. >>>> >>>> I think it is ok to drop @ignore tag, but I wonder why did you add >>>> the step6 to the instruction. >>>> 197???????????????????? +????????? "updated.\n" >>>> 198???????????????????? + "Step 6: If the list is not updated, wait >>>> for another " >>>> 199???????????????????? +????????? "4 minutes, and then click >>>> Refresh again.\n" >>>> >>>> -- Regards, Alexey From takiguc at linux.vnet.ibm.com Tue Apr 2 16:27:53 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 03 Apr 2019 01:27:53 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties Message-ID: Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.) Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file. On current implementation, Java tries to load X11 bitmap fonts even if these are not used. This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories. Just font name format should be supported. To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From philip.race at oracle.com Wed Apr 3 16:09:29 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Apr 2019 09:09:29 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: References: Message-ID: <5CA4DAB9.2060602@oracle.com> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: > Hello. > (I am sorry to post it again. Previously, I posted the wrong mailing > list.) > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > On AIX platform, fontconfig.properties file is used to pick up proper > fonts. > TrueType font settings are written by XLFD format on > fontconfig.properties file. > > On current implementation, Java tries to load X11 bitmap fonts even if > these are not used. I think you need to clarify what you mean here. I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this. > This font load work is almost name as "xlsfonts -ll". > It spends many CPU time and memories. > > Just font name format should be supported. Not clear enough for me. -phil. > > To SAP representative, > I have a question about copyright year on > make/data/fontconfig/aix.fontconfig.properties. > Please let me know how I should write down copyright year. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > From alexey.ivanov at oracle.com Wed Apr 3 16:35:24 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 3 Apr 2019 17:35:24 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> Message-ID: <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> Hi Phil, Sergey, On 01/04/2019 13:08, Alexey Ivanov wrote: > On 29/03/2019 20:35, Sergey Bylokhov wrote: >> But it looks like an overkill to wait 8 minutes for one test, isn't it? > > I agree 8 minutes seem too much. However, I admit it might take even > more time to setup a network printer. > >> Probably we can force the less timeout by the >> "sun.java2d.print.minRefreshTime"? > > That's a good option. Unix uses 2 minutes' interval for polling. > > We can make minRefreshTime equal to 2 minutes but leave the default > refresh time of 4 minutes. Does it sound good? This way the time of > waiting for two refresh cycles would be reduced to 4 minutes only. What do you think about this suggestion? If you agree, I'll submit a new CR to update both the implementation and the test. If not, then I would rather leave the test and its instructions as they are in webrev.1. Are there any other comments? >> On 29/03/2019 08:28, Alexey Ivanov wrote: >>> Please take a look at the updated webrev where I've removed @ignore >>> tag from the test: >>> http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ >>> >>> On 29/03/2019 01:09, Philip Race wrote: >>>> Are you looking for a reason other than that the implementation >>>> is set to refresh the printer list every 4 minutes ? >>> >>> Yes, remote printer list is refreshed every 4 minutes on Windows. >>> >>> The reason why I added step 6 is that the user has no way of knowing >>> when the refresh occurred. The refresh could happen just before the >>> printer is added. Waiting for another refresh is to prevent false >>> failures. If the list isn't updated in two refresh cycles, likely it >>> won't be updated. In this case, the user will click Fail. >>> >>> Regards, >>> Alexey >>> >>>> >>>> -phil. >>>> >>>> >>>> On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >>>>> Hi, Alexey. >>>>> >>>>> I think it is ok to drop @ignore tag, but I wonder why did you add >>>>> the step6 to the instruction. >>>>> 197???????????????????? +????????? "updated.\n" >>>>> 198???????????????????? + "Step 6: If the list is not updated, >>>>> wait for another " >>>>> 199???????????????????? +????????? "4 minutes, and then click >>>>> Refresh again.\n" >>>>> >>>>> -- Regards, Alexey From philip.race at oracle.com Thu Apr 4 02:53:13 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Apr 2019 19:53:13 -0700 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: , <5C84D34E.2070601@oracle.com> Message-ID: <5CA57199.3050405@oracle.com> I will get back to this soon but you will still need a 2nd reviewer. -phil. On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: > Hi Phil, > Just a gentle reminder, I appreciate it if you have a time to look at > this. > Thanks, > Toshio Nakamura > > ----- Original message ----- > From: "Toshio 5 Nakamura" > Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> > To: Philip Race > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for > East Asian countries cannot belong to CompositeFont > Date: Mon, Mar 11, 2019 9:58 PM > > Hi Phil, > > Thank you so much for your reviewing. > > Yes, "family" part can be removed with a few changes in > "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". > > The updated webrev is: > http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01 > / > > > So you don't need to clean everything - just your develop -internal > > and -ea folders. > Yes, thank you for the clarification. > > Thanks, > Toshio Nakamura > > Philip Race wrote on 2019/03/10 18:05:18: > > > From: Philip Race > > To: Toshio 5 Nakamura > > Cc: 2d-dev <2d-dev at openjdk.java.net> > > Date: 2019/03/10 18:05 > > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East > > Asian countries cannot belong to CompositeFont > > > > I can sponsor this but first : > > > > You seem to have made "family" redundant but aren't removing it. > > There's no point in writing it out if nothing uses it on reading. > > So we should remove it unless you can explain why you think it > should be kept. > > > > I don't think this (removing it) is a problem for backports or > > compatibility of the > > format since release name is part of the file name where we write > > the information, > > and such a file name will necessarily be a consequence of a feature > > or update release > > containing this fix. > > > > Where it might be an issue is testing on 13-ea builds since they > all report > > that as the version string so for testing you may need to clean > out your > > ~/.java/fonts/13-ea folder. The same is for your 13-internal > private builds. > > > > I think this is your point when you wrote :- > > > >> The cached font list is stored under ~/.java/fonts directory. > >> We should delete it before applying the fix. > > > > So you don't need to clean everything - just your develop -internal > > and -ea folders. > > > > Meanwhile I tested it .. and it seemed OK but I am still trying > to join > > up all the dots to make sure it is all correct code-wise. > > > > -phil > > > > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > > Hi, > > > > Could you review the fix and may I have a sponsor for it? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 > > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ > > > > > Issue: > > Even if Google Noto fonts[1] were installed and listed by > fontconfig library > > on Linux, CompositeFont couldn't contain it. > > > > Fix description: > > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. > 296) > > validates the target font by comparing names. But, the current code > > compared FamilyName with FullName (Font.getFontName()). > > Then, Noto font was treated as invalid. > > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" > > should provide FullName. > > > > The cached font list is stored under ~/.java/fonts directory. > > We should delete it before applying the fix. > > > > This fix is possible to change the default font, if CompositeFont > > is used (especially under Ubuntu18.04 and East Asian settings). > > But, I believe the fixed behavior is correct. > > > > [1] https://www.google.com/get/noto/ > > > > Thanks, > > Toshio Nakamura > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Apr 4 11:44:37 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Thu, 4 Apr 2019 17:14:37 +0530 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: <5CA57199.3050405@oracle.com> References: <5C84D34E.2070601@oracle.com> <5CA57199.3050405@oracle.com> Message-ID: <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com> Hi, I am also taking a look at this. I will update my observations soon. Thanks, Jay > On 04-Apr-2019, at 8:23 AM, Philip Race wrote: > > I will get back to this soon but you will still need a 2nd reviewer. > > -phil. > > On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: >> >> Hi Phil, >> >> Just a gentle reminder, I appreciate it if you have a time to look at this. >> >> Thanks, >> Toshio Nakamura >> >> ----- Original message ----- >> From: "Toshio 5 Nakamura" >> Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> >> To: Philip Race >> Cc: 2d-dev <2d-dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont >> Date: Mon, Mar 11, 2019 9:58 PM >> Hi Phil, >> >> Thank you so much for your reviewing. >> >> Yes, "family" part can be removed with a few changes in >> "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". >> >> The updated webrev is: >> http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01 / >> >> > So you don't need to clean everything - just your develop -internal >> > and -ea folders. >> Yes, thank you for the clarification. >> >> Thanks, >> Toshio Nakamura >> >> Philip Race wrote on 2019/03/10 18:05:18: >> >> > From: Philip Race >> > To: Toshio 5 Nakamura >> > Cc: 2d-dev <2d-dev at openjdk.java.net> >> > Date: 2019/03/10 18:05 >> > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East >> > Asian countries cannot belong to CompositeFont >> > >> > I can sponsor this but first : >> > >> > You seem to have made "family" redundant but aren't removing it. >> > There's no point in writing it out if nothing uses it on reading. >> > So we should remove it unless you can explain why you think it should be kept. >> > >> > I don't think this (removing it) is a problem for backports or >> > compatibility of the >> > format since release name is part of the file name where we write >> > the information, >> > and such a file name will necessarily be a consequence of a feature >> > or update release >> > containing this fix. >> > >> > Where it might be an issue is testing on 13-ea builds since they all report >> > that as the version string so for testing you may need to clean out your >> > ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds. >> > >> > I think this is your point when you wrote :- >> > >> >> The cached font list is stored under ~/.java/fonts directory. >> >> We should delete it before applying the fix. >> > >> > So you don't need to clean everything - just your develop -internal >> > and -ea folders. >> > >> > Meanwhile I tested it .. and it seemed OK but I am still trying to join >> > up all the dots to make sure it is all correct code-wise. >> > >> > -phil >> > >> > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: >> > Hi, >> > >> > Could you review the fix and may I have a sponsor for it? >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 >> > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ >> > >> > Issue: >> > Even if Google Noto fonts[1] were installed and listed by fontconfig library >> > on Linux, CompositeFont couldn't contain it. >> > >> > Fix description: >> > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296) >> > validates the target font by comparing names. But, the current code >> > compared FamilyName with FullName (Font.getFontName()). >> > Then, Noto font was treated as invalid. >> > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" >> > should provide FullName. >> > >> > The cached font list is stored under ~/.java/fonts directory. >> > We should delete it before applying the fix. >> > >> > This fix is possible to change the default font, if CompositeFont >> > is used (especially under Ubuntu18.04 and East Asian settings). >> > But, I believe the fixed behavior is correct. >> > >> > [1] https://www.google.com/get/noto/ >> > >> > Thanks, >> > Toshio Nakamura >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Thu Apr 4 12:44:45 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Thu, 4 Apr 2019 12:44:45 +0000 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com> References: <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com>, <5C84D34E.2070601@oracle.com> <5CA57199.3050405@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Apr 5 22:30:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 5 Apr 2019 15:30:15 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> Message-ID: <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> On 03/04/2019 09:35, Alexey Ivanov wrote: >> We can make minRefreshTime equal to 2 minutes but leave the default refresh time of 4 minutes. Does it sound good? This way the time of waiting for two refresh cycles would be reduced to 4 minutes only> > What do you think about this suggestion? > If you agree, I'll submit a new CR to update both the implementation and the test. But why do you need a separate CR? The "sun.java2d.print.minRefreshTime" is a java property, we can set it in this test to 1 minute or so, and suggest the user to wait 2 minutes, no? > > If not, then I would rather leave the test and its instructions as they are in webrev.1. > > Are there any other comments? > >>> On 29/03/2019 08:28, Alexey Ivanov wrote: >>>> Please take a look at the updated webrev where I've removed @ignore tag from the test: >>>> http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ >>>> >>>> On 29/03/2019 01:09, Philip Race wrote: >>>>> Are you looking for a reason other than that the implementation >>>>> is set to refresh the printer list every 4 minutes ? >>>> >>>> Yes, remote printer list is refreshed every 4 minutes on Windows. >>>> >>>> The reason why I added step 6 is that the user has no way of knowing when the refresh occurred. The refresh could happen just before the printer is added. Waiting for another refresh is to prevent false failures. If the list isn't updated in two refresh cycles, likely it won't be updated. In this case, the user will click Fail. >>>> >>>> Regards, >>>> Alexey >>>> >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >>>>>> Hi, Alexey. >>>>>> >>>>>> I think it is ok to drop @ignore tag, but I wonder why did you add the step6 to the instruction. >>>>>> 197???????????????????? +????????? "updated.\n" >>>>>> 198???????????????????? + "Step 6: If the list is not updated, wait for another " >>>>>> 199???????????????????? +????????? "4 minutes, and then click Refresh again.\n" >>>>>> >>>>>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Apr 5 22:32:24 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 5 Apr 2019 15:32:24 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> Message-ID: On 05/04/2019 15:30, Sergey Bylokhov wrote: > On 03/04/2019 09:35, Alexey Ivanov wrote: >>> We can make minRefreshTime equal to 2 minutes but leave the default refresh time of 4 minutes. Does it sound good? This way the time of waiting for two refresh cycles would be reduced to 4 minutes only> >> What do you think about this suggestion? >> If you agree, I'll submit a new CR to update both the implementation and the test. > > But why do you need a separate CR? The "sun.java2d.print.minRefreshTime" is a java property, we can set it in this test to 1 minute or so, and suggest the user to wait 2 minutes, no? > >> >> If not, then I would rather leave the test and its instructions as they are in webrev.1. I just got it, we cannot set the timeout less than DEFAULT_MINREFRESH, yes please file a separate CR. >> >> Are there any other comments? >> >>>> On 29/03/2019 08:28, Alexey Ivanov wrote: >>>>> Please take a look at the updated webrev where I've removed @ignore tag from the test: >>>>> http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ >>>>> >>>>> On 29/03/2019 01:09, Philip Race wrote: >>>>>> Are you looking for a reason other than that the implementation >>>>>> is set to refresh the printer list every 4 minutes ? >>>>> >>>>> Yes, remote printer list is refreshed every 4 minutes on Windows. >>>>> >>>>> The reason why I added step 6 is that the user has no way of knowing when the refresh occurred. The refresh could happen just before the printer is added. Waiting for another refresh is to prevent false failures. If the list isn't updated in two refresh cycles, likely it won't be updated. In this case, the user will click Fail. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Alexey. >>>>>>> >>>>>>> I think it is ok to drop @ignore tag, but I wonder why did you add the step6 to the instruction. >>>>>>> 197???????????????????? +????????? "updated.\n" >>>>>>> 198???????????????????? + "Step 6: If the list is not updated, wait for another " >>>>>>> 199???????????????????? +????????? "4 minutes, and then click Refresh again.\n" >>>>>>> >>>>>>> > > -- Best regards, Sergey. From dmitry.batrak at jetbrains.com Mon Apr 8 08:27:38 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Mon, 8 Apr 2019 11:27:38 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: <5C81B594.6060209@oracle.com> <5C9937BF.9010500@oracle.com> Message-ID: A second reviewer is still required. Best regards, Dmitry Batrak. On Mon, Apr 1, 2019 at 10:44 AM Dmitry Batrak wrote: > > Sorry for the delay. I've now finished verifying this and it is a +1 > from me. > Thanks! > > Anyone else, please? A second reviewer is required. > > On Mon, Mar 25, 2019 at 11:19 PM Philip Race > wrote: > >> Sorry for the delay. I've now finished verifying this and it is a +1 from >> me. >> >> -phil. >> >> On 3/12/19, 1:32 AM, Dmitry Batrak wrote: >> >> > This looks good to me, if I understand correctly that we now create >> > the face on first use and cache it fin Java or as long as the Font2D is >> > alive. >> > And the JNIEnv is always found on >> That's correct. The assumption is that HarfBuzz doesn't create its own >> threads, >> so HarfBuzz-related native code will always be invoked from a Java thread >> (as part of 'shape' call), and so JNIEnv will be available in that >> context. >> >> I've updated the webrev by including a stress test for multi-threaded >> behaviour >> testing. Apart from the test, webrev also has some cosmetic differences >> from the previous version (like a comment fix or parameter order >> changing), >> appeared during 'splitting' process. To simplify the review, I'm also >> providing >> the links to the 'split' version of the same webrev - three parts that >> produce >> the same result when combined. I've not tested the changes separately >> (except basic compilation check). >> >> Complete change: >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ >> Part 1 (caching hb_face_t): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ >> Part 2 (tables caching removal): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ >> Part 3 (scaler pointer passing removal): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ >> >> Best regards, >> Dmitry Batrak >> >> On Fri, Mar 8, 2019 at 3:21 AM Philip Race >> wrote: >> >>> This looks good to me, if I understand correctly that we now create >>> the face on first use and cache it fin Java or as long as the Font2D is >>> alive. >>> And the JNIEnv is always found on >>> >>> I think you are right that we don't need the caching of the tables since >>> now the face will do it. The unfortunate thing is that the removal of >>> this code is >>> well over half the changes and as such it greatly muddied finding the >>> changes >>> that make the performance difference so my review was harder and less >>> certain >>> because of that. >>> It could have been separated into a follow-on change I think so that it >>> would have >>> been easier to review the important change. >>> >>> The pScaler parameter looks like it is unused these days which is why I >>> expect you removed it but also not directly relevant. >>> >>> I have run builds + some tests - but I'm not in a position to run more >>> tests >>> for a couple of weeks. >>> >>> A (mild) stress test re-using the same font from multiple threads >>> eachmaking >>> multiple calls into layout would be a good addition here. That should >>> help tell >>> us if there are any MT or re-entrancy problems. Can you provide such a >>> test ? >>> It will be a good thing to have automatically run to catch any problems >>> introduced later either on the Java side or by an update to harfbuzz. >>> >>> -phil. >>> >>> >>> >>> On 3/6/19, 5:45 PM, Dmitry Batrak wrote: >>> > Hello, >>> > >>> > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so >>> > I'll need someone to sponsor this change. >>> > >>> > The proposed approach is used without known issues in OpenJDK-based >>> > JetBrains Runtime for almost three years now. I've mentioned it >>> > previously on this mailing list >>> > ( >>> https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). >>> > The change has been refactored as compared to the version mentioned >>> > above (the logic has been moved to SunLayoutEngine), and includes the >>> > removal of font tables caching (JDK-8186317). The latter, I believe, >>> > becomes redundant with this fix. >>> > >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 >>> > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ >>> > >>> > >>> > Best regards, >>> > Dmitry Batrak >>> > >>> >> >> >> > > -- > Dmitry Batrak > Senior Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Mon Apr 8 10:14:36 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 8 Apr 2019 11:14:36 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> Message-ID: On 05/04/2019 23:32, Sergey Bylokhov wrote: > On 05/04/2019 15:30, Sergey Bylokhov wrote: >> On 03/04/2019 09:35, Alexey Ivanov wrote: >>>> We can make minRefreshTime equal to 2 minutes but leave the default >>>> refresh time of 4 minutes. Does it sound good? This way the time of >>>> waiting for two refresh cycles would be reduced to 4 minutes only> >>> What do you think about this suggestion? >>> If you agree, I'll submit a new CR to update both the implementation >>> and the test. >> >> But why do you need a separate CR? The >> "sun.java2d.print.minRefreshTime" is a java property, we can set it >> in this test to 1 minute or so, and suggest the user to wait 2 >> minutes, no? >> >>> >>> If not, then I would rather leave the test and its instructions as >>> they are in webrev.1. > > I just got it, we cannot set the timeout less than DEFAULT_MINREFRESH, > yes please file a separate CR. Exactly! I would've done it if it had been possible. Changing the minRefreshTime requires changes to both the implementation and the test, so it's better to do it under separate CR, I've submitted one: https://bugs.openjdk.java.net/browse/JDK-8222108 Is this changeset approved now? >>> Are there any other comments? >>> >>>>> On 29/03/2019 08:28, Alexey Ivanov wrote: >>>>>> Please take a look at the updated webrev where I've removed >>>>>> @ignore tag from the test: >>>>>> http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ >>>>>> >>>>>> On 29/03/2019 01:09, Philip Race wrote: >>>>>>> Are you looking for a reason other than that the implementation >>>>>>> is set to refresh the printer list every 4 minutes ? >>>>>> >>>>>> Yes, remote printer list is refreshed every 4 minutes on Windows. >>>>>> >>>>>> The reason why I added step 6 is that the user has no way of >>>>>> knowing when the refresh occurred. The refresh could happen just >>>>>> before the printer is added. Waiting for another refresh is to >>>>>> prevent false failures. If the list isn't updated in two refresh >>>>>> cycles, likely it won't be updated. In this case, the user will >>>>>> click Fail. >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Alexey. >>>>>>>> >>>>>>>> I think it is ok to drop @ignore tag, but I wonder why did you >>>>>>>> add the step6 to the instruction. >>>>>>>> 197???????????????????? +????????? "updated.\n" >>>>>>>> 198???????????????????? + "Step 6: If the list is not updated, >>>>>>>> wait for another " >>>>>>>> 199???????????????????? +????????? "4 minutes, and then click >>>>>>>> Refresh again.\n" >>>>>>>> >>>>>>>> -- Regards, Alexey From Sergey.Bylokhov at oracle.com Mon Apr 8 19:14:02 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 8 Apr 2019 12:14:02 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> Message-ID: <58748251-3f59-9e38-ab5e-03f2b61b8bf5@oracle.com> On 08/04/2019 03:14, Alexey Ivanov wrote: > Exactly! I would've done it if it had been possible. > Changing the minRefreshTime requires changes to both the implementation and the test, so it's better to do it under separate CR, I've submitted one: > https://bugs.openjdk.java.net/browse/JDK-8222108 yes, it looks fine, thank you for clarification. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 8 19:14:59 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 8 Apr 2019 12:14:59 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: <5C81B594.6060209@oracle.com> <5C9937BF.9010500@oracle.com> Message-ID: <7a2c7b7c-bebf-99e6-85dc-306508f67f2c@oracle.com> +1 On 01/04/2019 02:12, Alexey Ushakov wrote: > Looks good for me. > > Best Regards, > Alexey > > On Mon, Apr 1, 2019 at 10:46 AM Dmitry Batrak > wrote: > > > Sorry for the delay. I've now finished verifying this and it is a +1 from me. > Thanks! > > Anyone else, please? A second reviewer is required. > > On Mon, Mar 25, 2019 at 11:19 PM Philip Race > wrote: > > Sorry for the delay. I've now finished verifying this and it is a +1 from me. > > -phil. > > On 3/12/19, 1:32 AM, Dmitry Batrak wrote: >> > This looks good to me, if I understand correctly that we now create >> > the face on first use and cache it fin Java or as long as the Font2D is >> > alive. >> > And the JNIEnv is always found on >> That's correct. The assumption is that HarfBuzz doesn't create its own threads, >> so HarfBuzz-related native code will always be invoked from a Java thread >> (as part of 'shape' call), and so JNIEnv will be available in that context. >> >> I've updated the webrev by including a stress test for multi-threaded behaviour >> testing. Apart from the test, webrev also has some cosmetic differences >> from the previous version (like a comment fix or parameter order changing), >> appeared during 'splitting' process. To simplify the review, I'm also providing >> the links to the 'split' version of the same webrev - three parts that produce >> the same result when combined. I've not tested the changes separately >> (except basic compilation check). >> >> Complete change: >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ >> Part 1 (caching hb_face_t): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ >> Part 2 (tables caching removal): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ >> Part 3 (scaler pointer passing removal): >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ >> >> Best regards, >> Dmitry Batrak >> >> On Fri, Mar 8, 2019 at 3:21 AM Philip Race > wrote: >> >> This looks good to me, if I understand correctly that we now create >> the face on first use and cache it fin Java or as long as the Font2D is >> alive. >> And the JNIEnv is always found on >> >> I think you are right that we don't need the caching of the tables since >> now the face will do it. The unfortunate thing is that the removal of >> this code is >> well over half the changes and as such it greatly muddied finding the >> changes >> that make the performance difference so my review was harder and less >> certain >> because of that. >> It could have been separated into a follow-on change I think so that it >> would have >> been easier to review the important change. >> >> The pScaler parameter looks like it is unused these days which is why I >> expect you removed it but also not directly relevant. >> >> I have run builds + some tests - but I'm not in a position to run more tests >> for a couple of weeks. >> >> A (mild) stress test re-using the same font from multiple threads eachmaking >> multiple calls into layout would be a good addition here. That should >> help tell >> us if there are any MT or re-entrancy problems. Can you provide such a >> test ? >> It will be a good thing to have automatically run to catch any problems >> introduced later either on the Java side or by an update to harfbuzz. >> >> -phil. >> >> >> >> On 3/6/19, 5:45 PM, Dmitry Batrak wrote: >> > Hello, >> > >> > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so >> > I'll need someone to sponsor this change. >> > >> > The proposed approach is used without known issues in OpenJDK-based >> > JetBrains Runtime for almost three years now. I've mentioned it >> > previously on this mailing list >> > (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). >> > The change has been refactored as compared to the version mentioned >> > above (the logic has been moved to SunLayoutEngine), and includes the >> > removal of font tables caching (JDK-8186317). The latter, I believe, >> > becomes redundant with this fix. >> > >> > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 >> > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ >> > >> > >> > Best regards, >> > Dmitry Batrak >> > >> >> >> > > > -- > Dmitry Batrak > Senior Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 8 19:16:24 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 8 Apr 2019 12:16:24 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions In-Reply-To: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> References: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> Message-ID: <237c13fe-8ea5-892a-42e0-34125f577a36@oracle.com> Looks fine. On 24/03/2019 12:18, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk 13. > > bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/ > > Description: > Splash screen functionality is broken in 32 bit Windows. It's because the functions in splashscreen.dll are exported with decorated names now, yet they're looked up by the undecorated names. > > The easiest way to reproduce the problem is to run SwingSet2: > java -jar SwingSet2.jar > > > Fix: > The fix removes JNICALL (__stdcall) declarations from splash screen functions. Thus the functions are exported undecorated. > > I've run SplashScreen jtreg tests, all tests pass. > > This is a follow-up fix to > https://bugs.openjdk.java.net/browse/JDK-8201226 > https://bugs.openjdk.java.net/browse/JDK-8202476 > which re-enabled 32 bit Windows post removal of mapfiles / compiler options. > > > Thank you in advance. > > Regards, > Alexey -- Best regards, Sergey. From philip.race at oracle.com Mon Apr 8 21:21:42 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 8 Apr 2019 14:21:42 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <58748251-3f59-9e38-ab5e-03f2b61b8bf5@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> <58748251-3f59-9e38-ab5e-03f2b61b8bf5@oracle.com> Message-ID: +1 -phil. On 4/8/2019 12:14 PM, Sergey Bylokhov wrote: > On 08/04/2019 03:14, Alexey Ivanov wrote: >> Exactly! I would've done it if it had been possible. >> Changing the minRefreshTime requires changes to both the >> implementation and the test, so it's better to do it under separate >> CR, I've submitted one: >> https://bugs.openjdk.java.net/browse/JDK-8222108 > > yes, it looks fine, thank you for clarification. > > > From alexey.ivanov at oracle.com Mon Apr 8 21:47:02 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 8 Apr 2019 22:47:02 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> <66e6913e-d7cc-7d63-9041-01e6181b4996@oracle.com> <6fa018c2-7f32-cf38-d752-de758e472506@oracle.com> <35c24542-f6df-f86b-dd30-e90360fceca0@oracle.com> <58748251-3f59-9e38-ab5e-03f2b61b8bf5@oracle.com> Message-ID: <3e2dba76-6e11-3582-88b6-280262948a42@oracle.com> Thank you, Sergey and Phil, for your review! -- Alexey On 08/04/2019 22:21, Phil Race wrote: > +1 > > > -phil. > > On 4/8/2019 12:14 PM, Sergey Bylokhov wrote: >> On 08/04/2019 03:14, Alexey Ivanov wrote: >>> Exactly! I would've done it if it had been possible. >>> Changing the minRefreshTime requires changes to both the >>> implementation and the test, so it's better to do it under separate >>> CR, I've submitted one: >>> https://bugs.openjdk.java.net/browse/JDK-8222108 >> >> yes, it looks fine, thank you for clarification. >> From jayathirth.d.v at oracle.com Tue Apr 9 06:26:14 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Tue, 9 Apr 2019 11:56:14 +0530 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com> <5C84D34E.2070601@oracle.com> <5CA57199.3050405@oracle.com> Message-ID: Hi, (Ignore the previous mail received with less info) Observations: I went through different FontConfiguration & FontManager implementations and I see that in case of fontConfig(linux) only we are encoding/decoding CompositeFonts in a unique way(In case of font config we override get2DCompositeFontInfo()). For other platforms we use parent get2DCompositeFontInfo() where we are populating face names using getFaceNameFromComponentFontName(). Also getDefaultPlatformFont() returns predetermined face names in case of Windows and Mac. For Linux changes made in FontConfiguration and FontManager looks fine. Thanks, Jay > On 04-Apr-2019, at 6:14 PM, Toshio 5 Nakamura wrote: > > Hi phil, Jay, > > Thank you for taking your time to review this patch. > > Thanks, > Toshio Nakamura > ----- Original message ----- > From: Jayathirth Rao > To: TOSHIONA at jp.ibm.com > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont > Date: Thu, Apr 4, 2019 8:43 PM > > Hi, > > I am also taking a look at this. > I will update my observations soon. > > Thanks, > Jay > >> >> On 04-Apr-2019, at 8:23 AM, Philip Race > wrote: >> >> I will get back to this soon but you will still need a 2nd reviewer. >> >> -phil. >> >> On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: >>> >>> Hi Phil, >>> >>> Just a gentle reminder, I appreciate it if you have a time to look at this. >>> >>> Thanks, >>> Toshio Nakamura >>> >>> ----- Original message ----- >>> From: "Toshio 5 Nakamura" >>> Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> >>> To: Philip Race >>> Cc: 2d-dev <2d-dev at openjdk.java.net> >>> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont >>> Date: Mon, Mar 11, 2019 9:58 PM >>> Hi Phil, >>> >>> Thank you so much for your reviewing. >>> >>> Yes, "family" part can be removed with a few changes in >>> "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". >>> >>> The updated webrev is: >>> http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01 / >>> >>> > So you don't need to clean everything - just your develop -internal >>> > and -ea folders. >>> Yes, thank you for the clarification. >>> >>> Thanks, >>> Toshio Nakamura >>> >>> Philip Race wrote on 2019/03/10 18:05:18: >>> >>> > From: Philip Race >>> > To: Toshio 5 Nakamura >>> > Cc: 2d-dev <2d-dev at openjdk.java.net> >>> > Date: 2019/03/10 18:05 >>> > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East >>> > Asian countries cannot belong to CompositeFont >>> > >>> > I can sponsor this but first : >>> > >>> > You seem to have made "family" redundant but aren't removing it. >>> > There's no point in writing it out if nothing uses it on reading. >>> > So we should remove it unless you can explain why you think it should be kept. >>> > >>> > I don't think this (removing it) is a problem for backports or >>> > compatibility of the >>> > format since release name is part of the file name where we write >>> > the information, >>> > and such a file name will necessarily be a consequence of a feature >>> > or update release >>> > containing this fix. >>> > >>> > Where it might be an issue is testing on 13-ea builds since they all report >>> > that as the version string so for testing you may need to clean out your >>> > ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds. >>> > >>> > I think this is your point when you wrote :- >>> > >>> >> The cached font list is stored under ~/.java/fonts directory. >>> >> We should delete it before applying the fix. >>> > >>> > So you don't need to clean everything - just your develop -internal >>> > and -ea folders. >>> > >>> > Meanwhile I tested it .. and it seemed OK but I am still trying to join >>> > up all the dots to make sure it is all correct code-wise. >>> > >>> > -phil >>> > >>> > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: >>> > Hi, >>> > >>> > Could you review the fix and may I have a sponsor for it? >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 >>> > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ >>> > >>> > Issue: >>> > Even if Google Noto fonts[1] were installed and listed by fontconfig library >>> > on Linux, CompositeFont couldn't contain it. >>> > >>> > Fix description: >>> > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296) >>> > validates the target font by comparing names. But, the current code >>> > compared FamilyName with FullName (Font.getFontName()). >>> > Then, Noto font was treated as invalid. >>> > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" >>> > should provide FullName. >>> > >>> > The cached font list is stored under ~/.java/fonts directory. >>> > We should delete it before applying the fix. >>> > >>> > This fix is possible to change the default font, if CompositeFont >>> > is used (especially under Ubuntu18.04 and East Asian settings). >>> > But, I believe the fixed behavior is correct. >>> > >>> > [1] https://www.google.com/get/noto/ >>> > >>> > Thanks, >>> > Toshio Nakamura >>> >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Tue Apr 9 07:28:26 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Tue, 9 Apr 2019 10:28:26 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: <7a2c7b7c-bebf-99e6-85dc-306508f67f2c@oracle.com> References: <5C81B594.6060209@oracle.com> <5C9937BF.9010500@oracle.com> <7a2c7b7c-bebf-99e6-85dc-306508f67f2c@oracle.com> Message-ID: Thanks! Hopefully someone can push (sponsor) it now. Best regards, Dmitry Batrak On Mon, Apr 8, 2019 at 10:16 PM Sergey Bylokhov wrote: > +1 > > On 01/04/2019 02:12, Alexey Ushakov wrote: > > Looks good for me. > > > > Best Regards, > > Alexey > > > > On Mon, Apr 1, 2019 at 10:46 AM Dmitry Batrak < > dmitry.batrak at jetbrains.com > wrote: > > > > > Sorry for the delay. I've now finished verifying this and it is a > +1 from me. > > Thanks! > > > > Anyone else, please? A second reviewer is required. > > > > On Mon, Mar 25, 2019 at 11:19 PM Philip Race > wrote: > > > > Sorry for the delay. I've now finished verifying this and it is > a +1 from me. > > > > -phil. > > > > On 3/12/19, 1:32 AM, Dmitry Batrak wrote: > >> > This looks good to me, if I understand correctly that we now > create > >> > the face on first use and cache it fin Java or as long as the > Font2D is > >> > alive. > >> > And the JNIEnv is always found on > >> That's correct. The assumption is that HarfBuzz doesn't create > its own threads, > >> so HarfBuzz-related native code will always be invoked from a > Java thread > >> (as part of 'shape' call), and so JNIEnv will be available in > that context. > >> > >> I've updated the webrev by including a stress test for > multi-threaded behaviour > >> testing. Apart from the test, webrev also has some cosmetic > differences > >> from the previous version (like a comment fix or parameter > order changing), > >> appeared during 'splitting' process. To simplify the review, > I'm also providing > >> the links to the 'split' version of the same webrev - three > parts that produce > >> the same result when combined. I've not tested the changes > separately > >> (except basic compilation check). > >> > >> Complete change: > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ < > http://cr.openjdk.java.net/%7Edbatrak/8220231/webrev.01/> > >> Part 1 (caching hb_face_t): > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ < > http://cr.openjdk.java.net/%7Edbatrak/8220231/webrev.01-1/> > >> Part 2 (tables caching removal): > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ < > http://cr.openjdk.java.net/%7Edbatrak/8220231/webrev.01-2/> > >> Part 3 (scaler pointer passing removal): > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ < > http://cr.openjdk.java.net/%7Edbatrak/8220231/webrev.01-3/> > >> > >> Best regards, > >> Dmitry Batrak > >> > >> On Fri, Mar 8, 2019 at 3:21 AM Philip Race < > philip.race at oracle.com > wrote: > >> > >> This looks good to me, if I understand correctly that we > now create > >> the face on first use and cache it fin Java or as long as > the Font2D is > >> alive. > >> And the JNIEnv is always found on > >> > >> I think you are right that we don't need the caching of the > tables since > >> now the face will do it. The unfortunate thing is that the > removal of > >> this code is > >> well over half the changes and as such it greatly muddied > finding the > >> changes > >> that make the performance difference so my review was > harder and less > >> certain > >> because of that. > >> It could have been separated into a follow-on change I > think so that it > >> would have > >> been easier to review the important change. > >> > >> The pScaler parameter looks like it is unused these days > which is why I > >> expect you removed it but also not directly relevant. > >> > >> I have run builds + some tests - but I'm not in a position > to run more tests > >> for a couple of weeks. > >> > >> A (mild) stress test re-using the same font from multiple > threads eachmaking > >> multiple calls into layout would be a good addition here. > That should > >> help tell > >> us if there are any MT or re-entrancy problems. Can you > provide such a > >> test ? > >> It will be a good thing to have automatically run to catch > any problems > >> introduced later either on the Java side or by an update to > harfbuzz. > >> > >> -phil. > >> > >> > >> > >> On 3/6/19, 5:45 PM, Dmitry Batrak wrote: > >> > Hello, > >> > > >> > I'd like to submit a patch for JDK-8220231. I'm not a > Committer, so > >> > I'll need someone to sponsor this change. > >> > > >> > The proposed approach is used without known issues in > OpenJDK-based > >> > JetBrains Runtime for almost three years now. I've > mentioned it > >> > previously on this mailing list > >> > ( > https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). > >> > The change has been refactored as compared to the version > mentioned > >> > above (the logic has been moved to SunLayoutEngine), and > includes the > >> > removal of font tables caching (JDK-8186317). The latter, > I believe, > >> > becomes redundant with this fix. > >> > > >> > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 > >> > Webrev: > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ < > http://cr.openjdk.java.net/%7Edbatrak/8220231/webrev.00/> > >> > > > >> > > >> > Best regards, > >> > Dmitry Batrak > >> > > >> > >> > >> > > > > > > -- > > Dmitry Batrak > > Senior Software Developer > > JetBrains > > http://www.jetbrains.com > > The Drive to Develop > > > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Apr 11 16:45:34 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 11 Apr 2019 09:45:34 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: <5C81B594.6060209@oracle.com> <5C9937BF.9010500@oracle.com> <7a2c7b7c-bebf-99e6-85dc-306508f67f2c@oracle.com> Message-ID: OK .. since no one else seems to be doing this I'll handle it for you. -phil. On 4/9/19 12:28 AM, Dmitry Batrak wrote: > Thanks! > > Hopefully someone can push (sponsor) it now. > > Best regards, > Dmitry Batrak > > > On Mon, Apr 8, 2019 at 10:16 PM Sergey Bylokhov > > wrote: > > +1 > > On 01/04/2019 02:12, Alexey Ushakov wrote: > > Looks good for me. > > > > Best Regards, > > Alexey > > > > On Mon, Apr 1, 2019 at 10:46 AM Dmitry Batrak > > >> wrote: > > > >? ? ? > Sorry for the delay. I've now finished verifying this and > it is a +1 from me. > >? ? ?Thanks! > > > >? ? ?Anyone else, please? A second reviewer is required. > > > >? ? ?On Mon, Mar 25, 2019 at 11:19 PM Philip Race > > >> > wrote: > > > >? ? ? ? ?Sorry for the delay. I've now finished verifying this > and it is a +1 from me. > > > >? ? ? ? ?-phil. > > > >? ? ? ? ?On 3/12/19, 1:32 AM, Dmitry Batrak wrote: > >>? ? ? ? ?> This looks good to me, if I understand correctly that > we now create > >>? ? ? ? ?> the face on first use and cache it fin Java or as > long as the Font2D is > >>? ? ? ? ?> alive. > >>? ? ? ? ?> And the JNIEnv is always found on > >>? ? ? ? ?That's correct. The assumption is that HarfBuzz doesn't > create its own threads, > >>? ? ? ? ?so HarfBuzz-related native code will always be invoked > from a Java thread > >>? ? ? ? ?(as part of 'shape' call), and so JNIEnv will be > available in that context. > >> > >>? ? ? ? ?I've updated the webrev by including a stress test for > multi-threaded behaviour > >>? ? ? ? ?testing. Apart from the test, webrev also has some > cosmetic differences > >>? ? ? ? ?from the previous version (like a comment fix or > parameter order changing), > >>? ? ? ? ?appeared during 'splitting' process. To simplify the > review, I'm also providing > >>? ? ? ? ?the links to the 'split' version of the same webrev - > three parts that produce > >>? ? ? ? ?the same result when combined. I've not tested the > changes separately > >>? ? ? ? ?(except basic compilation check). > >> > >>? ? ? ? ?Complete change: > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ > > >>? ? ? ? ?Part 1 (caching hb_face_t): > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ > > >>? ? ? ? ?Part 2 (tables caching removal): > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ > > >>? ? ? ? ?Part 3 (scaler pointer passing removal): > >> http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ > > >> > >>? ? ? ? ?Best regards, > >>? ? ? ? ?Dmitry Batrak > >> > >>? ? ? ? ?On Fri, Mar 8, 2019 at 3:21 AM Philip Race > > >> > wrote: > >> > >>? ? ? ? ? ? ?This looks good to me, if I understand correctly > that we now create > >>? ? ? ? ? ? ?the face on first use and cache it fin Java or as > long as the Font2D is > >>? ? ? ? ? ? ?alive. > >>? ? ? ? ? ? ?And the JNIEnv is always found on > >> > >>? ? ? ? ? ? ?I think you are right that we don't need the > caching of the tables since > >>? ? ? ? ? ? ?now the face will do it. The unfortunate thing is > that the removal of > >>? ? ? ? ? ? ?this code is > >>? ? ? ? ? ? ?well over half the changes and as such it greatly > muddied finding the > >>? ? ? ? ? ? ?changes > >>? ? ? ? ? ? ?that make the performance difference so my review > was harder and less > >>? ? ? ? ? ? ?certain > >>? ? ? ? ? ? ?because of that. > >>? ? ? ? ? ? ?It could have been separated into a follow-on > change I think so that it > >>? ? ? ? ? ? ?would have > >>? ? ? ? ? ? ?been easier to review the important change. > >> > >>? ? ? ? ? ? ?The pScaler parameter looks like it is unused these > days which is why I > >>? ? ? ? ? ? ?expect you removed it but also not directly relevant. > >> > >>? ? ? ? ? ? ?I have run builds + some tests - but I'm not in a > position to run more tests > >>? ? ? ? ? ? ?for a couple of weeks. > >> > >>? ? ? ? ? ? ?A (mild) stress test re-using the same font from > multiple threads eachmaking > >>? ? ? ? ? ? ?multiple calls into layout would be a good addition > here. That should > >>? ? ? ? ? ? ?help tell > >>? ? ? ? ? ? ?us if there are any MT or re-entrancy problems. Can > you provide such a > >>? ? ? ? ? ? ?test ? > >>? ? ? ? ? ? ?It will be a good thing to have automatically run > to catch any problems > >>? ? ? ? ? ? ?introduced later either on the Java side or by an > update to harfbuzz. > >> > >>? ? ? ? ? ? ?-phil. > >> > >> > >> > >>? ? ? ? ? ? ?On 3/6/19, 5:45 PM, Dmitry Batrak wrote: > >>? ? ? ? ? ? ?> Hello, > >>? ? ? ? ? ? ?> > >>? ? ? ? ? ? ?> I'd like to submit a patch for JDK-8220231. I'm > not a Committer, so > >>? ? ? ? ? ? ?> I'll need someone to sponsor this change. > >>? ? ? ? ? ? ?> > >>? ? ? ? ? ? ?> The proposed approach is used without known > issues in OpenJDK-based > >>? ? ? ? ? ? ?> JetBrains Runtime for almost three years now. > I've mentioned it > >>? ? ? ? ? ? ?> previously on this mailing list > >>? ? ? ? ? ? ?> > (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). > >>? ? ? ? ? ? ?> The change has been refactored as compared to the > version mentioned > >>? ? ? ? ? ? ?> above (the logic has been moved to > SunLayoutEngine), and includes the > >>? ? ? ? ? ? ?> removal of font tables caching (JDK-8186317). The > latter, I believe, > >>? ? ? ? ? ? ?> becomes redundant with this fix. > >>? ? ? ? ? ? ?> > >>? ? ? ? ? ? ?> Issue: > https://bugs.openjdk.java.net/browse/JDK-8220231 > >>? ? ? ? ? ? ?> Webrev: > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ > > >>? ? ? ? ? ? ?> > > >>? ? ? ? ? ? ?> > >>? ? ? ? ? ? ?> Best regards, > >>? ? ? ? ? ? ?> Dmitry Batrak > >>? ? ? ? ? ? ?> > >> > >> > >> > > > > > >? ? ?-- > >? ? ?Dmitry Batrak > >? ? ?Senior Software Developer > >? ? ?JetBrains > > http://www.jetbrains.com > >? ? ?The Drive to Develop > > > > > -- > Best regards, Sergey. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Apr 16 23:40:14 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 16 Apr 2019 16:40:14 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8222362: Upgrade to Freetype 2.10.0 Message-ID: <5CB667DE.3050702@oracle.com> freetype 2.10 has been released and this fix upgrades the JDK's internal copy from the previous latest of 2.9.1 Bug : https://bugs.openjdk.java.net/browse/JDK-8222362 Webrev : http://cr.openjdk.java.net/~prr/8222362/ Built on all platforms - tested using --with-freetype=bundled Automated regression tests run Verified manually with Font2DTest & SwingSet2 The license is the same - just a version update is needed. A couple of new build warnings needed to be disabled and there was a build problem on Windows, so one change in AwtLibraries.gmk is to deal with this error : > t:\workspace\build\windows-x64\support\native\java.desktop\libfreetype\freetype.lib : fatal error LNK1136: invalid or corrupt file > Awt2dLibraries.gmk:602: recipe for target '/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll' failed > make[3]: *** [/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll] Error 1 The problem is that freetype.lib is empty (0 bytes) I inferred this was because for some reason there was no longer anything being exported. Hunting sound the source diff I found this : src/java.desktop/share/native/libfreetype/include/freetype/config/ftconfig.h.udiff.html -#if defined( _WIN32 )&& ( defined( _DLL ) || defined( DLL_EXPORT ) ) +#if defined( _WIN32 )&& defined( DLL_EXPORT ) #define FT_EXPORT( x ) __declspec( dllexport ) x Since we were are passing /MD to VC++ cl.exe will define _DLL for us, but now freetype no longer looks for it. This can be tracked back to a change in freetype build so that it relies on an explicit define of DLL_EXPORT set up in the vcxproj file. The comment as to why is below although I don't really understand if the reference to static builds is meant to be a justification. My best guess is that they are trying to say that even if _DLL is defined sometimes you maybe don't want/ need to exports ymbols so we are now going to make you say so explicitly using DLL_EXPORT. >We no longer use predefined _DLL, which can be defined for static builds too with /MD. >We use DLL_EXPORT and DLL_IMPORT instead, following libtool convention. https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/builds/windows/vc2010/freetype.vcxproj?id=4b97ab98a8e90ae5403058b73c345974247bf01e https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/include/freetype/config/ftconfig.h?id=4b97ab98a8e90ae5403058b73c345974247bf01e ---- So my fix is to add the same manual define to our build as used by freetype. -phil. From erik.joelsson at oracle.com Wed Apr 17 13:15:56 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Apr 2019 06:15:56 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8222362: Upgrade to Freetype 2.10.0 In-Reply-To: <5CB667DE.3050702@oracle.com> References: <5CB667DE.3050702@oracle.com> Message-ID: <5848d6bb-9854-46a1-9c0f-e76f2fc53a90@oracle.com> Looks good! /Erik On 2019-04-16 16:40, Philip Race wrote: > freetype 2.10 has been released and this fix upgrades > the JDK's internal copy from the previous latest of 2.9.1 > > Bug : https://bugs.openjdk.java.net/browse/JDK-8222362 > Webrev : http://cr.openjdk.java.net/~prr/8222362/ > Built on all platforms - tested using --with-freetype=bundled > Automated regression tests run > Verified manually with Font2DTest & SwingSet2 > The license is the same - just a version update is needed. > > A couple of new build warnings needed to be disabled and > there was a build problem on Windows, so one change > in AwtLibraries.gmk is to deal with this error : > > > ?> > t:\workspace\build\windows-x64\support\native\java.desktop\libfreetype\freetype.lib > : fatal error LNK1136: invalid or corrupt file > ?>? Awt2dLibraries.gmk:602: recipe for target > '/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll' > failed > ?>? make[3]: *** > [/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll] > Error 1 > > The problem is that freetype.lib is empty (0 bytes) > I inferred this was because for some reason there was no longer > anything being exported. > > Hunting sound the source diff I found this : > > src/java.desktop/share/native/libfreetype/include/freetype/config/ftconfig.h.udiff.html > > > -#if defined( _WIN32 )&&? ( defined( _DLL ) || defined( DLL_EXPORT ) ) > +#if defined( _WIN32 )&&? defined( DLL_EXPORT ) > #define FT_EXPORT( x )? __declspec( dllexport )? x > > > Since we were are passing /MD to VC++ cl.exe will define _DLL for us, but > now freetype no longer looks for it. > > This can be tracked back to a change in freetype build so that it > relies on > an explicit define of DLL_EXPORT set up in the vcxproj file. > The comment as to why is below although I don't really understand if > the reference > to static builds is meant to be a justification. My best guess is that > they > are trying to say that even if _DLL is defined sometimes you maybe > don't want/ need to > exports ymbols so we are now going to make you say so explicitly using > DLL_EXPORT. > > >We no longer use predefined _DLL, which can be defined for static > builds too with /MD. > >We use DLL_EXPORT and DLL_IMPORT instead, following libtool convention. > > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/builds/windows/vc2010/freetype.vcxproj?id=4b97ab98a8e90ae5403058b73c345974247bf01e > > > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/include/freetype/config/ftconfig.h?id=4b97ab98a8e90ae5403058b73c345974247bf01e > > ---- > > So my fix is to add the same manual define to our build as used by > freetype. > > -phil. From Sergey.Bylokhov at oracle.com Wed Apr 17 23:06:27 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 17 Apr 2019 16:06:27 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8222362: Upgrade to Freetype 2.10.0 In-Reply-To: <5848d6bb-9854-46a1-9c0f-e76f2fc53a90@oracle.com> References: <5CB667DE.3050702@oracle.com> <5848d6bb-9854-46a1-9c0f-e76f2fc53a90@oracle.com> Message-ID: <773e8acb-5f99-61fb-c60f-96c0b70ef1bc@oracle.com> +1 On 17/04/2019 06:15, Erik Joelsson wrote: > Looks good! > > /Erik > > On 2019-04-16 16:40, Philip Race wrote: >> freetype 2.10 has been released and this fix upgrades >> the JDK's internal copy from the previous latest of 2.9.1 >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8222362 >> Webrev : http://cr.openjdk.java.net/~prr/8222362/ >> Built on all platforms - tested using --with-freetype=bundled >> Automated regression tests run >> Verified manually with Font2DTest & SwingSet2 >> The license is the same - just a version update is needed. >> >> A couple of new build warnings needed to be disabled and >> there was a build problem on Windows, so one change >> in AwtLibraries.gmk is to deal with this error : >> >> >> ?> t:\workspace\build\windows-x64\support\native\java.desktop\libfreetype\freetype.lib : fatal error LNK1136: invalid or corrupt file >> ?>? Awt2dLibraries.gmk:602: recipe for target '/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll' failed >> ?>? make[3]: *** [/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll] Error 1 >> >> The problem is that freetype.lib is empty (0 bytes) >> I inferred this was because for some reason there was no longer anything being exported. >> >> Hunting sound the source diff I found this : >> >> src/java.desktop/share/native/libfreetype/include/freetype/config/ftconfig.h.udiff.html >> >> -#if defined( _WIN32 )&&? ( defined( _DLL ) || defined( DLL_EXPORT ) ) >> +#if defined( _WIN32 )&&? defined( DLL_EXPORT ) >> #define FT_EXPORT( x )? __declspec( dllexport )? x >> >> >> Since we were are passing /MD to VC++ cl.exe will define _DLL for us, but >> now freetype no longer looks for it. >> >> This can be tracked back to a change in freetype build so that it relies on >> an explicit define of DLL_EXPORT set up in the vcxproj file. >> The comment as to why is below although I don't really understand if the reference >> to static builds is meant to be a justification. My best guess is that they >> are trying to say that even if _DLL is defined sometimes you maybe don't want/ need to >> exports ymbols so we are now going to make you say so explicitly using DLL_EXPORT. >> >> >We no longer use predefined _DLL, which can be defined for static builds too with /MD. >> >We use DLL_EXPORT and DLL_IMPORT instead, following libtool convention. >> >> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/builds/windows/vc2010/freetype.vcxproj?id=4b97ab98a8e90ae5403058b73c345974247bf01e >> >> https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/include/freetype/config/ftconfig.h?id=4b97ab98a8e90ae5403058b73c345974247bf01e >> ---- >> >> So my fix is to add the same manual define to our build as used by freetype. >> >> -phil. -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Thu Apr 18 06:55:56 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 18 Apr 2019 15:55:56 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <5CA4DAB9.2060602@oracle.com> References: <5CA4DAB9.2060602@oracle.com> Message-ID: <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> Hello Phil. I appreciate your reply. I put problem analysis information in JDK-8221741 [1]. The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like: $ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2] Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome) [1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-04-04 01:09, Philip Race wrote: > On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >> Hello. >> (I am sorry to post it again. Previously, I posted the wrong mailing >> list.) >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >> >> I'd like to obtain a sponsor for this issue. >> >> On AIX platform, fontconfig.properties file is used to pick up proper >> fonts. >> TrueType font settings are written by XLFD format on >> fontconfig.properties file. >> >> On current implementation, Java tries to load X11 bitmap fonts even if >> these are not used. > > I think you need to clarify what you mean here. > > I'd like you to provide a step by step analysis of what happens and > what the effect of your proposed change is on AIX *AND* what it might > mean for other X11 platforms, as I don't have time to reverse engineer > the > reasons for the odd-looking change. > It looks like a hack to short-circuit support your syntax. > Right now I am saying no to this. > >> This font load work is almost name as "xlsfonts -ll". >> It spends many CPU time and memories. >> >> Just font name format should be supported. > > Not clear enough for me. > > -phil. >> >> To SAP representative, >> I have a question about copyright year on >> make/data/fontconfig/aix.fontconfig.properties. >> Please let me know how I should write down copyright year. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From philip.race at oracle.com Thu Apr 18 20:20:10 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 18 Apr 2019 13:20:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> Message-ID: <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ? -phil. On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: > Hello Phil. > > I appreciate your reply. > I put problem analysis information in JDK-8221741 [1]. > > The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. > According to my problem analysis, > In this case, Java tried to load large 11 X11 bitmap fonts via > XLoadQueryFont() on Xlib. > The situation can emulate by "xlsfonts -ll" command, like: > > $ time xlsfonts -ll -fn > "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" > ... > real??? 0m2.07s > user??? 0m0.00s > sys 0m0.00s > > One of solution is, Unix's fontconfig.properties can support > TrueType/Type1 font name format. [2] > > Anyway, > I don't know the reason why X11 bitmap font is required for logical font. > (I don't know how to use X11 bitmap font for physical font. > I could not see X11 bitmap font name via > GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) > > I just want to fix Xserver frozen issue. > I appreciate your advice. > (Other solutions are welcome) > > [1] https://bugs.openjdk.java.net/browse/JDK-8221741 > [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-04-04 01:09, Philip Race wrote: >> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>> Hello. >>> (I am sorry to post it again. Previously, I posted the wrong mailing >>> list.) >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> On AIX platform, fontconfig.properties file is used to pick up >>> proper fonts. >>> TrueType font settings are written by XLFD format on >>> fontconfig.properties file. >>> >>> On current implementation, Java tries to load X11 bitmap fonts even >>> if these are not used. >> >> I think you need to clarify what you mean here. >> >> I'd like you to provide a step by step analysis of what happens and >> what the effect of your proposed change is on AIX *AND* what it might >> mean for other X11 platforms, as I don't have time to reverse >> engineer the >> reasons for the odd-looking change. >> It looks like a hack to short-circuit support your syntax. >> Right now I am saying no to this. >> >>> This font load work is almost name as "xlsfonts -ll". >>> It spends many CPU time and memories. >>> >>> Just font name format should be supported. >> >> Not clear enough for me. >> >> -phil. >>> >>> To SAP representative, >>> I have a question about copyright year on >>> make/data/fontconfig/aix.fontconfig.properties. >>> Please let me know how I should write down copyright year. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> > From takiguc at linux.vnet.ibm.com Fri Apr 19 12:18:44 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 19 Apr 2019 21:18:44 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> Message-ID: Hello Phil. I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself) To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) at sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) ... I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. Thanks, Ichiroh Takiguchi On 2019-04-19 05:20, Phil Race wrote: > On startup ? > What is the Java stack trace that gets you into that call ? > Is it this with any modified IBM code, or pure OpenJDK ? > > -phil. > > On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I appreciate your reply. >> I put problem analysis information in JDK-8221741 [1]. >> >> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >> box. >> According to my problem analysis, >> In this case, Java tried to load large 11 X11 bitmap fonts via >> XLoadQueryFont() on Xlib. >> The situation can emulate by "xlsfonts -ll" command, like: >> >> $ time xlsfonts -ll -fn >> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >> ... >> real??? 0m2.07s >> user??? 0m0.00s >> sys 0m0.00s >> >> One of solution is, Unix's fontconfig.properties can support >> TrueType/Type1 font name format. [2] >> >> Anyway, >> I don't know the reason why X11 bitmap font is required for logical >> font. >> (I don't know how to use X11 bitmap font for physical font. >> I could not see X11 bitmap font name via >> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >> I just want to fix Xserver frozen issue. >> I appreciate your advice. >> (Other solutions are welcome) >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-04-04 01:09, Philip Race wrote: >>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>> Hello. >>>> (I am sorry to post it again. Previously, I posted the wrong mailing >>>> list.) >>>> >>>> Could you review the fix ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> On AIX platform, fontconfig.properties file is used to pick up >>>> proper fonts. >>>> TrueType font settings are written by XLFD format on >>>> fontconfig.properties file. >>>> >>>> On current implementation, Java tries to load X11 bitmap fonts even >>>> if these are not used. >>> >>> I think you need to clarify what you mean here. >>> >>> I'd like you to provide a step by step analysis of what happens and >>> what the effect of your proposed change is on AIX *AND* what it might >>> mean for other X11 platforms, as I don't have time to reverse >>> engineer the >>> reasons for the odd-looking change. >>> It looks like a hack to short-circuit support your syntax. >>> Right now I am saying no to this. >>> >>>> This font load work is almost name as "xlsfonts -ll". >>>> It spends many CPU time and memories. >>>> >>>> Just font name format should be supported. >>> >>> Not clear enough for me. >>> >>> -phil. >>>> >>>> To SAP representative, >>>> I have a question about copyright year on >>>> make/data/fontconfig/aix.fontconfig.properties. >>>> Please let me know how I should write down copyright year. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >> From philip.race at oracle.com Fri Apr 19 18:55:11 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Apr 2019 11:55:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> Message-ID: <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason. ??? protected void registerFontFile(String fontFileName, String[] nativeNames, ??????????????????????????????????? int fontRank, boolean defer) { //????? REMIND: case compare depends on platform ??????? if (registeredFontFiles.contains(fontFileName)) { ??????????? return; ??????? } ??????? int fontFormat; ??????? if (ttFilter.accept(null, fontFileName)) { ??????????? fontFormat = FONTFORMAT_TRUETYPE; ??????? } else if (t1Filter.accept(null, fontFileName)) { ??????????? fontFormat = FONTFORMAT_TYPE1; ??????? } else { ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I think you are getting here, but why ? ??????? } -phil. On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: > Hello Phil. > > I'm using standard OpenJDK JDK13 b13 for AIX, like: > openjdk version "13-internal" 2019-09-17 > OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) > OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) > (Compiled it by myself) > > To see stack trace, I tried following instruction: > ?1. Login to AIX box from another machine > ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale > (Ja_JP) or C locale > ?3. Open terminal, like dtterm on local AIX box > ?4. Start SwingSet2 demo program > ?5. Check java's process id > ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side > ?7. Move mouse cursor on cow image to display ToolTip > ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped > ??? (I said this situation was "frozen".) > ?9. After Xserver was frozen, execute "kill -3" with java process id > 10. Then stack trace is displayed > > "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s > tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] > ?? java.lang.Thread.State: RUNNABLE > ??? at sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native > Method) > ??? at > sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) > ??? at > sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) > ??? at > sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) > ??? at > sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) > ... > > I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. > > Thanks, > Ichiroh Takiguchi > > On 2019-04-19 05:20, Phil Race wrote: >> On startup ? >> What is the Java stack trace that gets you into that call ? >> Is it this with any modified IBM code, or pure OpenJDK ? >> >> -phil. >> >> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> I appreciate your reply. >>> I put problem analysis information in JDK-8221741 [1]. >>> >>> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >>> box. >>> According to my problem analysis, >>> In this case, Java tried to load large 11 X11 bitmap fonts via >>> XLoadQueryFont() on Xlib. >>> The situation can emulate by "xlsfonts -ll" command, like: >>> >>> $ time xlsfonts -ll -fn >>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>> ... >>> real??? 0m2.07s >>> user??? 0m0.00s >>> sys 0m0.00s >>> >>> One of solution is, Unix's fontconfig.properties can support >>> TrueType/Type1 font name format. [2] >>> >>> Anyway, >>> I don't know the reason why X11 bitmap font is required for logical >>> font. >>> (I don't know how to use X11 bitmap font for physical font. >>> I could not see X11 bitmap font name via >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>> I just want to fix Xserver frozen issue. >>> I appreciate your advice. >>> (Other solutions are welcome) >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2019-04-04 01:09, Philip Race wrote: >>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>> mailing list.) >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>> proper fonts. >>>>> TrueType font settings are written by XLFD format on >>>>> fontconfig.properties file. >>>>> >>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>> even if these are not used. >>>> >>>> I think you need to clarify what you mean here. >>>> >>>> I'd like you to provide a step by step analysis of what happens and >>>> what the effect of your proposed change is on AIX *AND* what it might >>>> mean for other X11 platforms, as I don't have time to reverse >>>> engineer the >>>> reasons for the odd-looking change. >>>> It looks like a hack to short-circuit support your syntax. >>>> Right now I am saying no to this. >>>> >>>>> This font load work is almost name as "xlsfonts -ll". >>>>> It spends many CPU time and memories. >>>>> >>>>> Just font name format should be supported. >>>> >>>> Not clear enough for me. >>>> >>>> -phil. >>>>> >>>>> To SAP representative, >>>>> I have a question about copyright year on >>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>> Please let me know how I should write down copyright year. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>> > From philip.race at oracle.com Sat Apr 20 23:29:35 2019 From: philip.race at oracle.com (Philip Race) Date: Sat, 20 Apr 2019 16:29:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK Message-ID: <5CBBAB5F.6080009@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8208179 Webrev: http://cr.openjdk.java.net/~prr/8208179/index.html The original complaint is missing devanagari in logical fonts in Oracle JDK 11. I realised in looking at this that we are also missing Thai. The reason is that Lucida Sans was removed and there are no windows fonts configured to replace these. In fixing this we can also add support for other Indic scripts and Khmer + Mongolian too as Windows 7 and later all contain suitable UI fonts. One wrinkle is that we will be more likely to trip over a small bug whereby if we have registered one font in a family due to it being mentioned in a logical font and that font can be used to synthesis another style of that font, we don't go to check to see if there is a system font of the exact style. FontFamily.getFont(String name, int style) has a comment warning of this possibility. This was observed that Mangal hid Mangal Bold for example, and inconsistently if you used the Mangal Bold font directly it was not hidden and would be used. So the fix adds a call to an existing method which will resolve all fonts in that family first. A test is provided which verifies the scripts are now supported by the logical fonts on Windows. -phil. From TOSHIONA at jp.ibm.com Tue Apr 23 10:14:55 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Tue, 23 Apr 2019 10:14:55 +0000 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: , <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com> <5C84D34E.2070601@oracle.com> <5CA57199.3050405@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Apr 24 07:35:50 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Apr 2019 00:35:50 -0700 Subject: [OpenJDK 2D-Dev] [13] Review Request: 8222917 GraphicsEnvironment for Unix still have an unused dependency on Solaris Message-ID: <0c0e6bc2-5b3b-fa0f-6070-84a32dfcaa5f@oracle.com> Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8222917 Fix: http://cr.openjdk.java.net/~serb/8222917/webrev.00 The SunGraphicsEnvironment has a codepath for the OpenSolaris, but in fact results on this execution is never used. This code was added in JDK-6378099: http://hg.openjdk.java.net/jdk/client/rev/c3e81f0acd3d#l5.7 But the usage of isOpenSolaris flag was dropped in JDK-6795908: http://hg.openjdk.java.net/jdk/client/rev/be186a33df9b#l45.717 In this fix, the unused code was removed. BTW I am not sure why we set the default font for SG2D in the constructor of SunGraphicsEnvironment and not assign the field directly? Probably the reason is related to some cyclic dependency?. -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Thu Apr 25 12:10:00 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 25 Apr 2019 21:10:00 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Message-ID: <02de48ec15c2446830715b1608800694@linux.vnet.ibm.com> Hello Phil. I appreciate your suggestion. I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font. On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility. On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-20 03:55, Phil Race wrote: > Something must have gone wrong upstream to have this font registered > as a native font. > You should trace back to find out. I suggest to start with this code > in SunFontManager.java, > where I am guessing you don't have the file name for some reason. > > ??? protected void registerFontFile(String fontFileName, String[] > nativeNames, > ??????????????????????????????????? > int fontRank, boolean defer) { > //????? REMIND: case compare depends on platform > ??????? if (registeredFontFiles.contains(fontFileName)) { > ??????????? return; > ??????? } > ??????? int fontFormat; > ??????? if (ttFilter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TRUETYPE; > ??????? } else if (t1Filter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TYPE1; > ??????? } else { > ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I > think you are getting here, but why ? > ??????? } > > -phil. > > On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I'm using standard OpenJDK JDK13 b13 for AIX, like: >> openjdk version "13-internal" 2019-09-17 >> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) >> (Compiled it by myself) >> >> To see stack trace, I tried following instruction: >> ?1. Login to AIX box from another machine >> ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale >> (Ja_JP) or C locale >> ?3. Open terminal, like dtterm on local AIX box >> ?4. Start SwingSet2 demo program >> ?5. Check java's process id >> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >> ?7. Move mouse cursor on cow image to display ToolTip >> ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped >> ??? (I said this situation was "frozen".) >> ?9. After Xserver was frozen, execute "kill -3" with java process id >> 10. Then stack trace is displayed >> >> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s >> tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] >> ?? java.lang.Thread.State: RUNNABLE >> ??? at >> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native >> Method) >> ??? at >> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >> ??? at >> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >> ??? at >> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >> ??? at >> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >> ... >> >> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-04-19 05:20, Phil Race wrote: >>> On startup ? >>> What is the Java stack trace that gets you into that call ? >>> Is it this with any modified IBM code, or pure OpenJDK ? >>> >>> -phil. >>> >>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> I appreciate your reply. >>>> I put problem analysis information in JDK-8221741 [1]. >>>> >>>> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >>>> box. >>>> According to my problem analysis, >>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>> XLoadQueryFont() on Xlib. >>>> The situation can emulate by "xlsfonts -ll" command, like: >>>> >>>> $ time xlsfonts -ll -fn >>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>> ... >>>> real??? 0m2.07s >>>> user??? 0m0.00s >>>> sys 0m0.00s >>>> >>>> One of solution is, Unix's fontconfig.properties can support >>>> TrueType/Type1 font name format. [2] >>>> >>>> Anyway, >>>> I don't know the reason why X11 bitmap font is required for logical >>>> font. >>>> (I don't know how to use X11 bitmap font for physical font. >>>> I could not see X11 bitmap font name via >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>> I just want to fix Xserver frozen issue. >>>> I appreciate your advice. >>>> (Other solutions are welcome) >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2019-04-04 01:09, Philip Race wrote: >>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>> mailing list.) >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>>> proper fonts. >>>>>> TrueType font settings are written by XLFD format on >>>>>> fontconfig.properties file. >>>>>> >>>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>>> even if these are not used. >>>>> >>>>> I think you need to clarify what you mean here. >>>>> >>>>> I'd like you to provide a step by step analysis of what happens and >>>>> what the effect of your proposed change is on AIX *AND* what it >>>>> might >>>>> mean for other X11 platforms, as I don't have time to reverse >>>>> engineer the >>>>> reasons for the odd-looking change. >>>>> It looks like a hack to short-circuit support your syntax. >>>>> Right now I am saying no to this. >>>>> >>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>> It spends many CPU time and memories. >>>>>> >>>>>> Just font name format should be supported. >>>>> >>>>> Not clear enough for me. >>>>> >>>>> -phil. >>>>>> >>>>>> To SAP representative, >>>>>> I have a question about copyright year on >>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>> Please let me know how I should write down copyright year. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>> >> From takiguc at linux.vnet.ibm.com Thu Apr 25 12:27:31 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 25 Apr 2019 21:27:31 +0900 Subject: [OpenJDK 2D-Dev] [Resend] Re: RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Message-ID: (Sorry, please ignore previous mail, it has wrong link for "Change") Hello Phil. I appreciate your suggestion. I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font. On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility. On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-20 03:55, Phil Race wrote: > Something must have gone wrong upstream to have this font registered > as a native font. > You should trace back to find out. I suggest to start with this code > in SunFontManager.java, > where I am guessing you don't have the file name for some reason. > > ??? protected void registerFontFile(String fontFileName, String[] > nativeNames, > ??????????????????????????????????? > int fontRank, boolean defer) { > //????? REMIND: case compare depends on platform > ??????? if (registeredFontFiles.contains(fontFileName)) { > ??????????? return; > ??????? } > ??????? int fontFormat; > ??????? if (ttFilter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TRUETYPE; > ??????? } else if (t1Filter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TYPE1; > ??????? } else { > ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I > think you are getting here, but why ? > ??????? } > > -phil. > > On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I'm using standard OpenJDK JDK13 b13 for AIX, like: >> openjdk version "13-internal" 2019-09-17 >> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) >> (Compiled it by myself) >> >> To see stack trace, I tried following instruction: >> ?1. Login to AIX box from another machine >> ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale >> (Ja_JP) or C locale >> ?3. Open terminal, like dtterm on local AIX box >> ?4. Start SwingSet2 demo program >> ?5. Check java's process id >> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >> ?7. Move mouse cursor on cow image to display ToolTip >> ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped >> ??? (I said this situation was "frozen".) >> ?9. After Xserver was frozen, execute "kill -3" with java process id >> 10. Then stack trace is displayed >> >> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s >> tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] >> ?? java.lang.Thread.State: RUNNABLE >> ??? at >> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native >> Method) >> ??? at >> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >> ??? at >> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >> ??? at >> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >> ??? at >> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >> ... >> >> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-04-19 05:20, Phil Race wrote: >>> On startup ? >>> What is the Java stack trace that gets you into that call ? >>> Is it this with any modified IBM code, or pure OpenJDK ? >>> >>> -phil. >>> >>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> I appreciate your reply. >>>> I put problem analysis information in JDK-8221741 [1]. >>>> >>>> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >>>> box. >>>> According to my problem analysis, >>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>> XLoadQueryFont() on Xlib. >>>> The situation can emulate by "xlsfonts -ll" command, like: >>>> >>>> $ time xlsfonts -ll -fn >>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>> ... >>>> real??? 0m2.07s >>>> user??? 0m0.00s >>>> sys 0m0.00s >>>> >>>> One of solution is, Unix's fontconfig.properties can support >>>> TrueType/Type1 font name format. [2] >>>> >>>> Anyway, >>>> I don't know the reason why X11 bitmap font is required for logical >>>> font. >>>> (I don't know how to use X11 bitmap font for physical font. >>>> I could not see X11 bitmap font name via >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>> I just want to fix Xserver frozen issue. >>>> I appreciate your advice. >>>> (Other solutions are welcome) >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2019-04-04 01:09, Philip Race wrote: >>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>> mailing list.) >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>>> proper fonts. >>>>>> TrueType font settings are written by XLFD format on >>>>>> fontconfig.properties file. >>>>>> >>>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>>> even if these are not used. >>>>> >>>>> I think you need to clarify what you mean here. >>>>> >>>>> I'd like you to provide a step by step analysis of what happens and >>>>> what the effect of your proposed change is on AIX *AND* what it >>>>> might >>>>> mean for other X11 platforms, as I don't have time to reverse >>>>> engineer the >>>>> reasons for the odd-looking change. >>>>> It looks like a hack to short-circuit support your syntax. >>>>> Right now I am saying no to this. >>>>> >>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>> It spends many CPU time and memories. >>>>>> >>>>>> Just font name format should be supported. >>>>> >>>>> Not clear enough for me. >>>>> >>>>> -phil. >>>>>> >>>>>> To SAP representative, >>>>>> I have a question about copyright year on >>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>> Please let me know how I should write down copyright year. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>> >> From philip.race at oracle.com Thu Apr 25 15:53:06 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Apr 2019 08:53:06 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK In-Reply-To: <5CBBAB5F.6080009@oracle.com> References: <5CBBAB5F.6080009@oracle.com> Message-ID: <294b1678-7516-6db2-9d5d-e8b19153b39b@oracle.com> Any takers ? Jay ? Also adding i18n-dev. -phil. On 4/20/19 4:29 PM, Philip Race wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208179 > Webrev: http://cr.openjdk.java.net/~prr/8208179/index.html > > The original complaint is missing devanagari in logical fonts in > Oracle JDK 11. > I realised in looking at this that we are also missing Thai. > The reason is that Lucida Sans was removed and there are no windows fonts > configured to replace these. > In fixing this we can also add support for other Indic scripts and > Khmer + Mongolian too > as Windows 7 and later all contain suitable UI fonts. > > One wrinkle is that we will be more likely to trip over a small bug > whereby > if we have registered one font in a family due to it being mentioned > in a logical > font and that font can be used to synthesis another style of that > font, we don't > go to check to see if there is a system font of the exact style. > FontFamily.getFont(String name, int style) has a comment warning of > this possibility. > This was observed that Mangal hid Mangal Bold for example, and > inconsistently if > you used the Mangal Bold font directly it was not hidden and would be > used. > So the fix adds a call to an existing method which will resolve all > fonts in that family first. > > A test is provided which verifies the scripts are now supported by the > logical fonts on Windows. > > -phil. > > From naoto.sato at oracle.com Thu Apr 25 17:00:52 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 25 Apr 2019 10:00:52 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK In-Reply-To: <294b1678-7516-6db2-9d5d-e8b19153b39b@oracle.com> References: <5CBBAB5F.6080009@oracle.com> <294b1678-7516-6db2-9d5d-e8b19153b39b@oracle.com> Message-ID: <8224e2e7-cc02-7393-4ac2-2f7c86603524@oracle.com> Looks good to me. Naoto On 4/25/19 8:53 AM, Phil Race wrote: > Any takers ? Jay ? Also adding i18n-dev. > > -phil. > > On 4/20/19 4:29 PM, Philip Race wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8208179 >> Webrev: http://cr.openjdk.java.net/~prr/8208179/index.html >> >> The original complaint is missing devanagari in logical fonts in >> Oracle JDK 11. >> I realised in looking at this that we are also missing Thai. >> The reason is that Lucida Sans was removed and there are no windows fonts >> configured to replace these. >> In fixing this we can also add support for other Indic scripts and >> Khmer + Mongolian too >> as Windows 7 and later all contain suitable UI fonts. >> >> One wrinkle is that we will be more likely to trip over a small bug >> whereby >> if we have registered one font in a family due to it being mentioned >> in a logical >> font and that font can be used to synthesis another style of that >> font, we don't >> go to check to see if there is a system font of the exact style. >> FontFamily.getFont(String name, int style) has a comment warning of >> this possibility. >> This was observed that Mangal hid Mangal Bold for example, and >> inconsistently if >> you used the Mangal Bold font directly it was not hidden and would be >> used. >> So the fix adds a call to an existing method which will resolve all >> fonts in that family first. >> >> A test is provided which verifies the scripts are now supported by the >> logical fonts on Windows. >> >> -phil. >> >> > From philip.race at oracle.com Thu Apr 25 20:12:52 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Apr 2019 13:12:52 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class Message-ID: <2923a8bb-bf80-d9c0-3150-d4fe05cada60@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8130266 CSR: https://bugs.openjdk.java.net/browse/JDK- Webrev: http://cr.openjdk.java.net/~prr/8130266/ Please review this fix + the CSR which eliminates the java.awt.graphicenv System property. To replace it we have platform-specific classes which can then more easily embed platform-specific logic. For example, logic in java.awt.GraphicsEnvironment was then moved down into this class. Also isInAquaSession used on Mac was moved into that class from the Mac Toolkit class. A reference to the property in J2D Bench - just used to log / document the testing environment was removed along with similar references to two other properties removed in earlier fixes. This has been built + tested on Mac, Linux + Windows in headful mode and also specifying headless via -Djava.awt.headless and by letting it default to headless in an ssh session on Mac + by unsetting the DISPLAY variable on Linux. -phil. From philip.race at oracle.com Thu Apr 25 20:32:27 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Apr 2019 13:32:27 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class In-Reply-To: <5CC2190C.50609@oracle.com> References: <2923a8bb-bf80-d9c0-3150-d4fe05cada60@oracle.com> <5CC2190C.50609@oracle.com> Message-ID: <5CC2195B.2060008@oracle.com> And the complete CSR link is this : https://bugs.openjdk.java.net/browse/JDK-8222990 On 4/25/19, 1:31 PM, Philip Race wrote: > Sorry, meant to include core-libs on this ! > > -phil. > > On 4/25/19, 1:12 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130266 >> CSR: https://bugs.openjdk.java.net/browse/JDK- >> Webrev: http://cr.openjdk.java.net/~prr/8130266/ >> >> Please review this fix + the CSR which eliminates the >> java.awt.graphicenv System property. >> >> To replace it we have platform-specific classes which can then more >> easily embed >> platform-specific logic. For example, logic in >> java.awt.GraphicsEnvironment was >> then moved down into this class. Also isInAquaSession used on Mac was >> moved >> into that class from the Mac Toolkit class. >> >> A reference to the property in J2D Bench - just used to log / >> document the testing environment >> was removed along with similar references to two other properties >> removed in earlier fixes. >> >> This has been built + tested on Mac, Linux + Windows in headful mode >> and also >> specifying headless via -Djava.awt.headless and by letting it default >> to headless >> in an ssh session on Mac + by unsetting the DISPLAY variable on Linux. >> >> -phil. From philip.race at oracle.com Thu Apr 25 20:31:08 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Apr 2019 13:31:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class In-Reply-To: <2923a8bb-bf80-d9c0-3150-d4fe05cada60@oracle.com> References: <2923a8bb-bf80-d9c0-3150-d4fe05cada60@oracle.com> Message-ID: <5CC2190C.50609@oracle.com> Sorry, meant to include core-libs on this ! -phil. On 4/25/19, 1:12 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8130266 > CSR: https://bugs.openjdk.java.net/browse/JDK- > Webrev: http://cr.openjdk.java.net/~prr/8130266/ > > Please review this fix + the CSR which eliminates the > java.awt.graphicenv System property. > > To replace it we have platform-specific classes which can then more > easily embed > platform-specific logic. For example, logic in > java.awt.GraphicsEnvironment was > then moved down into this class. Also isInAquaSession used on Mac was > moved > into that class from the Mac Toolkit class. > > A reference to the property in J2D Bench - just used to log / document > the testing environment > was removed along with similar references to two other properties > removed in earlier fixes. > > This has been built + tested on Mac, Linux + Windows in headful mode > and also > specifying headless via -Djava.awt.headless and by letting it default > to headless > in an ssh session on Mac + by unsetting the DISPLAY variable on Linux. > > -phil. From philip.race at oracle.com Thu Apr 25 20:41:08 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Apr 2019 13:41:08 -0700 Subject: [OpenJDK 2D-Dev] [Resend] Re: RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Message-ID: I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file. Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms. Also I am puzzled when I see this : ?449???????????????? && "FILE_NAMES_ALIASES".equals(st.sval)) { and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in? a random place, and your code is broken. -phil. On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote: > (Sorry, please ignore previous mail, it has wrong link for "Change") > > Hello Phil. > > I appreciate your suggestion. > > I could find out the root cause. > XLFD format font name (which was on AIX's fontconfig.properties file) > is not included > into fonts.dir (fonts.scale) file. > It was in fonts.alias file. > It seems that Java could not find font file on fonts.dir, > then it tried to use XLFD format font name to load X11's font for > logical font. > > On AIX platform, TrueType font files had been changed several times. > XLFD format font names were registered into fonts.alias file for > compatibility. > > On this condition, I think adding fonts.alias support feature is > better than > fixing AIX's fontconfig.properties file. > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/ > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > > On 2019-04-20 03:55, Phil Race wrote: >> Something must have gone wrong upstream to have this font registered >> as a native font. >> You should trace back to find out. I suggest to start with this code >> in SunFontManager.java, >> where I am guessing you don't have the file name for some reason. >> >> ??? protected void registerFontFile(String fontFileName, String[] >> nativeNames, >> >> int fontRank, boolean defer) { >> //????? REMIND: case compare depends on platform >> ??????? if (registeredFontFiles.contains(fontFileName)) { >> ??????????? return; >> ??????? } >> ??????? int fontFormat; >> ??????? if (ttFilter.accept(null, fontFileName)) { >> ??????????? fontFormat = FONTFORMAT_TRUETYPE; >> ??????? } else if (t1Filter.accept(null, fontFileName)) { >> ??????????? fontFormat = FONTFORMAT_TYPE1; >> ??????? } else { >> ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I >> think you are getting here, but why ? >> ??????? } >> >> -phil. >> >> On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> I'm using standard OpenJDK JDK13 b13 for AIX, like: >>> openjdk version "13-internal" 2019-09-17 >>> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >>> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) >>> (Compiled it by myself) >>> >>> To see stack trace, I tried following instruction: >>> ?1. Login to AIX box from another machine >>> ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale >>> (Ja_JP) or C locale >>> ?3. Open terminal, like dtterm on local AIX box >>> ?4. Start SwingSet2 demo program >>> ?5. Check java's process id >>> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >>> ?7. Move mouse cursor on cow image to display ToolTip >>> ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped >>> ??? (I said this situation was "frozen".) >>> ?9. After Xserver was frozen, execute "kill -3" with java process id >>> 10. Then stack trace is displayed >>> >>> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms >>> elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable >>> [0x0000000114159000] >>> ?? java.lang.Thread.State: RUNNABLE >>> ??? at >>> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native Method) >>> ??? at >>> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >>> ??? at >>> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >>> ??? at >>> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >>> ??? at >>> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >>> ... >>> >>> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2019-04-19 05:20, Phil Race wrote: >>>> On startup ? >>>> What is the Java stack trace that gets you into that call ? >>>> Is it this with any modified IBM code, or pure OpenJDK ? >>>> >>>> -phil. >>>> >>>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>>> Hello Phil. >>>>> >>>>> I appreciate your reply. >>>>> I put problem analysis information in JDK-8221741 [1]. >>>>> >>>>> The issue is AIX's Xserver was frozen about 25 secs on my local >>>>> AIX box. >>>>> According to my problem analysis, >>>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>>> XLoadQueryFont() on Xlib. >>>>> The situation can emulate by "xlsfonts -ll" command, like: >>>>> >>>>> $ time xlsfonts -ll -fn >>>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>>> >>>>> ... >>>>> real??? 0m2.07s >>>>> user??? 0m0.00s >>>>> sys 0m0.00s >>>>> >>>>> One of solution is, Unix's fontconfig.properties can support >>>>> TrueType/Type1 font name format. [2] >>>>> >>>>> Anyway, >>>>> I don't know the reason why X11 bitmap font is required for >>>>> logical font. >>>>> (I don't know how to use X11 bitmap font for physical font. >>>>> I could not see X11 bitmap font name via >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>>> I just want to fix Xserver frozen issue. >>>>> I appreciate your advice. >>>>> (Other solutions are welcome) >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2019-04-04 01:09, Philip Race wrote: >>>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>>> Hello. >>>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>>> mailing list.) >>>>>>> >>>>>>> Could you review the fix ? >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>>> >>>>>>> I'd like to obtain a sponsor for this issue. >>>>>>> >>>>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>>>> proper fonts. >>>>>>> TrueType font settings are written by XLFD format on >>>>>>> fontconfig.properties file. >>>>>>> >>>>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>>>> even if these are not used. >>>>>> >>>>>> I think you need to clarify what you mean here. >>>>>> >>>>>> I'd like you to provide a step by step analysis of what happens and >>>>>> what the effect of your proposed change is on AIX *AND* what it >>>>>> might >>>>>> mean for other X11 platforms, as I don't have time to reverse >>>>>> engineer the >>>>>> reasons for the odd-looking change. >>>>>> It looks like a hack to short-circuit support your syntax. >>>>>> Right now I am saying no to this. >>>>>> >>>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>>> It spends many CPU time and memories. >>>>>>> >>>>>>> Just font name format should be supported. >>>>>> >>>>>> Not clear enough for me. >>>>>> >>>>>> -phil. >>>>>>> >>>>>>> To SAP representative, >>>>>>> I have a question about copyright year on >>>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>>> Please let me know how I should write down copyright year. >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> IBM Japan, Ltd. >>>>>>> >>>>> >>> > From philip.race at oracle.com Thu Apr 25 22:22:44 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Apr 2019 15:22:44 -0700 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com> <5C84D34E.2070601@oracle.com> <5CA57199.3050405@oracle.com> Message-ID: <7a7d3613-fe0f-68df-02e2-b84bc1b7a7bf@oracle.com> The test fails for me when I set the Japanese locale. I am using Ubuntu 16.04. Have you done any locale testing ? env|grep LANG LANG=ja_JP.UTF-8 GDM_LANG=ja_JP LANGUAGE=ja_JP.UTF-8 ?$ ~/jdk-client/build/linux-x86_64-server-release/jdk/bin/java FCCompositeTest PF=Noto Sans Mono CJK JP Regular FC=Noto Sans Mono CJK JP Regular PF=TakaoPGothic FC=Takao P???????????? java.lang.RuntimeException: FullName mismatch: TakaoPGothic,Takao P???????????? ??? at FCCompositeTest.test(FCCompositeTest.java:92) ??? at FCCompositeTest.main(FCCompositeTest.java:52) Exception in thread "main" java.lang.RuntimeException: Method invocation exception ??? at FCCompositeTest.test(FCCompositeTest.java:97) ??? at FCCompositeTest.main(FCCompositeTest.java:52) -phil. On 4/23/19 3:14 AM, Toshio 5 Nakamura wrote: > I apologize if my poor description caused confusion. > Hi Jay, > Thank you so much for your review. > Hi phil, > I'm looking forward to hearing your results. > Noto font is expected to be used more widely, and I'm eager to fix > this?problem. > I welcome any suggestions or comments. > Thanks, > Toshio Nakamura > > ----- Original message ----- > From: Jayathirth Rao > To: Toshio 5 Nakamura > Cc: Philip Race , 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for > East Asian countries cannot belong to CompositeFont > Date: Tue, Apr 9, 2019 3:26 PM > > Hi, > (Ignore the previous mail received with less info) > Observations: > I went through different FontConfiguration & FontManager > implementations and I?see that in case of fontConfig(linux) only > we?are?encoding/decoding CompositeFonts in a unique way(In case > of?font config we override get2DCompositeFontInfo()). For other > platforms we use parent get2DCompositeFontInfo() where we are > populating face names using getFaceNameFromComponentFontName(). > Also getDefaultPlatformFont() returns predetermined face names in > case of Windows and Mac. > For Linux changes made in FontConfiguration and FontManager looks > fine. > Thanks, > Jay >> On 04-Apr-2019, at 6:14 PM, Toshio 5 Nakamura >> > wrote: >> Hi phil, Jay, >> Thank you for taking your?time to review this patch. >> Thanks, >> Toshio Nakamura >> >> ----- Original message ----- >> From: Jayathirth Rao > > >> To: TOSHIONA at jp.ibm.com >> Cc: 2d-dev <2d-dev at openjdk.java.net >> > >> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts >> for East Asian countries cannot belong to CompositeFont >> Date: Thu, Apr 4, 2019 8:43 PM >> >> Hi, >> I am also taking a look at this. >> I will update my observations soon. >> Thanks, >> Jay >>> On 04-Apr-2019, at 8:23 AM, Philip Race >>> > wrote: >>> I will get back to this soon but you will still need a 2nd >>> reviewer. >>> >>> -phil. >>> >>> On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: >>>> Hi Phil, >>>> Just a gentle reminder, I appreciate it if you have a time >>>> to look at this. >>>> Thanks, >>>> Toshio Nakamura >>>> >>>> ----- Original message ----- >>>> From: "Toshio 5 Nakamura" >>>> >>>> Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> >>>> >>>> To: Philip Race >>>> >>>> Cc: 2d-dev <2d-dev at openjdk.java.net> >>>> >>>> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto >>>> fonts for East Asian countries cannot belong to >>>> CompositeFont >>>> Date: Mon, Mar 11, 2019 9:58 PM >>>> >>>> Hi Phil, >>>> >>>> Thank you so much for your reviewing. >>>> >>>> Yes, "family" part can be removed with a few changes in >>>> "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". >>>> >>>> The updated webrev is: >>>> http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01 >>>> / >>>> >>>> > ?So you don't need to clean everything - just your >>>> develop -internal >>>> > and -ea folders. >>>> Yes, thank you for the clarification. >>>> >>>> Thanks, >>>> Toshio Nakamura >>>> >>>> Philip Race >>>> wrote on 2019/03/10 >>>> 18:05:18: >>>> >>>> > From: Philip Race >>>> >>>> > To: Toshio 5 Nakamura >>>> >>>> > Cc: 2d-dev <2d-dev at openjdk.java.net> >>>> >>>> > Date: 2019/03/10 18:05 >>>> > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto >>>> fonts for East >>>> > Asian countries cannot belong to CompositeFont >>>> > >>>> > I can sponsor this but first : >>>> > >>>> > You seem to have made "family" redundant but aren't >>>> removing it. >>>> > There's no point in writing it out if nothing uses it >>>> on reading. >>>> > So we should remove it unless you can explain why you >>>> think it should be kept. >>>> > >>>> > I don't think this (removing it) is a problem for >>>> backports or >>>> > compatibility of the >>>> > format since release name is part of the file name >>>> where we write >>>> > the information, >>>> > and such a file name will necessarily be a >>>> consequence of a feature >>>> > or update release >>>> > containing this fix. >>>> > >>>> > Where it might be an issue is testing on 13-ea builds >>>> since they all report >>>> > that as the version string so for testing you may >>>> need to clean out your >>>> > ~/.java/fonts/13-ea folder. The same is for your >>>> 13-internal private builds. >>>> > >>>> > I think this is your point when you wrote :- >>>> > >>>> >> The cached font list is stored under ~/.java/fonts >>>> directory. >>>> >> We should delete it before applying the fix. >>>> > >>>> > ?So you don't need to clean everything - just your >>>> develop -internal >>>> > and -ea folders. >>>> > >>>> > Meanwhile I tested it .. and it seemed OK but I am >>>> still trying to join >>>> > up all the dots to make sure it is all correct code-wise. >>>> > >>>> > -phil >>>> > >>>> > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: >>>> > Hi, >>>> > >>>> > Could you review the fix and may I have a sponsor for it? >>>> > >>>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 >>>> > Webrev: >>>> http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ >>>> >>>> > >>>> > Issue: >>>> > Even if Google Noto fonts[1] were installed and >>>> listed by fontconfig library >>>> > on Linux, CompositeFont couldn't contain it. >>>> > >>>> > Fix description: >>>> > >>>> "src/java.desktop/share/classes/sun/font/CompositeFont.java" >>>> (l. 296) >>>> > validates the target font by comparing names. But, >>>> the current code >>>> > compared FamilyName with FullName (Font.getFontName()). >>>> > Then, Noto font was treated as invalid. >>>> > >>>> "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" >>>> > should provide FullName. >>>> > >>>> > The cached font list is stored under ~/.java/fonts >>>> directory. >>>> > We should delete it before applying the fix. >>>> > >>>> > This fix is possible to change the default font, if >>>> CompositeFont >>>> > is used (especially under Ubuntu18.04 and East Asian >>>> settings). >>>> > But, I believe the fixed behavior is correct. >>>> > >>>> > [1] https://www.google.com/get/noto/ >>>> > >>>> > Thanks, >>>> > Toshio Nakamura >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Apr 26 06:22:32 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Fri, 26 Apr 2019 11:52:32 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK In-Reply-To: <294b1678-7516-6db2-9d5d-e8b19153b39b@oracle.com> References: <5CBBAB5F.6080009@oracle.com> <294b1678-7516-6db2-9d5d-e8b19153b39b@oracle.com> Message-ID: <7FC8CA3D-5FDE-424D-83BE-407003DFB7EA@oracle.com> Hi Phil, Changes are fine. I think script name of Telugu should be ?telugu? and not ?telegu?. Thanks, Jay > On 25-Apr-2019, at 9:23 PM, Phil Race wrote: > > Any takers ? Jay ? Also adding i18n-dev. > > -phil. > > On 4/20/19 4:29 PM, Philip Race wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8208179 >> Webrev: http://cr.openjdk.java.net/~prr/8208179/index.html >> >> The original complaint is missing devanagari in logical fonts in Oracle JDK 11. >> I realised in looking at this that we are also missing Thai. >> The reason is that Lucida Sans was removed and there are no windows fonts >> configured to replace these. >> In fixing this we can also add support for other Indic scripts and Khmer + Mongolian too >> as Windows 7 and later all contain suitable UI fonts. >> >> One wrinkle is that we will be more likely to trip over a small bug whereby >> if we have registered one font in a family due to it being mentioned in a logical >> font and that font can be used to synthesis another style of that font, we don't >> go to check to see if there is a system font of the exact style. >> FontFamily.getFont(String name, int style) has a comment warning of this possibility. >> This was observed that Mangal hid Mangal Bold for example, and inconsistently if >> you used the Mangal Bold font directly it was not hidden and would be used. >> So the fix adds a call to an existing method which will resolve all fonts in that family first. >> >> A test is provided which verifies the scripts are now supported by the logical fonts on Windows. >> >> -phil. >> >> > From Sergey.Bylokhov at oracle.com Fri Apr 26 06:22:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Apr 2019 23:22:15 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class In-Reply-To: <5CC2190C.50609@oracle.com> References: <2923a8bb-bf80-d9c0-3150-d4fe05cada60@oracle.com> <5CC2190C.50609@oracle.com> Message-ID: <889dc961-acf5-c75a-e215-c498b587c396@oracle.com> Looks fine. On 25/04/2019 13:31, Philip Race wrote: > Sorry, meant to include core-libs on this ! > > -phil. > > On 4/25/19, 1:12 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130266 >> CSR: https://bugs.openjdk.java.net/browse/JDK- >> Webrev: http://cr.openjdk.java.net/~prr/8130266/ >> >> Please review this fix + the CSR which eliminates the java.awt.graphicenv System property. >> >> To replace it we have platform-specific classes which can then more easily embed >> platform-specific logic. For example, logic in java.awt.GraphicsEnvironment was >> then moved down into this class. Also isInAquaSession used on Mac was moved >> into that class from the Mac Toolkit class. >> >> A reference to the property in J2D Bench - just used to log / document the testing environment >> was removed along with similar references to two other properties removed in earlier fixes. >> >> This has been built + tested on Mac, Linux + Windows in headful mode and also >> specifying headless via -Djava.awt.headless and by letting it default to headless >> in an ssh session on Mac + by unsetting the DISPLAY variable on Linux. >> >> -phil. -- Best regards, Sergey. From philip.race at oracle.com Fri Apr 26 13:19:18 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 26 Apr 2019 06:19:18 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK In-Reply-To: <7FC8CA3D-5FDE-424D-83BE-407003DFB7EA@oracle.com> References: <5CBBAB5F.6080009@oracle.com> <294b1678-7516-6db2-9d5d-e8b19153b39b@oracle.com> <7FC8CA3D-5FDE-424D-83BE-407003DFB7EA@oracle.com> Message-ID: <5CC30556.8010702@oracle.com> On 4/25/19, 11:22 PM, Jayathirth Rao wrote: > Hi Phil, > > Changes are fine. > I think script name of Telugu should be ?telugu? and not ?telegu?. Thanks. I think I've made that same typo in the past .. I'll fix before pushing. -phil. > > Thanks, > Jay > >> On 25-Apr-2019, at 9:23 PM, Phil Race wrote: >> >> Any takers ? Jay ? Also adding i18n-dev. >> >> -phil. >> >> On 4/20/19 4:29 PM, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208179 >>> Webrev: http://cr.openjdk.java.net/~prr/8208179/index.html >>> >>> The original complaint is missing devanagari in logical fonts in Oracle JDK 11. >>> I realised in looking at this that we are also missing Thai. >>> The reason is that Lucida Sans was removed and there are no windows fonts >>> configured to replace these. >>> In fixing this we can also add support for other Indic scripts and Khmer + Mongolian too >>> as Windows 7 and later all contain suitable UI fonts. >>> >>> One wrinkle is that we will be more likely to trip over a small bug whereby >>> if we have registered one font in a family due to it being mentioned in a logical >>> font and that font can be used to synthesis another style of that font, we don't >>> go to check to see if there is a system font of the exact style. >>> FontFamily.getFont(String name, int style) has a comment warning of this possibility. >>> This was observed that Mangal hid Mangal Bold for example, and inconsistently if >>> you used the Mangal Bold font directly it was not hidden and would be used. >>> So the fix adds a call to an existing method which will resolve all fonts in that family first. >>> >>> A test is provided which verifies the scripts are now supported by the logical fonts on Windows. >>> >>> -phil. >>> >>> From philip.race at oracle.com Thu Apr 4 00:17:15 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 04 Apr 2019 00:17:15 -0000 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: , <5C84D34E.2070601@oracle.com> Message-ID: <5CA54D05.60609@oracle.com> I will get back to this soon but you will still need a 2nd reviewer. -phil. On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: > Hi Phil, > Just a gentle reminder, I appreciate it if you have a time to look at > this. > Thanks, > Toshio Nakamura > > ----- Original message ----- > From: "Toshio 5 Nakamura" > Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> > To: Philip Race > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for > East Asian countries cannot belong to CompositeFont > Date: Mon, Mar 11, 2019 9:58 PM > > Hi Phil, > > Thank you so much for your reviewing. > > Yes, "family" part can be removed with a few changes in > "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". > > The updated webrev is: > http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01 > / > > > So you don't need to clean everything - just your develop -internal > > and -ea folders. > Yes, thank you for the clarification. > > Thanks, > Toshio Nakamura > > Philip Race wrote on 2019/03/10 18:05:18: > > > From: Philip Race > > To: Toshio 5 Nakamura > > Cc: 2d-dev <2d-dev at openjdk.java.net> > > Date: 2019/03/10 18:05 > > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East > > Asian countries cannot belong to CompositeFont > > > > I can sponsor this but first : > > > > You seem to have made "family" redundant but aren't removing it. > > There's no point in writing it out if nothing uses it on reading. > > So we should remove it unless you can explain why you think it > should be kept. > > > > I don't think this (removing it) is a problem for backports or > > compatibility of the > > format since release name is part of the file name where we write > > the information, > > and such a file name will necessarily be a consequence of a feature > > or update release > > containing this fix. > > > > Where it might be an issue is testing on 13-ea builds since they > all report > > that as the version string so for testing you may need to clean > out your > > ~/.java/fonts/13-ea folder. The same is for your 13-internal > private builds. > > > > I think this is your point when you wrote :- > > > >> The cached font list is stored under ~/.java/fonts directory. > >> We should delete it before applying the fix. > > > > So you don't need to clean everything - just your develop -internal > > and -ea folders. > > > > Meanwhile I tested it .. and it seemed OK but I am still trying > to join > > up all the dots to make sure it is all correct code-wise. > > > > -phil > > > > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > > Hi, > > > > Could you review the fix and may I have a sponsor for it? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 > > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ > > > > > Issue: > > Even if Google Noto fonts[1] were installed and listed by > fontconfig library > > on Linux, CompositeFont couldn't contain it. > > > > Fix description: > > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. > 296) > > validates the target font by comparing names. But, the current code > > compared FamilyName with FullName (Font.getFontName()). > > Then, Noto font was treated as invalid. > > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" > > should provide FullName. > > > > The cached font list is stored under ~/.java/fonts directory. > > We should delete it before applying the fix. > > > > This fix is possible to change the default font, if CompositeFont > > is used (especially under Ubuntu18.04 and East Asian settings). > > But, I believe the fixed behavior is correct. > > > > [1] https://www.google.com/get/noto/ > > > > Thanks, > > Toshio Nakamura > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Fri Apr 26 16:46:30 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 26 Apr 2019 09:46:30 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class In-Reply-To: <5CC2195B.2060008@oracle.com> References: <2923a8bb-bf80-d9c0-3150-d4fe05cada60@oracle.com> <5CC2190C.50609@oracle.com> <5CC2195B.2060008@oracle.com> Message-ID: <55731071-832b-5f87-f0e6-f73a63c683b5@oracle.com> The java.base portion looks good to me. -Brent On 4/25/19 1:32 PM, Philip Race wrote: > And the complete CSR link is this : > https://bugs.openjdk.java.net/browse/JDK-8222990 > > On 4/25/19, 1:31 PM, Philip Race wrote: >> Sorry, meant to include core-libs on this ! >> >> -phil. >> >> On 4/25/19, 1:12 PM, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8130266 >>> CSR: https://bugs.openjdk.java.net/browse/JDK- >>> Webrev: http://cr.openjdk.java.net/~prr/8130266/ >>> >>> Please review this fix + the CSR which eliminates the >>> java.awt.graphicenv System property. >>> >>> To replace it we have platform-specific classes which can then more >>> easily embed >>> platform-specific logic. For example, logic in >>> java.awt.GraphicsEnvironment was >>> then moved down into this class. Also isInAquaSession used on Mac was >>> moved >>> into that class from the Mac Toolkit class. >>> >>> A reference to the property in J2D Bench - just used to log / >>> document the testing environment >>> was removed along with similar references to two other properties >>> removed in earlier fixes. >>> >>> This has been built + tested on Mac, Linux + Windows in headful mode >>> and also >>> specifying headless via -Djava.awt.headless and by letting it default >>> to headless >>> in an ssh session on Mac + by unsetting the DISPLAY variable on Linux. >>> >>> -phil. From philip.race at oracle.com Fri Apr 26 19:00:57 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Apr 2019 12:00:57 -0700 Subject: [OpenJDK 2D-Dev] [13] Review Request: 8222917 GraphicsEnvironment for Unix still have an unused dependency on Solaris In-Reply-To: <0c0e6bc2-5b3b-fa0f-6070-84a32dfcaa5f@oracle.com> References: <0c0e6bc2-5b3b-fa0f-6070-84a32dfcaa5f@oracle.com> Message-ID: On 4/24/19 12:35 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222917 > Fix: http://cr.openjdk.java.net/~serb/8222917/webrev.00 > > The SunGraphicsEnvironment has a codepath for the OpenSolaris, but in > fact results on this execution is never used. > This code was added in JDK-6378099: > http://hg.openjdk.java.net/jdk/client/rev/c3e81f0acd3d#l5.7 > But the usage of isOpenSolaris flag was dropped in JDK-6795908: > http://hg.openjdk.java.net/jdk/client/rev/be186a33df9b#l45.717 That refactoring caused a lot of fall out. I don't know how much it mattered since OpenSolaris didn't get deployed a lot, SFAIK. And it was a moving target. I am sure it is fine to remove this now > > In this fix, the unused code was removed. > > BTW I am not sure why we set the default font for SG2D in the > constructor of SunGraphicsEnvironment and not assign the field > directly? Probably the reason is related to some cyclic dependency?. > I am not sure. Too long ago. BTW did you intend to remove the comment ahead of that assignment ? -phil From harvey at actenum.com Sun Apr 28 15:25:59 2019 From: harvey at actenum.com (Peter Harvey) Date: Sun, 28 Apr 2019 09:25:59 -0600 Subject: [OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows Message-ID: Apologies if this is not the correct channel for this email. >From what I can tell, Freetype 2.7 contained a change in hint processing that led to poorer quality font rendering on Windows. Any OpenJDK distribution using Freetype 2.7 or higher (ie. most distributions) will have poorer quality font rendering on Windows. I may have found a solution to this issue but I am unable to add comments to the relevant bugs: https://bugs.openjdk.java.net/browse/JDK-8217731 https://bugs.openjdk.java.net/browse/JDK-8208377 https://bugs.openjdk.java.net/browse/JDK-8214538 As a temporary workaround, users of OpenJDK distributions can force pre-2.7 font rendering by simply setting an environment variable: FREETYPE_PROPERTIES=truetype:interpreter-version=35 I've tested this workaround on OpenJDK distributions from Amazon, Oracle, and AdoptOpenJDK. Note that AdoptOpenJDK's distribution for Java 8 didn't require the workaround because it appears to be using Freetype 2.5.3. A quick Google for "truetype:interpreter-version=35" shows plenty of people in other open-source communities (eg. Wine, Fedora) which encourage this workaround for other software. A more permanent solution would be to change the default build process for OpenJDK to set "truetype:interpreter-version=35" as the default when compiling Freetype. Please let me know if I can assist in any way. Regards, Peter. -- *Actenum Corporation* Peter Harvey | Cell: 780.729.8192 | harvey at actenum.com | www.actenum.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Apr 28 17:14:18 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 28 Apr 2019 10:14:18 -0700 Subject: [OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows In-Reply-To: References: Message-ID: <5CC5DF6A.4000409@oracle.com> On 4/28/19, 8:25 AM, Peter Harvey wrote: > Apologies if this is not the correct channel for this email. It is, but if you want to send any more emails to this list, you will need to subscribe. > > From what I can tell, Freetype 2.7 contained a change in hint > processing that led to poorer quality font rendering on Windows. Any > OpenJDK distribution using Freetype 2.7 or higher (ie. most > distributions) will have poorer quality font rendering on Windows. I > may have found a solution to this issue but I am unable to add > comments to the relevant bugs: > > https://bugs.openjdk.java.net/browse/JDK-8217731 > https://bugs.openjdk.java.net/browse/JDK-8208377 > https://bugs.openjdk.java.net/browse/JDK-8214538 > > As a temporary workaround, users of OpenJDK distributions can force > pre-2.7 font rendering by simply setting an environment variable: > > FREETYPE_PROPERTIES=truetype:interpreter-version=35 > > I've tested this workaround on OpenJDK distributions from Amazon, > Oracle, and AdoptOpenJDK. Do you mean you specifically tested out exactly the issues & scenarios listed in the above bug reports and found them all 100% reverted & cured ? If not, please detail what exactly you see in each case when applying the property vs previous JDKs. What version of Windows did you test, and did you test anything other than Windows ? > Note that AdoptOpenJDK's distribution for Java 8 didn't require the > workaround because it appears to be using Freetype 2.5.3. A quick > Google for "truetype:interpreter-version=35" shows plenty of people in > other open-source communities (eg. Wine, Fedora) which encourage this > workaround for other software. > > A more permanent solution would be to change the default build process > for OpenJDK to set "truetype:interpreter-version=35" as the default > when compiling Freetype. I have read freetype notes on this and it isn't clear whether we want to go against what it does by default. And in any case, Oracle JDK switched from T2K to freetype in 11 so there can be differences due to that too. It may be that Windows is the only platform on which this reversion is a good idea. And in any case, on Linux + Solaris (not sure about other Unix-like distros) OpenJDK currently uses the system freetype so a JDK build change for freetype wouldn't help. > > Please let me know if I can assist in any way. > The above requested information .. -phil. > Regards, > Peter. > > -- > *Actenum Corporation* > Peter Harvey | Cell: 780.729.8192 | harvey at actenum.com > | www.actenum.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Apr 28 19:05:32 2019 From: philip.race at oracle.com (Phil Race) Date: Sun, 28 Apr 2019 12:05:32 -0700 Subject: [OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows In-Reply-To: <5CC5DF6A.4000409@oracle.com> References: <5CC5DF6A.4000409@oracle.com> Message-ID: <59DFB8C7-755E-428F-ACFC-5D2D0DEE8933@oracle.com> One thing to add is that Swing on Windows will use LCD text in all cases I can think of and that is rendered by Windows/GDI not free type. Line and glyph spacing may still be affected (come from freetype) but not the glyph image itself. So it would have to be some custom rendering in another mode using 2D directly to get freetype glyph images in b&w or grayscale. -Phil. > On Apr 28, 2019, at 10:14 AM, Philip Race wrote: > > > >> On 4/28/19, 8:25 AM, Peter Harvey wrote: >> Apologies if this is not the correct channel for this email. > > It is, but if you want to send any more emails to this list, you will need to subscribe. >> >> From what I can tell, Freetype 2.7 contained a change in hint processing that led to poorer quality font rendering on Windows. Any OpenJDK distribution using Freetype 2.7 or higher (ie. most distributions) will have poorer quality font rendering on Windows. I may have found a solution to this issue but I am unable to add comments to the relevant bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8217731 >> https://bugs.openjdk.java.net/browse/JDK-8208377 >> https://bugs.openjdk.java.net/browse/JDK-8214538 >> >> As a temporary workaround, users of OpenJDK distributions can force pre-2.7 font rendering by simply setting an environment variable: >> >> FREETYPE_PROPERTIES=truetype:interpreter-version=35 >> >> I've tested this workaround on OpenJDK distributions from Amazon, Oracle, and AdoptOpenJDK. > > Do you mean you specifically tested out exactly the issues & scenarios > listed in the above bug reports and found them all 100% reverted & cured ? > If not, please detail what exactly you see in each case when applying the property vs previous JDKs. > What version of Windows did you test, and did you test anything other than Windows ? > > > >> Note that AdoptOpenJDK's distribution for Java 8 didn't require the workaround because it appears to be using Freetype 2.5.3. A quick Google for "truetype:interpreter-version=35" shows plenty of people in other open-source communities (eg. Wine, Fedora) which encourage this workaround for other software. >> >> A more permanent solution would be to change the default build process for OpenJDK to set "truetype:interpreter-version=35" as the default when compiling Freetype. > > I have read freetype notes on this and it isn't clear whether we want to go against what it does by default. > And in any case, Oracle JDK switched from T2K to freetype in 11 so there can be differences due to that too. > > It may be that Windows is the only platform on which this reversion is a good idea. > And in any case, on Linux + Solaris (not sure about other Unix-like distros) OpenJDK > currently uses the system freetype so a JDK build change for freetype wouldn't help. > >> >> Please let me know if I can assist in any way. >> > > The above requested information .. > > -phil. > >> Regards, >> Peter. >> >> -- >> Actenum Corporation >> Peter Harvey | Cell: 780.729.8192 | harvey at actenum.com | www.actenum.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From harvey at actenum.com Mon Apr 29 01:49:16 2019 From: harvey at actenum.com (Peter Harvey) Date: Sun, 28 Apr 2019 19:49:16 -0600 Subject: [OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows In-Reply-To: <59DFB8C7-755E-428F-ACFC-5D2D0DEE8933@oracle.com> References: <5CC5DF6A.4000409@oracle.com> <59DFB8C7-755E-428F-ACFC-5D2D0DEE8933@oracle.com> Message-ID: On Sun, Apr 28, 2019 at 1:05 PM Phil Race wrote: > One thing to add is that Swing on Windows will use LCD text in all cases I > can think of and that is rendered by Windows/GDI not free type. > Line and glyph spacing may still be affected (come from freetype) but not > the glyph image itself. > So it would have to be some custom rendering in another mode using 2D > directly to get freetype glyph images in b&w or grayscale. > I'm speculating here, but perhaps the issue is that glyphs are being positioned using Freetype while the actual glyph rendering is using GDI, and there is a disagreement between the two systems re: kerning? The issue does seem to be limited to the kerning between glyphs and not the actual rendering of glyphs themselves. On Apr 28, 2019, at 10:14 AM, Philip Race wrote: > > On 4/28/19, 8:25 AM, Peter Harvey wrote: > > From what I can tell, Freetype 2.7 contained a change in hint processing > that led to poorer quality font rendering on Windows. Any OpenJDK > distribution using Freetype 2.7 or higher (ie. most distributions) will > have poorer quality font rendering on Windows. I may have found a solution > to this issue but I am unable to add comments to the relevant bugs: > > https://bugs.openjdk.java.net/browse/JDK-8217731 > https://bugs.openjdk.java.net/browse/JDK-8208377 > https://bugs.openjdk.java.net/browse/JDK-8214538 > > As a temporary workaround, users of OpenJDK distributions can force > pre-2.7 font rendering by simply setting an environment variable: > > FREETYPE_PROPERTIES=truetype:interpreter-version=35 > > I've tested this workaround on OpenJDK distributions from Amazon, Oracle, > and AdoptOpenJDK. > > > Do you mean you specifically tested out exactly the issues & scenarios > listed in the above bug reports and found them all 100% reverted & cured ? > If not, please detail what exactly you see in each case when applying the > property vs previous JDKs. > What version of Windows did you test, and did you test anything other than > Windows ? > > I have only tested on Windows 10 Home 1803, with no font scaling enabled. My initial tests were performed using a desktop application, many OpenJDK distributions, and visually comparing the poor kerning when using Tahoma. I have now produced a screenshot using sample text and 12 different OpenJDK distributions. I have highlighted the font kerning issues in a zoomed/cropped image: https://imgur.com/a/a9R0oBi https://imgur.com/a/BAZNJg6 Each window in the above screenshot represents a different OpenJDK distribution running on my Windows environment with or without the FREETYPE_PROPERTIES environment variable specified: - the sample text is "Activity dwedwedwedwe" though kerning issues can be seen throughout most text within the dialog - the first JLabels use the default font, while the last three JLabels use 10pt, 11pt, and 12pt Tahoma - the left-side windows do not have FREETYPE_PROPERTIES specified - the right-side windows have FREETYPE_PROPERTIES specified - the first 8 OpenJDK distributions all show kerning issues which are fixed by setting FREETYPE_PROPERTIES - the last 4 OpenJDK distributions don't show kerning issues at all and are not affected by setting FREETYPE_PROPERTIES As shown in the screenshot, setting the FREETYPE_PROPERTIES environment variable appears to fix the kinds of kerning issues described in JDK-8217731 and JDK-8214538. I have not checked if it fixes the line spacing issue described in JDK-8217731, but I doubt it. JDK-8208377 looks to be unrelated and that is my mistake. If you need to replicate the test, the code is below: import javax.swing.BorderFactory; import javax.swing.BoxLayout; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JPanel; import java.awt.Font; public class TestSwingTexts { public static void main(String[] args) { JFrame frame = new JFrame(); JPanel panel = new JPanel(); panel.setLayout(new BoxLayout(panel, BoxLayout.Y_AXIS)); System.out.println(System.getProperties()); JLabel vendor = new JLabel( System.getProperty("java.vm.vendor") + " " + System.getProperty("java.runtime.version") + " " + (System.getenv("FREETYPE_PROPERTIES") == null ? "without fix" : "with fix")); JLabel label1 = new JLabel("Activity its dwedwedwedwe"); JLabel label2 = new JLabel("Activity its dwedwedwedwe"); JLabel label3 = new JLabel("Activity its dwedwedwedwe"); JLabel label4 = new JLabel("Activity its dwedwedwedwe"); label2.setFont(new Font("Tahoma", Font.PLAIN, 10)); label3.setFont(new Font("Tahoma", Font.PLAIN, 11)); label4.setFont(new Font("Tahoma", Font.PLAIN, 12)); panel.add(vendor); panel.add(label1); panel.add(label2); panel.add(label3); panel.add(label4); panel.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5)); frame.add(panel); frame.pack(); frame.setLocationRelativeTo(null); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setVisible(true); } } Note that AdoptOpenJDK's distribution for Java 8 didn't require the > workaround because it appears to be using Freetype 2.5.3. A quick Google > for "truetype:interpreter-version=35" shows plenty of people in other > open-source communities (eg. Wine, Fedora) which encourage this workaround > for other software. > > A more permanent solution would be to change the default build process for > OpenJDK to set "truetype:interpreter-version=35" as the default when > compiling Freetype. > > > I have read freetype notes on this and it isn't clear whether we want to > go against what it does by default. > And in any case, Oracle JDK switched from T2K to freetype in 11 so there > can be differences due to that too. > > It may be that Windows is the only platform on which this reversion is a > good idea. > And in any case, on Linux + Solaris (not sure about other Unix-like > distros) OpenJDK > currently uses the system freetype so a JDK build change for freetype > wouldn't help. > > After reading a little more, I would suggest keeping the latest Freetype but compiling it using truetype:interpreter-version=35 to fix the kerning issues. Regards, Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Apr 29 06:15:01 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 28 Apr 2019 23:15:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [13] Review Request: 8222917 GraphicsEnvironment for Unix still have an unused dependency on Solaris In-Reply-To: References: <0c0e6bc2-5b3b-fa0f-6070-84a32dfcaa5f@oracle.com> Message-ID: On 26/04/2019 12:00, Phil Race wrote: > I am not sure. Too long ago. BTW did you intend to remove the comment ahead of that assignment ? That comment was moved to the field itself, I think we can go further and drop the constructor itself: http://cr.openjdk.java.net/~serb/8222917/webrev.01 -- Best regards, Sergey. From ROH at ivu.de Tue Apr 30 07:56:33 2019 From: ROH at ivu.de (Judith Rohloff) Date: Tue, 30 Apr 2019 07:56:33 +0000 Subject: [OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows In-Reply-To: References: Message-ID: <57be7d47c60643e5a231c505ff7c71df@ivu.de> Hi, We tested this workaround for the bug https://bugs.openjdk.java.net/browse/JDK-8217731 on windows 7 and 10 with Java11 (Oracle JDK). It solves the ugly font problem. Thanks a lot Judith Von: 2d-dev <2d-dev-bounces at openjdk.java.net> Im Auftrag von Peter Harvey Gesendet: Sonntag, 28. April 2019 17:26 An: 2d-dev at openjdk.java.net Betreff: [OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows Apologies if this is not the correct channel for this email. From what I can tell, Freetype 2.7 contained a change in hint processing that led to poorer quality font rendering on Windows. Any OpenJDK distribution using Freetype 2.7 or higher (ie. most distributions) will have poorer quality font rendering on Windows. I may have found a solution to this issue but I am unable to add comments to the relevant bugs: https://bugs.openjdk.java.net/browse/JDK-8217731 https://bugs.openjdk.java.net/browse/JDK-8208377 https://bugs.openjdk.java.net/browse/JDK-8214538 As a temporary workaround, users of OpenJDK distributions can force pre-2.7 font rendering by simply setting an environment variable: FREETYPE_PROPERTIES=truetype:interpreter-version=35 I've tested this workaround on OpenJDK distributions from Amazon, Oracle, and AdoptOpenJDK. Note that AdoptOpenJDK's distribution for Java 8 didn't require the workaround because it appears to be using Freetype 2.5.3. A quick Google for "truetype:interpreter-version=35" shows plenty of people in other open-source communities (eg. Wine, Fedora) which encourage this workaround for other software. A more permanent solution would be to change the default build process for OpenJDK to set "truetype:interpreter-version=35" as the default when compiling Freetype. Please let me know if I can assist in any way. Regards, Peter. -- Actenum Corporation Peter Harvey | Cell: 780.729.8192 | harvey at actenum.com | www.actenum.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ushakov at jetbrains.com Tue Apr 30 09:22:21 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Tue, 30 Apr 2019 12:22:21 +0300 Subject: [OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework Message-ID: <2202E165-D9E9-44EE-9D99-71D81C026857@jetbrains.com> Hello, Here is an update on our effort to use Metal framework for java2d rendering. We?ve added image rendering support and some support for LinearGradient. Also, the code has been refactored. Please have a look: http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 Best Regards, Alexey > Hello, > > As far as we know Apple has deprecated OpenGL on MacOS platform (https://developer.apple.com/macos/whats-new/ ). > > Unfortunately, this decision greatly affects our products that based on Java Client technologies. So, we (here at JetBrains) decided to start a project to replace OpenGL rendering on MacOS platform with a new one based on Metal. This is a huge task, so we decided to leverage current rendering architecture that is used in OpenGL rendering pipeline on Mac. > > That?s why we didn?t use MTKView for representing AWT windows (that probably would be a better approach in the long term). Currently we're using CAMetalLayer within AWTView. We?ve implemented flat color shape/curve rendering so far and there is a lot of work to do. So, we?re looking forward to any collaboration. > > In the mean time I?d like to share our current work to discuss metal pipeline architecture at the early stage of work. > > Here is the webrev with our on going development: > > http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00 > > Best Regards, > Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Apr 30 09:26:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 09:26:25 +0000 Subject: [OpenJDK 2D-Dev] [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3.1 Message-ID: Hi, please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the latest 2.3.1. This has been backported to 11.0.4-oracle already. I took the large change down to 11u-dev. It applies quite nicely, apart from a little issue in make/lib/Awt2dLibraries.gmk: --- Awt2dLibraries.gmk +++ Awt2dLibraries.gmk @@ -613,8 +614,7 @@ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ - maybe-uninitialized \ - missing-attributes class-memaccess, \ + maybe-uninitialized class-memaccess, \ DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ tautological-constant-out-of-range-compare int-to-pointer-cast \ sign-compare undef missing-field-initializers, \ The original change would remove the disabling of the "missing-attributes" warnings, but since this warning type is not disabled in jdk11u-dev currently, I would just skip that diff. With that change, most platforms did build fine, except for Solaris (where we use Oracle Studio 12u4 in jdk11u-dev vs Oracle Studio 12u6 in jdk/jdk) and AIX (xlc12 vs. xlc16). To keep support for Oracle Studio 12u4 for Solaris, I had to remove the warning flag "refmemnoconstr_aggr" from line 622 (as opposed to the original change). Seems that it is not yet supported in OS12u4. Furthermore, a code tweak had to be done (Thanks, Matthias, for your help here): --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-common.hh Fri Mar 01 16:59:19 2019 -0800 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-cff-common.hh Mon Apr 29 16:26:41 2019 +0200 @@ -280,6 +280,10 @@ { str_buff_t &flatStr; bool drop_hints; + + // Solaris: OS12u4 complains about "A class with a reference member lacks a user-defined constructor" + // so provide the constructor + flatten_param_t(str_buff_t& sbt, bool dh) : flatStr(sbt), drop_hints(dh) {} }; template @@ -305,7 +309,9 @@ return false; cs_interpreter_t interp; interp.env.init (str, acc, fd); - flatten_param_t param = { flat_charstrings[i], drop_hints }; + // Solaris: OS12u4 does not like the C++11 style init + // flatten_param_t param = { flat_charstrings[i], drop_hints }; + flatten_param_t param(flat_charstrings[i], drop_hints); if (unlikely (!interp.interpret (param))) return false; } For AIX, this tweak had to be added (credit goes to Matthias as well): diff -r 2b3dbedfbfb9 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Fri Mar 01 16:59:19 2019 -0800 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-null.hh Mon Apr 29 16:26:41 2019 +0200 @@ -83,7 +83,9 @@ template struct _hb_assign -{ static inline void value (T &o, const V v) { o = v; } }; +// add cast to please AIX xlc12.1 +//{ static inline void value (T &o, const V v) { o = v; } }; +{ static inline void value (T &o, const V v) { o = (T&) v; } }; template struct _hb_assign > { static inline void value (T &o, const V v) { o.set (v); } }; Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/7c11a7cc7c1d Review discussion for jdk/jdk: https://mail.openjdk.java.net/pipermail/2d-dev/2019-March/009914.html New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8210782.jdk11u/ Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Tue Apr 30 10:54:48 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Tue, 30 Apr 2019 10:54:48 +0000 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: <7a7d3613-fe0f-68df-02e2-b84bc1b7a7bf@oracle.com> References: <7a7d3613-fe0f-68df-02e2-b84bc1b7a7bf@oracle.com>, <91D0B610-FCF7-4A8C-A678-1FE94E377E24@oracle.com> <5C84D34E.2070601@oracle.com> <5CA57199.3050405@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: