Issue 96669 - performance: DrawingLayer primitives should cache their B2DRange
Summary: performance: DrawingLayer primitives should cache their B2DRange
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: DEV300m36
Hardware: Unknown All
: P2 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@graphics
: 98284 (view as issue list)
Depends on:
Blocks: 97544
  Show dependency tree
Reported: 2008-11-27 19:52 UTC by Rainer Bielefeld
Modified: 2009-02-17 09:40 UTC (History)
2 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2008-11-27 19:52:31 UTC
I checked with "Ooo 3.1 Multilingual version German UI WIN XP: [DEV300m36 (Build
9369)]" whether crashes of  Issue 96221 really are solved for that version, but
it seems it will take weeks for so many operations I was able to do with 3.0
between 2 crashes ;-)

I tested on PC AMD Athlon 64bit 3500+ / 1GB RAM

Currently I  can't say whether it's a general problem or only with my special
documents (>> 20 pages, many big linked images).

I can contribute a test document, but not as attachment (20MB).
Comment 1 wolframgarten 2008-11-28 09:29:23 UTC
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?
Comment 2 wolframgarten 2008-11-28 11:56:56 UTC
Switching the pages of  the bugdoc nearly does not work here for me. Drag and
Drop of the objects works fine.
Comment 3 groucho266 2008-11-28 13:20:39 UTC
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.
Comment 4 Rainer Bielefeld 2008-11-28 16:08:57 UTC
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.
Comment 5 Armin Le Grand 2008-12-18 14:45:19 UTC
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!
Comment 6 Armin Le Grand 2008-12-18 17:02:57 UTC
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....
Comment 7 Armin Le Grand 2008-12-18 17:40:34 UTC
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...
Comment 8 Armin Le Grand 2008-12-19 11:38:01 UTC
AW: Hmmm. Looking with callgrind on the 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.
Comment 9 Armin Le Grand 2008-12-22 09:58:38 UTC
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...
Comment 10 Armin Le Grand 2008-12-22 16:32:50 UTC
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...
Comment 11 Armin Le Grand 2008-12-23 12:45:17 UTC
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
Checking in changes. Increasing priority since this is a important task.
Comment 12 Armin Le Grand 2008-12-23 14:35:16 UTC
AW: Done for WIN32, need to check Unix versions...
Comment 13 Armin Le Grand 2008-12-23 20:15:56 UTC
AW: Linux build is done, checked, much better than before. STill we have
potential here, I'll wite a Follow-Up for HDU.
Comment 14 Armin Le Grand 2008-12-23 20:20:24 UTC
AW: Filed #i975444# as follow-up.
Comment 15 Armin Le Grand 2009-01-09 16:07:34 UTC
AW->WG: Please verify. I will forward the mail from rainerbielefeld containing
the test document to You.
Comment 16 wolframgarten 2009-01-13 15:09:59 UTC
Verified in CWS.
Comment 17 2009-01-13 16:18:19 UTC
Updated the issue summary. It was way too generic ("unusable slow") for any bugtracking system with 
more than 100 issues.
Comment 18 Armin Le Grand 2009-01-20 16:06:48 UTC
*** Issue 98284 has been marked as a duplicate of this issue. ***
Comment 19 wolframgarten 2009-02-17 09:40:21 UTC
Tested in DEV300_m41. Closed.