From matthias.baesken at sap.com Tue Oct 1 08:18:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 1 Oct 2019 08:18:57 +0000 Subject: [OpenJDK 2D-Dev] [11u] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: Hi Christoph, looks good to me . I think the naming ?xinerama_init_linux? is a bit misleading now , because the function is obviously not any more just for linux : 619 #if defined(__linux__) || defined(MACOSX) || defined(_AIX) 620 static void xinerama_init_linux() But this is out of scope of your downport change . Best regards, Matthias From: Langer, Christoph Sent: Dienstag, 24. September 2019 15:39 To: jdk-updates-dev at openjdk.java.net Cc: 2d-dev at openjdk.java.net Subject: [11u] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality Hi, please help reviewing this backport of the fix for AIX Xinerama/Xrender basic functionality to JDK11 Updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8220528 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0223b7b8a1c5 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220528.11u-dev.0/ The patch did not apply cleanly. I had to manually resolve the part around line 125 because the 11u version defines another function for Solaris that didn?t exist any more in the head version. Furthermore I needed to fix the #ifdef in line 1641 (new) to explicitly refer Solaris. Otherwise it would not build on AIX. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Oct 3 05:39:34 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Oct 2019 22:39:34 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8229810 NullPointerException getting bounds of GraphicsConfiguration In-Reply-To: References: Message-ID: <0bf1cf82-e134-ec41-0b73-64e22cbb824c@oracle.com> Any volunteers to review=)? On 8/19/19 12:03 pm, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229810 > Fix: http://cr.openjdk.java.net/~serb/8229810/webrev.00 > > The root cause is a lack of synchronization in CGraphicsEnvironment, > we create the GraphicsDevice under a special lock which is used to > access the list of devices: > http://hg.openjdk.java.net/jdk/client/file/39f133168348/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#l184 > > but initialize the device w/o this lock. > http://hg.openjdk.java.net/jdk/client/file/39f133168348/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#l187 > > So it is possible that we create the device, add it to the list of devices, > and before we initialize it the user could access the not fully initialized object. > > The bug exists from the jdk7, but it was hidden because all fields in CGraphicsDevice > were primitives, so the app just used invalid data. In JDK-8211992 the object field "bounds" > was added and now we can get NPE if this field was not initialized. > > As a fix, I suggest to always initialize the graphics device in the constructor. > > Note that we cannot move "displayChanged" which will notify devices and all listeners > in awt/swing in the CGraphicsEnvironment under the lock, it will cause various > deadlocks in the a different listeners. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Oct 3 05:40:40 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Oct 2019 22:40:40 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8228676 Cleanup the native code related to fonts on Unix In-Reply-To: <11bf4129-661f-5f75-56c6-20ad70611aba@oracle.com> References: <11bf4129-661f-5f75-56c6-20ad70611aba@oracle.com> Message-ID: Anyone? On 9/14/19 12:44 pm, Sergey Bylokhov wrote: > Any volunteers to review=)? > > On 7/26/19 2:48 pm, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 14. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228676 >> Fix: http://cr.openjdk.java.net/~serb/8228676/webrev.00 >> >> There is some amount of code which is unused since MToolkit was removed. >> In the fix, unused code was removed, note that some stubs like xx_initIDs >> still present in the code, because they are still called from the java side. >> >> Mach5 is green. >> >> The fix itself is similar to the previous fixes: >> https://bugs.openjdk.java.net/browse/JDK-8223766 >> https://bugs.openjdk.java.net/browse/JDK-8224171 >> > > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Thu Oct 3 07:47:12 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Thu, 3 Oct 2019 13:17:12 +0530 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8229810 NullPointerException getting bounds of GraphicsConfiguration In-Reply-To: <0bf1cf82-e134-ec41-0b73-64e22cbb824c@oracle.com> References: <0bf1cf82-e134-ec41-0b73-64e22cbb824c@oracle.com> Message-ID: <5BE96CFD-3291-491B-82A0-404A7C75EA08@oracle.com> Hi Sergey, I think we should drive device update through GraphicsEnvironment.displayChanged() and DisplayChangeListener instead of force updating bounds in GraphicsDevice.displayChanged in the constructor. We can synchronise the GraphicsEnvironment.displayChanged() by calling it under CGraphicsEnvironment.initDevices() sync lock, this will force call DisplayChangeListener when devices are updated. --- a/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Oct 03 00:38:17 2019 +0300 +++ b/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Oct 03 13:16:12 2019 +0530 @@ -183,8 +183,8 @@ devices.put(id, old.containsKey(id) ? old.get(id) : new CGraphicsDevice(id)); } + displayChanged(); } - displayChanged(); } I made this change and tested with reproduction steps and I dont see NPE. Thanks, Jay > On 03-Oct-2019, at 11:09 AM, Sergey Bylokhov wrote: > > Any volunteers to review=)? > > On 8/19/19 12:03 pm, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 14. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229810 >> Fix: http://cr.openjdk.java.net/~serb/8229810/webrev.00 >> The root cause is a lack of synchronization in CGraphicsEnvironment, >> we create the GraphicsDevice under a special lock which is used to >> access the list of devices: >> http://hg.openjdk.java.net/jdk/client/file/39f133168348/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#l184 >> but initialize the device w/o this lock. >> http://hg.openjdk.java.net/jdk/client/file/39f133168348/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#l187 >> So it is possible that we create the device, add it to the list of devices, >> and before we initialize it the user could access the not fully initialized object. >> The bug exists from the jdk7, but it was hidden because all fields in CGraphicsDevice >> were primitives, so the app just used invalid data. In JDK-8211992 the object field "bounds" >> was added and now we can get NPE if this field was not initialized. >> As a fix, I suggest to always initialize the graphics device in the constructor. >> Note that we cannot move "displayChanged" which will notify devices and all listeners >> in awt/swing in the CGraphicsEnvironment under the lock, it will cause various >> deadlocks in the a different listeners. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Oct 3 08:29:42 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Thu, 3 Oct 2019 13:59:42 +0530 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8228676 Cleanup the native code related to fonts on Unix In-Reply-To: References: <11bf4129-661f-5f75-56c6-20ad70611aba@oracle.com> Message-ID: <2B6F80CA-FA84-46E3-838C-06489BA70FF0@oracle.com> Changes are fine. Thanks, Jay > On 03-Oct-2019, at 11:10 AM, Sergey Bylokhov wrote: > > Anyone? > > On 9/14/19 12:44 pm, Sergey Bylokhov wrote: >> Any volunteers to review=)? >> On 7/26/19 2:48 pm, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for JDK 14. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228676 >>> Fix: http://cr.openjdk.java.net/~serb/8228676/webrev.00 >>> >>> There is some amount of code which is unused since MToolkit was removed. >>> In the fix, unused code was removed, note that some stubs like xx_initIDs >>> still present in the code, because they are still called from the java side. >>> >>> Mach5 is green. >>> >>> The fix itself is similar to the previous fixes: >>> https://bugs.openjdk.java.net/browse/JDK-8223766 >>> https://bugs.openjdk.java.net/browse/JDK-8224171 >>> > > > -- > Best regards, Sergey. From alexey.ivanov at oracle.com Thu Oct 3 15:57:45 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 3 Oct 2019 16:57:45 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java apps do not support Myanmar fonts In-Reply-To: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> Message-ID: Any volunteers to review? On 25/09/2019 20:38, Alexey Ivanov wrote: > Hello, > > Please review the fix for JDK 14: > > bug: https://bugs.openjdk.java.net/browse/JDK-8223558 > webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ > > Problem description: > Java renders Myanmar script incorrectly. Some glyphs are not combined, > which makes text unreadable. > For example, this glyph ?? is made of two characters U+1000 and > U+103C. Java renders two separate glyphs. > > Workaround: > Enable ligatures or kerning on the font to get the correct rendering. > > The fix: > Enables complex layout for base Myanmar characters (U+1000-U+109F). > Provides fallback font on Windows. > On Linux, fontconfig handles the fallback. > > I ran awt/font tests, no new failures found. > -- Regards, Alexey From philip.race at oracle.com Thu Oct 3 16:31:40 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 03 Oct 2019 09:31:40 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java apps do not support Myanmar fonts In-Reply-To: References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> Message-ID: <5D96226C.7050503@oracle.com> 1) This is an RFE, not a bug. 2) Does this font exist on Windows 7 ? 3) This cannot be backported since the older JDK releases will not support it. -phil. On 10/3/19, 8:57 AM, Alexey Ivanov wrote: > Any volunteers to review? > > On 25/09/2019 20:38, Alexey Ivanov wrote: >> Hello, >> >> Please review the fix for JDK 14: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >> >> Problem description: >> Java renders Myanmar script incorrectly. Some glyphs are not >> combined, which makes text unreadable. >> For example, this glyph ?? is made of two characters U+1000 and >> U+103C. Java renders two separate glyphs. >> >> Workaround: >> Enable ligatures or kerning on the font to get the correct rendering. >> >> The fix: >> Enables complex layout for base Myanmar characters (U+1000-U+109F). >> Provides fallback font on Windows. >> On Linux, fontconfig handles the fallback. >> >> I ran awt/font tests, no new failures found. >> From alexey.ivanov at oracle.com Thu Oct 3 17:28:46 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 3 Oct 2019 18:28:46 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java apps do not support Myanmar fonts In-Reply-To: <5D96226C.7050503@oracle.com> References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> <5D96226C.7050503@oracle.com> Message-ID: Hi Phil, Thank you for your review. Please see my answers inline: On 03/10/2019 17:31, Philip Race wrote: > 1) This is an RFE, not a bug. I have updated the CR type to RFE. > 2) Does this font exist on Windows 7 ? No, it does not. This font was added in Windows 8. https://docs.microsoft.com/en-us/typography/font-list/myanmar-text The tests check if the required font is available; if not, an message is printed and the test exists. > 3) This cannot be backported since the older JDK releases will not > support it. No, it cannot be backported to 8u because ICU does not support Myanmar. It can be brought to 11 updates. Regards, Alexey > > > -phil. > > > On 10/3/19, 8:57 AM, Alexey Ivanov wrote: >> Any volunteers to review? >> >> On 25/09/2019 20:38, Alexey Ivanov wrote: >>> Hello, >>> >>> Please review the fix for JDK 14: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >>> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >>> >>> Problem description: >>> Java renders Myanmar script incorrectly. Some glyphs are not >>> combined, which makes text unreadable. >>> For example, this glyph ?? is made of two characters U+1000 and >>> U+103C. Java renders two separate glyphs. >>> >>> Workaround: >>> Enable ligatures or kerning on the font to get the correct rendering. >>> >>> The fix: >>> Enables complex layout for base Myanmar characters (U+1000-U+109F). >>> Provides fallback font on Windows. >>> On Linux, fontconfig handles the fallback. >>> >>> I ran awt/font tests, no new failures found. >>> From Sergey.Bylokhov at oracle.com Thu Oct 3 21:49:24 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 3 Oct 2019 14:49:24 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8229810 NullPointerException getting bounds of GraphicsConfiguration In-Reply-To: <5BE96CFD-3291-491B-82A0-404A7C75EA08@oracle.com> References: <0bf1cf82-e134-ec41-0b73-64e22cbb824c@oracle.com> <5BE96CFD-3291-491B-82A0-404A7C75EA08@oracle.com> Message-ID: <7bfc2af5-1c35-4426-0e67-c439cb5e98f2@oracle.com> Hi, Jay. > I think we should drive device update through GraphicsEnvironment.displayChanged() and DisplayChangeListener instead of force updating bounds in GraphicsDevice.displayChanged in the constructor. > We can synchronise the GraphicsEnvironment.displayChanged() by calling it under CGraphicsEnvironment.initDevices() sync lock, this will force call DisplayChangeListener when devices are updated. Unfortunately, we cannot move the "displayChanged()" method under the lock, because this method will notify all DisplayChangedListener which might use some other locks, so we will have GraphicsEnvironment.sync->SomeOther locks order, and at the same time, some other thread may acquired SomeOther lock and tried to call CGraphicsEnvironment.getScreenDevices(), so we will get SomeOther->CGraphicsEnvironment.sync and this will cause a deadlock. -- Best regards, Sergey. From philip.race at oracle.com Fri Oct 4 20:13:27 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 4 Oct 2019 13:13:27 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java apps do not support Myanmar fonts In-Reply-To: References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> <5D96226C.7050503@oracle.com> Message-ID: The code changes look fine, but? nothing you are doing here makes Myanmar "supported". It may work reasonably well, but it does not get added to the list of supported locales - for Oracle JDK anyway. Also I don't know what input method support might be required for this besides what you are doing here on the display side. -phil. On 10/3/19 10:28 AM, Alexey Ivanov wrote: > Hi Phil, > > Thank you for your review. > Please see my answers inline: > > On 03/10/2019 17:31, Philip Race wrote: >> 1) This is an RFE, not a bug. > > I have updated the CR type to RFE. > >> 2) Does this font exist on Windows 7 ? > > No, it does not. This font was added in Windows 8. > https://docs.microsoft.com/en-us/typography/font-list/myanmar-text > > The tests check if the required font is available; if not, an message > is printed and the test exists. > >> 3) This cannot be backported since the older JDK releases will not >> support it. > > No, it cannot be backported to 8u because ICU does not support Myanmar. > It can be brought to 11 updates. > > > Regards, > Alexey >> >> >> -phil. >> >> >> On 10/3/19, 8:57 AM, Alexey Ivanov wrote: >>> Any volunteers to review? >>> >>> On 25/09/2019 20:38, Alexey Ivanov wrote: >>>> Hello, >>>> >>>> Please review the fix for JDK 14: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >>>> >>>> Problem description: >>>> Java renders Myanmar script incorrectly. Some glyphs are not >>>> combined, which makes text unreadable. >>>> For example, this glyph ?? is made of two characters U+1000 and >>>> U+103C. Java renders two separate glyphs. >>>> >>>> Workaround: >>>> Enable ligatures or kerning on the font to get the correct rendering. >>>> >>>> The fix: >>>> Enables complex layout for base Myanmar characters (U+1000-U+109F). >>>> Provides fallback font on Windows. >>>> On Linux, fontconfig handles the fallback. >>>> >>>> I ran awt/font tests, no new failures found. >>>> > From takiguc at linux.vnet.ibm.com Mon Oct 7 07:33:23 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 07 Oct 2019 16:33:23 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used Message-ID: Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ JTreg testcase and results are including JDK-8221741 [1]. [1] https://bugs.openjdk.java.net/browse/JDK-8221741 Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From alexey.ivanov at oracle.com Mon Oct 7 12:07:12 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 7 Oct 2019 13:07:12 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java does not render Myanmar script correctly In-Reply-To: References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> <5D96226C.7050503@oracle.com> Message-ID: <23ff6890-e126-990c-68d5-df11597a9327@oracle.com> Hi Phil, Thank you for your review. I have updated the summary of the bug to be more specific: ?Java does not render Myanmar script correctly?. This fix addresses only the rendering of Myanmar characters. Adding Myanmar script and related languages to the list of supported locales is premature at this point. No input method is required. One just types characters one by one; the correct positioning of the glyphs is highly dependent software support and the fonts. With this fix, it should work reasonably well. Regards, Alexey On 04/10/2019 21:13, Phil Race wrote: > The code changes look fine, but? nothing you are doing here makes > Myanmar "supported". > It may work reasonably well, but it does not get added to the list of > supported locales - for Oracle JDK anyway. > Also I don't know what input method support might be required for this > besides what > you are doing here on the display side. > > > -phil. > > > On 10/3/19 10:28 AM, Alexey Ivanov wrote: >> Hi Phil, >> >> Thank you for your review. >> Please see my answers inline: >> >> On 03/10/2019 17:31, Philip Race wrote: >>> 1) This is an RFE, not a bug. >> >> I have updated the CR type to RFE. >> >>> 2) Does this font exist on Windows 7 ? >> >> No, it does not. This font was added in Windows 8. >> https://docs.microsoft.com/en-us/typography/font-list/myanmar-text >> >> The tests check if the required font is available; if not, an message >> is printed and the test exists. >> >>> 3) This cannot be backported since the older JDK releases will not >>> support it. >> >> No, it cannot be backported to 8u because ICU does not support Myanmar. >> It can be brought to 11 updates. >> >> >> Regards, >> Alexey >>> >>> >>> -phil. >>> >>> >>> On 10/3/19, 8:57 AM, Alexey Ivanov wrote: >>>> Any volunteers to review? >>>> >>>> On 25/09/2019 20:38, Alexey Ivanov wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for JDK 14: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >>>>> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >>>>> >>>>> Problem description: >>>>> Java renders Myanmar script incorrectly. Some glyphs are not >>>>> combined, which makes text unreadable. >>>>> For example, this glyph ?? is made of two characters U+1000 and >>>>> U+103C. Java renders two separate glyphs. >>>>> >>>>> Workaround: >>>>> Enable ligatures or kerning on the font to get the correct rendering. >>>>> >>>>> The fix: >>>>> Enables complex layout for base Myanmar characters (U+1000-U+109F). >>>>> Provides fallback font on Windows. >>>>> On Linux, fontconfig handles the fallback. >>>>> >>>>> I ran awt/font tests, no new failures found. >>>>> >> > From christoph.langer at sap.com Mon Oct 7 13:53:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Oct 2019 13:53:02 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: References: Message-ID: Hi Ichiroh, this is great, thanks for doing this. We regularly see this and just stumbled over it the other day where the fontconfig of our test user was corrupted somehow. As for the test, I would reduce the amount of reflection a little bit. It should not be necessary to access SunFontManager via Class.forName, you already exported it to the test via the @modules statement. You can probably use this coding (please try as I didn't test it??): SunFontManager sfm = SunFontManager.getInstance(); Field defaultFontName_fid = SunFontManager.class.getDeclaredField("defaultFontName"); defaultFontName_fid.setAccessible(true); defaultFontName_fid.set(sfm, "Dialog"); Method loadFonts_mid = SunFontManager.class.getDeclaredMethod("loadFonts"); loadFonts_mid.setAccessible(true); loadFonts_mid.invoke(sfm); PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); System.out.println(physicalFont); If you want, I can run your (updated) patch through our test system. Thanks Christoph > -----Original Message----- > From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh > Takiguchi > Sent: Montag, 7. Oktober 2019 09:33 > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when > fontconfig.properties was used > > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ > > JTreg testcase and results are including JDK-8221741 [1]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8221741 > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From philip.race at oracle.com Mon Oct 7 15:51:41 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 7 Oct 2019 08:51:41 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java does not render Myanmar script correctly In-Reply-To: <23ff6890-e126-990c-68d5-df11597a9327@oracle.com> References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> <5D96226C.7050503@oracle.com> <23ff6890-e126-990c-68d5-df11597a9327@oracle.com> Message-ID: <66a60d1c-da9f-75a7-c539-4536effba302@oracle.com> sounds good. -phil. On 10/7/19 5:07 AM, Alexey Ivanov wrote: > Hi Phil, > > Thank you for your review. > I have updated the summary of the bug to be more specific: ?Java does > not render Myanmar script correctly?. > > This fix addresses only the rendering of Myanmar characters. Adding > Myanmar script and related languages to the list of supported locales > is premature at this point. > > No input method is required. One just types characters one by one; the > correct positioning of the glyphs is highly dependent software support > and the fonts. With this fix, it should work reasonably well. > > Regards, > Alexey > > On 04/10/2019 21:13, Phil Race wrote: >> The code changes look fine, but? nothing you are doing here makes >> Myanmar "supported". >> It may work reasonably well, but it does not get added to the list of >> supported locales - for Oracle JDK anyway. >> Also I don't know what input method support might be required for >> this besides what >> you are doing here on the display side. >> >> >> -phil. >> >> >> On 10/3/19 10:28 AM, Alexey Ivanov wrote: >>> Hi Phil, >>> >>> Thank you for your review. >>> Please see my answers inline: >>> >>> On 03/10/2019 17:31, Philip Race wrote: >>>> 1) This is an RFE, not a bug. >>> >>> I have updated the CR type to RFE. >>> >>>> 2) Does this font exist on Windows 7 ? >>> >>> No, it does not. This font was added in Windows 8. >>> https://docs.microsoft.com/en-us/typography/font-list/myanmar-text >>> >>> The tests check if the required font is available; if not, an >>> message is printed and the test exists. >>> >>>> 3) This cannot be backported since the older JDK releases will not >>>> support it. >>> >>> No, it cannot be backported to 8u because ICU does not support Myanmar. >>> It can be brought to 11 updates. >>> >>> >>> Regards, >>> Alexey >>>> >>>> >>>> -phil. >>>> >>>> >>>> On 10/3/19, 8:57 AM, Alexey Ivanov wrote: >>>>> Any volunteers to review? >>>>> >>>>> On 25/09/2019 20:38, Alexey Ivanov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix for JDK 14: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >>>>>> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >>>>>> >>>>>> Problem description: >>>>>> Java renders Myanmar script incorrectly. Some glyphs are not >>>>>> combined, which makes text unreadable. >>>>>> For example, this glyph ?? is made of two characters U+1000 and >>>>>> U+103C. Java renders two separate glyphs. >>>>>> >>>>>> Workaround: >>>>>> Enable ligatures or kerning on the font to get the correct >>>>>> rendering. >>>>>> >>>>>> The fix: >>>>>> Enables complex layout for base Myanmar characters (U+1000-U+109F). >>>>>> Provides fallback font on Windows. >>>>>> On Linux, fontconfig handles the fallback. >>>>>> >>>>>> I ran awt/font tests, no new failures found. >>>>>> >>> >> > From takiguc at linux.vnet.ibm.com Mon Oct 7 17:15:36 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 08 Oct 2019 02:15:36 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: References: Message-ID: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> Hello Christoph. I appreciate your suggestion. JTreg testcase could throw ClassCastException instead of InvocationTargetException. JTreg results were in JDK-8221741 Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ Could you review the fix ? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-10-07 22:53, Langer, Christoph wrote: > Hi Ichiroh, > > this is great, thanks for doing this. We regularly see this and just > stumbled over it the other day where the fontconfig of our test user > was corrupted somehow. > > As for the test, I would reduce the amount of reflection a little bit. > It should not be necessary to access SunFontManager via Class.forName, > you already exported it to the test via the @modules statement. You > can probably use this coding (please try as I didn't test it??): > > SunFontManager sfm = SunFontManager.getInstance(); > Field defaultFontName_fid = > SunFontManager.class.getDeclaredField("defaultFontName"); > defaultFontName_fid.setAccessible(true); > defaultFontName_fid.set(sfm, "Dialog"); > Method loadFonts_mid = > SunFontManager.class.getDeclaredMethod("loadFonts"); > loadFonts_mid.setAccessible(true); > loadFonts_mid.invoke(sfm); > PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); > System.out.println(physicalFont); > > If you want, I can run your (updated) patch through our test system. > > Thanks > Christoph > > >> -----Original Message----- >> From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh >> Takiguchi >> Sent: Montag, 7. Oktober 2019 09:33 >> To: 2d-dev at openjdk.java.net >> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when >> fontconfig.properties was used >> >> Hello. >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ >> >> JTreg testcase and results are including JDK-8221741 [1]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. From christoph.langer at sap.com Tue Oct 8 07:32:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Oct 2019 07:32:28 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work with UTF-8 locale on minimum software requirements In-Reply-To: References: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, I ran this patch through our test queue and it works fine. I also checked the output of a simple test program that does GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames() which loads the font configuration with -Dsun.java2d.debugfonts=true. I can see that lots of errors/logs like: Oct 04, 2019 9:59:39 AM sun.awt.X11FontManager getFileNameFromPlatformName WARNING: ** Registering all font paths because can't find file for -monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0 are gone now. So it must be good ?? Best regards Christoph > -----Original Message----- > From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh > Takiguchi > Sent: Dienstag, 24. September 2019 09:54 > To: 2d-dev at openjdk.java.net; ppc-aix-port-dev dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work > with UTF-8 locale on minimum software requirements > > Hello. > > I'm sorry, I made a typo in the Subject. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 > Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-09-24 02:16, Ichiroh Takiguchi wrote: > > Hello. > > > > Could you review the fix ? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 > > Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ > > > > GUI application does not work with AIX's JA_JP UTF-8 locale on minimum > > software requirements and settings because of following exception: > > Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: > > class sun.font.CompositeFont cannot be cast to class > > sun.font.PhysicalFont > > (sun.font.CompositeFont and sun.font.PhysicalFont are in module > > java.desktop of loader 'bootstrap') > > > > About the reasons for this exception: > > 1. Default physical font is not defined (like Lucida sans) > > 2. XLFD charset name entries for JA_JP locale have Underscore character > > (Underscore character replaces with Space character on > > fontconfig.proeprties > > (fontconfig.bfs) file loading phase.) > > > > About "1", I'd like to handle it by JDK-8221741 [1]. > > About "2", OpenJDK for AIX is using fontconfig.properties > > (fontconfig.bfc) file > > to find out TrueType fonts. > > On AIX JCK UTF-8 locales, Java cannot find out TrueType font because > > above XLFD charset name issue. > > > > This fix only changes fontconfig.properties for AIX platform > > * make/data/fontconfig/aix.fontconfig.properties > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 > > > > Thanks, > > Ichiroh Takiguchi > > IBM Japan, Ltd. From christoph.langer at sap.com Tue Oct 8 07:35:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Oct 2019 07:35:07 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> References: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, thanks for the update. It looks good to me. I'll run it through test system tonight and let you know if we see issues by tomorrow. Should you not hear back from me, consider it as reviewed and tested ?? Thanks Christoph > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Montag, 7. Oktober 2019 19:16 > To: Langer, Christoph > Cc: 2d-dev at openjdk.java.net; Zeller, Arno > Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen > when fontconfig.properties was used > > Hello Christoph. > > I appreciate your suggestion. > JTreg testcase could throw ClassCastException instead of > InvocationTargetException. > JTreg results were in JDK-8221741 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ > > Could you review the fix ? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-10-07 22:53, Langer, Christoph wrote: > > Hi Ichiroh, > > > > this is great, thanks for doing this. We regularly see this and just > > stumbled over it the other day where the fontconfig of our test user > > was corrupted somehow. > > > > As for the test, I would reduce the amount of reflection a little bit. > > It should not be necessary to access SunFontManager via Class.forName, > > you already exported it to the test via the @modules statement. You > > can probably use this coding (please try as I didn't test it??): > > > > SunFontManager sfm = SunFontManager.getInstance(); > > Field defaultFontName_fid = > > SunFontManager.class.getDeclaredField("defaultFontName"); > > defaultFontName_fid.setAccessible(true); > > defaultFontName_fid.set(sfm, "Dialog"); > > Method loadFonts_mid = > > SunFontManager.class.getDeclaredMethod("loadFonts"); > > loadFonts_mid.setAccessible(true); > > loadFonts_mid.invoke(sfm); > > PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); > > System.out.println(physicalFont); > > > > If you want, I can run your (updated) patch through our test system. > > > > Thanks > > Christoph > > > > > >> -----Original Message----- > >> From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh > >> Takiguchi > >> Sent: Montag, 7. Oktober 2019 09:33 > >> To: 2d-dev at openjdk.java.net > >> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen > when > >> fontconfig.properties was used > >> > >> Hello. > >> > >> Could you review the fix ? > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > >> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ > >> > >> JTreg testcase and results are including JDK-8221741 [1]. > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. From philip.race at oracle.com Tue Oct 8 16:06:16 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 08 Oct 2019 09:06:16 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: References: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> Message-ID: <5D9CB3F8.9070205@oracle.com> I think this needs a little bit more explanation first. Systems without fontconfig ... meaning without libfontconfig. So does that mean you just can't find fonts or have none installed ? If you have fonts installed and have a custom fontconfig.properties file for AIX which references those, then you should be able to get a default font from that set of known existent physical fonts. If you have neither .. then you have a system configuration problem and without a physical font installed avoiding an exception here isn't really going to help you get much further. Perhaps we should throw InternalError a bit earlier. I see no point in trying to survive .. -phil On 10/8/19, 12:35 AM, Langer, Christoph wrote: > Hi Ichiroh, > > thanks for the update. It looks good to me. I'll run it through test system tonight and let you know if we see issues by tomorrow. Should you not hear back from me, consider it as reviewed and tested ?? > > Thanks > Christoph > >> -----Original Message----- >> From: Ichiroh Takiguchi >> Sent: Montag, 7. Oktober 2019 19:16 >> To: Langer, Christoph >> Cc: 2d-dev at openjdk.java.net; Zeller, Arno >> Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >> when fontconfig.properties was used >> >> Hello Christoph. >> >> I appreciate your suggestion. >> JTreg testcase could throw ClassCastException instead of >> InvocationTargetException. >> JTreg results were in JDK-8221741 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ >> >> Could you review the fix ? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-10-07 22:53, Langer, Christoph wrote: >>> Hi Ichiroh, >>> >>> this is great, thanks for doing this. We regularly see this and just >>> stumbled over it the other day where the fontconfig of our test user >>> was corrupted somehow. >>> >>> As for the test, I would reduce the amount of reflection a little bit. >>> It should not be necessary to access SunFontManager via Class.forName, >>> you already exported it to the test via the @modules statement. You >>> can probably use this coding (please try as I didn't test it??): >>> >>> SunFontManager sfm = SunFontManager.getInstance(); >>> Field defaultFontName_fid = >>> SunFontManager.class.getDeclaredField("defaultFontName"); >>> defaultFontName_fid.setAccessible(true); >>> defaultFontName_fid.set(sfm, "Dialog"); >>> Method loadFonts_mid = >>> SunFontManager.class.getDeclaredMethod("loadFonts"); >>> loadFonts_mid.setAccessible(true); >>> loadFonts_mid.invoke(sfm); >>> PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); >>> System.out.println(physicalFont); >>> >>> If you want, I can run your (updated) patch through our test system. >>> >>> Thanks >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: 2d-dev<2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh >>>> Takiguchi >>>> Sent: Montag, 7. Oktober 2019 09:33 >>>> To: 2d-dev at openjdk.java.net >>>> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >> when >>>> fontconfig.properties was used >>>> >>>> Hello. >>>> >>>> Could you review the fix ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ >>>> >>>> JTreg testcase and results are including JDK-8221741 [1]. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. From jayathirth.d.v at oracle.com Wed Oct 9 06:07:36 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 9 Oct 2019 11:37:36 +0530 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8229810 NullPointerException getting bounds of GraphicsConfiguration In-Reply-To: <7bfc2af5-1c35-4426-0e67-c439cb5e98f2@oracle.com> References: <0bf1cf82-e134-ec41-0b73-64e22cbb824c@oracle.com> <5BE96CFD-3291-491B-82A0-404A7C75EA08@oracle.com> <7bfc2af5-1c35-4426-0e67-c439cb5e98f2@oracle.com> Message-ID: Thanks for the clarification. Changes are fine. Thanks, Jay > On 04-Oct-2019, at 3:19 AM, Sergey Bylokhov wrote: > > Hi, Jay. >> I think we should drive device update through GraphicsEnvironment.displayChanged() and DisplayChangeListener instead of force updating bounds in GraphicsDevice.displayChanged in the constructor. >> We can synchronise the GraphicsEnvironment.displayChanged() by calling it under CGraphicsEnvironment.initDevices() sync lock, this will force call DisplayChangeListener when devices are updated. > > Unfortunately, we cannot move the "displayChanged()" method under the lock, > because this method will notify all DisplayChangedListener which might use some > other locks, so we will have GraphicsEnvironment.sync->SomeOther locks order, > and at the same time, some other thread may acquired SomeOther lock and tried to > call CGraphicsEnvironment.getScreenDevices(), so we will get > SomeOther->CGraphicsEnvironment.sync and this will cause a deadlock. > > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Oct 9 08:06:58 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 Oct 2019 13:36:58 +0530 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> Message-ID: Hi Sergey, On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>> 2) I guess we don't need to free "attrs" or "attrs1" since it is >>> stack allocated .. >>> Unfortunate that we have to repeat the entire initialisation minus >>> glMask. >>> Can you think of a better way to do this ? >>> >> As per >> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >> >> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { /* >> initWithAttributes failed. Try to alloc/init with a different list of >> attributes. */ } it is appropriate to try with another list, which is >> what I tried here. Regards Prasanta | > > NSOpenGLPFAScreenMask attribute and its usage it is quite interesting. > It is used only once > mostly at startup to initialize the "sharedPixelFormat" and > "sharedContext". Later we create > context per GraphicsConfig on top of these "sharedPixelFormat" and > "sharedContext". > > In the single monitor configuration this logic is clear, we request > "sharedPixelFormat" > which supports "NSOpenGLPFAScreenMask" for the main display and it > just work. > > But how it should work when the new screen will be attached > dynamically, and/or old > screen for which we requested NSOpenGLPFAScreenMask will be detached. > > For example in the test case for this bug: > ?- If the screen via dock is attached before start of the app, we get > an exception because > ?? we cannot initialize the "sharedContext". > ?- If the screen via dock is attached after start of the app, it > works, right? > Yes, since we do not have the required docked hardware, had to ask customer to test this and they confirm app does work if screen via dock is attached after they start the app. > > It looks like we "ignore" this attribute most of the time in the > multi-monitor config, > probably we can drop if completely? > Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. Normal working on primary display is not affected and I have given a fix to the customer to test in their environment and they confirmed it is working for them with external monitor. http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ Regards Prasanta > >> >> >> >>> -phil. >>> >>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>> >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that if a >>>> MacBookPro is attached to an external monitor via dock and macbook >>>> lid is closed, >>>> no Java swing applications will start. >>>> >>>> It was found >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() >>>> is returning null in this particular setup. >>>> >>>> Since it was difficult to reproduce locally, enabling tracing >>>> reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing in >>>> NSOpenGLPixelFormat.initWithAttributes() >>>> >>>> Appkit documentation >>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>> says that it will return "|nil| if an object with the desired >>>> attributes could not be initialized". >>>> Now, when the main display is closed, the >>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>> is returning 2 as glMask which when passed as an attribute to >>>> NSOpenGLPixelFormat, it fails to initialize. >>>> Normally, with main Display being used, glMask is 1. >>>> >>>> Proposed fix is to see if first initialization fails, then retry >>>> initialization without the offending glMask value for >>>> NSOpenGLPFAScreenMask attributes, >>>> as documentation >>>> https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>> says "All screens specified in the bit mask are guaranteed to be >>>> supported by the pixel format.", so if it is not guranteed to be >>>> supported, initAttributes() might fail. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>> >>>> Regards >>>> Prasanta > > From philip.race at oracle.com Wed Oct 9 16:01:04 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 9 Oct 2019 09:01:04 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> Message-ID: <670aa65b-b142-b493-773c-72aad4478324@oracle.com> So this means your speculation below that it was needed for the main display turns out to be untrue and we can definitely just drop it ? =============== On 9/25/19 11:13 PM, Prasanta Sadhukhan wrote: > > Hi Phil, > > On 25-Sep-19 9:58 PM, Philip Race wrote: ... >> What is the implication of not having glMask ? If we don't need it, >> why specify it at all ? >> > I guess we need it for displaying on main display. =============== In that case, OK. this simplifies things, but I still don't understand why when what we are doing looks to be correct that the call fails. -phil. On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: > Hi Sergey, > > On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>> 2) I guess we don't need to free "attrs" or "attrs1" since it is >>>> stack allocated .. >>>> Unfortunate that we have to repeat the entire initialisation minus >>>> glMask. >>>> Can you think of a better way to do this ? >>>> >>> As per >>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>> >>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { /* >>> initWithAttributes failed. Try to alloc/init with a different list >>> of attributes. */ } it is appropriate to try with another list, >>> which is what I tried here. Regards Prasanta | >> >> NSOpenGLPFAScreenMask attribute and its usage it is quite >> interesting. It is used only once >> mostly at startup to initialize the "sharedPixelFormat" and >> "sharedContext". Later we create >> context per GraphicsConfig on top of these "sharedPixelFormat" and >> "sharedContext". >> >> In the single monitor configuration this logic is clear, we request >> "sharedPixelFormat" >> which supports "NSOpenGLPFAScreenMask" for the main display and it >> just work. >> >> But how it should work when the new screen will be attached >> dynamically, and/or old >> screen for which we requested NSOpenGLPFAScreenMask will be detached. >> >> For example in the test case for this bug: >> ?- If the screen via dock is attached before start of the app, we get >> an exception because >> ?? we cannot initialize the "sharedContext". >> ?- If the screen via dock is attached after start of the app, it >> works, right? >> > Yes, since we do not have the required docked hardware, had to ask > customer to test this and they confirm app does work if screen via > dock is attached after they start the app. >> >> It looks like we "ignore" this attribute most of the time in the >> multi-monitor config, >> probably we can drop if completely? >> > Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. Normal > working on primary display is not affected and I have given a fix to > the customer to test in their environment and they confirmed it is > working for them with external monitor. > > http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ > > Regards > Prasanta >> >>> >>> >>> >>>> -phil. >>>> >>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that if a >>>>> MacBookPro is attached to an external monitor via dock and macbook >>>>> lid is closed, >>>>> no Java swing applications will start. >>>>> >>>>> It was found >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() >>>>> is returning null in this particular setup. >>>>> >>>>> Since it was difficult to reproduce locally, enabling tracing >>>>> reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing in >>>>> NSOpenGLPixelFormat.initWithAttributes() >>>>> >>>>> Appkit documentation >>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>> says that it will return "|nil| if an object with the desired >>>>> attributes could not be initialized". >>>>> Now, when the main display is closed, the >>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>> is returning 2 as glMask which when passed as an attribute to >>>>> NSOpenGLPixelFormat, it fails to initialize. >>>>> Normally, with main Display being used, glMask is 1. >>>>> >>>>> Proposed fix is to see if first initialization fails, then retry >>>>> initialization without the offending glMask value for >>>>> NSOpenGLPFAScreenMask attributes, >>>>> as documentation >>>>> https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>> says "All screens specified in the bit mask are guaranteed to be >>>>> supported by the pixel format.", so if it is not guranteed to be >>>>> supported, initAttributes() might fail. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>> >>>>> Regards >>>>> Prasanta >> >> From takiguc at linux.vnet.ibm.com Thu Oct 10 05:59:56 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 10 Oct 2019 14:59:56 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work with UTF-8 locale on minimum software requirements In-Reply-To: References: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com> Message-ID: <2b4547c2be6135cd014834b7c9810309@linux.vnet.ibm.com> Thanks Christoph. I attached console log files for -Dsun.java2d.debugfonts=true option into JDK-8230873 [1] [1] https://bugs.openjdk.java.net/browse/JDK-8230873 Thanks, Ichiroh Takiguchi On 2019-10-08 16:32, Langer, Christoph wrote: > Hi Ichiroh, > > I ran this patch through our test queue and it works fine. > > I also checked the output of a simple test program that does > GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames() > which loads the font configuration with -Dsun.java2d.debugfonts=true. > I can see that lots of errors/logs like: > > Oct 04, 2019 9:59:39 AM sun.awt.X11FontManager > getFileNameFromPlatformName > WARNING: ** Registering all font paths because can't find file for > -monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0 > > are gone now. So it must be good ?? > > Best regards > Christoph > >> -----Original Message----- >> From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh >> Takiguchi >> Sent: Dienstag, 24. September 2019 09:54 >> To: 2d-dev at openjdk.java.net; ppc-aix-port-dev > dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work >> with UTF-8 locale on minimum software requirements >> >> Hello. >> >> I'm sorry, I made a typo in the Subject. >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 >> Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-09-24 02:16, Ichiroh Takiguchi wrote: >> > Hello. >> > >> > Could you review the fix ? >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 >> > Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ >> > >> > GUI application does not work with AIX's JA_JP UTF-8 locale on minimum >> > software requirements and settings because of following exception: >> > Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: >> > class sun.font.CompositeFont cannot be cast to class >> > sun.font.PhysicalFont >> > (sun.font.CompositeFont and sun.font.PhysicalFont are in module >> > java.desktop of loader 'bootstrap') >> > >> > About the reasons for this exception: >> > 1. Default physical font is not defined (like Lucida sans) >> > 2. XLFD charset name entries for JA_JP locale have Underscore character >> > (Underscore character replaces with Space character on >> > fontconfig.proeprties >> > (fontconfig.bfs) file loading phase.) >> > >> > About "1", I'd like to handle it by JDK-8221741 [1]. >> > About "2", OpenJDK for AIX is using fontconfig.properties >> > (fontconfig.bfc) file >> > to find out TrueType fonts. >> > On AIX JCK UTF-8 locales, Java cannot find out TrueType font because >> > above XLFD charset name issue. >> > >> > This fix only changes fontconfig.properties for AIX platform >> > * make/data/fontconfig/aix.fontconfig.properties >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 >> > >> > Thanks, >> > Ichiroh Takiguchi >> > IBM Japan, Ltd. From prasanta.sadhukhan at oracle.com Thu Oct 10 06:05:33 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 10 Oct 2019 11:35:33 +0530 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: <670aa65b-b142-b493-773c-72aad4478324@oracle.com> References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> Message-ID: <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> On 09-Oct-19 9:31 PM, Phil Race wrote: > So this means your speculation below that it was needed for the main > display > turns out to be untrue and we can definitely just drop it ? > > =============== > On 9/25/19 11:13 PM, Prasanta Sadhukhan wrote: >> >> Hi Phil, >> >> On 25-Sep-19 9:58 PM, Philip Race wrote: > ... >>> What is the implication of not having glMask ? If we don't need it, >>> why specify it at all ? >>> >> I guess we need it for displaying on main display. > =============== > > In that case, OK. this simplifies things, but I still don't understand > why > when what we are doing looks to be correct that the call fails. > I do not have any definite answer to this but it seems getting display mask from DisplayLink driver for a docked display might be wrong so |NSOpenGLPixelFormat#init fails as that mask is probably not supported.| |Regards| |Prasanta | > -phil. > > On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it is >>>>> stack allocated .. >>>>> Unfortunate that we have to repeat the entire initialisation minus >>>>> glMask. >>>>> Can you think of a better way to do this ? >>>>> >>>> As per >>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>> >>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { >>>> /* initWithAttributes failed. Try to alloc/init with a different >>>> list of attributes. */ } it is appropriate to try with another >>>> list, which is what I tried here. Regards Prasanta | >>> >>> NSOpenGLPFAScreenMask attribute and its usage it is quite >>> interesting. It is used only once >>> mostly at startup to initialize the "sharedPixelFormat" and >>> "sharedContext". Later we create >>> context per GraphicsConfig on top of these "sharedPixelFormat" and >>> "sharedContext". >>> >>> In the single monitor configuration this logic is clear, we request >>> "sharedPixelFormat" >>> which supports "NSOpenGLPFAScreenMask" for the main display and it >>> just work. >>> >>> But how it should work when the new screen will be attached >>> dynamically, and/or old >>> screen for which we requested NSOpenGLPFAScreenMask will be detached. >>> >>> For example in the test case for this bug: >>> ?- If the screen via dock is attached before start of the app, we >>> get an exception because >>> ?? we cannot initialize the "sharedContext". >>> ?- If the screen via dock is attached after start of the app, it >>> works, right? >>> >> Yes, since we do not have the required docked hardware, had to ask >> customer to test this and they confirm app does work if screen via >> dock is attached after they start the app. >>> >>> It looks like we "ignore" this attribute most of the time in the >>> multi-monitor config, >>> probably we can drop if completely? >>> >> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. Normal >> working on primary display is not affected and I have given a fix to >> the customer to test in their environment and they confirmed it is >> working for them with external monitor. >> >> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >> >> Regards >> Prasanta >>> >>>> >>>> >>>> >>>>> -phil. >>>>> >>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that if a >>>>>> MacBookPro is attached to an external monitor via dock and >>>>>> macbook lid is closed, >>>>>> no Java swing applications will start. >>>>>> >>>>>> It was found >>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() >>>>>> is returning null in this particular setup. >>>>>> >>>>>> Since it was difficult to reproduce locally, enabling tracing >>>>>> reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing in >>>>>> NSOpenGLPixelFormat.initWithAttributes() >>>>>> >>>>>> Appkit documentation >>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>> says that it will return "|nil| if an object with the desired >>>>>> attributes could not be initialized". >>>>>> Now, when the main display is closed, the >>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>> is returning 2 as glMask which when passed as an attribute to >>>>>> NSOpenGLPixelFormat, it fails to initialize. >>>>>> Normally, with main Display being used, glMask is 1. >>>>>> >>>>>> Proposed fix is to see if first initialization fails, then retry >>>>>> initialization without the offending glMask value for >>>>>> NSOpenGLPFAScreenMask attributes, >>>>>> as documentation >>>>>> https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>> says "All screens specified in the bit mask are guaranteed to be >>>>>> supported by the pixel format.", so if it is not guranteed to be >>>>>> supported, initAttributes() might fail. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Oct 10 19:14:57 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 Oct 2019 12:14:57 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> Message-ID: On 10/9/19 11:05 pm, Prasanta Sadhukhan wrote: >> In that case, OK. this simplifies things, but I still don't understand why >> when what we are doing looks to be correct that the call fails. >> > I do not have any definite answer to this but it seems getting display mask from DisplayLink driver for a docked display might be wrong so |NSOpenGLPixelFormat#init fails as that mask is probably not supported.| I just got the similar bug: https://bugs.openjdk.java.net/browse/JDK-8232086 I cannot reproduce that, but I guess the reason is the same, so I looked to the list of requirements and I think that some of them are unused as well. NSOpenGLPFAWindow - is not needed because we never render to the window directly. NSOpenGLPFAPixelBuffer - is not needed because we never render to the pixel buffer. NSOpenGLPFADoubleBuffer - we use our own texture as a backbuffer I guess at a minimum we can align this list to the list used by the JavaFX. > > |Regards| > |Prasanta > | >> -phil. >> >> On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >>> Hi Sergey, >>> >>> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it is stack allocated .. >>>>>> Unfortunate that we have to repeat the entire initialisation minus glMask. >>>>>> Can you think of a better way to do this ? >>>>>> >>>>> As per https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>> >>>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { /* initWithAttributes failed. Try to alloc/init with a different list of attributes. */ } it is appropriate to try with another list, which is what I tried here. Regards Prasanta | >>>> >>>> NSOpenGLPFAScreenMask attribute and its usage it is quite interesting. It is used only once >>>> mostly at startup to initialize the "sharedPixelFormat" and "sharedContext". Later we create >>>> context per GraphicsConfig on top of these "sharedPixelFormat" and "sharedContext". >>>> >>>> In the single monitor configuration this logic is clear, we request "sharedPixelFormat" >>>> which supports "NSOpenGLPFAScreenMask" for the main display and it just work. >>>> >>>> But how it should work when the new screen will be attached dynamically, and/or old >>>> screen for which we requested NSOpenGLPFAScreenMask will be detached. >>>> >>>> For example in the test case for this bug: >>>> ?- If the screen via dock is attached before start of the app, we get an exception because >>>> ?? we cannot initialize the "sharedContext". >>>> ?- If the screen via dock is attached after start of the app, it works, right? >>>> >>> Yes, since we do not have the required docked hardware, had to ask customer to test this and they confirm app does work if screen via dock is attached after they start the app. >>>> >>>> It looks like we "ignore" this attribute most of the time in the multi-monitor config, >>>> probably we can drop if completely? >>>> >>> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. Normal working on primary display is not affected and I have given a fix to the customer to test in their environment and they confirmed it is working for them with external monitor. >>> >>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >>> >>> Regards >>> Prasanta >>>> >>>>> >>>>> >>>>> >>>>>> -phil. >>>>>> >>>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for an issue where it is seen that if a MacBookPro is attached to an external monitor via dock and macbook lid is closed, >>>>>>> no Java swing applications will start. >>>>>>> >>>>>>> It was found GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() is returning null in this particular setup. >>>>>>> >>>>>>> Since it was difficult to reproduce locally, enabling tracing reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing in NSOpenGLPixelFormat.initWithAttributes() >>>>>>> >>>>>>> Appkit documentation https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>> says that it will return "|nil| if an object with the desired attributes could not be initialized". >>>>>>> Now, when the main display is closed, the >>>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>>> is returning 2 as glMask which when passed as an attribute to NSOpenGLPixelFormat, it fails to initialize. >>>>>>> Normally, with main Display being used, glMask is 1. >>>>>>> >>>>>>> Proposed fix is to see if first initialization fails, then retry initialization without the offending glMask value for NSOpenGLPFAScreenMask attributes, >>>>>>> as documentation https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>>> says "All screens specified in the bit mask are guaranteed to be supported by the pixel format.", so if it is not guranteed to be supported, initAttributes() might fail. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>> >>>> >> -- Best regards, Sergey. From philip.race at oracle.com Thu Oct 10 20:35:41 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 10 Oct 2019 13:35:41 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> Message-ID: <4509b270-e5c1-a7c2-04bb-fb5eac641f03@oracle.com> > I guess at a minimum we can align this list to the list used by the JavaFX. If by the minimum you mean make the list as short as possible that is probably OK but if you want the lowest risk fix you want the minimum change :-) I'd prefer to do the latter right now. -phil. On 10/10/19 12:14 PM, Sergey Bylokhov wrote: > On 10/9/19 11:05 pm, Prasanta Sadhukhan wrote: >>> In that case, OK. this simplifies things, but I still don't >>> understand why >>> when what we are doing looks to be correct that the call fails. >>> >> I do not have any definite answer to this but it seems getting >> display mask from DisplayLink driver for a docked display might be >> wrong so |NSOpenGLPixelFormat#init fails as that mask is probably not >> supported.| > > I just got the similar bug: > https://bugs.openjdk.java.net/browse/JDK-8232086 > > I cannot reproduce that, but I guess the reason is the same, so I > looked to the list > of requirements and I think that some of them are unused as well. > NSOpenGLPFAWindow - is not needed because we never render to the > window directly. > NSOpenGLPFAPixelBuffer - is not needed because we never render to the > pixel buffer. > NSOpenGLPFADoubleBuffer - we use our own texture as a backbuffer > > I guess at a minimum we can align this list to the list used by the > JavaFX. > > >> >> |Regards| >> |Prasanta >> | >>> -phil. >>> >>> On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >>>> Hi Sergey, >>>> >>>> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it is >>>>>>> stack allocated .. >>>>>>> Unfortunate that we have to repeat the entire initialisation >>>>>>> minus glMask. >>>>>>> Can you think of a better way to do this ? >>>>>>> >>>>>> As per >>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>> >>>>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { >>>>>> /* initWithAttributes failed. Try to alloc/init with a different >>>>>> list of attributes. */ } it is appropriate to try with another >>>>>> list, which is what I tried here. Regards Prasanta | >>>>> >>>>> NSOpenGLPFAScreenMask attribute and its usage it is quite >>>>> interesting. It is used only once >>>>> mostly at startup to initialize the "sharedPixelFormat" and >>>>> "sharedContext". Later we create >>>>> context per GraphicsConfig on top of these "sharedPixelFormat" and >>>>> "sharedContext". >>>>> >>>>> In the single monitor configuration this logic is clear, we >>>>> request "sharedPixelFormat" >>>>> which supports "NSOpenGLPFAScreenMask" for the main display and it >>>>> just work. >>>>> >>>>> But how it should work when the new screen will be attached >>>>> dynamically, and/or old >>>>> screen for which we requested NSOpenGLPFAScreenMask will be detached. >>>>> >>>>> For example in the test case for this bug: >>>>> ?- If the screen via dock is attached before start of the app, we >>>>> get an exception because >>>>> ?? we cannot initialize the "sharedContext". >>>>> ?- If the screen via dock is attached after start of the app, it >>>>> works, right? >>>>> >>>> Yes, since we do not have the required docked hardware, had to ask >>>> customer to test this and they confirm app does work if screen via >>>> dock is attached after they start the app. >>>>> >>>>> It looks like we "ignore" this attribute most of the time in the >>>>> multi-monitor config, >>>>> probably we can drop if completely? >>>>> >>>> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. >>>> Normal working on primary display is not affected and I have given >>>> a fix to the customer to test in their environment and they >>>> confirmed it is working for them with external monitor. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >>>> >>>> Regards >>>> Prasanta >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for an issue where it is seen that if a >>>>>>>> MacBookPro is attached to an external monitor via dock and >>>>>>>> macbook lid is closed, >>>>>>>> no Java swing applications will start. >>>>>>>> >>>>>>>> It was found >>>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() >>>>>>>> is returning null in this particular setup. >>>>>>>> >>>>>>>> Since it was difficult to reproduce locally, enabling tracing >>>>>>>> reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing >>>>>>>> in NSOpenGLPixelFormat.initWithAttributes() >>>>>>>> >>>>>>>> Appkit documentation >>>>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>> says that it will return "|nil| if an object with the desired >>>>>>>> attributes could not be initialized". >>>>>>>> Now, when the main display is closed, the >>>>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>>>> is returning 2 as glMask which when passed as an attribute to >>>>>>>> NSOpenGLPixelFormat, it fails to initialize. >>>>>>>> Normally, with main Display being used, glMask is 1. >>>>>>>> >>>>>>>> Proposed fix is to see if first initialization fails, then >>>>>>>> retry initialization without the offending glMask value for >>>>>>>> NSOpenGLPFAScreenMask attributes, >>>>>>>> as documentation >>>>>>>> https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>>>> says "All screens specified in the bit mask are guaranteed to >>>>>>>> be supported by the pixel format.", so if it is not guranteed >>>>>>>> to be supported, initAttributes() might fail. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>> >>>>> >>> > > From Sergey.Bylokhov at oracle.com Thu Oct 10 20:58:00 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 Oct 2019 13:58:00 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: <4509b270-e5c1-a7c2-04bb-fb5eac641f03@oracle.com> References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> <4509b270-e5c1-a7c2-04bb-fb5eac641f03@oracle.com> Message-ID: On 10/10/19 1:35 pm, Phil Race wrote: > > I guess at a minimum we can align this list to the list used by the JavaFX. > > If by the minimum you mean make the list as short as possible that is probably OK > but if you want the lowest risk fix you want the minimum change :-) > > I'd prefer to do the latter right now. I am fine, I can drop them in JDK-8232086 and do not backport it to 11 for some amount of time. > > -phil. > > On 10/10/19 12:14 PM, Sergey Bylokhov wrote: >> On 10/9/19 11:05 pm, Prasanta Sadhukhan wrote: >>>> In that case, OK. this simplifies things, but I still don't understand why >>>> when what we are doing looks to be correct that the call fails. >>>> >>> I do not have any definite answer to this but it seems getting display mask from DisplayLink driver for a docked display might be wrong so |NSOpenGLPixelFormat#init fails as that mask is probably not supported.| >> >> I just got the similar bug: >> https://bugs.openjdk.java.net/browse/JDK-8232086 >> >> I cannot reproduce that, but I guess the reason is the same, so I looked to the list >> of requirements and I think that some of them are unused as well. >> NSOpenGLPFAWindow - is not needed because we never render to the window directly. >> NSOpenGLPFAPixelBuffer - is not needed because we never render to the pixel buffer. >> NSOpenGLPFADoubleBuffer - we use our own texture as a backbuffer >> >> I guess at a minimum we can align this list to the list used by the JavaFX. >> >> >>> >>> |Regards| >>> |Prasanta >>> | >>>> -phil. >>>> >>>> On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >>>>> Hi Sergey, >>>>> >>>>> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta. >>>>>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it is stack allocated .. >>>>>>>> Unfortunate that we have to repeat the entire initialisation minus glMask. >>>>>>>> Can you think of a better way to do this ? >>>>>>>> >>>>>>> As per https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>> >>>>>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { /* initWithAttributes failed. Try to alloc/init with a different list of attributes. */ } it is appropriate to try with another list, which is what I tried here. Regards Prasanta | >>>>>> >>>>>> NSOpenGLPFAScreenMask attribute and its usage it is quite interesting. It is used only once >>>>>> mostly at startup to initialize the "sharedPixelFormat" and "sharedContext". Later we create >>>>>> context per GraphicsConfig on top of these "sharedPixelFormat" and "sharedContext". >>>>>> >>>>>> In the single monitor configuration this logic is clear, we request "sharedPixelFormat" >>>>>> which supports "NSOpenGLPFAScreenMask" for the main display and it just work. >>>>>> >>>>>> But how it should work when the new screen will be attached dynamically, and/or old >>>>>> screen for which we requested NSOpenGLPFAScreenMask will be detached. >>>>>> >>>>>> For example in the test case for this bug: >>>>>> ?- If the screen via dock is attached before start of the app, we get an exception because >>>>>> ?? we cannot initialize the "sharedContext". >>>>>> ?- If the screen via dock is attached after start of the app, it works, right? >>>>>> >>>>> Yes, since we do not have the required docked hardware, had to ask customer to test this and they confirm app does work if screen via dock is attached after they start the app. >>>>>> >>>>>> It looks like we "ignore" this attribute most of the time in the multi-monitor config, >>>>>> probably we can drop if completely? >>>>>> >>>>> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. Normal working on primary display is not affected and I have given a fix to the customer to test in their environment and they confirmed it is working for them with external monitor. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >>>>> >>>>> Regards >>>>> Prasanta >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review a fix for an issue where it is seen that if a MacBookPro is attached to an external monitor via dock and macbook lid is closed, >>>>>>>>> no Java swing applications will start. >>>>>>>>> >>>>>>>>> It was found GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() is returning null in this particular setup. >>>>>>>>> >>>>>>>>> Since it was difficult to reproduce locally, enabling tracing reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing in NSOpenGLPixelFormat.initWithAttributes() >>>>>>>>> >>>>>>>>> Appkit documentation https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>>> says that it will return "|nil| if an object with the desired attributes could not be initialized". >>>>>>>>> Now, when the main display is closed, the >>>>>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>>>>> is returning 2 as glMask which when passed as an attribute to NSOpenGLPixelFormat, it fails to initialize. >>>>>>>>> Normally, with main Display being used, glMask is 1. >>>>>>>>> >>>>>>>>> Proposed fix is to see if first initialization fails, then retry initialization without the offending glMask value for NSOpenGLPFAScreenMask attributes, >>>>>>>>> as documentation https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>>>>> says "All screens specified in the bit mask are guaranteed to be supported by the pixel format.", so if it is not guranteed to be supported, initAttributes() might fail. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>> >>>>>> >>>> >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Oct 11 06:34:10 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 11 Oct 2019 12:04:10 +0530 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> <4509b270-e5c1-a7c2-04bb-fb5eac641f03@oracle.com> Message-ID: Hi Phil, Sergey Then, is http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ good to check-in? Regards Prasanta On 11-Oct-19 2:28 AM, Sergey Bylokhov wrote: > On 10/10/19 1:35 pm, Phil Race wrote: >> ?> I guess at a minimum we can align this list to the list used by >> the JavaFX. >> >> If by the minimum you mean make the list as short as possible that is >> probably OK >> but if you want the lowest risk fix you want the minimum change :-) >> >> I'd prefer to do the latter right now. > > I am fine, I can drop them in JDK-8232086 and do not backport it to 11 > for some amount of time. > >> >> -phil. >> >> On 10/10/19 12:14 PM, Sergey Bylokhov wrote: >>> On 10/9/19 11:05 pm, Prasanta Sadhukhan wrote: >>>>> In that case, OK. this simplifies things, but I still don't >>>>> understand why >>>>> when what we are doing looks to be correct that the call fails. >>>>> >>>> I do not have any definite answer to this but it seems getting >>>> display mask from DisplayLink driver for a docked display might be >>>> wrong so |NSOpenGLPixelFormat#init fails as that mask is probably >>>> not supported.| >>> >>> I just got the similar bug: >>> https://bugs.openjdk.java.net/browse/JDK-8232086 >>> >>> I cannot reproduce that, but I guess the reason is the same, so I >>> looked to the list >>> of requirements and I think that some of them are unused as well. >>> NSOpenGLPFAWindow - is not needed because we never render to the >>> window directly. >>> NSOpenGLPFAPixelBuffer - is not needed because we never render to >>> the pixel buffer. >>> NSOpenGLPFADoubleBuffer - we use our own texture as a backbuffer >>> >>> I guess at a minimum we can align this list to the list used by the >>> JavaFX. >>> >>> >>>> >>>> |Regards| >>>> |Prasanta >>>> | >>>>> -phil. >>>>> >>>>> On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>>>>>> Hi, Prasanta. >>>>>>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>>>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it >>>>>>>>> is stack allocated .. >>>>>>>>> Unfortunate that we have to repeat the entire initialisation >>>>>>>>> minus glMask. >>>>>>>>> Can you think of a better way to do this ? >>>>>>>>> >>>>>>>> As per >>>>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>> >>>>>>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) >>>>>>>> { /* initWithAttributes failed. Try to alloc/init with a >>>>>>>> different list of attributes. */ } it is appropriate to try >>>>>>>> with another list, which is what I tried here. Regards Prasanta | >>>>>>> >>>>>>> NSOpenGLPFAScreenMask attribute and its usage it is quite >>>>>>> interesting. It is used only once >>>>>>> mostly at startup to initialize the "sharedPixelFormat" and >>>>>>> "sharedContext". Later we create >>>>>>> context per GraphicsConfig on top of these "sharedPixelFormat" >>>>>>> and "sharedContext". >>>>>>> >>>>>>> In the single monitor configuration this logic is clear, we >>>>>>> request "sharedPixelFormat" >>>>>>> which supports "NSOpenGLPFAScreenMask" for the main display and >>>>>>> it just work. >>>>>>> >>>>>>> But how it should work when the new screen will be attached >>>>>>> dynamically, and/or old >>>>>>> screen for which we requested NSOpenGLPFAScreenMask will be >>>>>>> detached. >>>>>>> >>>>>>> For example in the test case for this bug: >>>>>>> ?- If the screen via dock is attached before start of the app, >>>>>>> we get an exception because >>>>>>> ?? we cannot initialize the "sharedContext". >>>>>>> ?- If the screen via dock is attached after start of the app, it >>>>>>> works, right? >>>>>>> >>>>>> Yes, since we do not have the required docked hardware, had to >>>>>> ask customer to test this and they confirm app does work if >>>>>> screen via dock is attached after they start the app. >>>>>>> >>>>>>> It looks like we "ignore" this attribute most of the time in the >>>>>>> multi-monitor config, >>>>>>> probably we can drop if completely? >>>>>>> >>>>>> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. >>>>>> Normal working on primary display is not affected and I have >>>>>> given a fix to the customer to test in their environment and they >>>>>> confirmed it is working for them with external monitor. >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for an issue where it is seen that if a >>>>>>>>>> MacBookPro is attached to an external monitor via dock and >>>>>>>>>> macbook lid is closed, >>>>>>>>>> no Java swing applications will start. >>>>>>>>>> >>>>>>>>>> It was found >>>>>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() >>>>>>>>>> is returning null in this particular setup. >>>>>>>>>> >>>>>>>>>> Since it was difficult to reproduce locally, enabling tracing >>>>>>>>>> reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing >>>>>>>>>> in NSOpenGLPixelFormat.initWithAttributes() >>>>>>>>>> >>>>>>>>>> Appkit documentation >>>>>>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>>>> says that it will return "|nil| if an object with the desired >>>>>>>>>> attributes could not be initialized". >>>>>>>>>> Now, when the main display is closed, the >>>>>>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>>>>>> is returning 2 as glMask which when passed as an attribute to >>>>>>>>>> NSOpenGLPixelFormat, it fails to initialize. >>>>>>>>>> Normally, with main Display being used, glMask is 1. >>>>>>>>>> >>>>>>>>>> Proposed fix is to see if first initialization fails, then >>>>>>>>>> retry initialization without the offending glMask value for >>>>>>>>>> NSOpenGLPFAScreenMask attributes, >>>>>>>>>> as documentation >>>>>>>>>> https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>>>>>> says "All screens specified in the bit mask are guaranteed to >>>>>>>>>> be supported by the pixel format.", so if it is not guranteed >>>>>>>>>> to be supported, initAttributes() might fail. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>> >>>>>>> >>>>> >>> >>> >> > > From philip.race at oracle.com Fri Oct 11 13:39:06 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 11 Oct 2019 06:39:06 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> <4509b270-e5c1-a7c2-04bb-fb5eac641f03@oracle.com> Message-ID: <5DA085FA.4090903@oracle.com> Ok by me. -phil On 10/10/19, 11:34 PM, Prasanta Sadhukhan wrote: > Hi Phil, Sergey > > Then, is http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ good > to check-in? > > Regards > Prasanta > On 11-Oct-19 2:28 AM, Sergey Bylokhov wrote: >> On 10/10/19 1:35 pm, Phil Race wrote: >>> > I guess at a minimum we can align this list to the list used by >>> the JavaFX. >>> >>> If by the minimum you mean make the list as short as possible that >>> is probably OK >>> but if you want the lowest risk fix you want the minimum change :-) >>> >>> I'd prefer to do the latter right now. >> >> I am fine, I can drop them in JDK-8232086 and do not backport it to >> 11 for some amount of time. >> >>> >>> -phil. >>> >>> On 10/10/19 12:14 PM, Sergey Bylokhov wrote: >>>> On 10/9/19 11:05 pm, Prasanta Sadhukhan wrote: >>>>>> In that case, OK. this simplifies things, but I still don't >>>>>> understand why >>>>>> when what we are doing looks to be correct that the call fails. >>>>>> >>>>> I do not have any definite answer to this but it seems getting >>>>> display mask from DisplayLink driver for a docked display might be >>>>> wrong so |NSOpenGLPixelFormat#init fails as that mask is probably >>>>> not supported.| >>>> >>>> I just got the similar bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8232086 >>>> >>>> I cannot reproduce that, but I guess the reason is the same, so I >>>> looked to the list >>>> of requirements and I think that some of them are unused as well. >>>> NSOpenGLPFAWindow - is not needed because we never render to the >>>> window directly. >>>> NSOpenGLPFAPixelBuffer - is not needed because we never render to >>>> the pixel buffer. >>>> NSOpenGLPFADoubleBuffer - we use our own texture as a backbuffer >>>> >>>> I guess at a minimum we can align this list to the list used by the >>>> JavaFX. >>>> >>>> >>>>> >>>>> |Regards| >>>>> |Prasanta >>>>> | >>>>>> -phil. >>>>>> >>>>>> On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>>>>>>> Hi, Prasanta. >>>>>>>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>>>>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it >>>>>>>>>> is stack allocated .. >>>>>>>>>> Unfortunate that we have to repeat the entire initialisation >>>>>>>>>> minus glMask. >>>>>>>>>> Can you think of a better way to do this ? >>>>>>>>>> >>>>>>>>> As per >>>>>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>>> >>>>>>>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == >>>>>>>>> nil) { /* initWithAttributes failed. Try to alloc/init with a >>>>>>>>> different list of attributes. */ } it is appropriate to try >>>>>>>>> with another list, which is what I tried here. Regards Prasanta | >>>>>>>> >>>>>>>> NSOpenGLPFAScreenMask attribute and its usage it is quite >>>>>>>> interesting. It is used only once >>>>>>>> mostly at startup to initialize the "sharedPixelFormat" and >>>>>>>> "sharedContext". Later we create >>>>>>>> context per GraphicsConfig on top of these "sharedPixelFormat" >>>>>>>> and "sharedContext". >>>>>>>> >>>>>>>> In the single monitor configuration this logic is clear, we >>>>>>>> request "sharedPixelFormat" >>>>>>>> which supports "NSOpenGLPFAScreenMask" for the main display and >>>>>>>> it just work. >>>>>>>> >>>>>>>> But how it should work when the new screen will be attached >>>>>>>> dynamically, and/or old >>>>>>>> screen for which we requested NSOpenGLPFAScreenMask will be >>>>>>>> detached. >>>>>>>> >>>>>>>> For example in the test case for this bug: >>>>>>>> - If the screen via dock is attached before start of the app, >>>>>>>> we get an exception because >>>>>>>> we cannot initialize the "sharedContext". >>>>>>>> - If the screen via dock is attached after start of the app, >>>>>>>> it works, right? >>>>>>>> >>>>>>> Yes, since we do not have the required docked hardware, had to >>>>>>> ask customer to test this and they confirm app does work if >>>>>>> screen via dock is attached after they start the app. >>>>>>>> >>>>>>>> It looks like we "ignore" this attribute most of the time in >>>>>>>> the multi-monitor config, >>>>>>>> probably we can drop if completely? >>>>>>>> >>>>>>> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. >>>>>>> Normal working on primary display is not affected and I have >>>>>>> given a fix to the customer to test in their environment and >>>>>>> they confirmed it is working for them with external monitor. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for an issue where it is seen that if a >>>>>>>>>>> MacBookPro is attached to an external monitor via dock and >>>>>>>>>>> macbook lid is closed, >>>>>>>>>>> no Java swing applications will start. >>>>>>>>>>> >>>>>>>>>>> It was found >>>>>>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() >>>>>>>>>>> is returning null in this particular setup. >>>>>>>>>>> >>>>>>>>>>> Since it was difficult to reproduce locally, enabling >>>>>>>>>>> tracing reveals that CGLGraphicsConfig#getCGLConfigInfo() >>>>>>>>>>> was failing in NSOpenGLPixelFormat.initWithAttributes() >>>>>>>>>>> >>>>>>>>>>> Appkit documentation >>>>>>>>>>> https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>>>>> says that it will return "|nil| if an object with the >>>>>>>>>>> desired attributes could not be initialized". >>>>>>>>>>> Now, when the main display is closed, the >>>>>>>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>>>>>>> is returning 2 as glMask which when passed as an attribute >>>>>>>>>>> to NSOpenGLPixelFormat, it fails to initialize. >>>>>>>>>>> Normally, with main Display being used, glMask is 1. >>>>>>>>>>> >>>>>>>>>>> Proposed fix is to see if first initialization fails, then >>>>>>>>>>> retry initialization without the offending glMask value for >>>>>>>>>>> NSOpenGLPFAScreenMask attributes, >>>>>>>>>>> as documentation >>>>>>>>>>> https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>>>>>>> says "All screens specified in the bit mask are guaranteed >>>>>>>>>>> to be supported by the pixel format.", so if it is not >>>>>>>>>>> guranteed to be supported, initAttributes() might fail. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >>> >> >> From philip.race at oracle.com Fri Oct 11 21:01:39 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 11 Oct 2019 14:01:39 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method Message-ID: <5DA0EDB3.2000904@oracle.com> Bug: ICC_Profile has un-needed, not-empty finalize method Webrev: http://cr.openjdk.java.net/~prr/8175984/ This is a native memory utilisation problem due to delay in collecting and freeing ICC_Profiles and their associated classes and data. The color management engine is native code and consumes the stream of data representing the ICC profile and constructs internal native data structures. The delay is because the garbage collector doesn't know about the native memory consumption and from a Java perspective there is no need to initiate garbage collection. But it is worse than that because even collection when does happen it is delayed in freeing this memory. The native data is referenced internally via a Profile object which is registered with the 2D disposer so that the data will be freed after the disposer's reference to it is enqueued and cleared. The disposer needing to run does add some delay but there's a further delay. ICC_Profile has non-empty finalize which is there to free this native data. This used to matter with the old closed source CMS *only* because no one bothered to implement 2D disposer support for it. But the call in finalize() is a no-op for LCMS So currently the ICC_Profile has to be finalized and only then can the GC initiate clearing the weak refs and freeing the native data. Emptying the finalize() [*] method helps make the reclamation more prompt. It is still possible to see large amounts of native memory consumed but it is much better than before. [*] For those who don't know, the VM treats an empty finalize() method as non-existent so the object does not need to be finalized. I had started to look at adding Disposer code to do the other thing that the finalize() method does which is remove a deferred activation registration but decided this was pointless. That is used only for the pre-defined instances held in static variables of the class and those live for the life of the VM so will never be freed ... There is more clean up that could be done in the lower classes - is freeProfile needed any more ? Do we actually want to keep the deferral mechanism ? Can we do something to provide a way to more promptly free the data, perhaps via new API ? But I decided to keep it to a minimum for safe and trivial backporting and leave the rest to another day. -phil. From Sergey.Bylokhov at oracle.com Fri Oct 11 21:31:10 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Oct 2019 14:31:10 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR: JDK-8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: <5DA085FA.4090903@oracle.com> References: <5D8B95BE.6000208@oracle.com> <1eb01745-1f45-8c51-a7a6-045f00b8dd5d@oracle.com> <670aa65b-b142-b493-773c-72aad4478324@oracle.com> <83776876-1a57-9284-f562-525b8da75f8c@oracle.com> <4509b270-e5c1-a7c2-04bb-fb5eac641f03@oracle.com> <5DA085FA.4090903@oracle.com> Message-ID: <48105cf7-2951-14b1-0a0a-c9a70da48c58@oracle.com> +1 On 10/11/19 6:39 am, Philip Race wrote: > Ok by me. > > -phil > > On 10/10/19, 11:34 PM, Prasanta Sadhukhan wrote: >> Hi Phil, Sergey >> >> Then, is http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ good to check-in? >> >> Regards >> Prasanta >> On 11-Oct-19 2:28 AM, Sergey Bylokhov wrote: >>> On 10/10/19 1:35 pm, Phil Race wrote: >>>> > I guess at a minimum we can align this list to the list used by the JavaFX. >>>> >>>> If by the minimum you mean make the list as short as possible that is probably OK >>>> but if you want the lowest risk fix you want the minimum change :-) >>>> >>>> I'd prefer to do the latter right now. >>> >>> I am fine, I can drop them in JDK-8232086 and do not backport it to 11 for some amount of time. >>> >>>> >>>> -phil. >>>> >>>> On 10/10/19 12:14 PM, Sergey Bylokhov wrote: >>>>> On 10/9/19 11:05 pm, Prasanta Sadhukhan wrote: >>>>>>> In that case, OK. this simplifies things, but I still don't understand why >>>>>>> when what we are doing looks to be correct that the call fails. >>>>>>> >>>>>> I do not have any definite answer to this but it seems getting display mask from DisplayLink driver for a docked display might be wrong so |NSOpenGLPixelFormat#init fails as that mask is probably not supported.| >>>>> >>>>> I just got the similar bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8232086 >>>>> >>>>> I cannot reproduce that, but I guess the reason is the same, so I looked to the list >>>>> of requirements and I think that some of them are unused as well. >>>>> NSOpenGLPFAWindow - is not needed because we never render to the window directly. >>>>> NSOpenGLPFAPixelBuffer - is not needed because we never render to the pixel buffer. >>>>> NSOpenGLPFADoubleBuffer - we use our own texture as a backbuffer >>>>> >>>>> I guess at a minimum we can align this list to the list used by the JavaFX. >>>>> >>>>> >>>>>> >>>>>> |Regards| >>>>>> |Prasanta >>>>>> | >>>>>>> -phil. >>>>>>> >>>>>>> On 10/9/19 1:06 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> On 27-Sep-19 2:58 AM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Prasanta. >>>>>>>>> On 9/25/19 11:13 pm, Prasanta Sadhukhan wrote: >>>>>>>>>>> 2) I guess we don't need to free "attrs" or "attrs1" since it is stack allocated .. >>>>>>>>>>> Unfortunate that we have to repeat the entire initialisation minus glMask. >>>>>>>>>>> Can you think of a better way to do this ? >>>>>>>>>>> >>>>>>>>>> As per https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>>>> >>>>>>>>>> |/* Check if initWithAttributes succeeded. */ if(pixFmt == nil) { /* initWithAttributes failed. Try to alloc/init with a different list of attributes. */ } it is appropriate to try with another list, which is what I tried here. Regards Prasanta | >>>>>>>>> >>>>>>>>> NSOpenGLPFAScreenMask attribute and its usage it is quite interesting. It is used only once >>>>>>>>> mostly at startup to initialize the "sharedPixelFormat" and "sharedContext". Later we create >>>>>>>>> context per GraphicsConfig on top of these "sharedPixelFormat" and "sharedContext". >>>>>>>>> >>>>>>>>> In the single monitor configuration this logic is clear, we request "sharedPixelFormat" >>>>>>>>> which supports "NSOpenGLPFAScreenMask" for the main display and it just work. >>>>>>>>> >>>>>>>>> But how it should work when the new screen will be attached dynamically, and/or old >>>>>>>>> screen for which we requested NSOpenGLPFAScreenMask will be detached. >>>>>>>>> >>>>>>>>> For example in the test case for this bug: >>>>>>>>> ?- If the screen via dock is attached before start of the app, we get an exception because >>>>>>>>> ?? we cannot initialize the "sharedContext". >>>>>>>>> ?- If the screen via dock is attached after start of the app, it works, right? >>>>>>>>> >>>>>>>> Yes, since we do not have the required docked hardware, had to ask customer to test this and they confirm app does work if screen via dock is attached after they start the app. >>>>>>>>> >>>>>>>>> It looks like we "ignore" this attribute most of the time in the multi-monitor config, >>>>>>>>> probably we can drop if completely? >>>>>>>>> >>>>>>>> Modified webrev ignoring this NSOpenGLPFAScreenMask attribute. Normal working on primary display is not affected and I have given a fix to the customer to test in their environment and they confirmed it is working for them with external monitor. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 9/25/19, 3:49 AM, Prasanta Sadhukhan wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Please review a fix for an issue where it is seen that if a MacBookPro is attached to an external monitor via dock and macbook lid is closed, >>>>>>>>>>>> no Java swing applications will start. >>>>>>>>>>>> >>>>>>>>>>>> It was found GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration() is returning null in this particular setup. >>>>>>>>>>>> >>>>>>>>>>>> Since it was difficult to reproduce locally, enabling tracing reveals that CGLGraphicsConfig#getCGLConfigInfo() was failing in NSOpenGLPixelFormat.initWithAttributes() >>>>>>>>>>>> >>>>>>>>>>>> Appkit documentation https://developer.apple.com/documentation/appkit/nsopenglpixelformat/1436219-initwithattributes?language=objc >>>>>>>>>>>> says that it will return "|nil| if an object with the desired attributes could not be initialized". >>>>>>>>>>>> Now, when the main display is closed, the >>>>>>>>>>>> CGDisplayIDToOpenGLDisplayMask(displayID) >>>>>>>>>>>> is returning 2 as glMask which when passed as an attribute to NSOpenGLPixelFormat, it fails to initialize. >>>>>>>>>>>> Normally, with main Display being used, glMask is 1. >>>>>>>>>>>> >>>>>>>>>>>> Proposed fix is to see if first initialization fails, then retry initialization without the offending glMask value for NSOpenGLPFAScreenMask attributes, >>>>>>>>>>>> as documentation https://developer.apple.com/documentation/appkit/1436213-opengl_pixel_format_attributes/nsopenglpfascreenmask?language=objc >>>>>>>>>>>> says "All screens specified in the bit mask are guaranteed to be supported by the pixel format.", so if it is not guranteed to be supported, initAttributes() might fail. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223158 >>>>>>>>>>>> >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.0/ >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Oct 11 21:52:56 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Oct 2019 14:52:56 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method In-Reply-To: <5DA0EDB3.2000904@oracle.com> References: <5DA0EDB3.2000904@oracle.com> Message-ID: <809efff9-7605-984f-ab88-fab2231302c3@oracle.com> Hi, Phil. It looks like after the fix we will skip the call "unregisterDeferral" and the ProfileActivator which was registered by the "ProfileDeferralMgr.registerDeferral" will not be removed --> memory leak? BTW do we have an option to mark this "finalize" as forRemoval=true or just delete it?(example JDK-8159009/JDK-8212198) On 10/11/19 2:01 pm, Philip Race wrote: > Bug: ICC_Profile has un-needed, not-empty finalize method > Webrev: http://cr.openjdk.java.net/~prr/8175984/ > > This is a native memory utilisation problem due to delay in collecting and > freeing ICC_Profiles and their associated classes and data. > > The color management engine is native code and consumes the stream of data > representing the ICC profile and constructs internal native data structures. > The delay is because the garbage collector doesn't know about the native memory > consumption and from a Java perspective there is no need to initiate garbage collection. > > But it is worse than that because even collection when does happen it is delayed in > freeing this memory. > > The native data is referenced internally via a Profile object which is registered with the 2D disposer > so that the data will be freed after the disposer's? reference to it is enqueued and cleared. > > The disposer needing to run does add some delay but there's a further delay. > > ICC_Profile has? non-empty finalize which is there to free this native data. > > This used to matter with the old closed source CMS *only* because no one bothered > to implement 2D disposer support for it. > > But the call in finalize() is a no-op for LCMS > > So currently the ICC_Profile has to be finalized and only then can the GC initiate > clearing the weak refs and freeing the native data. > > Emptying the finalize() [*] method helps make the reclamation more prompt. > It is still possible to see large amounts of native memory consumed but it is > much better than before. > > [*] For those who don't know, the VM treats an empty finalize() method as non-existent > so the object does not need to be finalized. > > I had started to look at adding Disposer code to do the other thing that > the finalize() method does which is remove a deferred activation registration > but decided this was pointless. > > That is used only for the pre-defined instances held in static variables of the class > and those live for the life of the VM so will never be freed ... > > There is more clean up that could be done in the lower classes - is freeProfile needed any more ? > Do we actually want to keep the deferral mechanism ? > > Can we do something to provide a way to more promptly free the data, perhaps via new API ? > > But I decided to keep it to a minimum for safe and trivial backporting and leave the rest > to another day. > > -phil. > > > > -- Best regards, Sergey. From philip.race at oracle.com Fri Oct 11 22:43:50 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 11 Oct 2019 15:43:50 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method In-Reply-To: <809efff9-7605-984f-ab88-fab2231302c3@oracle.com> References: <5DA0EDB3.2000904@oracle.com> <809efff9-7605-984f-ab88-fab2231302c3@oracle.com> Message-ID: <5DA105A6.80100@oracle.com> On 10/11/19, 2:52 PM, Sergey Bylokhov wrote: > Hi, Phil. > > It looks like after the fix we will skip the call "unregisterDeferral" > and > the ProfileActivator which was registered by the > "ProfileDeferralMgr.registerDeferral" will not be removed --> memory > leak? I discussed that below in my initial email. It won't in practice leak anything. > I had started to look at adding Disposer code to do the other thing that >the finalize() method does which is remove a deferred activation registration >but decided this was pointless. >That is used only for the pre-defined instances held in static variables of the class >and those live for the life of the VM so will never be freed ... -phil. > > BTW do we have an option to mark this "finalize" as forRemoval=true or > just delete it?(example JDK-8159009/JDK-8212198) > > On 10/11/19 2:01 pm, Philip Race wrote: >> Bug: ICC_Profile has un-needed, not-empty finalize method >> Webrev: http://cr.openjdk.java.net/~prr/8175984/ >> >> This is a native memory utilisation problem due to delay in >> collecting and >> freeing ICC_Profiles and their associated classes and data. >> >> The color management engine is native code and consumes the stream of >> data >> representing the ICC profile and constructs internal native data >> structures. >> The delay is because the garbage collector doesn't know about the >> native memory >> consumption and from a Java perspective there is no need to initiate >> garbage collection. >> >> But it is worse than that because even collection when does happen it >> is delayed in >> freeing this memory. >> >> The native data is referenced internally via a Profile object which >> is registered with the 2D disposer >> so that the data will be freed after the disposer's reference to it >> is enqueued and cleared. >> >> The disposer needing to run does add some delay but there's a further >> delay. >> >> ICC_Profile has non-empty finalize which is there to free this >> native data. >> >> This used to matter with the old closed source CMS *only* because no >> one bothered >> to implement 2D disposer support for it. >> >> But the call in finalize() is a no-op for LCMS >> >> So currently the ICC_Profile has to be finalized and only then can >> the GC initiate >> clearing the weak refs and freeing the native data. >> >> Emptying the finalize() [*] method helps make the reclamation more >> prompt. >> It is still possible to see large amounts of native memory consumed >> but it is >> much better than before. >> >> [*] For those who don't know, the VM treats an empty finalize() >> method as non-existent >> so the object does not need to be finalized. >> >> I had started to look at adding Disposer code to do the other thing that >> the finalize() method does which is remove a deferred activation >> registration >> but decided this was pointless. >> >> That is used only for the pre-defined instances held in static >> variables of the class >> and those live for the life of the VM so will never be freed ... >> >> There is more clean up that could be done in the lower classes - is >> freeProfile needed any more ? >> Do we actually want to keep the deferral mechanism ? >> >> Can we do something to provide a way to more promptly free the data, >> perhaps via new API ? >> >> But I decided to keep it to a minimum for safe and trivial >> backporting and leave the rest >> to another day. >> >> -phil. >> >> >> >> > > From philip.race at oracle.com Fri Oct 11 22:45:46 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 11 Oct 2019 15:45:46 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method In-Reply-To: <809efff9-7605-984f-ab88-fab2231302c3@oracle.com> References: <5DA0EDB3.2000904@oracle.com> <809efff9-7605-984f-ab88-fab2231302c3@oracle.com> Message-ID: <5DA1061A.5060301@oracle.com> PS .. > > BTW do we have an option to mark this "finalize" as forRemoval=true or > just delete it?(example JDK-8159009/JDK-8212198) This will be for a backport, so that would be inappropriate even if I wanted to address that now .. -phil. From Sergey.Bylokhov at oracle.com Fri Oct 11 23:33:14 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Oct 2019 16:33:14 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method In-Reply-To: <5DA105A6.80100@oracle.com> References: <5DA0EDB3.2000904@oracle.com> <809efff9-7605-984f-ab88-fab2231302c3@oracle.com> <5DA105A6.80100@oracle.com> Message-ID: <6cde0a9a-ff87-8a65-cf68-d50dcd930c32@oracle.com> On 10/11/19 3:43 pm, Philip Race wrote: > On 10/11/19, 2:52 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> >> It looks like after the fix we will skip the call "unregisterDeferral" and >> the ProfileActivator which was registered by the >> "ProfileDeferralMgr.registerDeferral" will not be removed --> memory leak? > > I discussed that below in my initial email. It won't in practice leak anything. Initially missed that, +1. > > > I had started to look at adding Disposer code to do the other thing that > >the finalize() method does which is remove a deferred activation registration > >but decided this was pointless. > > >That is used only for the pre-defined instances held in static variables of the class > >and those live for the life of the VM so will never be freed ... > > -phil. >> >> BTW do we have an option to mark this "finalize" as forRemoval=true or just delete it?(example JDK-8159009/JDK-8212198) >> >> On 10/11/19 2:01 pm, Philip Race wrote: >>> Bug: ICC_Profile has un-needed, not-empty finalize method >>> Webrev: http://cr.openjdk.java.net/~prr/8175984/ >>> >>> This is a native memory utilisation problem due to delay in collecting and >>> freeing ICC_Profiles and their associated classes and data. >>> >>> The color management engine is native code and consumes the stream of data >>> representing the ICC profile and constructs internal native data structures. >>> The delay is because the garbage collector doesn't know about the native memory >>> consumption and from a Java perspective there is no need to initiate garbage collection. >>> >>> But it is worse than that because even collection when does happen it is delayed in >>> freeing this memory. >>> >>> The native data is referenced internally via a Profile object which is registered with the 2D disposer >>> so that the data will be freed after the disposer's? reference to it is enqueued and cleared. >>> >>> The disposer needing to run does add some delay but there's a further delay. >>> >>> ICC_Profile has? non-empty finalize which is there to free this native data. >>> >>> This used to matter with the old closed source CMS *only* because no one bothered >>> to implement 2D disposer support for it. >>> >>> But the call in finalize() is a no-op for LCMS >>> >>> So currently the ICC_Profile has to be finalized and only then can the GC initiate >>> clearing the weak refs and freeing the native data. >>> >>> Emptying the finalize() [*] method helps make the reclamation more prompt. >>> It is still possible to see large amounts of native memory consumed but it is >>> much better than before. >>> >>> [*] For those who don't know, the VM treats an empty finalize() method as non-existent >>> so the object does not need to be finalized. >>> >>> I had started to look at adding Disposer code to do the other thing that >>> the finalize() method does which is remove a deferred activation registration >>> but decided this was pointless. >>> >>> That is used only for the pre-defined instances held in static variables of the class >>> and those live for the life of the VM so will never be freed ... >>> >>> There is more clean up that could be done in the lower classes - is freeProfile needed any more ? >>> Do we actually want to keep the deferral mechanism ? >>> >>> Can we do something to provide a way to more promptly free the data, perhaps via new API ? >>> >>> But I decided to keep it to a minimum for safe and trivial backporting and leave the rest >>> to another day. >>> >>> -phil. >>> >>> >>> >>> >> >> -- Best regards, Sergey. From alexey.ivanov at oracle.com Mon Oct 14 11:57:17 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 14 Oct 2019 12:57:17 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java does not render Myanmar script correctly In-Reply-To: <66a60d1c-da9f-75a7-c539-4536effba302@oracle.com> References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> <5D96226C.7050503@oracle.com> <23ff6890-e126-990c-68d5-df11597a9327@oracle.com> <66a60d1c-da9f-75a7-c539-4536effba302@oracle.com> Message-ID: <04d2cf3c-4041-8772-4e2a-99779653b3f4@oracle.com> Thank you, Phil, for your review. I'm still looking for a second reviewer. Any volunteers, please? bug: https://bugs.openjdk.java.net/browse/JDK-8223558 webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ Thank you in advance. On 07/10/2019 16:51, Phil Race wrote: > sounds good. > > -phil. > > On 10/7/19 5:07 AM, Alexey Ivanov wrote: >> Hi Phil, >> >> Thank you for your review. >> I have updated the summary of the bug to be more specific: ?Java does >> not render Myanmar script correctly?. >> >> This fix addresses only the rendering of Myanmar characters. Adding >> Myanmar script and related languages to the list of supported locales >> is premature at this point. >> >> No input method is required. One just types characters one by one; >> the correct positioning of the glyphs is highly dependent software >> support and the fonts. With this fix, it should work reasonably well. >> >> Regards, >> Alexey >> >> On 04/10/2019 21:13, Phil Race wrote: >>> The code changes look fine, but? nothing you are doing here makes >>> Myanmar "supported". >>> It may work reasonably well, but it does not get added to the list >>> of supported locales - for Oracle JDK anyway. >>> Also I don't know what input method support might be required for >>> this besides what >>> you are doing here on the display side. >>> >>> >>> -phil. >>> >>> >>> On 10/3/19 10:28 AM, Alexey Ivanov wrote: >>>> Hi Phil, >>>> >>>> Thank you for your review. >>>> Please see my answers inline: >>>> >>>> On 03/10/2019 17:31, Philip Race wrote: >>>>> 1) This is an RFE, not a bug. >>>> >>>> I have updated the CR type to RFE. >>>> >>>>> 2) Does this font exist on Windows 7 ? >>>> >>>> No, it does not. This font was added in Windows 8. >>>> https://docs.microsoft.com/en-us/typography/font-list/myanmar-text >>>> >>>> The tests check if the required font is available; if not, an >>>> message is printed and the test exists. >>>> >>>>> 3) This cannot be backported since the older JDK releases will not >>>>> support it. >>>> >>>> No, it cannot be backported to 8u because ICU does not support >>>> Myanmar. >>>> It can be brought to 11 updates. >>>> >>>> >>>> Regards, >>>> Alexey >>>>> >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 10/3/19, 8:57 AM, Alexey Ivanov wrote: >>>>>> Any volunteers to review? >>>>>> >>>>>> On 25/09/2019 20:38, Alexey Ivanov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the fix for JDK 14: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >>>>>>> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >>>>>>> >>>>>>> Problem description: >>>>>>> Java renders Myanmar script incorrectly. Some glyphs are not >>>>>>> combined, which makes text unreadable. >>>>>>> For example, this glyph ?? is made of two characters U+1000 and >>>>>>> U+103C. Java renders two separate glyphs. >>>>>>> >>>>>>> Workaround: >>>>>>> Enable ligatures or kerning on the font to get the correct >>>>>>> rendering. >>>>>>> >>>>>>> The fix: >>>>>>> Enables complex layout for base Myanmar characters (U+1000-U+109F). >>>>>>> Provides fallback font on Windows. >>>>>>> On Linux, fontconfig handles the fallback. >>>>>>> >>>>>>> I ran awt/font tests, no new failures found. >>>>>>> -- Alexey From Sergey.Bylokhov at oracle.com Mon Oct 14 19:07:35 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Oct 2019 12:07:35 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8223558: Java does not render Myanmar script correctly In-Reply-To: <04d2cf3c-4041-8772-4e2a-99779653b3f4@oracle.com> References: <80d2aa44-4c3e-91b2-4a82-9e6cecf5bb7e@oracle.com> <5D96226C.7050503@oracle.com> <23ff6890-e126-990c-68d5-df11597a9327@oracle.com> <66a60d1c-da9f-75a7-c539-4536effba302@oracle.com> <04d2cf3c-4041-8772-4e2a-99779653b3f4@oracle.com> Message-ID: <1812be31-c786-8321-ae34-7d9c35f61d6f@oracle.com> +1 On 10/14/19 4:57 am, Alexey Ivanov wrote: > Thank you, Phil, for your review. > I'm still looking for a second reviewer. Any volunteers, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8223558 > webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ > > Thank you in advance. > > On 07/10/2019 16:51, Phil Race wrote: >> sounds good. >> >> -phil. >> >> On 10/7/19 5:07 AM, Alexey Ivanov wrote: >>> Hi Phil, >>> >>> Thank you for your review. >>> I have updated the summary of the bug to be more specific: ?Java does not render Myanmar script correctly?. >>> >>> This fix addresses only the rendering of Myanmar characters. Adding Myanmar script and related languages to the list of supported locales is premature at this point. >>> >>> No input method is required. One just types characters one by one; the correct positioning of the glyphs is highly dependent software support and the fonts. With this fix, it should work reasonably well. >>> >>> Regards, >>> Alexey >>> >>> On 04/10/2019 21:13, Phil Race wrote: >>>> The code changes look fine, but? nothing you are doing here makes Myanmar "supported". >>>> It may work reasonably well, but it does not get added to the list of supported locales - for Oracle JDK anyway. >>>> Also I don't know what input method support might be required for this besides what >>>> you are doing here on the display side. >>>> >>>> >>>> -phil. >>>> >>>> >>>> On 10/3/19 10:28 AM, Alexey Ivanov wrote: >>>>> Hi Phil, >>>>> >>>>> Thank you for your review. >>>>> Please see my answers inline: >>>>> >>>>> On 03/10/2019 17:31, Philip Race wrote: >>>>>> 1) This is an RFE, not a bug. >>>>> >>>>> I have updated the CR type to RFE. >>>>> >>>>>> 2) Does this font exist on Windows 7 ? >>>>> >>>>> No, it does not. This font was added in Windows 8. >>>>> https://docs.microsoft.com/en-us/typography/font-list/myanmar-text >>>>> >>>>> The tests check if the required font is available; if not, an message is printed and the test exists. >>>>> >>>>>> 3) This cannot be backported since the older JDK releases will not support it. >>>>> >>>>> No, it cannot be backported to 8u because ICU does not support Myanmar. >>>>> It can be brought to 11 updates. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 10/3/19, 8:57 AM, Alexey Ivanov wrote: >>>>>>> Any volunteers to review? >>>>>>> >>>>>>> On 25/09/2019 20:38, Alexey Ivanov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the fix for JDK 14: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223558 >>>>>>>> webrev: http://cr.openjdk.java.net/~aivanov/8223558/webrev.00/ >>>>>>>> >>>>>>>> Problem description: >>>>>>>> Java renders Myanmar script incorrectly. Some glyphs are not combined, which makes text unreadable. >>>>>>>> For example, this glyph ?? is made of two characters U+1000 and U+103C. Java renders two separate glyphs. >>>>>>>> >>>>>>>> Workaround: >>>>>>>> Enable ligatures or kerning on the font to get the correct rendering. >>>>>>>> >>>>>>>> The fix: >>>>>>>> Enables complex layout for base Myanmar characters (U+1000-U+109F). >>>>>>>> Provides fallback font on Windows. >>>>>>>> On Linux, fontconfig handles the fallback. >>>>>>>> >>>>>>>> I ran awt/font tests, no new failures found. >>>>>>>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Oct 14 21:33:41 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Oct 2019 14:33:41 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8232225 Rework the fix for JDK-8071483 Message-ID: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8232225 Fix: http://cr.openjdk.java.net/~serb/8232225/webrev.00 The fix for JDK-8071483 merged the tests for java.awt.color package and java.awt.Color class under java/awt/Color folder. But it is better to use another approach which was used in JDK-4413685 and split these tests to java/awt/color and java/awt/ColorClass in the same way as: java/awt/font and java/awt/FontClass; -- Best regards, Sergey. From yan at azul.com Tue Oct 15 08:59:54 2019 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 15 Oct 2019 11:59:54 +0300 Subject: [OpenJDK 2D-Dev] JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u In-Reply-To: <045CB7FE-AA43-4EF7-89B7-38C81EA1A837@amazon.com> References: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> <045CB7FE-AA43-4EF7-89B7-38C81EA1A837@amazon.com> Message-ID: Hi all, Paul have suggested to cross-post this downport request to 2d-dev, and so I do. Please take a look at the webrev http://cr.openjdk.java.net/~yan/8215210/webrev.0/ -- I don't think there's anything new though. NB: the idea of the test related to RTL is to write an asymmetric line containing letter shin which has three vertical prongs. Thank you! --yan On 09.10.2019 0:50, Hohensee, Paul wrote: > This looks reasonable to me based on prr's description, but I've got almost no experience in this area. I'd cross-post to 2d-dev to see what they think. They might be interested in your regression tests. > > Paul > > ?On 10/7/19, 5:28 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: > > Hi all, > > could you please review this downport of > https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? > > Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ > > There is a single digit change discovered by prr and a couple of > regression tests: > > one verifies that required shaping works as expected and another -- that > there's no obvious regression for JDK-8201801 > > > Thank you! > > --yan > > > > > From takiguc at linux.vnet.ibm.com Tue Oct 15 11:33:59 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 15 Oct 2019 20:33:59 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: <5D9CB3F8.9070205@oracle.com> References: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> <5D9CB3F8.9070205@oracle.com> Message-ID: Hello Phil. Sorry for bad response. AIX is following case, but physical font is not defined by default. > If you have fonts installed and have a custom fontconfig.properties > file for AIX > which references those, then you should be able to get a default font > from that > set of known existent physical fonts. Please try following steps to emulate same kind this on linux (RHEL7). 1. Download DefaultFontTestA.java and fontconfig.properties files Please modify fontconfig.properties if c0419bt_.pfb is not in /usr/share/X11/fonts/Type1 directory. 2. Compile and run with following options and environment variable. $ javac --add-exports java.desktop/sun.font=ALL-UNNAMED DefaultFontTestA.java $ USE_J2D_FONTCONFIG=no java --add-opens java.desktop/sun.font=ALL-UNNAMED -Dsun.awt.fontconfigfontconfig.properties DefaultFontTestA defaultFontName=Dialog defaultFontFileName=/dialog.ttf Exception in thread "main" java.lang.ClassCastException: class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont (sun.font.CompositeFont and sun.font.PhysicalFont are in module java.desktop of loader 'bootstrap') at java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1081) at DefaultFontTestA.main(DefaultFontTestA.java:48) Font2D font2d = findFont2D(getDefaultFontFaceName(), Font.PLAIN, NO_FALLBACK); Note: USE_J2D_FONTCONFIG is defined into src/java.desktop/unix/native/common/awt/fontpath.c Dialog and /dialog.ttf are defined into src/java.desktop/unix/classes/sun/awt/FcFontManager.java getDefaultFontFaceName returns defaultFontName, it's "Dialog". findFont2D() returns Dialog CompositeFont instead of physical font. I think we cannot control return value for physicalFonts.values().iterator(); "defaultPhysicalFont = ((CompositeFont) font2d).getSlotFont(0);" is useful. Please give me your comment. Thanks, Ichiroh Takiguchi On 2019-10-09 01:06, Philip Race wrote: > I think this needs a little bit more explanation first. > Systems without fontconfig ... meaning without libfontconfig. > So does that mean you just can't find fonts or have none installed ? > If you have fonts installed and have a custom fontconfig.properties > file for AIX > which references those, then you should be able to get a default font > from that > set of known existent physical fonts. > > If you have neither .. then you have a system configuration problem and > without > a physical font installed avoiding an exception here isn't really > going to help you > get much further. Perhaps we should throw InternalError a bit earlier. > I see no point in trying to survive .. > > -phil > > > On 10/8/19, 12:35 AM, Langer, Christoph wrote: >> Hi Ichiroh, >> >> thanks for the update. It looks good to me. I'll run it through test >> system tonight and let you know if we see issues by tomorrow. Should >> you not hear back from me, consider it as reviewed and tested ?? >> >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: Ichiroh Takiguchi >>> Sent: Montag, 7. Oktober 2019 19:16 >>> To: Langer, Christoph >>> Cc: 2d-dev at openjdk.java.net; Zeller, Arno >>> Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >>> when fontconfig.properties was used >>> >>> Hello Christoph. >>> >>> I appreciate your suggestion. >>> JTreg testcase could throw ClassCastException instead of >>> InvocationTargetException. >>> JTreg results were in JDK-8221741 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ >>> >>> Could you review the fix ? >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2019-10-07 22:53, Langer, Christoph wrote: >>>> Hi Ichiroh, >>>> >>>> this is great, thanks for doing this. We regularly see this and just >>>> stumbled over it the other day where the fontconfig of our test user >>>> was corrupted somehow. >>>> >>>> As for the test, I would reduce the amount of reflection a little >>>> bit. >>>> It should not be necessary to access SunFontManager via >>>> Class.forName, >>>> you already exported it to the test via the @modules statement. You >>>> can probably use this coding (please try as I didn't test it??): >>>> >>>> SunFontManager sfm = SunFontManager.getInstance(); >>>> Field defaultFontName_fid = >>>> SunFontManager.class.getDeclaredField("defaultFontName"); >>>> defaultFontName_fid.setAccessible(true); >>>> defaultFontName_fid.set(sfm, "Dialog"); >>>> Method loadFonts_mid = >>>> SunFontManager.class.getDeclaredMethod("loadFonts"); >>>> loadFonts_mid.setAccessible(true); >>>> loadFonts_mid.invoke(sfm); >>>> PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); >>>> System.out.println(physicalFont); >>>> >>>> If you want, I can run your (updated) patch through our test system. >>>> >>>> Thanks >>>> Christoph >>>> >>>> >>>>> -----Original Message----- >>>>> From: 2d-dev<2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh >>>>> Takiguchi >>>>> Sent: Montag, 7. Oktober 2019 09:33 >>>>> To: 2d-dev at openjdk.java.net >>>>> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >>> when >>>>> fontconfig.properties was used >>>>> >>>>> Hello. >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ >>>>> >>>>> JTreg testcase and results are including JDK-8221741 [1]. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. From philip.race at oracle.com Tue Oct 15 16:53:51 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2019 09:53:51 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8232225 Rework the fix for JDK-8071483 In-Reply-To: References: Message-ID: Looks fine to me. I checked none of these are on the problem list so you don't need to change anything there. -phil. On 10/14/19 2:33 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232225 > Fix: http://cr.openjdk.java.net/~serb/8232225/webrev.00 > > The fix for JDK-8071483 merged the tests for java.awt.color package > and java.awt.Color class > under java/awt/Color folder. > > But it is better to use another approach which was used in JDK-4413685 > and split these tests > to java/awt/color and java/awt/ColorClass in the same way as: > ?? java/awt/font? and java/awt/FontClass; > From matthias.baesken at sap.com Thu Oct 17 07:22:07 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 17 Oct 2019 07:22:07 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c Message-ID: Hello, please review the following small webrev . Java_sun_font_FreetypeFontScaler_getGlyphImageNative might return NULL which should be checked , the change add one missing check . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8232381 http://cr.openjdk.java.net/~mbaesken/webrevs/8232381.0/ Thanks and regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Oct 17 19:34:13 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Oct 2019 12:34:13 -0700 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c In-Reply-To: References: Message-ID: + jfloat advanceDefault = 0.0f; + (*env)->SetFloatField(env, metrics, sunFontIDs.xFID, advanceDefault); + (*env)->SetFloatField(env, metrics, sunFontIDs.yFID, advanceDefault); I don't think we need a variable here. Make it : + (*env)->SetFloatField(env, metrics, sunFontIDs.xFID, 0.0f); + (*env)->SetFloatField(env, metrics, sunFontIDs.yFID, 0.0f); -phil. On 10/17/19 12:22 AM, Baesken, Matthias wrote: > > Hello, please review the following small webrev . > > Java_sun_font_FreetypeFontScaler_getGlyphImageNative might return NULL > which should be checked , the change add one missing check . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8232381 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232381.0/ > > Thanks and regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Oct 18 12:04:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Oct 2019 12:04:47 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c In-Reply-To: References: Message-ID: +1 (also to remove the variable and use 0.0f in place) /Christoph From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Phil Race Sent: Donnerstag, 17. Oktober 2019 21:34 To: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c + jfloat advanceDefault = 0.0f; + (*env)->SetFloatField(env, metrics, sunFontIDs.xFID, advanceDefault); + (*env)->SetFloatField(env, metrics, sunFontIDs.yFID, advanceDefault); I don't think we need a variable here. Make it : + (*env)->SetFloatField(env, metrics, sunFontIDs.xFID, 0.0f); + (*env)->SetFloatField(env, metrics, sunFontIDs.yFID, 0.0f); -phil. On 10/17/19 12:22 AM, Baesken, Matthias wrote: Hello, please review the following small webrev . Java_sun_font_FreetypeFontScaler_getGlyphImageNative might return NULL which should be checked , the change add one missing check . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8232381 http://cr.openjdk.java.net/~mbaesken/webrevs/8232381.0/ Thanks and regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Oct 18 12:54:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 18 Oct 2019 12:54:09 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c In-Reply-To: References: Message-ID: Thanks for the reviews . I'll remove the variable before pushing . Best regards, Matthias From: Langer, Christoph Sent: Freitag, 18. Oktober 2019 14:05 To: Phil Race ; 2d-dev at openjdk.java.net; Baesken, Matthias Subject: RE: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c +1 (also to remove the variable and use 0.0f in place) /Christoph From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Phil Race Sent: Donnerstag, 17. Oktober 2019 21:34 To: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] RFR [XS] : 8232381: add result NULL-checking to freetypeScaler.c + jfloat advanceDefault = 0.0f; + (*env)->SetFloatField(env, metrics, sunFontIDs.xFID, advanceDefault); + (*env)->SetFloatField(env, metrics, sunFontIDs.yFID, advanceDefault); I don't think we need a variable here. Make it : + (*env)->SetFloatField(env, metrics, sunFontIDs.xFID, 0.0f); + (*env)->SetFloatField(env, metrics, sunFontIDs.yFID, 0.0f); -phil. On 10/17/19 12:22 AM, Baesken, Matthias wrote: Hello, please review the following small webrev . Java_sun_font_FreetypeFontScaler_getGlyphImageNative might return NULL which should be checked , the change add one missing check . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8232381 http://cr.openjdk.java.net/~mbaesken/webrevs/8232381.0/ Thanks and regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Mon Oct 21 19:11:01 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 21 Oct 2019 20:11:01 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time Message-ID: Hello, Please review the fix for the test: bug: https://bugs.openjdk.java.net/browse/JDK-8232634 webrev: http://cr.openjdk.java.net/~aivanov/8232634/webrev.00/ The test exhausts native memory so that a memory allocation fails. This situation is quite easy to achieve with 32 bit processes but it's somewhat impossible with 64 bit processes. With 64 bit JREs, the test could take a very long time to run: up to 80 minutes on Windows in the most extreme cases. It's a lot of time! I was running this test in different configurations and found that the expected exception is thrown at 20-25 thousand iterations (32-bit). It usually takes 3-4 minutes. If a Garbage Collector cycle is triggered, Java objects (BufferedImage) are disposed of, and native resources are freed. If it happens, the test will not throw the expected exceptions. When using 64-bit JRE, a GC is triggered after 65 thousand iterations, which takes about 30-40 minutes. I had to use SerialGC because the default G1 reclaims Java objects too fast, so that the error condition is never reached. In the fix, I reduced the number of iterations to 30,000 which covers the case where the problem is reproducible. The execution time reduced to about 5 minutes. I set the new timeout for the test to 10 minutes (600 seconds) which should be enough even for slower hardware. -- Regards, Alexey From Sergey.Bylokhov at oracle.com Mon Oct 21 19:47:46 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 Oct 2019 12:47:46 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: References: Message-ID: Hi, Alexey. On 10/21/19 12:11 pm, Alexey Ivanov wrote: > I was running this test in different configurations and found that the expected exception is thrown at 20-25 thousand iterations (32-bit). It usually takes 3-4 minutes. > > If a Garbage Collector cycle is triggered, Java objects (BufferedImage) are disposed of, and native resources are freed. If it happens, the test will not throw the expected exceptions. When using 64-bit JRE, a GC is triggered after 65 thousand iterations, which takes about 30-40 minutes. I had to use SerialGC because the default G1 reclaims Java objects too fast, so that the error condition is never reached. I am not sure that these exceptions are really "expected", the test just passes if some of them are thrown, but when I run this test on macOSx64 it is completed in 3 minutes w/o any exception(300_000 iterations were completed successfully). Why it is so slow in your environment? -- Best regards, Sergey. From alexey.ivanov at oracle.com Mon Oct 21 22:48:47 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 21 Oct 2019 23:48:47 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: References: Message-ID: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> Hi Sergey, On 21/10/2019 20:47, Sergey Bylokhov wrote: > Hi, Alexey. > > On 10/21/19 12:11 pm, Alexey Ivanov wrote: >> I was running this test in different configurations and found that >> the expected exception is thrown at 20-25 thousand iterations >> (32-bit). It usually takes 3-4 minutes. >> >> If a Garbage Collector cycle is triggered, Java objects >> (BufferedImage) are disposed of, and native resources are freed. If >> it happens, the test will not throw the expected exceptions. When >> using 64-bit JRE, a GC is triggered after 65 thousand iterations, >> which takes about 30-40 minutes. I had to use SerialGC because the >> default G1 reclaims Java objects too fast, so that the error >> condition is never reached. > > I am not sure that these exceptions are really "expected", the test > just passes if some of them are thrown, but when I run this test on > macOSx64 it is completed in 3 minutes w/o any exception(300_000 > iterations were completed successfully). Why it is so slow in your > environment? Yes, I noticed that the test is pretty fast both on Linux and Mac but it's not as fast on Windows. In fact, I reproduced the bug only on Windows and only on 32 bit. The bug was in shared code, that's why the test is not Windows-specific. -- Regards, Alexey From Sergey.Bylokhov at oracle.com Mon Oct 21 23:15:46 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 Oct 2019 16:15:46 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> Message-ID: <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> On 10/21/19 3:48 pm, Alexey Ivanov wrote: > Yes, I noticed that the test is pretty fast both on Linux and Mac but it's not as fast on Windows. In fact, I reproduced the bug only on Windows and only on 32 bit. The bug was in shared code, that's why the test is not Windows-specific. Then, isn't it is a product bug on windows rather than a test issue? -- Best regards, Sergey. From alexey.ivanov at oracle.com Tue Oct 22 13:09:31 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 22 Oct 2019 14:09:31 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> Message-ID: <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> On 22/10/2019 00:15, Sergey Bylokhov wrote: > On 10/21/19 3:48 pm, Alexey Ivanov wrote: >> Yes, I noticed that the test is pretty fast both on Linux and Mac but >> it's not as fast on Windows. In fact, I reproduced the bug only on >> Windows and only on 32 bit. The bug was in shared code, that's why >> the test is not Windows-specific. > > Then, isn't it is a product bug on windows rather than a test issue? That it runs for a long time? It's hard to say? The test has always been slower on Windows. The product bug JDK-8201433 was that it could crash and it did on 32 bit Windows. The test verifies JDK does not crash, it may throw OOME or NPE. With this patch I'm trying to reduce the time it takes to run the test. -- Regards, Alexey From Sergey.Bylokhov at oracle.com Wed Oct 23 16:54:38 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Oct 2019 09:54:38 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> Message-ID: On 10/22/19 6:09 am, Alexey Ivanov wrote: >> Then, isn't it is a product bug on windows rather than a test issue? > > That it runs for a long time? It's hard to say? The test has always been slower on Windows. Then probably we can exclude windows 32bit by the jtreg tag? And continue to test other platforms that they work properly and fast. But it will be good to check why it is so slow, probably our native code compiled using wrong flags? > The product bug JDK-8201433 was that it could crash and it did on 32 bit Windows. The test verifies JDK does not crash, it may throw OOME or NPE. > > With this patch I'm trying to reduce the time it takes to run the test. -- Best regards, Sergey. From jayathirth.d.v at oracle.com Wed Oct 23 21:07:10 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 23 Oct 2019 14:07:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method In-Reply-To: <5DA0EDB3.2000904@oracle.com> References: <5DA0EDB3.2000904@oracle.com> Message-ID: Changes are fine. Thanks, Jay > On 11-Oct-2019, at 2:01 PM, Philip Race wrote: > > Bug: ICC_Profile has un-needed, not-empty finalize method > Webrev: http://cr.openjdk.java.net/~prr/8175984/ > > This is a native memory utilisation problem due to delay in collecting and > freeing ICC_Profiles and their associated classes and data. > > The color management engine is native code and consumes the stream of data > representing the ICC profile and constructs internal native data structures. > The delay is because the garbage collector doesn't know about the native memory > consumption and from a Java perspective there is no need to initiate garbage collection. > > But it is worse than that because even collection when does happen it is delayed in > freeing this memory. > > The native data is referenced internally via a Profile object which is registered with the 2D disposer > so that the data will be freed after the disposer's reference to it is enqueued and cleared. > > The disposer needing to run does add some delay but there's a further delay. > > ICC_Profile has non-empty finalize which is there to free this native data. > > This used to matter with the old closed source CMS *only* because no one bothered > to implement 2D disposer support for it. > > But the call in finalize() is a no-op for LCMS > > So currently the ICC_Profile has to be finalized and only then can the GC initiate > clearing the weak refs and freeing the native data. > > Emptying the finalize() [*] method helps make the reclamation more prompt. > It is still possible to see large amounts of native memory consumed but it is > much better than before. > > [*] For those who don't know, the VM treats an empty finalize() method as non-existent > so the object does not need to be finalized. > > I had started to look at adding Disposer code to do the other thing that > the finalize() method does which is remove a deferred activation registration > but decided this was pointless. > > That is used only for the pre-defined instances held in static variables of the class > and those live for the life of the VM so will never be freed ... > > There is more clean up that could be done in the lower classes - is freeProfile needed any more ? > Do we actually want to keep the deferral mechanism ? > > Can we do something to provide a way to more promptly free the data, perhaps via new API ? > > But I decided to keep it to a minimum for safe and trivial backporting and leave the rest > to another day. > > -phil. > > > > From alexey.ivanov at oracle.com Wed Oct 23 22:32:06 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 23 Oct 2019 23:32:06 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> Message-ID: <9912c058-089a-c27c-0896-cb6912747e1c@oracle.com> On 23/10/2019 17:54, Sergey Bylokhov wrote: > On 10/22/19 6:09 am, Alexey Ivanov wrote: >>> Then, isn't it is a product bug on windows rather than a test issue? >> >> That it runs for a long time? It's hard to say? The test has always >> been slower on Windows. > > Then probably we can exclude windows 32bit by the jtreg tag? And > continue to > test other platforms that they work properly and fast. I'm confused now. Why would we exclude 32-bit Windows? It is the only platform where the original bug could be reproduced and where OOME or NPE is thrown in the test. With 64-bit platforms, it's nearly impossible to exhaust native memory to the state where OOME or NPE is thrown. It's the reason why the unmodified test takes too long on 64-bit Windows. > But it will be good to check why it is so slow, probably our native code > compiled using wrong flags? Yeah, probably it makes sense to investigate where the most time is spent on Windows. >> The product bug JDK-8201433 was that it could crash and it did on 32 >> bit Windows. The test verifies JDK does not crash, it may throw OOME >> or NPE. >> >> With this patch I'm trying to reduce the time it takes to run the test. > -- Regards, Alexey From Sergey.Bylokhov at oracle.com Thu Oct 24 07:48:38 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Oct 2019 00:48:38 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: <9912c058-089a-c27c-0896-cb6912747e1c@oracle.com> References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> <9912c058-089a-c27c-0896-cb6912747e1c@oracle.com> Message-ID: On 10/23/19 3:32 pm, Alexey Ivanov wrote: > I'm confused now. Why would we exclude 32-bit Windows? It is the only platform where the original bug could be reproduced and where OOME or NPE is thrown in the test. With 64-bit platforms, it's nearly impossible to exhaust native memory to the state where OOME or NPE is thrown. It's the reason why the unmodified test takes too long on 64-bit Windows. I though the comment below was about the current bug: > In fact, I reproduced the bug only on Windows and only on 32 bit If it is slow on win x64 only, then it really looks like a product bug. It should not be much different from the lin/mac x64, 3-4 min vs 30-40 min... -- Best regards, Sergey. From alexey.ivanov at oracle.com Fri Oct 25 17:39:55 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 25 Oct 2019 18:39:55 +0100 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> <9912c058-089a-c27c-0896-cb6912747e1c@oracle.com> Message-ID: <8fc39031-4a68-879d-73d3-4ab8a573ac54@oracle.com> On 24/10/2019 08:48, Sergey Bylokhov wrote: > On 10/23/19 3:32 pm, Alexey Ivanov wrote: >> I'm confused now. Why would we exclude 32-bit Windows? It is the only >> platform where the original bug could be reproduced and where OOME or >> NPE is thrown in the test. With 64-bit platforms, it's nearly >> impossible to exhaust native memory to the state where OOME or NPE is >> thrown. It's the reason why the unmodified test takes too long on >> 64-bit Windows. > > I though the comment below was about the current bug: >> In fact, I reproduced the bug only on Windows and only on 32 bit > If it is slow on win x64 only, then it really looks like a product bug. > It should not be much different from the lin/mac x64, 3-4 min vs 30-40 > min... I wasn't clear enough when referring to different bugs. I have submitted https://bugs.openjdk.java.net/browse/JDK-8233028 to investigate slow performance of ICMColorDataTest which could indicate a product bug. What about this patch? By reducing the number of iterations, the time to complete the test on 64-bit Windows is decreased from about 30 minutes to about 5 minutes. -- Regards, Alexey From Sergey.Bylokhov at oracle.com Fri Oct 25 21:15:05 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Oct 2019 14:15:05 -0700 Subject: [OpenJDK 2D-Dev] [14] RFR JDK-8232634: [TEST_BUG] ICMColorDataTest runs for a long time In-Reply-To: <8fc39031-4a68-879d-73d3-4ab8a573ac54@oracle.com> References: <1319bb49-7724-f48a-4dfb-7eafffa03a91@oracle.com> <88b6c492-7d18-9548-aaa1-73a48946b4cb@oracle.com> <402ca3f9-fabc-f12e-b6fa-f63697666e1f@oracle.com> <9912c058-089a-c27c-0896-cb6912747e1c@oracle.com> <8fc39031-4a68-879d-73d3-4ab8a573ac54@oracle.com> Message-ID: On 10/25/19 10:39 am, Alexey Ivanov wrote: > I have submitted > https://bugs.openjdk.java.net/browse/JDK-8233028 > to investigate slow performance of ICMColorDataTest which could indicate a product bug. Thank you. > > What about this patch? > By reducing the number of iterations, the time to complete the test on 64-bit Windows is decreased from about 30 minutes to about 5 minutes. I think we can add this test to the problem list for winx64 using bugid above. So it will be easy to verify the fix for JDK-8233028 later. -- Best regards, Sergey. From philip.race at oracle.com Sun Oct 27 14:51:27 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 27 Oct 2019 07:51:27 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8227324: Upgrade to freetype 2.10.1 Message-ID: <5DB5AEEF.7070703@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8227324 Webrev: http://cr.openjdk.java.net/~prr/8227324/ A patch update from 2.10.0 to 2.10.1. Some refactoring and some bug fixes. Builds fine with --use-freetype=bundled -phil. From takiguc at linux.vnet.ibm.com Mon Oct 28 16:58:50 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Oct 2019 01:58:50 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: References: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> <5D9CB3F8.9070205@oracle.com> Message-ID: Hello Phil and other reviewers. I appreciate if you give me your comment and suggestion. Thanks, Ichiroh Takiguchi On 2019-10-15 20:33, Ichiroh Takiguchi wrote: > Hello Phil. > > Sorry for bad response. > > AIX is following case, but physical font is not defined by default. >> If you have fonts installed and have a custom fontconfig.properties >> file for AIX >> which references those, then you should be able to get a default font >> from that >> set of known existent physical fonts. > > Please try following steps to emulate same kind this on linux (RHEL7). > 1. Download DefaultFontTestA.java and fontconfig.properties files > Please modify fontconfig.properties if c0419bt_.pfb is not in > /usr/share/X11/fonts/Type1 directory. > > 2. Compile and run with following options and environment variable. > $ javac --add-exports java.desktop/sun.font=ALL-UNNAMED > DefaultFontTestA.java > $ USE_J2D_FONTCONFIG=no java --add-opens > java.desktop/sun.font=ALL-UNNAMED > -Dsun.awt.fontconfigfontconfig.properties DefaultFontTestA > defaultFontName=Dialog > defaultFontFileName=/dialog.ttf > Exception in thread "main" java.lang.ClassCastException: class > sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont > (sun.font.CompositeFont and sun.font.PhysicalFont are in module > java.desktop of loader 'bootstrap') > at > java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1081) > at DefaultFontTestA.main(DefaultFontTestA.java:48) > > Font2D font2d = > findFont2D(getDefaultFontFaceName(), Font.PLAIN, > NO_FALLBACK); > Note: > USE_J2D_FONTCONFIG is defined into > src/java.desktop/unix/native/common/awt/fontpath.c > Dialog and /dialog.ttf are defined into > src/java.desktop/unix/classes/sun/awt/FcFontManager.java > > getDefaultFontFaceName returns defaultFontName, it's "Dialog". > findFont2D() returns Dialog CompositeFont instead of physical font. > I think we cannot control return value for > physicalFonts.values().iterator(); > "defaultPhysicalFont = ((CompositeFont) font2d).getSlotFont(0);" is > useful. > > Please give me your comment. > > Thanks, > Ichiroh Takiguchi > > On 2019-10-09 01:06, Philip Race wrote: >> I think this needs a little bit more explanation first. >> Systems without fontconfig ... meaning without libfontconfig. >> So does that mean you just can't find fonts or have none installed ? >> If you have fonts installed and have a custom fontconfig.properties >> file for AIX >> which references those, then you should be able to get a default font >> from that >> set of known existent physical fonts. >> >> If you have neither .. then you have a system configuration problem >> and without >> a physical font installed avoiding an exception here isn't really >> going to help you >> get much further. Perhaps we should throw InternalError a bit earlier. >> I see no point in trying to survive .. >> >> -phil >> >> >> On 10/8/19, 12:35 AM, Langer, Christoph wrote: >>> Hi Ichiroh, >>> >>> thanks for the update. It looks good to me. I'll run it through test >>> system tonight and let you know if we see issues by tomorrow. Should >>> you not hear back from me, consider it as reviewed and tested ?? >>> >>> Thanks >>> Christoph >>> >>>> -----Original Message----- >>>> From: Ichiroh Takiguchi >>>> Sent: Montag, 7. Oktober 2019 19:16 >>>> To: Langer, Christoph >>>> Cc: 2d-dev at openjdk.java.net; Zeller, Arno >>>> Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >>>> when fontconfig.properties was used >>>> >>>> Hello Christoph. >>>> >>>> I appreciate your suggestion. >>>> JTreg testcase could throw ClassCastException instead of >>>> InvocationTargetException. >>>> JTreg results were in JDK-8221741 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ >>>> >>>> Could you review the fix ? >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2019-10-07 22:53, Langer, Christoph wrote: >>>>> Hi Ichiroh, >>>>> >>>>> this is great, thanks for doing this. We regularly see this and >>>>> just >>>>> stumbled over it the other day where the fontconfig of our test >>>>> user >>>>> was corrupted somehow. >>>>> >>>>> As for the test, I would reduce the amount of reflection a little >>>>> bit. >>>>> It should not be necessary to access SunFontManager via >>>>> Class.forName, >>>>> you already exported it to the test via the @modules statement. You >>>>> can probably use this coding (please try as I didn't test it??): >>>>> >>>>> SunFontManager sfm = SunFontManager.getInstance(); >>>>> Field defaultFontName_fid = >>>>> SunFontManager.class.getDeclaredField("defaultFontName"); >>>>> defaultFontName_fid.setAccessible(true); >>>>> defaultFontName_fid.set(sfm, "Dialog"); >>>>> Method loadFonts_mid = >>>>> SunFontManager.class.getDeclaredMethod("loadFonts"); >>>>> loadFonts_mid.setAccessible(true); >>>>> loadFonts_mid.invoke(sfm); >>>>> PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); >>>>> System.out.println(physicalFont); >>>>> >>>>> If you want, I can run your (updated) patch through our test >>>>> system. >>>>> >>>>> Thanks >>>>> Christoph >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: 2d-dev<2d-dev-bounces at openjdk.java.net> On Behalf Of >>>>>> Ichiroh >>>>>> Takiguchi >>>>>> Sent: Montag, 7. Oktober 2019 09:33 >>>>>> To: 2d-dev at openjdk.java.net >>>>>> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >>>> when >>>>>> fontconfig.properties was used >>>>>> >>>>>> Hello. >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ >>>>>> >>>>>> JTreg testcase and results are including JDK-8221741 [1]. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. From takiguc at linux.vnet.ibm.com Mon Oct 28 17:23:16 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 29 Oct 2019 02:23:16 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work with UTF-8 locale on minimum software requirements In-Reply-To: <2b4547c2be6135cd014834b7c9810309@linux.vnet.ibm.com> References: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com> <2b4547c2be6135cd014834b7c9810309@linux.vnet.ibm.com> Message-ID: <70128c77ec336d8e0835a8cfb8ccf698@linux.vnet.ibm.com> Hello. I added my comment into JDK-8230873 [1] I appreciate if you give me your comment and suggestion. [1] https://bugs.openjdk.java.net/browse/JDK-8230873 Thanks, Ichiroh Takiguchi On 2019-10-10 14:59, Ichiroh Takiguchi wrote: > Thanks Christoph. > > I attached console log files for -Dsun.java2d.debugfonts=true option > into JDK-8230873 [1] > > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 > > Thanks, > Ichiroh Takiguchi > > On 2019-10-08 16:32, Langer, Christoph wrote: >> Hi Ichiroh, >> >> I ran this patch through our test queue and it works fine. >> >> I also checked the output of a simple test program that does >> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames() >> which loads the font configuration with -Dsun.java2d.debugfonts=true. >> I can see that lots of errors/logs like: >> >> Oct 04, 2019 9:59:39 AM sun.awt.X11FontManager >> getFileNameFromPlatformName >> WARNING: ** Registering all font paths because can't find file for >> -monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0 >> >> are gone now. So it must be good ?? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh >>> Takiguchi >>> Sent: Dienstag, 24. September 2019 09:54 >>> To: 2d-dev at openjdk.java.net; ppc-aix-port-dev >> dev at openjdk.java.net> >>> Subject: Re: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not >>> work >>> with UTF-8 locale on minimum software requirements >>> >>> Hello. >>> >>> I'm sorry, I made a typo in the Subject. >>> >>> Could you review the fix ? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2019-09-24 02:16, Ichiroh Takiguchi wrote: >>> > Hello. >>> > >>> > Could you review the fix ? >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 >>> > Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ >>> > >>> > GUI application does not work with AIX's JA_JP UTF-8 locale on minimum >>> > software requirements and settings because of following exception: >>> > Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: >>> > class sun.font.CompositeFont cannot be cast to class >>> > sun.font.PhysicalFont >>> > (sun.font.CompositeFont and sun.font.PhysicalFont are in module >>> > java.desktop of loader 'bootstrap') >>> > >>> > About the reasons for this exception: >>> > 1. Default physical font is not defined (like Lucida sans) >>> > 2. XLFD charset name entries for JA_JP locale have Underscore character >>> > (Underscore character replaces with Space character on >>> > fontconfig.proeprties >>> > (fontconfig.bfs) file loading phase.) >>> > >>> > About "1", I'd like to handle it by JDK-8221741 [1]. >>> > About "2", OpenJDK for AIX is using fontconfig.properties >>> > (fontconfig.bfc) file >>> > to find out TrueType fonts. >>> > On AIX JCK UTF-8 locales, Java cannot find out TrueType font because >>> > above XLFD charset name issue. >>> > >>> > This fix only changes fontconfig.properties for AIX platform >>> > * make/data/fontconfig/aix.fontconfig.properties >>> > >>> > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 >>> > >>> > Thanks, >>> > Ichiroh Takiguchi >>> > IBM Japan, Ltd. From philip.race at oracle.com Tue Oct 29 19:51:09 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Oct 2019 12:51:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8232154: Update Mesa 3-D Headers to version 19.2.1 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8232154 Webrev: http://cr.openjdk.java.net/~prr/8232154/ This is updating the header files we use to build the OpenGL code on all platforms. It is quite a large update since we were many, many years behind. Previously we used to get the "ext" headers from Khronos but now we get all the headers from the Mesa project. This reduces the number of upstream sources we need to monitor. There is one new header file that the "ext" headers now depend upon. All includes of another file reference the J2D_GL location where we store all these files. Search for "JDK modification" comments to find these updates There is a JDK modification in glxext.h to get it to build on Solaris Details in the bug report and reported upstream. Now builds fine and runs without issue in limited (SwingSet + J2Ddemo) testing. The licensing is really all the same but since we no longer get files directly from Khronos the opengl.md file is gone and the mesa3d.md is updated as required by the lawyers to mention these files. -phil. From kevin.rushforth at oracle.com Tue Oct 29 20:55:36 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 29 Oct 2019 13:55:36 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8232154: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: +1 -- Kevin On 10/29/2019 12:51 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8232154 > Webrev: http://cr.openjdk.java.net/~prr/8232154/ > > This is updating the header files we use to build the OpenGL code on > all platforms. > > It is quite a large update since we were many, many years behind. > > Previously we used to get the "ext" headers from Khronos but now we > get all > the headers from the Mesa project. > > This reduces the number of upstream sources we need to monitor. > > There is one new header file that the "ext" headers now depend upon. > All includes of another file reference the J2D_GL location where we store > all these files. > > Search for "JDK modification" comments to find these updates > > There is a JDK modification in glxext.h to get it to build on Solaris > Details in the bug report and reported upstream. > > Now builds fine and runs without issue in limited (SwingSet + J2Ddemo) > testing. > > The licensing is really all the same but since we no longer get files > directly from Khronos the opengl.md file is gone and the mesa3d.md > is updated as required by the lawyers to mention these files. > > -phil. > > From Sergey.Bylokhov at oracle.com Wed Oct 30 00:17:01 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Oct 2019 17:17:01 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8232154: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: +1 On 10/29/19 1:55 pm, Kevin Rushforth wrote: > +1 > > -- Kevin > > On 10/29/2019 12:51 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232154 >> Webrev: http://cr.openjdk.java.net/~prr/8232154/ >> >> This is updating the header files we use to build the OpenGL code on all platforms. >> >> It is quite a large update since we were many, many years behind. >> >> Previously we used to get the "ext" headers from Khronos but now we get all >> the headers from the Mesa project. >> >> This reduces the number of upstream sources we need to monitor. >> >> There is one new header file that the "ext" headers now depend upon. >> All includes of another file reference the J2D_GL location where we store >> all these files. >> >> Search for "JDK modification" comments to find these updates >> >> There is a JDK modification in glxext.h to get it to build on Solaris >> Details in the bug report and reported upstream. >> >> Now builds fine and runs without issue in limited (SwingSet + J2Ddemo) testing. >> >> The licensing is really all the same but since we no longer get files >> directly from Khronos the opengl.md file is gone and the mesa3d.md >> is updated as required by the lawyers to mention these files. >> >> -phil. >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Oct 30 00:25:38 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Oct 2019 17:25:38 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8227324: Upgrade to freetype 2.10.1 In-Reply-To: <5DB5AEEF.7070703@oracle.com> References: <5DB5AEEF.7070703@oracle.com> Message-ID: <4f4140fa-fa7b-185a-554e-de5c3f8a71a1@oracle.com> Looks fine. On 10/27/19 7:51 am, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8227324 > Webrev: http://cr.openjdk.java.net/~prr/8227324/ > > A patch update from 2.10.0 to 2.10.1. > > Some refactoring and some bug fixes. > > Builds fine with --use-freetype=bundled > > > -phil. -- Best regards, Sergey. From matthias.baesken at sap.com Wed Oct 30 13:59:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 Oct 2019 13:59:24 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java Message-ID: Please review the following small change . It excludes javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java ; the test seems to be fragile on various Linux distros , for instance on our Ubuntu 18 . The issues are already described in detail here : https://bugs.openjdk.java.net/browse/JDK-8229935 "All in all this test looks really fragile. It is a miracle it has passed as much as it has .. I think Linux may expose this because the font being used is more or less "fixed" on the other platforms but on Linux the font being used varies." As long as 8229935 is not fixed, the test should be excluded at least on Linux . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233202 http://cr.openjdk.java.net/~mbaesken/webrevs/8233202.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Oct 30 14:14:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 14:14:08 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java In-Reply-To: References: Message-ID: Hi Matthias, looks good, I definitely second that. Let's wait what 2d folks (Phil?) have to say. Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 30. Oktober 2019 14:59 To: 2d-dev at openjdk.java.net Cc: Langer, Christoph Subject: RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java Please review the following small change . It excludes javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java ; the test seems to be fragile on various Linux distros , for instance on our Ubuntu 18 . The issues are already described in detail here : https://bugs.openjdk.java.net/browse/JDK-8229935 "All in all this test looks really fragile. It is a miracle it has passed as much as it has .. I think Linux may expose this because the font being used is more or less "fixed" on the other platforms but on Linux the font being used varies." As long as 8229935 is not fixed, the test should be excluded at least on Linux . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233202 http://cr.openjdk.java.net/~mbaesken/webrevs/8233202.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Oct 30 14:38:35 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 30 Oct 2019 07:38:35 -0700 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java In-Reply-To: References: Message-ID: <5DB9A06B.6060905@oracle.com> Theoretically we've been going to fix this fragile test for weeks. It tests something important or else I'd ditch it completely .. Prasanta ? -phil. On 10/30/19, 7:14 AM, Langer, Christoph wrote: > > Hi Matthias, > > looks good, I definitely second that. Let's wait what 2d folks (Phil?) > have to say. > > Best regards > > Christoph > > *From:* Baesken, Matthias > *Sent:* Mittwoch, 30. Oktober 2019 14:59 > *To:* 2d-dev at openjdk.java.net > *Cc:* Langer, Christoph > *Subject:* RFR [XS] : 8233202: exclude > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java > > Please review the following small change . > > It excludes > javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java ; > the test seems to be fragile on various Linux distros , > > for instance on our Ubuntu 18 . > > The issues are already described in detail here : > > https://bugs.openjdk.java.net/browse/JDK-8229935 > > "All in all this test looks really fragile. It is a miracle it has > passed as much as it has .. I think Linux > may expose this because the font being used is more or less "fixed" on > the other platforms but > on Linux the font being used varies." > > As long as 8229935 is notfixed, the test should be excluded at > least on Linux . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8233202 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8233202.0/ > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Oct 30 14:59:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 14:59:45 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work with UTF-8 locale on minimum software requirements In-Reply-To: <70128c77ec336d8e0835a8cfb8ccf698@linux.vnet.ibm.com> References: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com> <2b4547c2be6135cd014834b7c9810309@linux.vnet.ibm.com> <70128c77ec336d8e0835a8cfb8ccf698@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, I think this one is ready for push (it's AIX only, at least I don't have anything to add). Or, Phil, do you have objections? Best regards Christoph > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Montag, 28. Oktober 2019 18:23 > To: Langer, Christoph > Cc: 2d-dev at openjdk.java.net; ppc-aix-port-dev dev at openjdk.java.net>; Baesken, Matthias > Subject: Re: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not work > with UTF-8 locale on minimum software requirements > > Hello. > > I added my comment into JDK-8230873 [1] > I appreciate if you give me your comment and suggestion. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 > > Thanks, > Ichiroh Takiguchi > > On 2019-10-10 14:59, Ichiroh Takiguchi wrote: > > Thanks Christoph. > > > > I attached console log files for -Dsun.java2d.debugfonts=true option > > into JDK-8230873 [1] > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2019-10-08 16:32, Langer, Christoph wrote: > >> Hi Ichiroh, > >> > >> I ran this patch through our test queue and it works fine. > >> > >> I also checked the output of a simple test program that does > >> > GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamil > yNames() > >> which loads the font configuration with -Dsun.java2d.debugfonts=true. > >> I can see that lots of errors/logs like: > >> > >> Oct 04, 2019 9:59:39 AM sun.awt.X11FontManager > >> getFileNameFromPlatformName > >> WARNING: ** Registering all font paths because can't find file for > >> -monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0 > >> > >> are gone now. So it must be good ?? > >> > >> Best regards > >> Christoph > >> > >>> -----Original Message----- > >>> From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of > Ichiroh > >>> Takiguchi > >>> Sent: Dienstag, 24. September 2019 09:54 > >>> To: 2d-dev at openjdk.java.net; ppc-aix-port-dev >>> dev at openjdk.java.net> > >>> Subject: Re: [OpenJDK 2D-Dev] RFR: 8230873 [AIX] GUI app does not > >>> work > >>> with UTF-8 locale on minimum software requirements > >>> > >>> Hello. > >>> > >>> I'm sorry, I made a typo in the Subject. > >>> > >>> Could you review the fix ? > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 > >>> Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ > >>> > >>> Thanks, > >>> Ichiroh Takiguchi > >>> IBM Japan, Ltd. > >>> > >>> On 2019-09-24 02:16, Ichiroh Takiguchi wrote: > >>> > Hello. > >>> > > >>> > Could you review the fix ? > >>> > > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8230873 > >>> > Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/ > >>> > > >>> > GUI application does not work with AIX's JA_JP UTF-8 locale on > minimum > >>> > software requirements and settings because of following exception: > >>> > Exception in thread "AWT-EventQueue-0" > java.lang.ClassCastException: > >>> > class sun.font.CompositeFont cannot be cast to class > >>> > sun.font.PhysicalFont > >>> > (sun.font.CompositeFont and sun.font.PhysicalFont are in module > >>> > java.desktop of loader 'bootstrap') > >>> > > >>> > About the reasons for this exception: > >>> > 1. Default physical font is not defined (like Lucida sans) > >>> > 2. XLFD charset name entries for JA_JP locale have Underscore > character > >>> > (Underscore character replaces with Space character on > >>> > fontconfig.proeprties > >>> > (fontconfig.bfs) file loading phase.) > >>> > > >>> > About "1", I'd like to handle it by JDK-8221741 [1]. > >>> > About "2", OpenJDK for AIX is using fontconfig.properties > >>> > (fontconfig.bfc) file > >>> > to find out TrueType fonts. > >>> > On AIX JCK UTF-8 locales, Java cannot find out TrueType font because > >>> > above XLFD charset name issue. > >>> > > >>> > This fix only changes fontconfig.properties for AIX platform > >>> > * make/data/fontconfig/aix.fontconfig.properties > >>> > > >>> > [1] https://bugs.openjdk.java.net/browse/JDK-8230873 > >>> > > >>> > Thanks, > >>> > Ichiroh Takiguchi > >>> > IBM Japan, Ltd. From christoph.langer at sap.com Wed Oct 30 15:00:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 15:00:51 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: References: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> <5D9CB3F8.9070205@oracle.com> Message-ID: Hi Ichiroh, I'm currently observing a test issue on one of our AIX boxes with that patch in place. Please give me some time to have a closer look... Best regards Christoph > -----Original Message----- > From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh > Takiguchi > Sent: Montag, 28. Oktober 2019 17:59 > To: Philip Race > Cc: 2d-dev at openjdk.java.net; Zeller, Arno > Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen > when fontconfig.properties was used > > Hello Phil and other reviewers. > > I appreciate if you give me your comment and suggestion. > > Thanks, > Ichiroh Takiguchi > > On 2019-10-15 20:33, Ichiroh Takiguchi wrote: > > Hello Phil. > > > > Sorry for bad response. > > > > AIX is following case, but physical font is not defined by default. > >> If you have fonts installed and have a custom fontconfig.properties > >> file for AIX > >> which references those, then you should be able to get a default font > >> from that > >> set of known existent physical fonts. > > > > Please try following steps to emulate same kind this on linux (RHEL7). > > 1. Download DefaultFontTestA.java and fontconfig.properties files > > Please modify fontconfig.properties if c0419bt_.pfb is not in > > /usr/share/X11/fonts/Type1 directory. > > > > 2. Compile and run with following options and environment variable. > > $ javac --add-exports java.desktop/sun.font=ALL-UNNAMED > > DefaultFontTestA.java > > $ USE_J2D_FONTCONFIG=no java --add-opens > > java.desktop/sun.font=ALL-UNNAMED > > -Dsun.awt.fontconfigfontconfig.properties DefaultFontTestA > > defaultFontName=Dialog > > defaultFontFileName=/dialog.ttf > > Exception in thread "main" java.lang.ClassCastException: class > > sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont > > (sun.font.CompositeFont and sun.font.PhysicalFont are in module > > java.desktop of loader 'bootstrap') > > at > > > java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontMa > nager.java:1081) > > at DefaultFontTestA.main(DefaultFontTestA.java:48) > > > > Font2D font2d = > > findFont2D(getDefaultFontFaceName(), Font.PLAIN, > > NO_FALLBACK); > > Note: > > USE_J2D_FONTCONFIG is defined into > > src/java.desktop/unix/native/common/awt/fontpath.c > > Dialog and /dialog.ttf are defined into > > src/java.desktop/unix/classes/sun/awt/FcFontManager.java > > > > getDefaultFontFaceName returns defaultFontName, it's "Dialog". > > findFont2D() returns Dialog CompositeFont instead of physical font. > > I think we cannot control return value for > > physicalFonts.values().iterator(); > > "defaultPhysicalFont = ((CompositeFont) font2d).getSlotFont(0);" is > > useful. > > > > Please give me your comment. > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2019-10-09 01:06, Philip Race wrote: > >> I think this needs a little bit more explanation first. > >> Systems without fontconfig ... meaning without libfontconfig. > >> So does that mean you just can't find fonts or have none installed ? > >> If you have fonts installed and have a custom fontconfig.properties > >> file for AIX > >> which references those, then you should be able to get a default font > >> from that > >> set of known existent physical fonts. > >> > >> If you have neither .. then you have a system configuration problem > >> and without > >> a physical font installed avoiding an exception here isn't really > >> going to help you > >> get much further. Perhaps we should throw InternalError a bit earlier. > >> I see no point in trying to survive .. > >> > >> -phil > >> > >> > >> On 10/8/19, 12:35 AM, Langer, Christoph wrote: > >>> Hi Ichiroh, > >>> > >>> thanks for the update. It looks good to me. I'll run it through test > >>> system tonight and let you know if we see issues by tomorrow. Should > >>> you not hear back from me, consider it as reviewed and tested ?? > >>> > >>> Thanks > >>> Christoph > >>> > >>>> -----Original Message----- > >>>> From: Ichiroh Takiguchi > >>>> Sent: Montag, 7. Oktober 2019 19:16 > >>>> To: Langer, Christoph > >>>> Cc: 2d-dev at openjdk.java.net; Zeller, Arno > >>>> Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException > happen > >>>> when fontconfig.properties was used > >>>> > >>>> Hello Christoph. > >>>> > >>>> I appreciate your suggestion. > >>>> JTreg testcase could throw ClassCastException instead of > >>>> InvocationTargetException. > >>>> JTreg results were in JDK-8221741 > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ > >>>> > >>>> Could you review the fix ? > >>>> > >>>> Thanks, > >>>> Ichiroh Takiguchi > >>>> IBM Japan, Ltd. > >>>> > >>>> On 2019-10-07 22:53, Langer, Christoph wrote: > >>>>> Hi Ichiroh, > >>>>> > >>>>> this is great, thanks for doing this. We regularly see this and > >>>>> just > >>>>> stumbled over it the other day where the fontconfig of our test > >>>>> user > >>>>> was corrupted somehow. > >>>>> > >>>>> As for the test, I would reduce the amount of reflection a little > >>>>> bit. > >>>>> It should not be necessary to access SunFontManager via > >>>>> Class.forName, > >>>>> you already exported it to the test via the @modules statement. You > >>>>> can probably use this coding (please try as I didn't test it??): > >>>>> > >>>>> SunFontManager sfm = SunFontManager.getInstance(); > >>>>> Field defaultFontName_fid = > >>>>> SunFontManager.class.getDeclaredField("defaultFontName"); > >>>>> defaultFontName_fid.setAccessible(true); > >>>>> defaultFontName_fid.set(sfm, "Dialog"); > >>>>> Method loadFonts_mid = > >>>>> SunFontManager.class.getDeclaredMethod("loadFonts"); > >>>>> loadFonts_mid.setAccessible(true); > >>>>> loadFonts_mid.invoke(sfm); > >>>>> PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); > >>>>> System.out.println(physicalFont); > >>>>> > >>>>> If you want, I can run your (updated) patch through our test > >>>>> system. > >>>>> > >>>>> Thanks > >>>>> Christoph > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: 2d-dev<2d-dev-bounces at openjdk.java.net> On Behalf Of > >>>>>> Ichiroh > >>>>>> Takiguchi > >>>>>> Sent: Montag, 7. Oktober 2019 09:33 > >>>>>> To: 2d-dev at openjdk.java.net > >>>>>> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen > >>>> when > >>>>>> fontconfig.properties was used > >>>>>> > >>>>>> Hello. > >>>>>> > >>>>>> Could you review the fix ? > >>>>>> > >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > >>>>>> Change: > https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ > >>>>>> > >>>>>> JTreg testcase and results are including JDK-8221741 [1]. > >>>>>> > >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 > >>>>>> > >>>>>> Thanks, > >>>>>> Ichiroh Takiguchi > >>>>>> IBM Japan, Ltd. From philip.race at oracle.com Wed Oct 30 16:06:49 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Oct 2019 09:06:49 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used In-Reply-To: References: <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com> <5D9CB3F8.9070205@oracle.com> Message-ID: Yes probably best if this is reviewed and approved by someone who has access to AIX. I have no idea if the XLFDs are even correct ... -phil. On 10/30/19 8:00 AM, Langer, Christoph wrote: > Hi Ichiroh, > > I'm currently observing a test issue on one of our AIX boxes with that patch in place. Please give me some time to have a closer look... > > Best regards > Christoph > >> -----Original Message----- >> From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Ichiroh >> Takiguchi >> Sent: Montag, 28. Oktober 2019 17:59 >> To: Philip Race >> Cc: 2d-dev at openjdk.java.net; Zeller, Arno >> Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >> when fontconfig.properties was used >> >> Hello Phil and other reviewers. >> >> I appreciate if you give me your comment and suggestion. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-10-15 20:33, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> Sorry for bad response. >>> >>> AIX is following case, but physical font is not defined by default. >>>> If you have fonts installed and have a custom fontconfig.properties >>>> file for AIX >>>> which references those, then you should be able to get a default font >>>> from that >>>> set of known existent physical fonts. >>> Please try following steps to emulate same kind this on linux (RHEL7). >>> 1. Download DefaultFontTestA.java and fontconfig.properties files >>> Please modify fontconfig.properties if c0419bt_.pfb is not in >>> /usr/share/X11/fonts/Type1 directory. >>> >>> 2. Compile and run with following options and environment variable. >>> $ javac --add-exports java.desktop/sun.font=ALL-UNNAMED >>> DefaultFontTestA.java >>> $ USE_J2D_FONTCONFIG=no java --add-opens >>> java.desktop/sun.font=ALL-UNNAMED >>> -Dsun.awt.fontconfigfontconfig.properties DefaultFontTestA >>> defaultFontName=Dialog >>> defaultFontFileName=/dialog.ttf >>> Exception in thread "main" java.lang.ClassCastException: class >>> sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont >>> (sun.font.CompositeFont and sun.font.PhysicalFont are in module >>> java.desktop of loader 'bootstrap') >>> at >>> >> java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontMa >> nager.java:1081) >>> at DefaultFontTestA.main(DefaultFontTestA.java:48) >>> >>> Font2D font2d = >>> findFont2D(getDefaultFontFaceName(), Font.PLAIN, >>> NO_FALLBACK); >>> Note: >>> USE_J2D_FONTCONFIG is defined into >>> src/java.desktop/unix/native/common/awt/fontpath.c >>> Dialog and /dialog.ttf are defined into >>> src/java.desktop/unix/classes/sun/awt/FcFontManager.java >>> >>> getDefaultFontFaceName returns defaultFontName, it's "Dialog". >>> findFont2D() returns Dialog CompositeFont instead of physical font. >>> I think we cannot control return value for >>> physicalFonts.values().iterator(); >>> "defaultPhysicalFont = ((CompositeFont) font2d).getSlotFont(0);" is >>> useful. >>> >>> Please give me your comment. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2019-10-09 01:06, Philip Race wrote: >>>> I think this needs a little bit more explanation first. >>>> Systems without fontconfig ... meaning without libfontconfig. >>>> So does that mean you just can't find fonts or have none installed ? >>>> If you have fonts installed and have a custom fontconfig.properties >>>> file for AIX >>>> which references those, then you should be able to get a default font >>>> from that >>>> set of known existent physical fonts. >>>> >>>> If you have neither .. then you have a system configuration problem >>>> and without >>>> a physical font installed avoiding an exception here isn't really >>>> going to help you >>>> get much further. Perhaps we should throw InternalError a bit earlier. >>>> I see no point in trying to survive .. >>>> >>>> -phil >>>> >>>> >>>> On 10/8/19, 12:35 AM, Langer, Christoph wrote: >>>>> Hi Ichiroh, >>>>> >>>>> thanks for the update. It looks good to me. I'll run it through test >>>>> system tonight and let you know if we see issues by tomorrow. Should >>>>> you not hear back from me, consider it as reviewed and tested ?? >>>>> >>>>> Thanks >>>>> Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: Ichiroh Takiguchi >>>>>> Sent: Montag, 7. Oktober 2019 19:16 >>>>>> To: Langer, Christoph >>>>>> Cc: 2d-dev at openjdk.java.net; Zeller, Arno >>>>>> Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException >> happen >>>>>> when fontconfig.properties was used >>>>>> >>>>>> Hello Christoph. >>>>>> >>>>>> I appreciate your suggestion. >>>>>> JTreg testcase could throw ClassCastException instead of >>>>>> InvocationTargetException. >>>>>> JTreg results were in JDK-8221741 >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/ >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> On 2019-10-07 22:53, Langer, Christoph wrote: >>>>>>> Hi Ichiroh, >>>>>>> >>>>>>> this is great, thanks for doing this. We regularly see this and >>>>>>> just >>>>>>> stumbled over it the other day where the fontconfig of our test >>>>>>> user >>>>>>> was corrupted somehow. >>>>>>> >>>>>>> As for the test, I would reduce the amount of reflection a little >>>>>>> bit. >>>>>>> It should not be necessary to access SunFontManager via >>>>>>> Class.forName, >>>>>>> you already exported it to the test via the @modules statement. You >>>>>>> can probably use this coding (please try as I didn't test it??): >>>>>>> >>>>>>> SunFontManager sfm = SunFontManager.getInstance(); >>>>>>> Field defaultFontName_fid = >>>>>>> SunFontManager.class.getDeclaredField("defaultFontName"); >>>>>>> defaultFontName_fid.setAccessible(true); >>>>>>> defaultFontName_fid.set(sfm, "Dialog"); >>>>>>> Method loadFonts_mid = >>>>>>> SunFontManager.class.getDeclaredMethod("loadFonts"); >>>>>>> loadFonts_mid.setAccessible(true); >>>>>>> loadFonts_mid.invoke(sfm); >>>>>>> PhysicalFont physicalFont = sfm.getDefaultPhysicalFont(); >>>>>>> System.out.println(physicalFont); >>>>>>> >>>>>>> If you want, I can run your (updated) patch through our test >>>>>>> system. >>>>>>> >>>>>>> Thanks >>>>>>> Christoph >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: 2d-dev<2d-dev-bounces at openjdk.java.net> On Behalf Of >>>>>>>> Ichiroh >>>>>>>> Takiguchi >>>>>>>> Sent: Montag, 7. Oktober 2019 09:33 >>>>>>>> To: 2d-dev at openjdk.java.net >>>>>>>> Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen >>>>>> when >>>>>>>> fontconfig.properties was used >>>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> Could you review the fix ? >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>>>> Change: >> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/ >>>>>>>> JTreg testcase and results are including JDK-8221741 [1]. >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ichiroh Takiguchi >>>>>>>> IBM Japan, Ltd. From philip.race at oracle.com Wed Oct 30 18:05:59 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Oct 2019 11:05:59 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8233097: Fontmetrics for large Fonts has zero width Message-ID: <1d2510fd-7d4c-7273-d306-d5e329b57aa8@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8233097 Webrev: http://cr.openjdk.java.net/~prr/8233097/ This bug is a regression from a fix in JDK 13.0.1 / 11.0.5 To work around a bug in old versions of freetype we capped the size of the glyph image but overlooked that we may use that code to get metrics even when the glyph image isn't needed. The fix is to still get the metrics the same way but in such a case skip getting the image. When the new "renderImage" variable is true the changes in the code should be a no-op, and this is used for metrics and images for typical sizes. So theoretically at least, safe there. For renderImage == false, as used from the advance/metrics functions it guards against rendering the image or accessing bitmap fields. The advance/metrics cases discard the image so it should also be safe there. I'm running regression tests as well as Font2DTest and all passes so far. This will need to be backported to 11u, so does still need careful review. -phil. From philip.race at oracle.com Wed Oct 30 18:37:47 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Oct 2019 11:37:47 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8233097: Fontmetrics for large Fonts has zero width In-Reply-To: <1d2510fd-7d4c-7273-d306-d5e329b57aa8@oracle.com> References: <1d2510fd-7d4c-7273-d306-d5e329b57aa8@oracle.com> Message-ID: <7c531893-d5be-358d-167a-72f428d2da8d@oracle.com> PS .. a positive from this is that with this fix the regression test runs about 10X faster than it did with say JDK 13 GA .. due to skipping the redundant images -phil. On 10/30/19 11:05 AM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8233097 > Webrev: http://cr.openjdk.java.net/~prr/8233097/ > > This bug is a regression from a fix in JDK 13.0.1 / 11.0.5 > > To work around a bug in old versions of freetype we capped the size > of the glyph image but overlooked that we may use that code to get > metrics even when the glyph image isn't needed. > > The fix is to still get the metrics the same way but in such a case > skip getting the image. > > When the new "renderImage" variable is true the changes in the > code should be a no-op, and this is used for metrics and images > for typical sizes. So theoretically at least, safe there. > > For renderImage == false, as used from the advance/metrics functions > it guards against rendering the image or accessing bitmap fields. > > The advance/metrics cases discard the image so it should also be safe > there. > > I'm running regression tests as well as Font2DTest and all passes so far. > > This will need to be backported to 11u, so does still need careful > review. > > -phil. > > > > > From philip.race at oracle.com Wed Oct 30 20:31:49 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Oct 2019 13:31:49 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8232154: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: <8d4dc92f-0d02-9a76-0df3-5e1b504c7198@oracle.com> Minor update :? http://cr.openjdk.java.net/~prr/8232154.1/ Only thing changed is these lines are REMOVED from mesa3.md since I've been told they aren't important to have there .. 7 License / Copyright Information 8 The Mesa distribution consists of several components. 9 Different copyrights and licenses apply to different components. 10 For example, the GLX client code uses the SGI Free Software License B, 11 and some of the Mesa device drivers are copyrighted by their authors. 12 See below for a list of Mesa's main components and the license for each. 13 14 The core Mesa library is licensed according to the terms of the MIT license. 15 This allows integration with the XFree86, Xorg and DRI projects. 16 17 The default Mesa license is as follows: -phil. On 10/29/19 5:17 PM, Sergey Bylokhov wrote: > +1 > > On 10/29/19 1:55 pm, Kevin Rushforth wrote: >> +1 >> >> -- Kevin >> >> On 10/29/2019 12:51 PM, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232154 >>> Webrev: http://cr.openjdk.java.net/~prr/8232154/ >>> >>> This is updating the header files we use to build the OpenGL code on >>> all platforms. >>> >>> It is quite a large update since we were many, many years behind. >>> >>> Previously we used to get the "ext" headers from Khronos but now we >>> get all >>> the headers from the Mesa project. >>> >>> This reduces the number of upstream sources we need to monitor. >>> >>> There is one new header file that the "ext" headers now depend upon. >>> All includes of another file reference the J2D_GL location where we >>> store >>> all these files. >>> >>> Search for "JDK modification" comments to find these updates >>> >>> There is a JDK modification in glxext.h to get it to build on Solaris >>> Details in the bug report and reported upstream. >>> >>> Now builds fine and runs without issue in limited (SwingSet + >>> J2Ddemo) testing. >>> >>> The licensing is really all the same but since we no longer get files >>> directly from Khronos the opengl.md file is gone and the mesa3d.md >>> is updated as required by the lawyers to mention these files. >>> >>> -phil. >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Oct 30 20:41:37 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 30 Oct 2019 13:41:37 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8232154: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: <8d4dc92f-0d02-9a76-0df3-5e1b504c7198@oracle.com> References: <8d4dc92f-0d02-9a76-0df3-5e1b504c7198@oracle.com> Message-ID: <6fb2d173-6f9f-4943-2be8-aa0094d7d6b6@oracle.com> Updated .md file looks fine. +1 -- Kevin On 10/30/2019 1:31 PM, Phil Race wrote: > Minor update : http://cr.openjdk.java.net/~prr/8232154.1/ > > Only thing changed is these lines are REMOVED from mesa3.md since > I've been told they aren't important to have there .. > 7 License / Copyright Information > 8 The Mesa distribution consists of several components. > 9 Different copyrights and licenses apply to different components. > 10 For example, the GLX client code uses the SGI Free Software License B, > 11 and some of the Mesa device drivers are copyrighted by their authors. > 12 See below for a list of Mesa's main components and the license for each. > 13 > 14 The core Mesa library is licensed according to the terms of the MIT license. > 15 This allows integration with the XFree86, Xorg and DRI projects. > 16 > 17 The default Mesa license is as follows: > > -phil. > > On 10/29/19 5:17 PM, Sergey Bylokhov wrote: >> +1 >> >> On 10/29/19 1:55 pm, Kevin Rushforth wrote: >>> +1 >>> >>> -- Kevin >>> >>> On 10/29/2019 12:51 PM, Phil Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232154 >>>> Webrev: http://cr.openjdk.java.net/~prr/8232154/ >>>> >>>> This is updating the header files we use to build the OpenGL code >>>> on all platforms. >>>> >>>> It is quite a large update since we were many, many years behind. >>>> >>>> Previously we used to get the "ext" headers from Khronos but now we >>>> get all >>>> the headers from the Mesa project. >>>> >>>> This reduces the number of upstream sources we need to monitor. >>>> >>>> There is one new header file that the "ext" headers now depend upon. >>>> All includes of another file reference the J2D_GL location where we >>>> store >>>> all these files. >>>> >>>> Search for "JDK modification" comments to find these updates >>>> >>>> There is a JDK modification in glxext.h to get it to build on Solaris >>>> Details in the bug report and reported upstream. >>>> >>>> Now builds fine and runs without issue in limited (SwingSet + >>>> J2Ddemo) testing. >>>> >>>> The licensing is really all the same but since we no longer get files >>>> directly from Khronos the opengl.md file is gone and the mesa3d.md >>>> is updated as required by the lawyers to mention these files. >>>> >>>> -phil. >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Oct 31 08:26:48 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 31 Oct 2019 13:56:48 +0530 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java In-Reply-To: <5DB9A06B.6060905@oracle.com> References: <5DB9A06B.6060905@oracle.com> Message-ID: This test tests the newly added public API of BasicGraphicsUtils (exposing the functionality provided by internal class SwingUtilities2) for use by third party LAFs in JDK9 and beyond, so I guess we cannot ditch it completely. Regarding the test fragility, I actually incorporated the changes proposed by Phil, which are - add "x"? to the position it passes to checkImageContainsSymbol - increase WIDTH - use rendering hints to use aliased text in testDrawString() which makes the test pass in linux but it now creates problem in macos. We can work on it but probably, it is safe to problem list the test for linux for now. Regards Prasanta On 30-Oct-19 8:08 PM, Philip Race wrote: > Theoretically we've been going to fix this fragile test for weeks. > > It tests something important or else I'd ditch it completely .. > > Prasanta? ? > > -phil. > > On 10/30/19, 7:14 AM, Langer, Christoph wrote: >> >> Hi Matthias, >> >> looks good, I definitely second that. Let?s wait what 2d folks >> (Phil?) have to say. >> >> Best regards >> >> Christoph >> >> *From:* Baesken, Matthias >> *Sent:* Mittwoch, 30. Oktober 2019 14:59 >> *To:* 2d-dev at openjdk.java.net >> *Cc:* Langer, Christoph >> *Subject:* RFR [XS] : 8233202: exclude >> javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java >> >> Please review the following small change . >> >> It excludes >> javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java ; >> the test ?seems to ?be ?fragile on various Linux distros , >> >> ??? for instance on our Ubuntu 18 . >> >> The issues are already described in detail? here : >> >> https://bugs.openjdk.java.net/browse/JDK-8229935 >> >> ?All in all this test looks really fragile. It is a miracle it has >> passed as much as it has .. I think Linux >> may expose this because the font being used is more or less "fixed" >> on the other platforms but >> on Linux the font being used varies.? >> >> As long as 8229935? is notfixed,? the test should be excluded at? >> least? on Linux . >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8233202 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8233202.0/ >> >> >> Thanks, Matthias >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Oct 31 08:51:00 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 31 Oct 2019 08:51:00 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java In-Reply-To: References: <5DB9A06B.6060905@oracle.com> Message-ID: * We can work on it but probably, it is safe to problem list the test for linux for now. Ok, great. May I add you as reviewer ? Best regards, Matthias From: Prasanta Sadhukhan Sent: Donnerstag, 31. Oktober 2019 09:27 To: Philip Race ; Langer, Christoph Cc: Baesken, Matthias ; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java This test tests the newly added public API of BasicGraphicsUtils (exposing the functionality provided by internal class SwingUtilities2) for use by third party LAFs in JDK9 and beyond, so I guess we cannot ditch it completely. Regarding the test fragility, I actually incorporated the changes proposed by Phil, which are - add "x" to the position it passes to checkImageContainsSymbol - increase WIDTH - use rendering hints to use aliased text in testDrawString() which makes the test pass in linux but it now creates problem in macos. We can work on it but probably, it is safe to problem list the test for linux for now. Regards Prasanta On 30-Oct-19 8:08 PM, Philip Race wrote: Theoretically we've been going to fix this fragile test for weeks. It tests something important or else I'd ditch it completely .. Prasanta ? -phil. On 10/30/19, 7:14 AM, Langer, Christoph wrote: Hi Matthias, looks good, I definitely second that. Let's wait what 2d folks (Phil?) have to say. Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 30. Oktober 2019 14:59 To: 2d-dev at openjdk.java.net Cc: Langer, Christoph Subject: RFR [XS] : 8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java Please review the following small change . It excludes javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java ; the test seems to be fragile on various Linux distros , for instance on our Ubuntu 18 . The issues are already described in detail here : https://bugs.openjdk.java.net/browse/JDK-8229935 "All in all this test looks really fragile. It is a miracle it has passed as much as it has .. I think Linux may expose this because the font being used is more or less "fixed" on the other platforms but on Linux the font being used varies." As long as 8229935 is not fixed, the test should be excluded at least on Linux . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233202 http://cr.openjdk.java.net/~mbaesken/webrevs/8233202.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Oct 31 19:59:31 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 31 Oct 2019 12:59:31 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8233097: Fontmetrics for large Fonts has zero width In-Reply-To: <7c531893-d5be-358d-167a-72f428d2da8d@oracle.com> References: <1d2510fd-7d4c-7273-d306-d5e329b57aa8@oracle.com> <7c531893-d5be-358d-167a-72f428d2da8d@oracle.com> Message-ID: <09cc1850-311b-03b6-15dc-0d9830b561fa@oracle.com> Looks fine. On 10/30/19 11:37 am, Phil Race wrote: > PS .. a positive from this is that with this fix the regression test > runs about 10X faster than it did with say JDK 13 GA .. due to > skipping the redundant images > > -phil. > > On 10/30/19 11:05 AM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233097 >> Webrev: http://cr.openjdk.java.net/~prr/8233097/ >> >> This bug is a regression from a fix in JDK 13.0.1 / 11.0.5 >> >> To work around a bug in old versions of freetype we capped the size >> of the glyph image but overlooked that we may use that code to get >> metrics even when the glyph image isn't needed. >> >> The fix is to still get the metrics the same way but in such a case >> skip getting the image. >> >> When the new "renderImage" variable is true the changes in the >> code should be a no-op, and this is used for metrics and images >> for typical sizes. So theoretically at least, safe there. >> >> For renderImage == false, as used from the advance/metrics functions >> it guards against rendering the image or accessing bitmap fields. >> >> The advance/metrics cases discard the image so it should also be safe there. >> >> I'm running regression tests as well as Font2DTest and all passes so far. >> >> This will need to be backported to 11u, so does still need careful review. >> >> -phil. >> >> >> >> >> > -- Best regards, Sergey.