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...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: low minor
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords: bibisectRequest, perf, regression
Depends on:
Blocks: Repagination
  Show dependency treegraph
 
Reported: 2015-11-07 16:53 UTC by David
Modified: 2017-04-24 18:38 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

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 5.0.3.2, 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
Version: 5.2.0.0.alpha0+
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.
http://opengrok.libreoffice.org/xref/core/vcl/source/bitmap/BitmapScaleConvolution.cxx#268

Also, just as a vague pointer, the issue appeared somewhere between 4.0 and 4.1.