Issue 96669

I have no problem opening the bugdoc from i96221 on m36 (~ 15 seconds). 
Maybe you can send your doc to me that I can check it?

Switching the pages of  the bugdoc nearly does not work here for me. Drag and
Drop of the objects works fine.

Set target to OOo3.1 because this is a regression.  Switching pages in OOO300
m10 is much faster.  Like WG I can not reproduce problems with drag and drop.

The drag and drop problem seems to be a secondary effect. Using the testkit I
sent to Wolfram it's more visible when I open a second window for this document.
Switching between slide 3 in one window and slide 4 in the other one, all
'mark', 'delete', 'drag and drop' and other operations become extremely slow,
but I belive main reason is some "unfinished" switch operation. I tried another
document with 119 slides only containing Drawing elements (Lines ...), and every
operation (even a simple drag and drop of a line document) causes some minutes
100% CPU load. I can also contribute that document, but it's not for public use.

AW->rainerbielefeld: I wanted to start on this issue, but WG is on vacation.
Could You somehow contribute the test document, i will need it. Thanks in advance!

AW: Got the bugdoc (thanks to rainerbielefeld), taking a look. First look with
debug version shows that it's slower. I need a non-debug version to compare....

AW: Indeed, much slower. For concrete results, i will need to ask valgrind on
the linux version. My first guess were the texts, so i added two static bools
for leaving out:
(a) text layouting into primitives
(b) text painting from primitives
It shows that indeed (a) is the time consumer. Only disabling (b) showed this
clearly. I will have to measure the text layouting on the linux version
(impDecomposeBlockTextPrimitive(...)). This is anyways a compromize since it
uses the old EditEngine/Outliner functionality. Sadly, we do not have another
text layouter, so i will have to check where the problem is...

AW: Hmmm. Looking with callgrind on the unxlngi6.pro version shows a completely
other picture: SdrBlockTextPrimitive2D::crealeLocalDecomposition uses 2.46%,
while painting takes 64.41% where RenderTextSimpleOrDecoratedPortionPrimitive
takes 47,16% alone. This shows that the problem is not text layouting, but
painting. I need to do more granular measurements. Setting HDU on copy, too.

AW: On friday, i found 'VerySleepy' and did some quick speedtests for the
windows version. I found that - compared to the pre-primitive versions - the
getB2DRange() method at the text primtives themselves uses a lot of time since
internally it uses OutputDevice::getTextBoundRect. To check, i added a quick
buffering of the B2DRange and speed was as in older versions.
I already have a buffering mechanism for decompositions at the primitive
implementations and i am now thinking about adding a standard buffering for the
range, too. I will have to design with care to not waste too much memory with
simply adding a B2DRange to every primitive (which would work). Thinking in
detail about refining buffering for decomposition and range at BasePrimitive2D...

AW: I made quite some extensive experiments today, mainly trying to find a good
modular redesign for BasePrimitive2D, so that buffering of the decomposed
Primitive2DSequence and the calculated B2DRange would be possible. All in all
this would be a lot of changes, but quite possible.
OTOH i have some not yet integrated changes in aw059 in similar regions, so this
would lead to conflicts and may be quite dangerous. So i will move the bigger
redesigns to a CWS after aw059 integration (should be after DEV300 m38 is ready)
and write a follow-up for it.
To get this task fixed, i will concentrate on simple and quite direct buffering
of B2DRange for the most calculation-intense primitives, Embedded3DPrimitive2D,
maybe MarkerArrayPrimitive2D, PointArrayPrimitive2D, ScenePrimitive2D and
TextSimplePortionPrimitive2D (of course).
Preparing simple buffering for named primitives...

AW: Works as expected. The maximum currently is to get the same speeds as for
the pre-primitive version since the default primitive renderer currently is the
VCL-Renderer. In the future, this will change (to e.g. GDI+ on WIN32) and show
the potential in speed and e.g. AA.
Also optimized the text primitive creation in
impTextBreakupHandler::impCreateTextPortionPrimitive to only create
TextDecoratedPortionPrimitive2D if needed, else TextSimplePortionPrimitive2D is
created.
Checking in changes. Increasing priority since this is a important task.

AW: Done for WIN32, need to check Unix versions...

AW: Linux build is done, checked, much better than before. STill we have
potential here, I'll wite a Follow-Up for HDU.

AW: Filed #i975444# as follow-up.

AW->WG: Please verify. I will forward the mail from rainerbielefeld containing
the test document to You.

Verified in CWS.

Updated the issue summary. It was way too generic ("unusable slow") for any bugtracking system with 
more than 100 issues.

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

Tested in DEV300_m41. Closed.