[OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties
Ichiroh Takiguchi
takiguc at linux.vnet.ibm.com
Tue May 14 12:13:33 UTC 2019
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 at 13-internal/Native
>>>> Method)
>>>> at
>>>> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312)
>>>> at
>>>> sun.font.NativeFont.<init>(java.desktop at 13-internal/NativeFont.java:90)
>>>> at
>>>> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023)
>>>> at
>>>> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946)
>>>> ...
>>>>
>>>> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM.
>>>>
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>>
>>>> On 2019-04-19 05:20, Phil Race wrote:
>>>>> On startup ?
>>>>> What is the Java stack trace that gets you into that call ?
>>>>> Is it this with any modified IBM code, or pure OpenJDK ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote:
>>>>>> Hello Phil.
>>>>>>
>>>>>> I appreciate your reply.
>>>>>> I put problem analysis information in JDK-8221741 [1].
>>>>>>
>>>>>> The issue is AIX's Xserver was frozen about 25 secs on my local
>>>>>> AIX box.
>>>>>> According to my problem analysis,
>>>>>> In this case, Java tried to load large 11 X11 bitmap fonts via
>>>>>> XLoadQueryFont() on Xlib.
>>>>>> The situation can emulate by "xlsfonts -ll" command, like:
>>>>>>
>>>>>> $ time xlsfonts -ll -fn
>>>>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0"
>>>>>> ...
>>>>>> real 0m2.07s
>>>>>> user 0m0.00s
>>>>>> sys 0m0.00s
>>>>>>
>>>>>> One of solution is, Unix's fontconfig.properties can support
>>>>>> TrueType/Type1 font name format. [2]
>>>>>>
>>>>>> Anyway,
>>>>>> I don't know the reason why X11 bitmap font is required for
>>>>>> logical font.
>>>>>> (I don't know how to use X11 bitmap font for physical font.
>>>>>> I could not see X11 bitmap font name via
>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().)
>>>>>> I just want to fix Xserver frozen issue.
>>>>>> I appreciate your advice.
>>>>>> (Other solutions are welcome)
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741
>>>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>> IBM Japan, Ltd.
>>>>>>
>>>>>> On 2019-04-04 01:09, Philip Race wrote:
>>>>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote:
>>>>>>>> Hello.
>>>>>>>> (I am sorry to post it again. Previously, I posted the wrong
>>>>>>>> mailing list.)
>>>>>>>>
>>>>>>>> Could you review the fix ?
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741
>>>>>>>> Change:
>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/
>>>>>>>>
>>>>>>>> I'd like to obtain a sponsor for this issue.
>>>>>>>>
>>>>>>>> On AIX platform, fontconfig.properties file is used to pick up
>>>>>>>> proper fonts.
>>>>>>>> TrueType font settings are written by XLFD format on
>>>>>>>> fontconfig.properties file.
>>>>>>>>
>>>>>>>> On current implementation, Java tries to load X11 bitmap fonts
>>>>>>>> even if these are not used.
>>>>>>>
>>>>>>> I think you need to clarify what you mean here.
>>>>>>>
>>>>>>> I'd like you to provide a step by step analysis of what happens
>>>>>>> and
>>>>>>> what the effect of your proposed change is on AIX *AND* what it
>>>>>>> might
>>>>>>> mean for other X11 platforms, as I don't have time to reverse
>>>>>>> engineer the
>>>>>>> reasons for the odd-looking change.
>>>>>>> It looks like a hack to short-circuit support your syntax.
>>>>>>> Right now I am saying no to this.
>>>>>>>
>>>>>>>> This font load work is almost name as "xlsfonts -ll".
>>>>>>>> It spends many CPU time and memories.
>>>>>>>>
>>>>>>>> Just font name format should be supported.
>>>>>>>
>>>>>>> Not clear enough for me.
>>>>>>>
>>>>>>> -phil.
>>>>>>>>
>>>>>>>> To SAP representative,
>>>>>>>> I have a question about copyright year on
>>>>>>>> make/data/fontconfig/aix.fontconfig.properties.
>>>>>>>> Please let me know how I should write down copyright year.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ichiroh Takiguchi
>>>>>>>> IBM Japan, Ltd.
>>>>>>>>
>>>>>>
>>>>
>>
More information about the ppc-aix-port-dev
mailing list