Apache OpenOffice (AOO) Bugzilla – Issue 83491
Massive performance problem due to use of system font config
Last modified: 2008-02-26 17:07:20 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.
Created attachment 49550 [details] Writer doc with chinese (trad.) text in text body and draw text box
accepting.
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.
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!
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.
Created attachment 49633 [details] bugdoc which actually exhibits the problem
@sba: please verify in the rebuilt CWS.
@SBA: please verify in the CWS
SBA: Verified in CWS gfbfcfg (Built on 680_m238).
SBA: OK in OOH_m7. Closed.