Bug 485916 - Openoffice.org is very sluggish due to glyph replacement
Summary: Openoffice.org is very sluggish due to glyph replacement
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-17 13:33 UTC by r6144
Modified: 2009-02-17 14:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-17 14:18:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description r6144 2009-02-17 13:33:13 UTC
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 13:46:52 UTC
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 14:18:28 UTC
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.