Issue 83491 - Massive performance problem due to use of system font config
Summary: Massive performance problem due to use of system font config
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All Unix, all
: P3 Trivial (vote)
Target Milestone: OOo 2.4
Assignee: stefan.baltzer
QA Contact: issues@gsl
Depends on: 83554 83553
  Show dependency tree
Reported: 2007-11-09 11:37 UTC by stefan.baltzer
Modified: 2008-02-26 17:07 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Writer doc with chinese (trad.) text in text body and draw text box (15.84 KB, application/vnd.sun.xml.writer)
2007-11-09 11:46 UTC, stefan.baltzer
no flags Details
bugdoc which actually exhibits the problem (9.58 KB, application/
2007-11-13 15:22 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description stefan.baltzer 2007-11-09 11:37:23 UTC
SBA: Note: Found by Autotest "d_update.bas"
Best to be seen on Solaris:
 - Ensure that CJK support is enabled (toosl-options-language
settings-languages...), OK
 - Load attached bugdoc (1-page Writer doc with Chinese (trad) text in Writer
text body and in Draw text box)
 - (via menu) Tools-Languages-Chinese translation
 - Choose "Traditional to Simplified"
 - Click OK
 - [now the respective Chinese (trad.) characters get replaced by Chinese (simp.)]
-> The character replacement is very slow (now several minutes compared to
several seconds for the entire document in master). During replacement, massive
repaint problems. After replacement is finished, office is not responsive for
several minutes.
Comment 1 stefan.baltzer 2007-11-09 11:46:32 UTC
Created attachment 49550 [details]
Writer doc with chinese (trad.) text in text body and draw text box
Comment 2 2007-11-09 12:13:36 UTC
Comment 3 2007-11-09 13:00:32 UTC
Caching the result of the expensive calls to fontconfig would help, but it can easily introduce 
1. document with string "AB" in fontX (which doesn't support A,B,C)
2. asking fontconfig results in fontY (which supports A,B)
3. a cache from font+char to fallback gets updated with "fontX+A->fontY" and "fontX+B->fontY"
4. user edits the document to "BC"
5. asking the cache would return "fontX+B->fontY"
6. asking fontconfig directly could result in fontZ (which supports B and C)
7. when fontX is changed a little to fontX' (e.g. zooming in, underlining, stretching)
8. the new fontX' cache would be initialized to fontZ
=> reformatting is needed, etc.

And even with this problematic approach the cache can grow huge very fast, e.g. when zooming, 
rotating, stretching, even though in many cases the fontX cache would be identical to a fontX' cache. 
Since only fontconfig knows if there are rules that change the fallback depending on the size, slant, etc. 
there are easily scenarios where the performance problem can hit us again if fontconfig doesn't make 
the calls less expensive and also doesn't provide a way to avoid these calls. 
Comment 4 2007-11-12 10:09:45 UTC
Though the performance regression was introduced by this CWS the root cause of the performance 
problem is in the layers above:
- see issue 83554 for why the whole text gets reformatted from top to bottom 77 times, which seems 
quite excessive for an operation that could/should be done by one string replacement and one reformat
- see issue 83553 about the problem that SdrView reformats the whole text from top to bottom for every 
single mouse move event!
Comment 5 2007-11-13 15:16:26 UTC
The CWS had some superfluous font cache misses which resulted in expensive font substitution lookups. 
These unneeded misses were caused by cache key string was not normalized. This is now fixed in the 
CWS. The many unneeded full reformats are still a problem, but the performance after the fix looks 
acceptable now.

@sba: the document you attached (i83491_tchinese_text.odt) doesn't exhibit the problem, because Writer 
only reformats once for the traditional->simplified conversion. Only when this is pasted into a Draw 
textbox the problem you described can be reproduced.
Comment 6 2007-11-13 15:22:43 UTC
Created attachment 49633 [details]
bugdoc which actually exhibits the problem
Comment 7 2007-11-14 12:47:32 UTC
@sba: please verify in the rebuilt CWS.
Comment 8 2007-12-04 13:48:07 UTC
@SBA: please verify in the CWS
Comment 9 stefan.baltzer 2007-12-10 12:49:03 UTC
SBA: Verified in CWS gfbfcfg (Built on 680_m238).
Comment 10 stefan.baltzer 2008-02-26 17:07:20 UTC
SBA: OK in OOH_m7. Closed.