RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.) Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file. On current implementation, Java tries to load X11 bitmap fonts even if these are not used. This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories. Just font name format should be supported. To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year. Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here. I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me. -phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
Hello Phil. I appreciate your reply. I put problem analysis information in JDK-8221741 [1]. The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like: $ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2] Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome) [1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me.
-phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ? -phil. On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().)
I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me.
-phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
Hello Phil. I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself) To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ... I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. Thanks, Ichiroh Takiguchi On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me.
-phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason. protected void registerFontFile(String fontFileName, String[] nativeNames, int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? } -phil. On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me.
-phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
Hello Phil. I appreciate your suggestion. I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font. On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility. On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames, int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me.
-phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
(Sorry, please ignore previous mail, it has wrong link for "Change") Hello Phil. I appreciate your suggestion. I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font. On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility. On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames, int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.)
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
I'd like to obtain a sponsor for this issue.
On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file.
On current implementation, Java tries to load X11 bitmap fonts even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories.
Just font name format should be supported.
Not clear enough for me.
-phil.
To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year.
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file. Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms. Also I am puzzled when I see this : 449 && "FILE_NAMES_ALIASES".equals(st.sval)) { and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in a random place, and your code is broken. -phil. On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote:
(Sorry, please ignore previous mail, it has wrong link for "Change")
Hello Phil.
I appreciate your suggestion.
I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font.
On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility.
On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames,
int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0"
... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote:
On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: > Hello. > (I am sorry to post it again. Previously, I posted the wrong > mailing list.) > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > On AIX platform, fontconfig.properties file is used to pick up > proper fonts. > TrueType font settings are written by XLFD format on > fontconfig.properties file. > > On current implementation, Java tries to load X11 bitmap fonts > even if these are not used.
I think you need to clarify what you mean here.
I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this.
> This font load work is almost name as "xlsfonts -ll". > It spends many CPU time and memories. > > Just font name format should be supported.
Not clear enough for me.
-phil. > > To SAP representative, > I have a question about copyright year on > make/data/fontconfig/aix.fontconfig.properties. > Please let me know how I should write down copyright year. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. >
Hello Phil. I appreciate your comment. I tried to debug this issue from another side. I checked fontconfig.properties file by CompileFontConfig (.bfc build tool) with -verbose option [1] Following messages were displayed: Note: 'filename' entry is undefined for "-monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0" ... I could find out encoding name has "_" character. And '_' -> ' ' conversion was in FontConfiguration. I applied following fixes: src/java.desktop/share/classes/sun/awt/FontConfiguration.java * '_' -> ' ' conversion only applies before PIXEL_SIZE field on XLFD * fontconfig.bfc is built by boot compiler, so above fix does not affect. After reading fontconfig.bfc, data need to be modified src/java.desktop/unix/classes/sun/awt/X11FontManager.java * Fix typo for logging output Could you review the fix again ? Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 [1] https://bugs.openjdk.java.net/browse/JDK-8221741 I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-26 05:41, Phil Race wrote:
I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file.
Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms.
Also I am puzzled when I see this : 449 && "FILE_NAMES_ALIASES".equals(st.sval)) {
and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html
I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in a random place, and your code is broken.
-phil.
On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote:
(Sorry, please ignore previous mail, it has wrong link for "Change")
Hello Phil.
I appreciate your suggestion.
I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font.
On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility.
On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames,
int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
Hello Phil.
I appreciate your reply. I put problem analysis information in JDK-8221741 [1].
The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like:
$ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s
One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2]
Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome)
[1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
On 2019-04-04 01:09, Philip Race wrote: > On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >> Hello. >> (I am sorry to post it again. Previously, I posted the wrong >> mailing list.) >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >> Change: >> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >> >> I'd like to obtain a sponsor for this issue. >> >> On AIX platform, fontconfig.properties file is used to pick up >> proper fonts. >> TrueType font settings are written by XLFD format on >> fontconfig.properties file. >> >> On current implementation, Java tries to load X11 bitmap fonts >> even if these are not used. > > I think you need to clarify what you mean here. > > I'd like you to provide a step by step analysis of what happens > and > what the effect of your proposed change is on AIX *AND* what it > might > mean for other X11 platforms, as I don't have time to reverse > engineer the > reasons for the odd-looking change. > It looks like a hack to short-circuit support your syntax. > Right now I am saying no to this. > >> This font load work is almost name as "xlsfonts -ll". >> It spends many CPU time and memories. >> >> Just font name format should be supported. > > Not clear enough for me. > > -phil. >> >> To SAP representative, >> I have a question about copyright year on >> make/data/fontconfig/aix.fontconfig.properties. >> Please let me know how I should write down copyright year. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >>
Hello. Could you review the fix and give me your suggestion, please ? I really appreciate your feedback. Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 And I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-05-14 21:13, Ichiroh Takiguchi wrote:
Hello Phil. I appreciate your comment.
I tried to debug this issue from another side. I checked fontconfig.properties file by CompileFontConfig (.bfc build tool) with -verbose option [1] Following messages were displayed: Note: 'filename' entry is undefined for "-monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0" ... I could find out encoding name has "_" character. And '_' -> ' ' conversion was in FontConfiguration.
I applied following fixes: src/java.desktop/share/classes/sun/awt/FontConfiguration.java * '_' -> ' ' conversion only applies before PIXEL_SIZE field on XLFD * fontconfig.bfc is built by boot compiler, so above fix does not affect. After reading fontconfig.bfc, data need to be modified src/java.desktop/unix/classes/sun/awt/X11FontManager.java * Fix typo for logging output
Could you review the fix again ?
Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
[1] https://bugs.openjdk.java.net/browse/JDK-8221741
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-26 05:41, Phil Race wrote:
I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file.
Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms.
Also I am puzzled when I see this : 449 && "FILE_NAMES_ALIASES".equals(st.sval)) {
and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html
I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in a random place, and your code is broken.
-phil.
On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote:
(Sorry, please ignore previous mail, it has wrong link for "Change")
Hello Phil.
I appreciate your suggestion.
I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font.
On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility.
On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames,
int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote:
On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ?
-phil.
On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: > Hello Phil. > > I appreciate your reply. > I put problem analysis information in JDK-8221741 [1]. > > The issue is AIX's Xserver was frozen about 25 secs on my local > AIX box. > According to my problem analysis, > In this case, Java tried to load large 11 X11 bitmap fonts via > XLoadQueryFont() on Xlib. > The situation can emulate by "xlsfonts -ll" command, like: > > $ time xlsfonts -ll -fn > "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" > ... > real 0m2.07s > user 0m0.00s > sys 0m0.00s > > One of solution is, Unix's fontconfig.properties can support > TrueType/Type1 font name format. [2] > > Anyway, > I don't know the reason why X11 bitmap font is required for > logical font. > (I don't know how to use X11 bitmap font for physical font. > I could not see X11 bitmap font name via > GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) > I just want to fix Xserver frozen issue. > I appreciate your advice. > (Other solutions are welcome) > > [1] https://bugs.openjdk.java.net/browse/JDK-8221741 > [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-04-04 01:09, Philip Race wrote: >> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>> Hello. >>> (I am sorry to post it again. Previously, I posted the wrong >>> mailing list.) >>> >>> Could you review the fix ? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>> Change: >>> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> On AIX platform, fontconfig.properties file is used to pick up >>> proper fonts. >>> TrueType font settings are written by XLFD format on >>> fontconfig.properties file. >>> >>> On current implementation, Java tries to load X11 bitmap fonts >>> even if these are not used. >> >> I think you need to clarify what you mean here. >> >> I'd like you to provide a step by step analysis of what happens >> and >> what the effect of your proposed change is on AIX *AND* what it >> might >> mean for other X11 platforms, as I don't have time to reverse >> engineer the >> reasons for the odd-looking change. >> It looks like a hack to short-circuit support your syntax. >> Right now I am saying no to this. >> >>> This font load work is almost name as "xlsfonts -ll". >>> It spends many CPU time and memories. >>> >>> Just font name format should be supported. >> >> Not clear enough for me. >> >> -phil. >>> >>> To SAP representative, >>> I have a question about copyright year on >>> make/data/fontconfig/aix.fontconfig.properties. >>> Please let me know how I should write down copyright year. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >
Hello. Could you review the fix and give me your suggestion, please ? I'd like to put some solution into JDK13 for this issue. Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 And I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-05-24 21:55, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix and give me your suggestion, please ? I really appreciate your feedback.
Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
And I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-05-14 21:13, Ichiroh Takiguchi wrote:
Hello Phil. I appreciate your comment.
I tried to debug this issue from another side. I checked fontconfig.properties file by CompileFontConfig (.bfc build tool) with -verbose option [1] Following messages were displayed: Note: 'filename' entry is undefined for "-monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0" ... I could find out encoding name has "_" character. And '_' -> ' ' conversion was in FontConfiguration.
I applied following fixes: src/java.desktop/share/classes/sun/awt/FontConfiguration.java * '_' -> ' ' conversion only applies before PIXEL_SIZE field on XLFD * fontconfig.bfc is built by boot compiler, so above fix does not affect. After reading fontconfig.bfc, data need to be modified src/java.desktop/unix/classes/sun/awt/X11FontManager.java * Fix typo for logging output
Could you review the fix again ?
Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
[1] https://bugs.openjdk.java.net/browse/JDK-8221741
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-26 05:41, Phil Race wrote:
I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file.
Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms.
Also I am puzzled when I see this : 449 && "FILE_NAMES_ALIASES".equals(st.sval)) {
and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html
I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in a random place, and your code is broken.
-phil.
On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote:
(Sorry, please ignore previous mail, it has wrong link for "Change")
Hello Phil.
I appreciate your suggestion.
I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font.
On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility.
On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames,
int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself)
To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed
"AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) at sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) ...
I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
Thanks, Ichiroh Takiguchi
On 2019-04-19 05:20, Phil Race wrote: > On startup ? > What is the Java stack trace that gets you into that call ? > Is it this with any modified IBM code, or pure OpenJDK ? > > -phil. > > On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I appreciate your reply. >> I put problem analysis information in JDK-8221741 [1]. >> >> The issue is AIX's Xserver was frozen about 25 secs on my local >> AIX box. >> According to my problem analysis, >> In this case, Java tried to load large 11 X11 bitmap fonts via >> XLoadQueryFont() on Xlib. >> The situation can emulate by "xlsfonts -ll" command, like: >> >> $ time xlsfonts -ll -fn >> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >> ... >> real 0m2.07s >> user 0m0.00s >> sys 0m0.00s >> >> One of solution is, Unix's fontconfig.properties can support >> TrueType/Type1 font name format. [2] >> >> Anyway, >> I don't know the reason why X11 bitmap font is required for >> logical font. >> (I don't know how to use X11 bitmap font for physical font. >> I could not see X11 bitmap font name via >> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >> I just want to fix Xserver frozen issue. >> I appreciate your advice. >> (Other solutions are welcome) >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-04-04 01:09, Philip Race wrote: >>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>> Hello. >>>> (I am sorry to post it again. Previously, I posted the wrong >>>> mailing list.) >>>> >>>> Could you review the fix ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> Change: >>>> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> On AIX platform, fontconfig.properties file is used to pick up >>>> proper fonts. >>>> TrueType font settings are written by XLFD format on >>>> fontconfig.properties file. >>>> >>>> On current implementation, Java tries to load X11 bitmap fonts >>>> even if these are not used. >>> >>> I think you need to clarify what you mean here. >>> >>> I'd like you to provide a step by step analysis of what happens >>> and >>> what the effect of your proposed change is on AIX *AND* what it >>> might >>> mean for other X11 platforms, as I don't have time to reverse >>> engineer the >>> reasons for the odd-looking change. >>> It looks like a hack to short-circuit support your syntax. >>> Right now I am saying no to this. >>> >>>> This font load work is almost name as "xlsfonts -ll". >>>> It spends many CPU time and memories. >>>> >>>> Just font name format should be supported. >>> >>> Not clear enough for me. >>> >>> -phil. >>>> >>>> To SAP representative, >>>> I have a question about copyright year on >>>> make/data/fontconfig/aix.fontconfig.properties. >>>> Please let me know how I should write down copyright year. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>
Hello Could you review the fix ? Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 I applied following changes: -- make/data/fontconfig/aix.fontconfig.properties * XLFD font name should be in fonts.dir * Use East Asian TrueType fonts for non UTF-8 CJK locales * Change encoding name for zh_CN (x-IBM1383) and zh_TW (x-IBM950) locale * Add taiwanese entries to support East Asian TrueType fonts * Add Unicode font into Thai UTF-8 locale * Unicode font's encoding name is changed to iso10646-1, because previous encoding name has underscore character -- src/java.desktop/share/classes/sun/font/SunFontManager.java If font file (which is defined into fontconfig.properties file) is missing, default physical font is used. But Java refers "dialog" font, then ClassCastException is happened. To avoid ClassCastException, set Dialog font's slot 0 font to default physical font Thanks, Ichiroh Takiguchi On 2019-06-04 01:33, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix and give me your suggestion, please ? I'd like to put some solution into JDK13 for this issue.
Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
And I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-05-24 21:55, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix and give me your suggestion, please ? I really appreciate your feedback.
Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
And I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-05-14 21:13, Ichiroh Takiguchi wrote:
Hello Phil. I appreciate your comment.
I tried to debug this issue from another side. I checked fontconfig.properties file by CompileFontConfig (.bfc build tool) with -verbose option [1] Following messages were displayed: Note: 'filename' entry is undefined for "-monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0" ... I could find out encoding name has "_" character. And '_' -> ' ' conversion was in FontConfiguration.
I applied following fixes: src/java.desktop/share/classes/sun/awt/FontConfiguration.java * '_' -> ' ' conversion only applies before PIXEL_SIZE field on XLFD * fontconfig.bfc is built by boot compiler, so above fix does not affect. After reading fontconfig.bfc, data need to be modified src/java.desktop/unix/classes/sun/awt/X11FontManager.java * Fix typo for logging output
Could you review the fix again ?
Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
[1] https://bugs.openjdk.java.net/browse/JDK-8221741
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-26 05:41, Phil Race wrote:
I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file.
Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms.
Also I am puzzled when I see this : 449 && "FILE_NAMES_ALIASES".equals(st.sval)) {
and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html
I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in a random place, and your code is broken.
-phil.
On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote:
(Sorry, please ignore previous mail, it has wrong link for "Change")
Hello Phil.
I appreciate your suggestion.
I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font.
On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility.
On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/
I'd like to obtain a sponsor for this issue.
Thanks, Ichiroh Takiguchi
On 2019-04-20 03:55, Phil Race wrote:
Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason.
protected void registerFontFile(String fontFileName, String[] nativeNames,
int fontRank, boolean defer) { // REMIND: case compare depends on platform if (registeredFontFiles.contains(fontFileName)) { return; } int fontFormat; if (ttFilter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TRUETYPE; } else if (t1Filter.accept(null, fontFileName)) { fontFormat = FONTFORMAT_TYPE1; } else { fontFormat = FONTFORMAT_NATIVE; /// <<<<< I think you are getting here, but why ? }
-phil.
On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: > Hello Phil. > > I'm using standard OpenJDK JDK13 b13 for AIX, like: > openjdk version "13-internal" 2019-09-17 > OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) > OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed > mode) > (Compiled it by myself) > > To see stack trace, I tried following instruction: > 1. Login to AIX box from another machine > 2. Login to AIX box from AIX CDE on local AIX box Japanese > locale (Ja_JP) or C locale > 3. Open terminal, like dtterm on local AIX box > 4. Start SwingSet2 demo program > 5. Check java's process id > 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side > 7. Move mouse cursor on cow image to display ToolTip > 8. Keep moving the mouse cursor slowly, mouse cursor may be > stopped > (I said this situation was "frozen".) > 9. After Xserver was frozen, execute "kill -3" with java > process id > 10. Then stack trace is displayed > > "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms > elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable > [0x0000000114159000] > java.lang.Thread.State: RUNNABLE > at > sun.font.NativeFont.countGlyphs(java.desktop@13-internal/Native > Method) > at > sun.font.NativeFont.getNumGlyphs(java.desktop@13-internal/NativeFont.java:312) > at > sun.font.NativeFont.<init>(java.desktop@13-internal/NativeFont.java:90) > at > sun.font.SunFontManager.registerFontFile(java.desktop@13-internal/SunFontManager.java:1023) > at > sun.font.SunFontManager.initialiseDeferredFont(java.desktop@13-internal/SunFontManager.java:946) > ... > > I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot > JVM. > > Thanks, > Ichiroh Takiguchi > > On 2019-04-19 05:20, Phil Race wrote: >> On startup ? >> What is the Java stack trace that gets you into that call ? >> Is it this with any modified IBM code, or pure OpenJDK ? >> >> -phil. >> >> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> I appreciate your reply. >>> I put problem analysis information in JDK-8221741 [1]. >>> >>> The issue is AIX's Xserver was frozen about 25 secs on my local >>> AIX box. >>> According to my problem analysis, >>> In this case, Java tried to load large 11 X11 bitmap fonts via >>> XLoadQueryFont() on Xlib. >>> The situation can emulate by "xlsfonts -ll" command, like: >>> >>> $ time xlsfonts -ll -fn >>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>> ... >>> real 0m2.07s >>> user 0m0.00s >>> sys 0m0.00s >>> >>> One of solution is, Unix's fontconfig.properties can support >>> TrueType/Type1 font name format. [2] >>> >>> Anyway, >>> I don't know the reason why X11 bitmap font is required for >>> logical font. >>> (I don't know how to use X11 bitmap font for physical font. >>> I could not see X11 bitmap font name via >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>> I just want to fix Xserver frozen issue. >>> I appreciate your advice. >>> (Other solutions are welcome) >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2019-04-04 01:09, Philip Race wrote: >>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>> mailing list.) >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> Change: >>>>> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> On AIX platform, fontconfig.properties file is used to pick >>>>> up proper fonts. >>>>> TrueType font settings are written by XLFD format on >>>>> fontconfig.properties file. >>>>> >>>>> On current implementation, Java tries to load X11 bitmap >>>>> fonts even if these are not used. >>>> >>>> I think you need to clarify what you mean here. >>>> >>>> I'd like you to provide a step by step analysis of what >>>> happens and >>>> what the effect of your proposed change is on AIX *AND* what >>>> it might >>>> mean for other X11 platforms, as I don't have time to reverse >>>> engineer the >>>> reasons for the odd-looking change. >>>> It looks like a hack to short-circuit support your syntax. >>>> Right now I am saying no to this. >>>> >>>>> This font load work is almost name as "xlsfonts -ll". >>>>> It spends many CPU time and memories. >>>>> >>>>> Just font name format should be supported. >>>> >>>> Not clear enough for me. >>>> >>>> -phil. >>>>> >>>>> To SAP representative, >>>>> I have a question about copyright year on >>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>> Please let me know how I should write down copyright year. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>> >
participants (3)
-
Ichiroh Takiguchi
-
Phil Race
-
Philip Race