Issue 83553 - performance: excessive reformatting in textboxes when mouse moves
Summary: performance: excessive reformatting in textboxes when mouse moves
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: OOo 2.3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: Armin Le Grand
QA Contact: issues@graphics
Depends on:
Blocks: 83491
  Show dependency tree
Reported: 2007-11-12 09:51 UTC by
Modified: 2009-08-03 12:22 UTC (History)
6 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description 2007-11-12 09:51:07 UTC
Issue 83491 complains about massive performance regressions even though the CWS that introduced it 
made text layout a little bit more costly. Analyzing the situation showed that the whole textbox is 
completely reformatted from top to bottom for every single mouse move event! This causes quite some 
sluggishness. It seems SdrTextObj is at fault.

#0  OutputDevice::GetTextArray (this=0xaed451d8, rStr=@0xae5bc378, pDXAry=0xabe9c730, 
nIndex=0, nLen=37)
#1  0xb1c4bf43 in SvxFont::QuickGetTextSize (this=0xbfc68d20, pOut=0xaed451d8, 
rTxt=@0xae5bc378, nIdx=0, nLen=37, pDXArray=0xabe9c730)
#2  0xb1cbe316 in ImpEditEngine::CreateLines (this=0xae5cbd60, nPara=0, nStartPosY=0) at ./
#3  0xb1cbf89e in ImpEditEngine::FormatDoc (this=0xae5cbd60) at ./editdoc.hxx:593
#4  0xb1cbfcb4 in ImpEditEngine::FormatFullDoc (this=0xae5cbd60) at svx/source/editeng/
#5  0xb1c8aca3 in EditEngine::SetPaperSize (this=0xb324a948, rNewSize=@0xbfc68f34) at svx/
#6  0xb1cde241 in Outliner::SetPaperSize (this=0xad699718, rSize=@0xbfc68f34) at svx/source/
#7  0xb1aac3b7 in SdrTextObj::TakeTextRect (this=0xadf72d38, rOutliner=@0xae886c24, 
rTextRect=@0xbfc69044, bNoEditText=0, pAnchorRect=0xbfc69054, 
    bLineWidth=0 '\0') at svx/source/svdraw/svdotext.cxx:971
#8  0xb1aa8db4 in SdrTextObj::CheckHit (this=0xadf72d38, rPnt=@0xbfc692b8, nTol=96, 
pVisiLayer=0x157) at svx/source/svdraw/svdotext.cxx:1549
#9  0xb1ab42f9 in SdrRectObj::ImpCheckHit (this=0xadf72d38, rPnt=@0xbfc692b8, nTol=96, 
pVisiLayer=0xad68c58e, bForceFilled=0, bForceTol=0)
    at svx/source/svdraw/svdorect.cxx:525
#10 0xb1ab4330 in SdrRectObj::CheckHit (this=0xadf72d38, rPnt=@0xbfc692b8, nTol=38680, 
    at svx/source/svdraw/svdorect.cxx:532
#11 0xb1a5ccaf in SdrMarkView::ImpCheckObjHit (this=0xaf26920c, rPnt=@0xbfc692b8, nTol=96, 
pObj=0xadf72d38, pPV=0xad68c544, nOptions=7, pMVisLay=0x0)
    at ../../inc/svx/svdpagv.hxx:275
#12 0xb1a5cab1 in SdrMarkView::ImpCheckObjHit (this=0xaf26920c, rPnt=@0xbfc692b8, nTol=96, 
pOL=0xae5a4ad8, pPV=0xad68c544, nOptions=7, pMVisLay=0x0, 
    rpRootObj=@0xbfc692b4) at svx/source/svdraw/svdmrkv.cxx:1639
#13 0xb1a5d065 in SdrMarkView::PickObj (this=0xaf26920c, rPnt=@0x1, nTol=96, 
rpObj=@0xbfc6940c, rpPV=@0xbfc69414, nOptions=7, ppRootObj=0xbfc69410, 
    pnMarkNum=0xad68c544, pnPassNum=0xbfc694f6) at svx/source/svdraw/svdmrkv.cxx:1732
#14 0xb1a90fb5 in SdrView::PickAnything (this=0xaf26920c, rLogicPos=@0xad699718, 
rVEvt=@0xbfc6959c) at svx/source/svdraw/svdview.cxx:411
#15 0xb1a920e8 in SdrView::PickAnything (this=0xaf26920c, rMEvt=@0xabf96668, 
nEventKind=38680, rVEvt=@0xbfc6959c)
    at svx/source/svdraw/svdview.cxx:342
#16 0xae3b9d6b in sd::FuDraw::ForcePointer (this=0xabf946cc, pMEvt=0xbfc69894) at sd/source/ui/
#17 0xae3b9603 in sd::FuDraw::MouseMove (this=0xabf946cc, rMEvt=@0xbfc69894) at sd/source/ui/
#18 0xae3bc0f4 in sd::FuSelection::MouseMove (this=0xabf946cc, rMEvt=@0xbfc69894) at sd/source/
#19 0xae14ffc2 in sd::ViewShell::MouseMove (this=0xabfbcc88, rMEvt=@0xbfc69894, 
pWin=0xabf96668) at
#20 0xae16353c in sd::DrawViewShell::MouseMove (this=0xabfbcc88, rMEvt=@0xbfc69894, 
pWin=0xabf96668) at sd/source/ui/view/drviews4.cxx:430
#21 0xae156d09 in sd::Window::MouseMove (this=0x0, rMEvt=@0xbfc69894) at sd/source/ui/view/
Comment 1 2007-11-13 10:28:54 UTC
Comment 2 Armin Le Grand 2007-11-16 09:49:08 UTC
AW: I am sorry, but i cannot see any regresson on DrawingLayer side. It has
always been like this (thanks to the people before me). What happens is pretty
- Mouse moves
- PickAnything is the central old method to find out what's under the given position
- To answer if we have a hit, the geometry of the object is needed
- To get that for text, the DrawOutliner is used
- Since the DrawOutliner is a single-incarnated, shared ressource, it needs to
be filled newly with text data (OutlinerParaObject)
- Since newly filled, it layouts the text
- With the layouted text, the position is tested against hit

Nothing has changed here from my side. Maybe sd::FuDraw::ForcePointer (or
better: the application) calls PickAnything more often than in older versions?
Maybe Text layout got slower or some buffering broke loose there?

One of the next steps for reworking the office is the controller side what would
include these interaction handlings. Forthe future this IsHit quastion can be
answered by the text primitives which get layouted only once when the more
complex primitive homing them changes.

For the current situaton i see only one possibility:
It makes no sense to try to hold the layouted OutlinerParaObject in the
DrawOutliner to rescue the layout, this changes too often. The only thing i can
think of is to buffer the last input to PickAnything() and it's result and just
try not to call PickAnything too often. Of course this will not really make
things better at real MouseMoves, but i guess it gets called often with the same

AW->HDU: What also is needed is an error description to recreate it. The stack
is nice, but under which circumstances does who have the impression that it is
much slower suddenly than before? Please add information. Also adding some
people to copy who may be involved.
Comment 3 2007-11-16 11:49:03 UTC
This issue is just a regular performance bug, not a regression. The performance bug became obvious 
because the CWS made reformatting a little bit more expensive, but Writer engine wasn't noticeably 
impacted, only the SdrView became sluggish.

I don't understand why the SdrView would need to know what is under the mouse pointer for regular 
mouse move events, even when nothing is selected, dragged or clicked?

@aw: The bugdoc is
i83491_tchinese.odg (the second attached file of issue 83491). Select the textbox then move the mouse 
over the text.
Comment 4 Armin Le Grand 2007-11-16 14:26:21 UTC
AW->HDU: Very simple: As You can see with the stack, the correct MousePointer
(Context-sensitive) is choosen. This depends on what is under the mouse position
and is completely independent from selection. It's a visual user feedback so
that it gets more clear what hapens when he presses the MouseButton. E.g. the
drag mouse cursor is shown when over an object. So for text objects, it is
necessary to check if we are over a Letter at every MouseMove. That's what
always happened. You may check this with an selected ellipse without filling but
with text, just hoover over it.
This will even be extended in the future, think about hilighting the object
under the cursor using a lightweight frame and evtl. displaying data. There is
also e.g. the ToolTip option to show URL contents, etc. when over an object with

To the task itself: I see good chances for less layouting when we have the
primitives since hit test will be possible with these then. Setting to
enhancement and target 3.0.
Comment 5 Armin Le Grand 2007-11-19 11:51:47 UTC
AW: Adding primitives tag since this can be enhanced with primitives...
Comment 6 Armin Le Grand 2008-04-29 03:22:31 UTC
AW: Adapting target to primitive move to 3.1.
Comment 7 thomas.lange 2008-04-29 08:47:44 UTC
Comment 8 Armin Le Grand 2008-05-05 11:21:21 UTC
AW->TL: How are Your plans when You set it to started? Do You have a concrete
plan to solve this? If Yes, please change owner, too.
Comment 9 thomas.lange 2008-05-05 11:37:09 UTC
Actually I missed that I'm not the owner. ^^° Sorry!
Thus if you don't think the problem lies within EditEngine or TextEngine you
might as well keep it. 
But reformatting sounded like I should probably have a look into the issue and
that's why I set it to started since I mistook me for the owner.

Thus for the time being no plans or action taken so far or planned within the
next few weeks.
Comment 10 Armin Le Grand 2008-10-07 11:35:48 UTC
AW: With aw033 in DEV300 m30, the base for changing this is in the office: Make
the HitTest use primitives. It is already used now for 3D objects and for
2D/3DBoundRect calculations. Needs to be used for 2D hit test, too. This is not
trivial since HitTest diversifies hits on line, fill, text and other parts of
objects which are not even always visible...
Comment 11 Armin Le Grand 2008-12-10 14:56:26 UTC
AW: Moved to 3.2
Comment 12 Armin Le Grand 2009-02-19 15:40:00 UTC
AW: Evaluated. Current implementations at the SdrObjects (CheckHit) use only
geometric knowledge, so this task will have to wait for #i99147# to be sure to
have the evtl. invisible geometry available with the primitives.
Comment 13 Armin Le Grand 2009-06-26 13:50:52 UTC
AW: This enhancement should be implemented with #i101872# which is in CWS aw065.
I will check when it's integrated.
Comment 14 Armin Le Grand 2009-08-03 12:22:29 UTC
AW: Done with DEV300 m52. HitTest uses the sequence of primitives now which gets
formatted only once. Setting to fixed.
Comment 15 Armin Le Grand 2009-08-03 12:22:50 UTC
AW: Closing.