Bug 129900 - Exiting Writer's Print Preview mode is slow in long documents
Summary: Exiting Writer's Print Preview mode is slow in long documents
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: Print-Preview
  Show dependency treegraph
Reported: 2020-01-09 06:08 UTC by Max Barry
Modified: 2021-12-11 11:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

1,500-page ODT (64.35 KB, application/vnd.oasis.opendocument.text)
2020-03-16 00:54 UTC, Max Barry
Madison May test doc (295 pages, 104k words) (349.08 KB, application/vnd.oasis.opendocument.text)
2020-03-17 00:31 UTC, Max Barry

Note You need to log in before you can comment on or make changes to this bug.
Description Max Barry 2020-01-09 06:08:54 UTC
Compared to LibreOffice 5, exiting Print Preview in long documents is extremely slow.

With a 1,500 page document, for example, exiting Print Preview is instant in LO5, but takes 5-6 seconds (!) in LO6.

To reproduce:

1. In LibreOffice 6 Writer, fill a document with text so that it comprises at least a few hundred pages.

2. Enter Print Preview (e.g. File -> Print Preview).

3. Observe it takes a second or two (based on document length) to display the Print Preview screen. This is similar to LibreOffice 5.

4. Press Escape to exit Print Preview mode.

5. Observe a significant delay (approx. 5-6 seconds for a 1,500 page document) with CPU usage spiking before returning to normal view. There is no such delay in LibreOffice Writer.

I tend to flip back and forth between Normal View and Print Preview when editing a document, and this new delay makes this very awkward.

Ubuntu 19.10
Comment 1 Durgapriyanka 2020-01-09 18:24:50 UTC
Thank you for reporting the bug. I can not reproduce this in (235 page document)

Version: (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

and in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 2 Xisco Faulí 2020-02-17 15:22:18 UTC Comment hidden (obsolete)
Comment 3 Max Barry 2020-02-18 00:30:18 UTC

I restarted in Safe Mode and confirmed the problem still exists.

I created a 1,600 page document (600k words / 3.3M characters) and observed that it took approximately 2 seconds to enter Print Preview and about 4.5 seconds to exit Print Preview. In both cases, CPU usage immediately rose from idle to 100% and the app was unresponsive for the duration.

I also created a 15,000 page document (11M words / 58M characters comprised of repeating "The quick brown fox jumps over the lazy dog."), which did the same thing, taking 16 seconds to enter Print Preview and 25 seconds to exit.

Build ID: 1:6.3.4-0ubuntu0.19.10.1
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 Dieter 2020-03-15 09:14:39 UTC Comment hidden (obsolete)
Comment 5 Max Barry 2020-03-16 00:54:32 UTC
Created attachment 158703 [details]
1,500-page ODT

Sure! And thanks for your attention to this issue.

Attached is a 1,500 ODT (1.1M words, 5.7M characters). 


Build ID: 1:6.3.5-0ubuntu0.19.10.1
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

On my PC:
* To load document: 4.0 seconds
* To enter File -> Print Preview: 2.3 seconds
* To exit, e.g. click "Close Preview": 3.1 seconds


Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 4; OS Version: Linux 5.3; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: en-AU (en_AU.UTF-8); Calc: group

On my PC:
* To load document: near-instant
* To enter File -> Print Preview: 5.3 seconds
* Click "Close Preview": instant

I notice the slow one is gtk2 and the fast one is gtk3; not sure if that matters. I tried switching from NVIDIA to Nouveau display driver, just in case that was related, but it made no difference.
Comment 6 Dieter 2020-03-16 09:15:20 UTC
I confirm it with your document

Result in 
Version: (x64)
Build-ID: dd0751754f11728f69b42ee2af66670068624673
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

Exit print preview: 5,8

Result in
Version: (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: group

Exit print preview: 2,8 sec
Comment 7 Timur 2020-03-16 10:22:13 UTC
I don't repro ESC slowness in 5.4. I *do* in 6.1 oldest. (I guess it started in 6.0). And slower in 6.3 (like 8 sec in oldest and 5 sec in master). 
In 7.0+ it's shorter (like 2 sec). So I'll close as WFM (there was an issue but not anymore).

Max, please test with master from https://dev-builds.libreoffice.org/daily/master/current.html to confirm. It will be separate to your working LO.   
If you think it's not good enough, set New (already confirmed) and we may try to track 1st slowness. I won't because it's a minor issue and delay. 

Note: I add load time, although that's not the point. 

5.4 oldest
real	0m23,747s
user	0m20,991s
sys	0m0,655s

5.4 master
real	0m56,090s
user	0m29,866s
sys	0m1,313s

6.1 oldest
real	0m43,481s
user	0m40,247s
sys	0m1,017s

6.1 master
real	1m10,217s
user	0m43,155s
sys	0m1,177s

6.3 oldest
real	0m49,571s
user	0m34,007s
sys	0m1,481s

6.3. master (not updated)
real	1m24,885s
user	0m26,936s
sys	0m1,319s

7.0+ oldest
real	0m40,184s
user	0m21,996s
sys	0m1,074s

7.0+ master
real	0m32,694s
user	0m19,179s
sys	0m1,338s
Comment 8 Max Barry 2020-03-17 00:31:45 UTC
Created attachment 158731 [details]
Madison May test doc (295 pages, 104k words)

Thanks again for your attention - it's much appreciated!

I will set to NEW because although 7.0 is indeed an improvement over 6.3, it is still *much* slower than 5.x. 

In particular, I've found that in long documents that contain formatting, 7.0 takes 4 times longer than 5.x to flip in and out of Print Preview mode (2.4s compared to 0.6s). This is better than LO6, but still so long that it makes me, as a user, reluctant to use it.

I'm attaching a new test document (Madison May test doc), which is a scrambled version of a document I work on, because this is closer to real-world conditions, and better demonstrates the performance degradation - which did indeed begin very suddenly in 6.0.

Madison May test doc (350 words per page, contains lots of basic formatting)
Time to enter & exit Print Preview mode:

enter 0.7s
exit  0.0s (0.7s total)
enter 0.6s
exit  0.0s (0.6s total)
enter 0.9s
exit  1.5s (2.4s total)

enter 1.2s
exit  2.5s (3.7s total)

enter 1.4s
exit  1.0s (2.4s total)
Comment 9 Timur 2020-03-17 10:22:44 UTC
There were many changes. Even in 6.0, I can see exit time as: fast/immediate, average/like current, slow/comparable to 6.3. 

I tried to bibisect and (if this is correct because it's subjective) this would be first fast to average change: 

commit 766fd9b2f246fcf98fca3698b813a3e843b8f41d
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Tue Nov 7 23:06:53 2017 +0100

    source sha:e6b200524bd5f614ab5ece88e8187466e7c40096

Previous commit 00579e8bdf3464a4b3581f83a52910e728089d08 (HEAD, refs/bisect/good-00579e8bdf3464a4b3581f83a52910e728089d08)
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Tue Nov 7 23:06:26 2017 +0100

    source sha:ffa46ebe6d83c5e812753c41857f31c059f33986


commit e6b200524bd5f614ab5ece88e8187466e7c40096	[log]
author	Ashod Nakashian <ashodnakashian@yahoo.com>	Thu Nov 02 21:20:50 2017 -0400
committer	Ashod Nakashian <ashnakash@gmail.com>	Mon Nov 06 06:12:21 2017 +0100
tree c90e7c8d45f353a43465aa8c43e9881d4d55d53f
parent ffa46ebe6d83c5e812753c41857f31c059f33986 [diff]

TSCP: Store paragraph signature RDF in the paragraph

Change-Id: Ic44e3238bd1c35445bc23d0cc1de07aa2bf4512c
Reviewed-on: https://gerrit.libreoffice.org/44243
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>

I don't think it makes sense to bibisect more.
Comment 10 BogdanB 2021-12-11 07:23:39 UTC
Barry please retest this bug.

2 seconds in
Version: / LibreOffice Community
Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

1 second in
Version: / LibreOffice Community
Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 11 Dieter 2021-12-11 11:13:58 UTC
Around two seconds in

Version: (x64) / LibreOffice Community
Build ID: 2934472ab888ebfe64a153984af2902fac63a7a0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

So I would say WORKSFORME. Max, feel free to change it back to NEW, if you get a different result.