|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Massive performance problem due to use of system font config | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | gsl | Reporter: | stefan.baltzer | ||||||
| Component: | code | Assignee: | 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
stefan.baltzer
2007-11-09 11:37:23 UTC
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. |