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 18.104.22.168, 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:
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)
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.
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.
Also, just as a vague pointer, the issue appeared somewhere between 4.0 and 4.1.