Bug 485916 - Openoffice.org is very sluggish due to glyph replacement
Openoffice.org is very sluggish due to glyph replacement
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-17 08:33 EST by r6144
Modified: 2009-02-17 09:18 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-17 09:18:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description r6144 2009-02-17 08:33:13 EST
Description of problem:

Openoffice.org sometimes freezes for 1-5 seconds with 100% CPU usage whenever switching focus or accessing the menu.  This seems to happen most often when Chinese fonts are involved, e.g. when LANG is set to zh_CN.UTF-8 or when a Chinese file is being edited.  Oprofile shows that most of the CPU time is spent in fontconfig, and the debug output from FC_DEBUG=1 suggests that there are indeed a lot of fontconfig calls.

Version-Release number of selected component (if applicable):
openoffice.org-core-3.0.1-15.2.fc10.i386
fontconfig-2.6.0-3.fc10.i386

How reproducible:
Reproducible on my machine, but might be dependent on fonts.conf and the available fonts.

Steps to Reproduce:
1. Install some font packages and the Chinese language pack for OO.o.
2. Start oowriter with LANG=zh_CN.UTF-8
  
Actual results:
There are one-second delays whenever accessing the Chinese menus due to fontconfig.

Expected results:
Fontconfig should not take so much CPU time.

Additional info:
oprofile in Fedora 10 does not currently work, likely due to some binutils bug.  I'm using Fedora 9's version of it, but even then I can't get call-graph profiling to work, so I don't know where the fontconfig calls come from.
Comment 1 r6144 2009-02-17 08:46:52 EST
The slowness seems to occur only when Openoffice is trying to display Chinese text with a non-Chinese font, e.g. when displaying a Chinese document with the Asian text font set to DejaVu (which happens to be the default).  The text is still displayed correctly (likely with some Chinese font chosen by Fontconfig), but only very slowly.  The slowness goes away when I set the Asian text font to a Chinese font.

The UI slowness when LANG=zh_CN.UTF-8 is probably due to the same reason.
Comment 2 Caolan McNamara 2009-02-17 09:18:28 EST
Yes, glyph replacement is very slow for CJK. Its not going to really get much
faster than it already is (though it will be a little faster in 3.1 in F-11).
The best thing to do is to simply set your font to a CJK font. If the font
doesn't have CJK glyphs but those are required for display, then every chunk of
text has to go through the process of finding something that can display it.

I think that if you actually *login* as a zh_CN locale you may get a font better tweaked towards CJK coverage as the default UI font for GNOME (and OOo) apps.

Note You need to log in before you can comment on or make changes to this bug.