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.
Reproducible with LO 5.0.3.2, Win 8.1
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..
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?
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
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.
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
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).
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
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.
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
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?
It used to be near instantaneous at one time for me. I didn't even realize then that it was re-paginating.
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).
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.
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.
People with the problem: 32 bits?
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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?
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
Seems to be fixed in 6.2.1. No repagination is happening now when changing what pages to print.
Yep, looks like it is gone. Thanks for following up! Arch Linux 64-bit Version: 6.3.0.0.alpha0+ 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