From philip.race at oracle.com Fri May 1 17:55:42 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 01 May 2020 10:55:42 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args. In-Reply-To: <5EAB4C5F.7090205@oracle.com> References: <5EA9CDF9.5010501@oracle.com> <5EAB4C5F.7090205@oracle.com> Message-ID: <5EAC629E.5090205@oracle.com> ping ! -phil. On 4/30/20, 3:08 PM, Philip Race wrote: > Updated with a couple of stability fixes : > 1) to use invokeAndWait() instead of invokeLater() > 2) To skip fonts that don't support the text we are testing. > > http://cr.openjdk.java.net/~prr/8244113.1 > > -phil > > On 4/29/20, 11:56 AM, Philip Race wrote: >> bug : https://bugs.openjdk.java.net/browse/JDK-8244113 >> webrev : http://cr.openjdk.java.net/~prr/8244113/ >> >> Apparently jtreg consumes text even from 2 lines later after an @run tag >> as being args to pass to the program. >> >> Test still passes everywhere after the change. >> >> -phil. From Sergey.Bylokhov at oracle.com Fri May 1 20:21:20 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 1 May 2020 13:21:20 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args. In-Reply-To: <5EAC629E.5090205@oracle.com> References: <5EA9CDF9.5010501@oracle.com> <5EAB4C5F.7090205@oracle.com> <5EAC629E.5090205@oracle.com> Message-ID: <7b4943c6-a688-0ea5-dc03-6165a5189c9c@oracle.com> Looks fine. On 5/1/20 10:55 am, Philip Race wrote: > ping ! > > -phil. > > On 4/30/20, 3:08 PM, Philip Race wrote: >> Updated with a couple of stability fixes : >> 1) to use invokeAndWait() instead of invokeLater() >> 2) To skip fonts that don't support the text we are testing. >> >> http://cr.openjdk.java.net/~prr/8244113.1 >> >> -phil >> >> On 4/29/20, 11:56 AM, Philip Race wrote: >>> bug : https://bugs.openjdk.java.net/browse/JDK-8244113 >>> webrev : http://cr.openjdk.java.net/~prr/8244113/ >>> >>> Apparently jtreg consumes text even from 2 lines later after an @run tag >>> as being args to pass to the program. >>> >>> Test still passes everywhere after the change. >>> >>> -phil. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sun May 3 23:11:50 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 3 May 2020 16:11:50 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris In-Reply-To: <5EAAFD5D.4080002@oracle.com> References: <5EA8862D.5010803@oracle.com> <60bef0c3-758c-d337-6519-58897ab50dd2@oracle.com> <5EA891D6.7060501@oracle.com> <5EA8BC21.4000101@oracle.com> <5EA9F2C0.3000902@oracle.com> <5EAA06AA.2090805@oracle.com> <1381abb5-e25c-c96e-ef7d-313f87bee7ef@oracle.com> <5EAAFD5D.4080002@oracle.com> Message-ID: <1407f671-ce8e-8049-0b30-52e785ecc9a7@oracle.com> On 4/30/20 9:31 am, Philip Race wrote: > This test is called MaxAdvance *is max*. My emphasis. So there is no way to check that MaxAdvance *is max* for some predictable values? even for simple char like "W" or "A"? > Not "all values returned by getWidths() are less than or equal to max advance. > The latter is simply the inadequate implementation to partially test the assertion > and which was already proving to be too much. The only way to make that test > pass is to make changes to what max advance reports and I am saying that > we should not do that. It would be artificial and wrong. > > -phil. > > > > On 4/30/20, 9:23 AM, Sergey Bylokhov wrote: >> On 4/29/20 3:58 pm, Philip Race wrote: >>> the advance of 'm' is a commonly used proxy for the design width of a latin font. >>> But I agree it is also not really a great estimate once you consider any international text. >>> >>> Anyway I am not sure where you are headed with that and the >>> discussion of charWidth() or charWidths(). >>> >>> I am not trying to "fix the world" here, I am just removing a test >>> that it is pointless to maintain. >> >> Then probably we can report a bug, to state that we have some issues here? >> From my point of view, the test is mostly fine, it does not check some >> real corner cases and compound glyphs but only the simple chars, which should >> work. If it does not work means all code where we try to predict the size of >> the text components is broken, and it looks like there is no way to fix that. >> >> -- Best regards, Sergey. From philip.race at oracle.com Mon May 4 00:52:50 2020 From: philip.race at oracle.com (Philip Race) Date: Sun, 03 May 2020 17:52:50 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris In-Reply-To: <1407f671-ce8e-8049-0b30-52e785ecc9a7@oracle.com> References: <5EA8862D.5010803@oracle.com> <60bef0c3-758c-d337-6519-58897ab50dd2@oracle.com> <5EA891D6.7060501@oracle.com> <5EA8BC21.4000101@oracle.com> <5EA9F2C0.3000902@oracle.com> <5EAA06AA.2090805@oracle.com> <1381abb5-e25c-c96e-ef7d-313f87bee7ef@oracle.com> <5EAAFD5D.4080002@oracle.com> <1407f671-ce8e-8049-0b30-52e785ecc9a7@oracle.com> Message-ID: <5EAF6762.7040107@oracle.com> On 5/3/20, 4:11 PM, Sergey Bylokhov wrote: > On 4/30/20 9:31 am, Philip Race wrote: >> This test is called MaxAdvance *is max*. My emphasis. > > So there is no way to check that MaxAdvance *is max* for some > predictable values? even for simple char like "W" or "A"? "Check" or "ensure" ? To check you compare. To ensure you would have to do as you said in a previous reply by forcing max advance to as great as those arbitrary characters and I already gave my reasons why I think that is not appropriate. It is very hard to defend why certain code points are special and you would adjust the spec. again(!) to say that. And it would be to no advantage and perhaps break applications that did not expect it to change. -phil. > >> Not "all values returned by getWidths() are less than or equal to max >> advance. >> The latter is simply the inadequate implementation to partially test >> the assertion >> and which was already proving to be too much. The only way to make >> that test >> pass is to make changes to what max advance reports and I am saying that >> we should not do that. It would be artificial and wrong. >> >> -phil. >> >> >> >> On 4/30/20, 9:23 AM, Sergey Bylokhov wrote: >>> On 4/29/20 3:58 pm, Philip Race wrote: >>>> the advance of 'm' is a commonly used proxy for the design width of >>>> a latin font. >>>> But I agree it is also not really a great estimate once you >>>> consider any international text. >>>> >>>> Anyway I am not sure where you are headed with that and the >>>> discussion of charWidth() or charWidths(). >>>> >>>> I am not trying to "fix the world" here, I am just removing a test >>>> that it is pointless to maintain. >>> >>> Then probably we can report a bug, to state that we have some issues >>> here? >>> From my point of view, the test is mostly fine, it does not check some >>> real corner cases and compound glyphs but only the simple chars, >>> which should >>> work. If it does not work means all code where we try to predict the >>> size of >>> the text components is broken, and it looks like there is no way to >>> fix that. >>> >>> > > From Sergey.Bylokhov at oracle.com Mon May 4 01:13:45 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 3 May 2020 18:13:45 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris In-Reply-To: <5EAF6762.7040107@oracle.com> References: <5EA8862D.5010803@oracle.com> <60bef0c3-758c-d337-6519-58897ab50dd2@oracle.com> <5EA891D6.7060501@oracle.com> <5EA8BC21.4000101@oracle.com> <5EA9F2C0.3000902@oracle.com> <5EAA06AA.2090805@oracle.com> <1381abb5-e25c-c96e-ef7d-313f87bee7ef@oracle.com> <5EAAFD5D.4080002@oracle.com> <1407f671-ce8e-8049-0b30-52e785ecc9a7@oracle.com> <5EAF6762.7040107@oracle.com> Message-ID: On 5/3/20 5:52 pm, Philip Race wrote: > "Check" or "ensure" ? > To check you compare. > To ensure you would have to do as you said in a previous reply by forcing max advance to > as great as those arbitrary characters and I already gave my reasons why I think that is not appropriate. > It is very hard to defend why certain code points are special and you would adjust the spec. again(!) to > say that. And it would be to no advantage and perhaps break applications that did not expect it to change. +1 Ok, looks like we(still) will use the chatW("w") in Swing then =( -- Best regards, Sergey. From mikael.vidstedt at oracle.com Mon May 4 05:12:05 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Sun, 3 May 2020 22:12:05 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) Message-ID: Please review this change which implements part of JEP 381: JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! Background: Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. Testing: A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. Cheers, Mikael [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From Sergey.Bylokhov at oracle.com Tue May 5 03:03:05 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 4 May 2020 20:03:05 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) In-Reply-To: References: Message-ID: Probably the files relate to the Jemmy library should be excluded, these files a copy of the library. But I do not know the future of this library on Solaris, (cc) Shura. On 5/3/20 10:12 pm, Mikael Vidstedt wrote: > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > -- Best regards, Sergey. From alexandre.iline at oracle.com Tue May 5 19:00:12 2020 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 5 May 2020 12:00:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) In-Reply-To: References: Message-ID: <4EC85EC4-C281-4E82-9CC6-076E7E268FD1@oracle.com> Hi. That is correct. Sources of Jemmy in JDK repository is a copy of sources from code-tools Jemmy project. Any changes should be done there first, and then propagated to the jdk testable. Thank you for the good catch, Sergey, Shura > On May 4, 2020, at 8:03 PM, Sergey Bylokhov wrote: > > Probably the files relate to the Jemmy library should be excluded, these files a copy of the library. > But I do not know the future of this library on Solaris, > (cc) Shura. > > On 5/3/20 10:12 pm, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> Background: >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> Testing: >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> Cheers, >> Mikael >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > > > -- > Best regards, Sergey. From matthias.baesken at sap.com Wed May 6 13:48:59 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 May 2020 13:48:59 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS]: jdk11 8244520: problemlist java/awt/font/Rotate/RotatedFontTest.java on linux Message-ID: Please review this small change. It adds java/awt/font/Rotate/RotatedFontTest.java to the jdk ProblemList (for linux ). Reason is that the test RotatedFontTest.java ( recently added to jdk11 ) still fails on some Linux machines . ( to track this there is https://bugs.openjdk.java.net/browse/JDK-8244518 ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8244520 http://cr.openjdk.java.net/~mbaesken/webrevs/8244520_0_jdk11/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Thu May 7 00:50:22 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 17:50:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) In-Reply-To: References: Message-ID: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com> Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups. New webrev here: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/ Cheers, Mikael > On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From christoph.langer at sap.com Thu May 7 08:10:45 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 May 2020 08:10:45 +0000 Subject: [OpenJDK 2D-Dev] [CAUTION] RFR [XS]: jdk11 8244520: problemlist java/awt/font/Rotate/RotatedFontTest.java on linux In-Reply-To: References: Message-ID: Hi Matthias, excluding this test for jdk11u seems reasonable to me. Change looks good. I converted the bug to subtask of JDK-8244518. Best regards Christoph From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Baesken, Matthias Sent: Mittwoch, 6. Mai 2020 15:49 To: 2d-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: [CAUTION] [OpenJDK 2D-Dev] RFR [XS]: jdk11 8244520: problemlist java/awt/font/Rotate/RotatedFontTest.java on linux Please review this small change. It adds java/awt/font/Rotate/RotatedFontTest.java to the jdk ProblemList (for linux ). Reason is that the test RotatedFontTest.java ( recently added to jdk11 ) still fails on some Linux machines . ( to track this there is https://bugs.openjdk.java.net/browse/JDK-8244518 ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8244520 http://cr.openjdk.java.net/~mbaesken/webrevs/8244520_0_jdk11/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu May 7 18:26:24 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 May 2020 11:26:24 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) In-Reply-To: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com> References: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com> Message-ID: <5EB452D0.3060309@oracle.com> This is all +1 from me. -phil. On 5/6/20, 5:50 PM, Mikael Vidstedt wrote: > Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups. > > New webrev here: > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/ > > Cheers, > Mikael > >> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >> From mikael.vidstedt at oracle.com Thu May 7 21:22:34 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 May 2020 14:22:34 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) In-Reply-To: <5EB452D0.3060309@oracle.com> References: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com> <5EB452D0.3060309@oracle.com> Message-ID: Thank you Phil! Cheers, Mikael > On May 7, 2020, at 11:26 AM, Philip Race wrote: > > This is all +1 from me. > > -phil. > > On 5/6/20, 5:50 PM, Mikael Vidstedt wrote: >> Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups. >> >> New webrev here: >> >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/ >> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/ >> >> Cheers, >> Mikael >> >>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>> >>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >>> From Sergey.Bylokhov at oracle.com Thu May 7 23:54:07 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 7 May 2020 16:54:07 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop) In-Reply-To: <5EB452D0.3060309@oracle.com> References: <3D91D7AE-11DB-4E80-B9A2-DAF6A96E24E6@oracle.com> <5EB452D0.3060309@oracle.com> Message-ID: <8d229cb5-7616-b6b8-6b13-17fdb7633cef@oracle.com> Looks fine. On 5/7/20 11:26 am, Philip Race wrote: > This is all +1 from me. > > -phil. > > On 5/6/20, 5:50 PM, Mikael Vidstedt wrote: >> Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups. >> >> New webrev here: >> >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/ >> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/ >> >> Cheers, >> Mikael >> >>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt? wrote: >>> >>> >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>> >>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >>> -- Best regards, Sergey. From philip.race at oracle.com Thu May 14 22:20:22 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 14 May 2020 15:20:22 -0700 Subject: [OpenJDK 2D-Dev] Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested. Message-ID: <5EBDC426.3020508@oracle.com> The first EA build of Project Lanai is available at https://jdk.java.net/lanai/ This is a new Java2D graphics pipeline for macOS. It can run the usual client demos, such as SwingSet2 and J2Ddemo, and even a large app like an IDE, although not without glitches. The EA download page has a link to the list of known, open bugs you can consult. It is a first EA build and there is plenty of work still to be done and we have doubtless not tested every situation nor do we have every piece of mac hardware out there, so there will be unreported issues too. Please try it, and provide feedback to the lanai-dev at openjdk.java.net mailing list. Make sure you specify -Dsun.java2d.metal=true !! -phil. From bourges.laurent at gmail.com Fri May 15 08:28:30 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 15 May 2020 10:28:30 +0200 Subject: [OpenJDK 2D-Dev] Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested. In-Reply-To: <5EBDC426.3020508@oracle.com> References: <5EBDC426.3020508@oracle.com> Message-ID: Congratulations ! I suppose it was an intense task. Does metal support correct color blending ? I mean not the basic srgb mixing but gamma corrected at least. FYI I am implementing a new experimental color blender in pure java for the future Marlin renderer to achieve higher quality like gimp 2.10, skia (firefox, android) does... Cheers, Laurent Le ven. 15 mai 2020 ? 00:20, Philip Race a ?crit : > The first EA build of Project Lanai is available at > https://jdk.java.net/lanai/ > > This is a new Java2D graphics pipeline for macOS. > > It can run the usual client demos, such as SwingSet2 and J2Ddemo, > and even a large app like an IDE, although not without glitches. > The EA download page has a link to the list of known, open bugs you can > consult. > > It is a first EA build and there is plenty of work still to be done > and we have doubtless not tested every situation nor do we have > every piece of mac hardware out there, so there will be unreported > issues too. > > Please try it, and provide feedback to the lanai-dev at openjdk.java.net > mailing list. > > Make sure you specify -Dsun.java2d.metal=true !! > > -phil. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ushakov at jetbrains.com Fri May 15 12:10:16 2020 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Fri, 15 May 2020 15:10:16 +0300 Subject: [OpenJDK 2D-Dev] Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested. In-Reply-To: References: <5EBDC426.3020508@oracle.com> Message-ID: <395A2BA5-4051-47EA-8F56-16AE9F1F5523@jetbrains.com> Hi Laurent, > Does metal support correct color blending ? > I mean not the basic srgb mixing but gamma corrected at least. No, metal does not support it out of the box but I think it should not be a problem to implement the conversion in shaders or computational kernels. > FYI I am implementing a new experimental color blender in pure java for the future Marlin renderer to achieve higher quality like gimp 2.10, skia (firefox, android) does... I think that GPU accelerated proper blending would be a great feature in Lanai. Best Regards, Alexey > On 15 May 2020, at 11:28, Laurent Bourg?s wrote: > > Congratulations ! > > I suppose it was an intense task. > > Does metal support correct color blending ? > I mean not the basic srgb mixing but gamma corrected at least. > > FYI I am implementing a new experimental color blender in pure java for the future Marlin renderer to achieve higher quality like gimp 2.10, skia (firefox, android) does... > > Cheers, > Laurent > > Le ven. 15 mai 2020 ? 00:20, Philip Race > a ?crit : > The first EA build of Project Lanai is available at > https://jdk.java.net/lanai/ > > This is a new Java2D graphics pipeline for macOS. > > It can run the usual client demos, such as SwingSet2 and J2Ddemo, > and even a large app like an IDE, although not without glitches. > The EA download page has a link to the list of known, open bugs you can > consult. > > It is a first EA build and there is plenty of work still to be done > and we have doubtless not tested every situation nor do we have > every piece of mac hardware out there, so there will be unreported > issues too. > > Please try it, and provide feedback to the lanai-dev at openjdk.java.net > mailing list. > > Make sure you specify -Dsun.java2d.metal=true !! > > -phil. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAYATHIRTH.D.V at ORACLE.COM Sat May 16 04:33:29 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Sat, 16 May 2020 10:03:29 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8166038 BufferedImage methods getTileGridXOffset() and getTileGridYOffset() return a non 0 value for sub images In-Reply-To: <2250d1eb-5043-cf4a-66d4-8877fc6acd52@geomatys.com> References: <3eef46ac-17cc-2641-496c-74d849ce8a93@oracle.com> <2d5fbd6b-61aa-546a-9a21-7f1d2554e8fb@oracle.com> <40B46970-F2F9-4796-BFB1-06F21608997A@ORACLE.COM> <2250d1eb-5043-cf4a-66d4-8877fc6acd52@geomatys.com> Message-ID: Hi Martin, Apologies for late reply(mail got lost and I forgot about checking it). I was under the impression that we have another implementation of RenderedImage which we can use, but looks like there are none. Doing that for just this test case is not needed. webrev.01 looks good to me. Thanks, Jay > On 24-Apr-2020, at 6:38 PM, Martin Desruisseaux wrote: > > Hello Jayathirth > > Le 24/04/2020 ? 14:32, Jayathirth D v a ?crit : > >> Then its better if we can include scenarios in test case(like using RenderedImage) to actually verify this behaviour(non-zero grid offsets) instead of just having BufferedImage. >> > No problem, I can edit the patch. But by scenario do you mean a static method like below? > > /** > * Verifies that the tile grid offsets provide a consistent mapping > * from the tile coordinate system and to the pixel coordinate system. > */ > static void verifyTileGridOffsets(RenderedImage img) { > ... > } > Martin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.desruisseaux at geomatys.com Sat May 16 08:28:26 2020 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Sat, 16 May 2020 10:28:26 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8166038 BufferedImage methods getTileGridXOffset() and getTileGridYOffset() return a non 0 value for sub images In-Reply-To: References: <3eef46ac-17cc-2641-496c-74d849ce8a93@oracle.com> <2d5fbd6b-61aa-546a-9a21-7f1d2554e8fb@oracle.com> <40B46970-F2F9-4796-BFB1-06F21608997A@ORACLE.COM> <2250d1eb-5043-cf4a-66d4-8877fc6acd52@geomatys.com> Message-ID: <729bbaf9-8c2e-a312-6a09-fdbf843bf08b@geomatys.com> Hello Jay Le 16/05/2020 ? 06:33, Jayathirth D v a ?crit?: > Apologies for late reply(mail got lost and I forgot about checking it). No problem, thanks for the reply. In the meantime I have sent an updated version of the test case to Sergey, with test for arbitrary RenderedImage as a separated method. > I was under the impression that we have another implementation of > RenderedImage which we can use, but looks like there are none. I have found in Java2D source code that SunGraphics2D.getTileIndex(int, int, int) method is using the same formula than JAI. Consequently I think it is possible to demonstrate BufferedImage problem by wrapping it behind another RenderedImage (just delegating all method calls to the wrapped BufferedImage) for forcing SunGraphics2D to execute the general case instead that its optimizations for BufferedImage special case. That test would demonstrate that without the fix, attempt to draw a wrapped BufferedImage.subSubImage(?) with Graphics2D.drawRenderedImage(?) causes an IndexOutOfBoundsException to be thrown. Please let me know if such test is desired. ??? Martin From philip.race at oracle.com Mon May 18 05:16:41 2020 From: philip.race at oracle.com (Philip Race) Date: Sun, 17 May 2020 22:16:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 6949753 java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop Message-ID: <5EC21A39.4080104@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-6949753 webrev : http://cr.openjdk.java.net/~prr/6949753/ Buggy, manual and not very useful. Delete. -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAYATHIRTH.D.V at ORACLE.COM Mon May 18 06:22:29 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Mon, 18 May 2020 11:52:29 +0530 Subject: [OpenJDK 2D-Dev] RFR: 6949753 java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop In-Reply-To: <5EC21A39.4080104@oracle.com> References: <5EC21A39.4080104@oracle.com> Message-ID: <723CFB34-3AB7-4001-B4FB-1BD5AE3B2676@ORACLE.COM> +1. Thanks, Jay > On 18-May-2020, at 10:46 AM, Philip Race wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-6949753 > webrev : http://cr.openjdk.java.net/~prr/6949753/ > > Buggy, manual and not very useful. Delete. > > -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue May 19 00:07:51 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 18 May 2020 17:07:51 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes. Message-ID: <5EC32357.9070108@oracle.com> bug : https://bugs.openjdk.java.net/browse/JDK-8245159 webrev: http://cr.openjdk.java.net/~prr/8245159/ TextLayout does not like being constructed with an empty string, so when we accept a string from the application and use it in creating a TextLayout we need to be check. I looked around for other cases that may be missing a check but did not spot any. -phil. From Sergey.Bylokhov at oracle.com Tue May 19 04:29:10 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 18 May 2020 21:29:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes. In-Reply-To: <5EC32357.9070108@oracle.com> References: <5EC32357.9070108@oracle.com> Message-ID: Hi, Phil. I guess the old code used TextLayout because the check above is "false": boolean simple = values == null || (values.getKerning() == 0 && values.getLigatures() == 0 && values.getBaselineTransform() == null); Is it possible that for the font which use attributes/kerning/ligatures the height calculated via TextLayout and FontDesignMetrics.getSimpleBounds() will be different? BTW what about the comment for this block: // this code should be in textlayout // quick check for simple text, assume GV ok to use if simple On 5/18/20 5:07 pm, Philip Race wrote: > bug : https://bugs.openjdk.java.net/browse/JDK-8245159 > webrev: http://cr.openjdk.java.net/~prr/8245159/ > > TextLayout does not like being constructed with an empty string, so > when we accept a string from the application and? use it in > creating a TextLayout we need to be check. > I looked around for other cases that may be missing a check but did not spot any. > > -phil. -- Best regards, Sergey. From philip.race at oracle.com Tue May 19 04:56:53 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 18 May 2020 21:56:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes. In-Reply-To: References: <5EC32357.9070108@oracle.com> Message-ID: <5EC36715.9060408@oracle.com> On 5/18/20, 9:29 PM, Sergey Bylokhov wrote: > Hi, Phil. > > I guess the old code used TextLayout because the check above is "false": > boolean simple = values == null || > (values.getKerning() == 0 && values.getLigatures() == 0 && > values.getBaselineTransform() == null); yes ... > > Is it possible that for the font which use > attributes/kerning/ligatures the height > calculated via TextLayout and FontDesignMetrics.getSimpleBounds() will > be different? no. > > BTW what about the comment for this block: > // this code should be in textlayout > // quick check for simple text, assume GV ok to use if simple > well, there's the the issue that TL should not barf, but it does. -phil. > > On 5/18/20 5:07 pm, Philip Race wrote: >> bug : https://bugs.openjdk.java.net/browse/JDK-8245159 >> webrev: http://cr.openjdk.java.net/~prr/8245159/ >> >> TextLayout does not like being constructed with an empty string, so >> when we accept a string from the application and use it in >> creating a TextLayout we need to be check. >> I looked around for other cases that may be missing a check but did >> not spot any. >> >> -phil. > > From Sergey.Bylokhov at oracle.com Tue May 19 05:20:41 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 18 May 2020 22:20:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes. In-Reply-To: <5EC36715.9060408@oracle.com> References: <5EC32357.9070108@oracle.com> <5EC36715.9060408@oracle.com> Message-ID: <17f412e6-bfc1-acb3-b8df-c6318983c33f@oracle.com> On 5/18/20 9:56 pm, Philip Race wrote: >> Is it possible that for the font which use attributes/kerning/ligatures the height >> calculated via TextLayout and FontDesignMetrics.getSimpleBounds() will be different? > > no. ok, +1 -- Best regards, Sergey. From philip.race at oracle.com Thu May 21 20:56:44 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 21 May 2020 13:56:44 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 Message-ID: <5EC6EB0C.3060706@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8244621 Webrev : http://cr.openjdk.java.net/~prr/8244621/ macOS ships some UI fonts which it does not enumerate, all having names beginning with "." It expects you to create them using APIs such as CTFontCreateUIFontForLanguage(kCTFontSystemFontType, 0, NULL); or nsFont = [NSFont systemFontOfSize:1.0]; In apps built with all SDKs to date, so long as you can get the real "." name you can still request it by name. But with the latest Xcode 11 this not only prints a warning that you should not do it, it also gives you Times New Roman instead - not a standard UI font - probably a choice so it is obvious it is not a UI font. Our problem here is that JavaFX uses the system font as its "logical" font called System and also JavaFX uses Java 2D for printing. It messages over the ".*" name to Java 2D to use as the font to print. But with the latest Xcode 2D is not allowed to create the font using that name. This fix changes the JDK code for macOS that creates the native font pointer to check if the name being requested is one of the UI fonts. If it is, then it uses the NSFont systemFontOfSize API to create the font, which fixes the problem. If someone asks for a random name such as ".foo" Note that 1) JDK only enumerates the regular and bold system font which is all FX uses. 2) The fix *could* have just tested to see if the requested name begins with "." and that worked too but it wasn't clear what would happen if there is some other font called ".Foo". We tested and names starting with "." seem to be absolutely reserved for these system fonts on macOS If you see such a font. it is a system font. We tested and if you have a random name such as ".FOO" macOS does the same thing - it assumes it is a system font and won't give it to you. So probably testing for a "." prefix would have been OK but as written it is more certain and is robust against Apple changing the nameing scheme to be (sa) a "~" prefix. No regression test as this isn't easily testable and the main place it matters is FX printing. However we've verified this on 10.13.6 with the old tool chain and 10.15.2 with the new toolchain and fixes the warnings and FX printing. The removal of adding the fixed width font is because we never needed it and it is just Monaco anyway ... -phil. From kevin.rushforth at oracle.com Thu May 21 21:16:18 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 May 2020 14:16:18 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 In-Reply-To: <5EC6EB0C.3060706@oracle.com> References: <5EC6EB0C.3060706@oracle.com> Message-ID: +1 In case you want to fix it before you push, you have trailing whitespace in the file (jcheck won't complain since it doesn't check .m files, so no worries if you don't). -- Kevin On 5/21/2020 1:56 PM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8244621 > Webrev : http://cr.openjdk.java.net/~prr/8244621/ > > macOS ships some UI fonts which it does not enumerate, all having > names beginning with "." > It expects you to create them using APIs such as > CTFontCreateUIFontForLanguage(kCTFontSystemFontType, 0, NULL); > or > nsFont = [NSFont systemFontOfSize:1.0]; > > In apps built with all SDKs to date, so long as you can get the real > "." name you can still > request it by name. > > But with the latest Xcode 11 this not only prints a warning that you > should not do it, > it also gives you Times New Roman instead - not a standard UI font - > probably a choice > so it is obvious it is not a UI font. > > Our problem here is that JavaFX uses the system font as its "logical" > font called System > and also JavaFX uses Java 2D for printing. It messages over the ".*" > name to Java 2D > to use as the font to print. But with the latest Xcode 2D is not > allowed to create the font using that name. > > This fix changes the JDK code for macOS that creates the native font > pointer to check if the name being requested > is one of the UI fonts. If it is, then it uses the NSFont > systemFontOfSize API to create the font, which fixes the problem. > > If someone asks for a random name such as ".foo" > Note that > 1) JDK only enumerates the regular and bold system font which is all > FX uses. > > 2) The fix *could* have just tested to see if the requested name > begins with "." and that worked too but it > wasn't clear what would happen if there is some other font called > ".Foo". We tested and > names starting with "." seem to be absolutely reserved for these > system fonts on macOS > If you see such a font. it is a system font. We tested and if you have > a random name such as ".FOO" > macOS does the same thing - it assumes it is a system font and won't > give it to you. > So probably testing for a "." prefix would have been OK but as written > it is more certain and > is robust against Apple changing the nameing scheme to be (sa) a "~" > prefix. > > No regression test as this isn't easily testable and the main place it > matters is FX printing. > However we've verified this on 10.13.6 with the old tool chain and > 10.15.2 with the new toolchain > and fixes the warnings and FX printing. > > The removal of adding the fixed width font is because we never needed > it and it is just Monaco anyway ... > > -phil. > > > From philip.race at oracle.com Thu May 21 21:23:45 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 21 May 2020 14:23:45 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 In-Reply-To: References: <5EC6EB0C.3060706@oracle.com> Message-ID: <5EC6F161.6090906@oracle.com> I know about the trailing white space. Well at least I know there is some. I didn't notice if I accidentally added more. Correct jcheck won't complain and I have an open bug to clean this up across all code before the move to git. https://bugs.openjdk.java.net/browse/JDK-8240487 -phil. On 5/21/20, 2:16 PM, Kevin Rushforth wrote: > +1 > > In case you want to fix it before you push, you have trailing > whitespace in the file (jcheck won't complain since it doesn't check > .m files, so no worries if you don't). > > -- Kevin > > > On 5/21/2020 1:56 PM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244621 >> Webrev : http://cr.openjdk.java.net/~prr/8244621/ >> >> macOS ships some UI fonts which it does not enumerate, all having >> names beginning with "." >> It expects you to create them using APIs such as >> CTFontCreateUIFontForLanguage(kCTFontSystemFontType, 0, NULL); >> or >> nsFont = [NSFont systemFontOfSize:1.0]; >> >> In apps built with all SDKs to date, so long as you can get the real >> "." name you can still >> request it by name. >> >> But with the latest Xcode 11 this not only prints a warning that you >> should not do it, >> it also gives you Times New Roman instead - not a standard UI font - >> probably a choice >> so it is obvious it is not a UI font. >> >> Our problem here is that JavaFX uses the system font as its "logical" >> font called System >> and also JavaFX uses Java 2D for printing. It messages over the ".*" >> name to Java 2D >> to use as the font to print. But with the latest Xcode 2D is not >> allowed to create the font using that name. >> >> This fix changes the JDK code for macOS that creates the native font >> pointer to check if the name being requested >> is one of the UI fonts. If it is, then it uses the NSFont >> systemFontOfSize API to create the font, which fixes the problem. >> >> If someone asks for a random name such as ".foo" >> Note that >> 1) JDK only enumerates the regular and bold system font which is all >> FX uses. >> >> 2) The fix *could* have just tested to see if the requested name >> begins with "." and that worked too but it >> wasn't clear what would happen if there is some other font called >> ".Foo". We tested and >> names starting with "." seem to be absolutely reserved for these >> system fonts on macOS >> If you see such a font. it is a system font. We tested and if you >> have a random name such as ".FOO" >> macOS does the same thing - it assumes it is a system font and won't >> give it to you. >> So probably testing for a "." prefix would have been OK but as >> written it is more certain and >> is robust against Apple changing the nameing scheme to be (sa) a "~" >> prefix. >> >> No regression test as this isn't easily testable and the main place >> it matters is FX printing. >> However we've verified this on 10.13.6 with the old tool chain and >> 10.15.2 with the new toolchain >> and fixes the warnings and FX printing. >> >> The removal of adding the fixed width font is because we never needed >> it and it is just Monaco anyway ... >> >> -phil. >> >> >> > From ayase177 at yahoo.co.jp Wed May 27 05:07:19 2020 From: ayase177 at yahoo.co.jp (Ayase177) Date: Tue, 26 May 2020 22:07:19 -0700 (MST) Subject: [OpenJDK 2D-Dev] The rotate method of OpenJDK is not working properly when using 180 degree rotation in DBCS plain style. Message-ID: <1590556039228-0.post@n7.nabble.com> The rotate method of OpenJDK is not working properly when using 180 degree rotation in DBCS plain style. [Enviroment] Win10Pro?Japanese AdoptOpenJDK Java8 u252b09.1(x86) [on condition] Use Font:MS Gothic <-?Japanese Font so Double byte character set use. Plain Style font size under 21pt(21pt over is work well) [Result] Use Oracle Java8 / Plain style -> OK Use Oracle Java8 / Bold style-> OK Use AdoptOpenJDK AdoptOpenJDK Java8 u252b09.1 / Plain style -> NG Use AdoptOpenJDK AdoptOpenJDK Java8 u252b09.1 / Bold style -> OK [what I want to know] Does AdoptOpenJDK AdoptOpenJDK Java8 u252b09.1 still have a rotating bug with an unfixed Double byte character set? [Similar bug report] Graphics2D.drawString produces different text widths, but the same height, when rotated 180 degrees https://bugs.openjdk.java.net/browse/JDK-8194555 OpenJDK can't support render text with rotation for DBCS fonts https://bugs.openjdk.java.net/browse/JDK-8163278 Fonts with embedded bitmaps are not always rotated https://bugs.openjdk.java.net/browse/JDK-8204929 The test code is below. !!test code use Japanese MS Gothic font and text.!! ===================================================== package fonttest; import java.awt.Font; import java.awt.FontMetrics; import java.awt.Graphics; import java.awt.Graphics2D; import javax.swing.JEditorPane; import javax.swing.JFrame; class TestWindow extends JFrame{ public TestWindow(String title, int width, int height) { super(title); setDefaultCloseOperation(EXIT_ON_CLOSE); setSize(width,height); setLocationRelativeTo(null); setResizable(false); } } class DrawCanvas extends JEditorPane{ public void paintComponent(Graphics g) { super.paintComponent(g); Font plain_FONT= new Font("?? ????", Font.PLAIN, 15); g.setFont(plain_FONT); g.drawString("ABCabc0123456789????? name=?? ???????? plain 15pt", 10, 50); System.out.println("1 " + g.getFont()); Font bold_FONT= new Font("?? ????", Font.BOLD, 15); g.setFont(bold_FONT); g.drawString("ABCabc0123456789????? name=?? ???????? Bold 15pt", 10, 100); System.out.println("2 " + g.getFont()); //rotate Graphics2D g2 = (Graphics2D)g; g2.setFont(plain_FONT); // change Font object for Bold Style test. FontMetrics fm = null; String str = "ABCabc0123456789?????"; fm = g2.getFontMetrics(); int asent = fm.getAscent(); g2.rotate(Math.toRadians(-180), 300, 200); g2.drawString(str, 150+asent,10); } } public class FontTest { public static void main(String[] args) { TestWindow tw = new TestWindow("???????", 800, 600); tw.add(new DrawCanvas()); tw.setVisible(true); } } ================================================================ Thank you. -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Java-2D-API-f95531.html