Issue 83554

Summary: performance: svx::HangulHanjaConversion is way too expensive
Product: Writer Reporter: hdu <hdu>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: ahz001, issues, nesshof
Version: OOo 2.3   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 83491    

Description 2007-11-12 10:07:28 UTC
Issue 83491 complains about massive performance regressions even though the CWS that introduced it 
made text layout only a little bit more costly.

Analyzing the situation showed that the whole textbox is reformatted from top to bottom for every 
single replaced codepoint! This causes quite some sluggishness. It would be better to convert whole 
paragraphs or even the whole document at once and reformat then.

Here is the backtrace of the performance problem, which may be helpful to find the culprit of the 
excessive reformats:

#0  OutputDevice::GetTextArray (this=0xaed451d8, rStr=@0xaace00c0, pDXAry=0xabed71ec, 
nIndex=0, nLen=4)
#1  0xb1c4bf43 in SvxFont::QuickGetTextSize (this=0xbfc69128, pOut=0xaed451d8, 
rTxt=@0xaace00c0, nIdx=0, nLen=4, pDXArray=0xabed71ec)
#2  0xb1cbe316 in ImpEditEngine::CreateLines (this=0xaad56d94, nPara=0, nStartPosY=0) at ./
#3  0xb1cbf89e in ImpEditEngine::FormatDoc (this=0xaad56d94) at ./editdoc.hxx:593
#4  0xb1cc280a in ImpEditEngine::FormatAndUpdate (this=0xaad56d94, pCurView=0xaab8e36c) at 
#5  0xb1c99492 in EditView::SetAttribs (this=0xaab8e36c, rSet=@0xaf2a7490) at svx/source/editeng/
#6  0xb1ccedec in TextConvWrapper::ChangeText_impl (this=0xbfc6963c, rNewText=@0xbfc69344, 
bKeepAttributes=1 '\001') at svx/source/editeng/textconv.cxx:624
#7  0xb1ccefaf in TextConvWrapper::ChangeText (this=0xbfc6963c, rNewText=@0xbfc693b8, 
rOrigText=@0xabd75450, pOffsets=0x1, pESelection=0xbfc693a8) at svx/source/editeng/
#8  0xb1ccf29a in TextConvWrapper::ReplaceUnit (this=0xbfc6963c, nUnitStart=0, 
nUnitEnd=-1077505096, rOrigText=@0xabd75450, rReplaceWith=@0xaacd68fc,
    rOffsets=@0xbfc6945c, eAction=svx::HangulHanjaConversion::eExchange, 
pNewUnitLanguage=0xbfc6945a) at svx/source/editeng/textconv.cxx:446
#9  0xb1d0cb4a in svx::HangulHanjaConversion_Impl::implChange (this=0xabd753f0, 
    at svx/source/dialog/hangulhanja.cxx:916
#10 0xb1d0cdb5 in svx::HangulHanjaConversion_Impl::ContinueConversion (this=0xabd753f0, 
#11 0xb1d0d263 in svx::HangulHanjaConversion_Impl::DoDocumentConversion (this=0xabd753f0) at 
#12 0xb1d0d283 in svx::HangulHanjaConversion::ConvertDocument (this=0xaf2a7490) at
#13 0xb1ccf401 in TextConvWrapper::Convert (this=0xbfc6963c) at svx/source/editeng/textconv.cxx:
#14 0xb1cc6d06 in ImpEditEngine::Convert (this=0xaad56d94, pEditView=0xaab8e36c, 
nSrcLang=1028, nDestLang=2052, pDestFont=0xbfc69888, nOptions=1,
    bIsInteractive=0 '\0', bMultipleDoc=1 '\001') at svx/source/editeng/impedit4.cxx:1651
#15 0xb1c9a68c in EditView::StartTextConversion (this=0xaed4529c, nSrcLang=1028, nDestLang=0, 
pDestFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0',
    bMultipleDoc=1 '\001') at svx/source/editeng/editview.cxx:1062
#16 0xb1ce16e4 in OutlinerView::StartTextConversion (this=0xaf2a7490, nSrcLang=1028, 
nDestLang=21148, pDestFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0',
    bMultipleDoc=1 '\001') at svx/source/outliner/outlvw.cxx:1375
#17 0xae1b41bd in sd::Outliner::StartConversion (this=0xabd81800, nSourceLanguage=1028, 
nTargetLanguage=2052, pTargetFont=0xbfc69888, nOptions=1,
    bIsInteractive=0 '\0') at sd/source/ui/view/Outliner.cxx:1658
#18 0xae3b47c0 in sd::FuHangulHanjaConversion::StartConversion (this=0xabeca48c, 
nSourceLanguage=1028, nTargetLanguage=2052, pTargetFont=0xbfc69888,
    nOptions=1, bIsInteractive=0 '\0') at sd/source/ui/func/fuhhconv.cxx:185
#19 0xae3b5368 in sd::FuHangulHanjaConversion::StartChineseConversion (this=0xabeca48c) at sd/
Comment 1 2007-11-12 10:13:00 UTC
Comment 2 thomas.lange 2007-11-12 10:25:28 UTC
Comment 3 thomas.lange 2007-11-14 12:15:57 UTC
TL: According to HDU the performance problem splits like this:
- ~30% due to painting
- ~65% due to formatting

According to AF the formatting problem can not be fixed in a reasonable time
frame. It is likely to require a complete new implementation of the interaction
between sd and EditEngine/Outliner.

Changing target to OOo later.
Comment 4 2007-11-22 13:31:58 UTC
@TL: on a second thought the problem SSA describes in issue 83491 was caused by this issue, even 
though even though the CPU load caused by it only 30% of the problem workload: In the test scenario 
there was an X11 server without XRENDER extension involved and repainting antialiased text in this 
context is limited by the round trip latencies from/to the X11 server. The resulting timeout of the testtool 
on this test is a result of the cumulative latencies. It would be great if repaints could be reduced or even 
be completely avoided while doing the text conversion.
Comment 5 2007-11-22 14:22:57 UTC
Correction to my comment above:"the problem SBA describes" instead of "the problem SSA describes"

As agreed with TL the target milestone needs to be adjusted because the scenario mentioned above (X11 
without XRENDER) is still too important. TL: feel free to adjust the target again if necessary
Comment 6 thomas.lange 2008-01-14 13:58:55 UTC
No more issues accepted for OOo 2.4 unless there are serious problems.
Comment 7 thomas.lange 2008-06-09 13:31:58 UTC
Comment 8 Mathias_Bauer 2008-07-14 14:29:28 UTC
Missed 3.0 code freeze, no showstopper -> 3.1
Comment 9 thomas.lange 2009-01-30 10:54:24 UTC
As discussed with SBA setting target to OOo 3.2 since this one is not that easy
to fix and test with its potential implications. And thus making a quick fix for
3.1 should be avoided.
Comment 10 thomas.lange 2009-10-12 12:59:38 UTC
Comment 11 thomas.lange 2010-08-18 07:50:22 UTC
No showstopper, setting target to 3.4