Issue 108636

Summary: Spreadsheet with chart unusable slow
Product: General Reporter: Rainer Bielefeld <rainerbielefeld_ooo_qa>
Component: chartAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: IngridvdM, issues
Version: 3.3.0 or older (OOo)Keywords: performance, regression
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 109016    

Description Rainer Bielefeld 2010-01-25 08:32:26 UTC
Please check with "Problems.ods" in "Problems.zip" from Issue 97722 
3.1.1 will open it within seconds, an you can scroll chart in sheet "Diagram1"
without bigger problems.

m69 will need one minute to open the document and some minutes (with 100% CPU
load) to switch to sheet "Diagram1". Now try to scroll ... I hope you don't have
other plans for the next days ;-)
Comment 1 kla 2010-01-25 09:53:04 UTC
confirmed
@IHA: I think its an issue for aw, but i prefer it that you check it before.
Comment 2 IngridvdM 2010-01-25 15:27:38 UTC
That switching to sheet 'Diagram1' needs much longer now is a regression
introduced into version dev300m69. dev300m68 was much faster and codeline for
OOo 3.2 seems also to be not affected by this problem.
@aw, no chart CWS was introduced into dev300m69 but CWS aw078. Please have a look.
Comment 3 Armin Le Grand 2010-01-29 17:31:36 UTC
AW: I compared DEV300m64(a) with DEV300m69(b) (my current CWS with debug code).
With similar zoom and rough counting, (a) needed 4s, while (b) needed 6s. This
may be the debug code, but is not 'much longer' or 'unusable slow'. I will now
check with an original DEV300m69, maybe in my CWS something already went better...
Comment 4 Armin Le Grand 2010-01-29 17:36:23 UTC
AW: Checked with original DEV300m69 (pro) and the same test as above, roughly
needs 3.5s, thus for my testfile (using HJMemulator_reduced.xls from some other
bugdoc) it even got faster.
I will now use the mentioned 'Problems.zip' and chech with that file...
Comment 5 Armin Le Grand 2010-01-29 17:36:39 UTC
AW: Checked with original DEV300m69 (pro) and the same test as above, roughly
needs 3.5s, thus for my testfile (using HJMemulator_reduced.xls from some other
bugdoc) it even got faster.
I will now use the mentioned 'Problems.zip' and chech with that file...
Comment 6 Armin Le Grand 2010-02-01 10:24:58 UTC
AW: With problems.ods it is reproducable. Thanks for so quickly finding this
regression! It indeed looks like a special paint method/style got signnificantly
more expensive, need to identrify that one now. This will not be easy since the
Metafile i get from the chart has 174020 actions...
Comment 7 Armin Le Grand 2010-02-01 10:45:43 UTC
AW: Found two problems:
(1) In SdrOle2Primitive2D::operator== the two sub-primtive-sequences were
compared using the standard UNO API operator== for sequences. That operator does
not what i expected, i need to compare the contents for equality like my helper
arePrimitive2DSequencesEqual(..) does. This leads to always re-decomposing the
metafile primitive since the SdrOle2Primitive2D::operator== always returned
false. This is avoided now.

This took time at each repaint, but just a fraction (maybe 20%) which is nice
for a decomposition of such a big metafile to primitives.

(2) In the metafile primitive decoder itself, the handling of ClipRegions was
not optimal. In this case, a ClipRegion was set very early in the metafile
(probably for the whole chart area). A lot of push/pop actions follow which not
really do anything (e.g. not changing the region). At pop() the old ClipRegion
needs to be restored which is a ClipRegion change. For that change, a
MaskPrimitive2D with the up-to-then created sub-content was created. While this
is not wrong, it is not necessary when as here with a pop() the old and the new
ClipRegion are the same. Optimized this and other cases so that much less
MaskPrimitive2Ds will be created. This brings bact the speed to former versions
with even slight speedups (as seen for HJMemulator_reduced.xls already).

Checking in both changes...
Comment 8 Armin Le Grand 2010-02-01 10:54:25 UTC
AW: Checked in, done.
Comment 9 Armin Le Grand 2010-02-12 10:59:08 UTC
AW->WG: Please verify as described. You will need the described BugDoc, it does
not happen with all big chart types.
Comment 10 wolframgarten 2010-02-15 14:50:53 UTC
Verified in CWS.