Issue 83491

Summary: Massive performance problem due to use of system font config
Product: gsl Reporter: stefan.baltzer
Component: codeAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@gsl <issues>
Severity: Trivial    
Priority: P3 CC: fonts-bugs, issues, rene
Version: current   
Target Milestone: OOo 2.4   
Hardware: All   
OS: Unix, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on: 83554, 83553    
Issue Blocks:    
Attachments:
Description Flags
Writer doc with chinese (trad.) text in text body and draw text box
none
bugdoc which actually exhibits the problem none

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 hdu@apache.org 2007-11-09 12:13:36 UTC
accepting.
Comment 3 hdu@apache.org 2007-11-09 13:00:32 UTC
Caching the result of the expensive calls to fontconfig would help, but it can easily introduce 
inconsistencies:
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 hdu@apache.org 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 hdu@apache.org 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 hdu@apache.org 2007-11-13 15:22:43 UTC
Created attachment 49633 [details]
bugdoc which actually exhibits the problem
Comment 7 hdu@apache.org 2007-11-14 12:47:32 UTC
@sba: please verify in the rebuilt CWS.
Comment 8 hdu@apache.org 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.