Bug 95658 - Repagination caused by changing print settings in File > Print .. under "Range and Copies" is too slow
Summary: Repagination caused by changing print settings in File > Print .. under "Ra...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: bibisected, perf, regression
Depends on:
Blocks: Repagination
  Show dependency treegraph
Reported: 2015-11-07 16:53 UTC by David
Modified: 2019-03-10 07:50 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description David 2015-11-07 16:53:42 UTC
I don't re-call this happening in version 4.x, and I've been unable to use version 5.0.x until 5.0.3 because of other regressions, so I don't know exactly when this problem started.  But when the print dialog is opened, every time you select an option under "Range and Copies" a repagination of the document will occur.  If you want to select a page to print, then every time you type in a number, another repagination will occur.  This is extremely annoying on a long or complex document that might take a while to repaginate.
Comment 1 A (Andy) 2015-11-07 18:43:53 UTC
Reproducible with LO, Win 8.1
Comment 2 Cor Nouws 2015-11-07 20:17:37 UTC
Also happens in 4.4, 4,1, ...
Would be nice if it could be a bit faster yes..
I see it is fast in 3.6.6, so there is a performance regression here. An indeed nasty..
Comment 3 David 2015-11-07 20:33:13 UTC
Seeing as the documents repaginates when the print dialog is opened, is there any reason it needs to repaginate every time you change a setting or page number to print?
Comment 4 Joel Madero 2015-12-13 16:20:10 UTC
It would be nice to know if anyone is reproducing this in Linux. Also is this with native dialogs or system dialogs? I can't reproduce with the given information:

Bodhi Moksha
Build ID: 5df326438fd3a5613a52b4de1935426911ff1301
Comment 5 David 2015-12-13 18:42:26 UTC
I am using this under Linux (Debian stable 64bit).  I also am using the native dialogs since I get a lot more crashes with large files when using system dialogs.
Comment 6 Joel Madero 2015-12-13 18:51:05 UTC
And does this happen with any document (even if it only has 2 pages)? I just tested with a basic document with 95 pages and I didn't get any delay
Comment 7 David 2015-12-13 23:16:43 UTC
Even with a 2 page blank document, you can see that the refresh of the preview page is noticeably slower than it was in 3.x versions and maybe later (I'm not sure when it started).
Comment 8 Robinson Tryon (qubit) 2015-12-14 05:32:30 UTC Comment hidden (obsolete)
Comment 9 Joel Madero 2015-12-14 17:40:41 UTC
Can you provide a test case (long and complex document you referred to) where I could see a more obvious performance issue...using regular text files (even when 100 pages) I *might* see a very slight issue but it's really hard to bibisect it without a better sample file.
Comment 10 Cor Nouws 2015-12-14 18:30:19 UTC
Hi Joel,

Thanks for willing to look at this!
You may try this one http://www.pitonyak.org/AndrewMacro.odt ?

(But also with 4 and more pages I can see it. Anyway on my PC ;) )

Cheers - Cor
Comment 11 Joel Madero 2015-12-19 16:38:39 UTC
I tested all the way back to 3.3 and see the same repagination with the file Cor suggested to test on....are we 100% sure that this is a regression?
Comment 12 David 2015-12-19 18:19:12 UTC
It used to be near instantaneous at one time for me.  I didn't even realize then that it was re-paginating.
Comment 13 Joel Madero 2015-12-19 18:36:50 UTC
Are you running Windows or Linux? If you're running Linux it would be really nice to get a bibisect from you. 

From what I can tell it's all basically the same speed (maybe not instantaneous but not more than a couple seconds).
Comment 14 David 2015-12-19 22:17:53 UTC
I am running Linux.  How is a bisect done?  A few seconds may not seem like much, but when it does it every time you press a key or make a selection it gets a bit irritating.
Comment 15 Joel Madero 2015-12-19 23:53:18 UTC
Sure I understand that *for you* it's particularly irritating, thus why I think if *you* are able to do a reasonable bibisect we might be able to push it forward. That being said, our priorities are set by objective standards and the impact on a single user is not going to cause the QA team to lift the priority. Also, priority/severity has no impact on what bugs are fixed (at least directly) they are only used to indicate to developers how serious the bug is. This one is objectively a minor issue.

Bibisect Instructions: https://wiki.documentfoundation.org/QA/Bibisect/Linux

If you need live help you can go ask in the QA Chat Channel: https://kiwiirc.com/client/irc.freenode.net/libreoffice-qa

Thanks for your understanding, help, and patience.
Comment 16 Cor Nouws 2015-12-20 09:42:27 UTC
People with the problem: 32 bits?
Comment 17 Aron Budea 2016-04-28 20:52:59 UTC
I tested this in Windows, and the cultprit seems to be ImplScaleConvolution (+called functions). It's far from an exact measure, but adding a breakpoint to the beginning and the end of the function can confirm noticeable time is spent in there.

Also, just as a vague pointer, the issue appeared somewhere between 4.0 and 4.1.
Comment 18 QA Administrators 2018-04-25 02:32:39 UTC Comment hidden (obsolete)
Comment 19 David 2018-04-26 16:30:21 UTC
In a long document it is still slow.  It repaginates when opening the print dialog.  Why does it need to repaginate every time the page range is changed?
Comment 20 Buovjaga 2018-07-04 14:44:39 UTC
Bibisected on Linux with 43all repo to https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5da10275a7475efdbfd9de14ea58cf8f4c6c1582...ba446dd58a4ad324d242afcd5b28d3b4dff5a881

Unfortunately, the range covers over a month of commits and I was unable to find anything relevant. If someone more knowledgeable has a hunch on the specific code path, feel free to investigate: https://wiki.documentfoundation.org/QA/Bibisect#Doing_detective_work_inside_a_commit_range
Comment 21 David 2019-03-09 23:42:17 UTC
Seems to be fixed in 6.2.1.  No repagination is happening now when changing what pages to print.
Comment 22 Buovjaga 2019-03-10 07:50:02 UTC
Yep, looks like it is gone. Thanks for following up!

Arch Linux 64-bit
Build ID: 08e78bc7705042d896f0d7c1eddff81d14c35d56
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 9 March 2019