Description: FILEEXPORT DOCX: Heading off and slow opening Steps to Reproduce: 1. Open the attached file 2. File save DOCX 3. File reload -> takes 30 seconds Actual Results: 30 seconds waiting time & every row has multiple numbers Expected Results: Opening speed of 4.4.7.2 (4 seconds) and no broken header Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 163713 [details] Example file
one bug at a time. it takes real 3m41,778s user 3m35,108s sys 0m3,169s in Version: 7.1.0.0.alpha0+ Build ID: 231e1e416c039d1f9724962a89cf0573a3db48a2 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 163819 [details] DOCX file created by LibreOffice 7.1
in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e it takes real 0m27,966s user 0m24,575s sys 0m1,113s
This seems to be quite similar to the bugdoc in bug #135171 Two problems here: - The headers contain frames for page number which are converted to drawing shapes on docx export. Loading many drawing shapes is slow. - On opening the docx version in LO the number of such shapes is a looot more than originally. This particular one went from ~150 to almost 6000 frames... the other in bug #135171 from 21 to 2100 with current nightly.
Created attachment 169070 [details] performance-bug_REDUCED2.odt: looking for duplication of page number frames (In reply to Gabor Kelemen from comment #5) > - On opening the docx version in LO the number of such shapes is a looot > more than originally. This particular one went from ~150 to almost 6000 > frames... the other in bug #135171 from 21 to 2100 with current nightly. I bibisected using my minimized test with Linux's bibisect-43max. These bibisects are terrible - can't save or open files without crashing for huge stretches. The last commit that was good is bibisect commit 79791a25c551c1e326c15a3ce325a1878a62c004 source-hash-0351b59aea2b87c2685c0963a57145bdc75a7a86 The next commit where saving and loading works is bibisect commit 5354507aaf9118ed4c1230ea167759a2274c1d4a source-hash-05955dd2096c29853f831d5d16b86c7b7ca00b28 So with a span of a mere 4400 commit, the range is https://cgit.freedesktop.org/libreoffice/core/log/?id=577dd32b1c4eb0a4cff574fbabca987cb52b831b&qt=range&q=0351b59aea2b87c2685c0963a57145bdc75a7a86..05955dd2096c29853f831d5d16b86c7b7ca00b28
Well, in these test documents, there truly are a TON of nested frames for the page numbers - as seen in the ODT's styles.xml. So almost certainly the first commit from author Zolnai Tamás on 2014-02-16 17:35:14 with commit 05955dd2096c29853f831d5d16b86c7b7ca00b28 DOCX export: nested text frames In Word it is not allowed to anchor a shape to another shape. That's why this code write text boxes only on the first level, nested frames is also written out on the same level because writeDMLText/WriteVMLText will push nested frames into m_aFramesOfParagraph's back. is the reason for the "multiplication" of frames seen in the header. So I'm not sure any of this could be considered a bug (except for the design of the original document). (In reply to Gabor Kelemen from comment #5) > Loading many drawing shapes is slow. Well yes - this known problem can be considered a problem, and these example documents are good proof of that. I imagine there is a bug report about that already.
*** Bug 135171 has been marked as a duplicate of this bug. ***
(In reply to Justin L from comment #7) The bug report is going in the wrong direction :P. Someone marked my initial file as obsolete.. The source ODT file has only 20 frames.. attachment 163713 [details].. Those tons of frame are generated by LibreOffice So not interested solving the issue of opening a DOCX with tones of frames.. But prefer LibreOffice not creating those in the first place.. But well never looked properly at the file.. more well opens slow so something wrong .. without looking at the frame count. So title/summary is kind of misleading.
(In reply to Telesto from comment #9) > The source ODT file has only 20 frames.. attachment 163713 [details].. Those > tons of frame are generated by LibreOffice No - it actually has about 20 frames per page. Look at styles.xml and you will see gazillions of frames within frames (11 to be exact) in the chapter5even and odd page styles. It is identical in concept (and probably identical in terms of original source document) to the bug I marked as duplicate.
Let's say:NAB