Apache OpenOffice (AOO) Bugzilla – Issue 108636
Spreadsheet with chart unusable slow
Last modified: 2017-05-20 11:41:45 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 ;-)
confirmed @IHA: I think its an issue for aw, but i prefer it that you check it before.
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.
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...
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...
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...
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...
AW: Checked in, done.
AW->WG: Please verify as described. You will need the described BugDoc, it does not happen with all big chart types.
Verified in CWS.