Bug 485916

Summary:	Openoffice.org is very sluggish due to glyph replacement
Product:	[Fedora] Fedora	Reporter:	r6144 <rainy6144>
Component:	openoffice.org	Assignee:	Caolan McNamara <caolanm>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	10	CC:	caolanm, jnavrati
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-02-17 14:18:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.