Created attachment 61508 [details]
Sample document

Same bad result with "Ooo Dev 3.2.0 multilingual version German UI WIN XP:
[DEV300m44 (Build 9395)]".

My system:
Graphic Card: Nvidia GeForce 7300 LE
Processor: AMD Athlon 64 Bit 3500+
Monitor : 1024*768
OS: WIN XP SP3

Confirmed with a similar Windows system.

Sample doc was fine in 3.0 -> regression 

Reasigning

SBA->OD: Please have a look at this ASAP, thx.
The "as character" anchored drawings seem to be the cause.
Put AW, MRU and myself on c/c.

MRU->OD: please have a look, this regression is easily to reproduce. Just scroll
up and down or type some text in the attached document.
The objects seem to be graphic objects pasted from OOo Draw.

First investigation reveals the following:
- The pictures/graphics are Draw graphics of the same embedded StarView metafile.
- Rendering of these Draw graphics in Writer is slower compared to OOo 3.0.1
- Broken in DEV300m30 - in DEV300m29 the rendering performance is ok.
- Rendering of these Draw graphics in Draw is also slower than in OOo 3.0.1

OD->AW: Please take over.

AW: I took a look. Each of the 18 objects is a MetaFile. Each of the MetaFiles
contains 3425 polygons, this makes 61650 polygons. In contrast to Non-AA, all
polygons get painted when AAed since filled polygons with a sub-pixel size have
an influence (which is not the case in the non-AAed case). This is simply the
cost of AAing those polygons. There is not even a change in handling MetaFile
painting with the primitives, except that VCL now uses AA when switched on at
the OutputDevice.
To test, i switched off AA in tools/options/view and it's not really faster (so
AAing on WIN32 is really fast). I checked with a DEV300 m29 (without primitives)
and painting those objects is also very slow (no difference to 3.1 version), try
to zoom to check this.

AW->OD: The painting speed has not really changed at all (it's just incredible
objects), but the SW typing seems to use another rectangle to determine if it
overlaps those objects, there must be a change there. Please check in that
direction. Even when the objects scroll out of sight, the typing seems to force
them to be repainted.

@aw:
I checked your results and I think anti aliasing really is a big part of the
problem. after I switched it off, let a typing work approximately twice as fast
as with anti-aliasing. .3.1 still as very slow!
Even without anti-aliasing in a document of my own it causes 100% CPU load if I
type "k" and "m" alternating as fast as I can.  With 2.4.1 the same proceeding
does not cause any abnormal CPU load.

And the same result with "test_502.odt". When I switch of AA typing works much
faster, but very much more slowly than with 2.4.1.

AW->rainerbielefeld: Please read again: Problem is not AA per se, but that a
region (the grahics) is somehow invalidated which should not be touched when
typing below it. 3.0(.1) would be comparable slow in that case; force repaints
there with zooming (hold CTRL, use mouse wheel). BTW: When AA is off in 3.1,
there is NO difference in MetaFile playback between 3.1 and 3.0.1 at all.

I agree to AW that the root cause of this issue is not the Anti-Aliasing,
because Anti-Aliasing has been introduced after DEV300m30.

OD->AW:
For the check, if a certain Draw graphic object overlaps with the paint region,
the sequences of its 2D primitives is generated. These primitives are used to
determine the geometry of the Draw graphic object in order to compare it with
the paint region.
It seems the determination of their 2D primitives cost some time.
Do you know an optimization for this case?
Can the area taken by the Draw graphic object be determined less "expensive" for
this check?
Does it make sense to check, if the bounding rectangle overlaps with the paint
region, before determining the geometry of a Drawing object?

AW: Checked with using the locally buffered getObjectRange method in
ViewObjectContact::getPrimitive2DSequenceHierarchy. This works well, but i am
not sure about the caveats this will have. Still trying to find the reason why
the primitive gereration involved is thus expensive...

AW: Using VerySleepy shows that SdrGrafPrimitive2D::SdrGrafPrimitive2D uses
nearly 100% of the time by calling the GraphicObject constructor. This call
registers the object at the graphic manager, adds it to sume buffering and uses
ImpGraphic::ImplGetChecksum when doing this.
This is surprising since it's a copy constructor which may simply copy the
checksum, knowing that the object gets copied, not a new one created.
If this cannot be changed it will still be possible to use only one instance of
the GraphicObject, e.g. using a shared ptr.

Setting KA on copy.

AW->KA: Why is copy-constructing a GraphicObject thus expensive? Does it have to
re-calculate the involved checksums in a copy constructor...?

KA=>AW: I'm currently  taking a look at the Copy Ctor, hoping to improve the
behaviour...

AW->KA: Adding code to GraphicObject::GraphicObject( const GraphicObject&
rGraphicObj, const GraphicManager* pMgr ) in grfmgr.cxx

    mpMgr = &rGraphicObj.GetGraphicManager();

directly before

    ImplSetGraphicManager( pMgr );

avoids the assignment and seems legal to me; the GraphicManager is known. This
solves the problem completely, no changes needed in graphic primitives. Is this
a possibility...?

AW: I took a look at GraphicObject usage for the whole chain through SdrGrafObj
and primitives. To change this to shared_ptr would mean to incompatible change
SdrGrafObj's member, the interface to get/set GraphicObject there and all users
(all apps, incompatible from svx). This would be possible, but highly dangerous.
It would be much better if GraphicObject copy constructor could manage to copy
it's registration at the GraphicsManager; the Graphic to use (checksum, etc...)
is all known - it's the copy constructor.
This change - if possible and not too dangerous - would also be potentially
useful for performance per se; i'm sure GraphicObject copy constructor is used
in quite some other cases, too.
Hoping for KA finding a good solution, looking forward for other possibilities...

AW: KA presented a good patch, we reviewed already and it solves the problem by
speeding up the GraphicObject copy constructor. Testing with various
presentations and stuff at KA and my side here.
Started to prepare AW071 CWS based on OOO310 m9...

AW: Small chnge to the patch after looking with KA, tested on WIN32 with the
bugdoc and 50-60 other documents. Looks like the load performance has increased,
too (feeled, not measured :-)). Added to CWS aw071, preparing versions...

AW: Changes committed, install sets building.

AW->WG: Please review. Just load the bugdoc and try typing where announced. Task
was for WIN32, but is the same on all plattforms.

Verified in CWS.

Closed.