Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Massive performance problem due to use of system font config|
|Status:||CLOSED FIXED||QA Contact:||issues@gsl <issues>|
|Priority:||P3||CC:||fonts-bugs, issues, rene|
|Target Milestone:||OOo 2.4|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||83554, 83553|
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 email@example.com 2007-11-09 12:13:36 UTC
Comment 3 firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 email@example.com 2007-11-13 15:22:43 UTC
Created attachment 49633 [details] bugdoc which actually exhibits the problem
Comment 7 firstname.lastname@example.org 2007-11-14 12:47:32 UTC
@sba: please verify in the rebuilt CWS.
Comment 8 email@example.com 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.