Created attachment 41553 [details]
document to reproduce the bug case

This is a regression in m194 - it does not happen in m193.

According to
http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority, this should
probably be a P2.

cc mmp

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
beginning.

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
one.
Testing...
AW: This works well, but i have to think about side effects.

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.

AW->FS: please review, install sets are all ready

BTW - I just installed aw039 and checked the behavior on the document
http://specs.openoffice.org/chart/wizards/ChartWizard.odt:

- about a dozen refreshes after loading the document
- still massive performance issues on typing text

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.)

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.

The CPU consumption ist still hitting 100% but the writing appears nearly
immediately now.

*** Issue 72852 has been marked as a duplicate of this issue. ***

Tested in m201. Closed.

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

added md to cc

.

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.

@pavel:

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

James McKenzie

AW->pjanik: Please check with switching off the settings flag for OverlayBuffer.
Any changes?

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...

@pjanik:

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

s/prolbem/problem.
James McKenzie

@pjanik:

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

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...

AW: Checked: no more OutputDevice::DrawOutDev with source Window is used.
Checking for form controls...

AW: Checked: ClipRegion for SdrPageView::DrawLayer is correct
AW: Checked: FormControls are okay (it's slower when disabled, but not the reason)

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
ObjectContact...

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!

AW->WG: Please verify. I already took a look at MMPs machine, but SW QA maybe
interested, too?

Retested this and now the input is really fluent, the CPU usage hangs arround at
30% when typing. From my side this is verified.

Also ok from Writer QA. Setting to verified.

Tested in master OOF680m7. Closed.