Issue 72752 - massive performance problems when editing the attached document
Summary: massive performance problems when editing the attached document
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: 680m194
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: wolframgarten
QA Contact: issues@sw
Keywords: regression
: 72852 (view as issue list)
Depends on:
Blocks: 73858
  Show dependency tree
Reported: 2006-12-19 12:15 UTC by Frank Schönheit
Modified: 2013-08-07 14:42 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

document to reproduce the bug case (588.69 KB, application/vnd.oasis.opendocument.text)
2006-12-19 12:16 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2006-12-19 12:15:31 UTC
- open the attached document
- wait until Writer finished formatting it (you'll note that it doesn't flicker
- position the cursor somewhere in the abstract section
- start a tool to watch the processor consumption (e.g. the Windows Task Manager)
- start typing garbage (just repeatedly insert arbitrary characters)
=> the "soffice" process starts consuming a complete CPU. If you're doing this
on the single-CPU machine, then your typing will be incredibly slow.
Comment 1 Frank Schönheit 2006-12-19 12:16:52 UTC
Created attachment 41553 [details]
document to reproduce the bug case
Comment 2 Frank Schönheit 2006-12-19 12:24:04 UTC
This is a regression in m194 - it does not happen in m193.
Comment 3 Frank Schönheit 2006-12-19 12:55:20 UTC
According to, this should
probably be a P2.
Comment 4 matthias.mueller-prove 2006-12-19 14:58:57 UTC
cc mmp
Comment 5 Armin Le Grand 2006-12-20 14:44:38 UTC
AW: Problem is the VirtualDevice usage in SW which undermines the DrawingLayer
paints. A DrawingLayer paint has three basic steps:
(1) BeginDrawLayer
(2) n x DrawLayer
(3) EndDrawLayer
This is necessary to be able to do the overlay logic in steps (1) and (3) and
consists of creating/setting the ClipRegion in step (1) for the also given OutDev.

When editing a SW line, step (1) gives the Window, so the DrawingLayer is set up
for the Window. Steps (2) then suddenly uses a VDev which is handled as 'unknown
device' and thus gets no ClipRegion set.
Thus, all objects are visible and all graphic objects load their graphics ->
that's the reason for the low speed. This means that low speed will show up when
a lot of graphic objects are in the document which are not visible from the

SW uses it's own local VDev to avoid flickering of the edited line, since during
typing the whole line gets repainted. This is a good reason and cannot be
changed easily without getting flickering.

AW: First try: When DrawingLayer gets a step (2) on an unknown (and
uninitialized device) it copies the ClipRegion to use from an known, initialized
AW: This works well, but i have to think about side effects.
Comment 6 Armin Le Grand 2007-01-02 13:38:22 UTC
AW: Okay, chekced again, i will take that solution to allow SW for the moment to
draw to a not-initialized (from DrawigLayer view) device. There is no other
quick solution, all other would lead to flickering. Checking in.
Comment 7 Armin Le Grand 2007-01-10 10:25:46 UTC
AW->FS: please review, install sets are all ready
Comment 8 matthias.mueller-prove 2007-01-10 12:08:19 UTC
BTW - I just installed aw039 and checked the behavior on the document

- about a dozen refreshes after loading the document
- still massive performance issues on typing text
Comment 9 Frank Schönheit 2007-01-10 14:39:35 UTC
fs->mmp: The initial repaints are a separate issue, I never intended to cover
them with this one here. I suspect they're completely independent from the
drawing layer issues, and simply show the continuous re-formatting after loading
of a large document. I'd also suspect this behaviour is present in m193 and before.

For the performance problem: I cannot reproduce them. However, I have a 4
processor machine here, and my indication when writing the bug was that
soffice.exe consumed one complete processor (though this does not have a
noticeable performance impact on this machine). This behaviour cannot be
observed in CWS aw039 anymore, so as far as I am concerned, this but looks like
being fixed.

If you're still not satisfied with the performance, and say it's a degradation
over previous versions, then please discuss this with aw.

(Sigh. That's the reason I don't like submitting other people's issues.)
Comment 10 matthias.mueller-prove 2007-01-11 12:27:30 UTC
hi wolfram,
allthough this is a very tricky one, Armin and I suppose that my performance
issue is addressed and fixed. Please check and approve this CWS for integration.
Comment 11 wolframgarten 2007-01-12 09:55:26 UTC
The CPU consumption ist still hitting 100% but the writing appears nearly
immediately now.
Comment 12 philipp.lohmann 2007-01-16 14:54:27 UTC
*** Issue 72852 has been marked as a duplicate of this issue. ***
Comment 13 wolframgarten 2007-01-26 14:47:12 UTC
Tested in m201. Closed.
Comment 14 mdxonefour 2007-01-30 11:47:18 UTC
MD: I can still reproduce this issue with a OOF680m5 build 9114 on a Windows XP
system running on 1800 MHz Pentium CPU. When I open the attached document and
type my name, it takes 2 to 3 seconds until it's written after typing it. The
screen is flickering and the CPU consumtion is 100%.

I think this is a stopper for 2.2
Comment 15 mdxonefour 2007-01-30 11:52:03 UTC
added md to cc
Comment 16 mdxonefour 2007-01-30 11:53:40 UTC
Comment 17 pavel 2007-01-30 20:29:07 UTC
This document makes Apple's X11 unusable/dead on Mac OS X Intel.

All X11 applications are dead after I open the document and move some pages down and back. Tested on 
OOF680_m5 build.
Comment 18 jjmckenzie 2007-01-31 03:38:04 UTC

Do you consider this a showstopper for the entire MacOSX series?

James McKenzie
Comment 19 Armin Le Grand 2007-01-31 09:58:34 UTC
AW->pjanik: Please check with switching off the settings flag for OverlayBuffer.
Any changes?
Comment 20 pavel 2007-01-31 10:22:03 UTC
aw: I can't no longer reproduce it even without changing that configuration. The document is OK in 
fullscreen X11, or in normal view, I can type into abstract section very fast.

jjmckenzie: no. I wanted you to test the document too...
Comment 21 jjmckenzie 2007-01-31 13:55:05 UTC

I did not see performance problems, but the scroll would not stop sometimes, but
that may be my system and not a document prolbem.

James McKenzie
Comment 22 jjmckenzie 2007-01-31 13:55:35 UTC
James McKenzie
Comment 23 jjmckenzie 2007-02-01 03:13:12 UTC

This may be another problem solved by the macosxmapfiles cws.  I am using an
Intel Core Duo laptop and the amount of CPU when idle was about 3.5% used and
when scrolling up and down the document never exceeded 15% and always went back
to the idle level.

James McKenzie
Comment 24 Armin Le Grand 2007-02-01 11:56:45 UTC
AW: Checked with Overlay disabled on MMPs machine. It's better, but still does
not reach the 2.1 performance. ATM i have no clue why, my overlay stuff is
disabled now. Re-checking for that using vcl with debug...
Comment 25 Armin Le Grand 2007-02-01 12:08:07 UTC
AW: Checked: no more OutputDevice::DrawOutDev with source Window is used.
Checking for form controls...
Comment 26 Armin Le Grand 2007-02-01 13:03:32 UTC
AW: Checked: ClipRegion for SdrPageView::DrawLayer is correct
AW: Checked: FormControls are okay (it's slower when disabled, but not the reason)
Comment 27 Armin Le Grand 2007-02-01 13:39:16 UTC
AW: I have another idea: When SdrPageView::DrawLayer() is given an OutputDevice
which was not registered at DrawingLayer, it needs to construct a temporary
SdrPageWindow and SdrPaintWindow to still paint there. This works, but the
SdrPageWindow is the ObjectContact, so a new DrawHierarchy and new VOCs are
created and destroyed.
AW: Trying to remember the prepared SdrPageWindow in SdrPageView::BeginDrawLayer
and use it in SdrPageView::DrawLayer when device is unknown. Create a temporary
SdrPaintWindow, but patch the remembered SdrPageWindow to reuse the existing
Comment 28 Armin Le Grand 2007-02-01 13:59:36 UTC
AW: Okay, remembering works. Checked with printing, multiple views, print
preview and pdf export. Also tested those for SC which also uses DrawLayer(),
works too.
AW: Checked in, building.
AW: This is a temporary workaround and will be no longer necessary when SC and
SW are able to paint to a buffer. Do NOT USE SdrPageWindow::patchPaintWindow
somewhere else!
Comment 29 Armin Le Grand 2007-02-02 10:04:09 UTC
AW->WG: Please verify. I already took a look at MMPs machine, but SW QA maybe
interested, too?
Comment 30 wolframgarten 2007-02-02 11:43:58 UTC
Retested this and now the input is really fluent, the CPU usage hangs arround at
30% when typing. From my side this is verified.
Comment 31 wolframgarten 2007-02-05 13:29:26 UTC
Also ok from Writer QA. Setting to verified.
Comment 32 wolframgarten 2007-02-12 11:53:20 UTC
Tested in master OOF680m7. Closed.