Bug 87907 - DIALOG: Page preview in print dialog refreshes when opening print details
Summary: DIALOG: Page preview in print dialog refreshes when opening print details
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.6.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
 
Reported: 2014-12-31 13:45 UTC by Yousuf Philips (jay)
Modified: 2017-10-23 14:04 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample complex document (18.19 KB, application/vnd.oasis.opendocument.text)
2015-02-22 12:25 UTC, Matthew Francis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2014-12-31 13:45:22 UTC
Steps:
1) Open Writer
2) Ctrl+P
3) Click the 'Details' label underneath the printer list
4) Notice the page preview to the left refreshes

Regression as this doesnt happen in 4.0.6. Likely caused by the conversion to the new UI.

Version: 4.5.0.0.alpha0+
Build ID: e570cd7a293ceee175949dcc9656cdf776ae3c37
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-12-12_18:49:54
Comment 1 Cor Nouws 2014-12-31 13:58:59 UTC
Thanks - there are more moments where refreshing happens in this dialog that I've the idea that it's unneeded.
Comment 2 A (Andy) 2014-12-31 14:58:27 UTC
Reproducible with LO 4.4.0.0.beta1 (Win 8.1).  But I don't know if this refresh is necessary (I am not a programmer).
But what I also recognized is that, after the refresh the page preview border gets broken.  Do you have the same?
Comment 3 Yousuf Philips (jay) 2014-12-31 17:46:55 UTC
(In reply to Cor Nouws from comment #1)
> Thanks - there are more moments where refreshing happens in this dialog that
> I've the idea that it's unneeded.

Would be good to figure those ones out to have them all in the bug report. :D

(In reply to A (Andy) from comment #2)
> But what I also recognized is that, after the refresh the page preview
> border gets broken.  Do you have the same?

Not happening here on Linux. Maybe put in a screenshot. :D
Comment 4 tmacalp 2015-02-01 21:20:08 UTC
I've bibisected:

c826604de689fbabd8b1b8ea41396694e99a23d4 is the first bad commit
commit c826604de689fbabd8b1b8ea41396694e99a23d4
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Oct 16 11:48:30 2013 +0000

    source-hash-32acb98b3fb6acb4712f7195cf5ea1bd69c9c6b4
    
    commit 32acb98b3fb6acb4712f7195cf5ea1bd69c9c6b4
    Author:     Luc Castermans <luc.castermans@gmail.com>
    AuthorDate: Sat Mar 2 21:46:59 2013 +0100
    Commit:     Michael Meeks <michael.meeks@suse.com>
    CommitDate: Mon Mar 4 12:02:06 2013 +0000
    
        translated German comments; all cleaned up.
    
        Conflicts:
    
        	dbaccess/source/ui/querydesign/QueryTableView.cxx
    
        Change-Id: I761b190361bbcca2f9655a7a028799586c2d8656

$ git bisect log
git bisect start 'last41onmaster' 'last40onmaster'
# bad: [c1631ee90606d0a7928496fb9548bcd0dbe69dbf] source-hash-28fb57daa77438f5e63132d3417062a11a44461e
git bisect bad c1631ee90606d0a7928496fb9548bcd0dbe69dbf
# good: [cd762eb968ba8783f726b67d9d70b0a76f4eb55d] source-hash-c9562064740baed3a9978723c5fe77b44a13a7aa
git bisect good cd762eb968ba8783f726b67d9d70b0a76f4eb55d
# bad: [5a52acff89c712acbd4be6896748c76a010cb507] source-hash-07352f07ce40ef40e9b73fd05aa4f9c5eac38290
git bisect bad 5a52acff89c712acbd4be6896748c76a010cb507
# bad: [6f1a441db6e60b3b26e8cb23a731e0ac9695a230] source-hash-ca44650259e9388bd7dfd0603e4c9908a116c59b
git bisect bad 6f1a441db6e60b3b26e8cb23a731e0ac9695a230
# good: [fe956dc63cc7ed1831f0e7e9e7253ea4d8c99549] source-hash-b15f095293c6127ecaef2f0fa3a1683e72392835
git bisect good fe956dc63cc7ed1831f0e7e9e7253ea4d8c99549
# bad: [c826604de689fbabd8b1b8ea41396694e99a23d4] source-hash-32acb98b3fb6acb4712f7195cf5ea1bd69c9c6b4
git bisect bad c826604de689fbabd8b1b8ea41396694e99a23d4
# good: [6b0fcfdf08f741216af030aceb20152a2b327f35] source-hash-310fb291ccfb817a3503785af143828682c0c1f1
git bisect good 6b0fcfdf08f741216af030aceb20152a2b327f35
# first bad commit: [c826604de689fbabd8b1b8ea41396694e99a23d4] source-hash-32acb98b3fb6acb4712f7195cf5ea1bd69c9c6b4
Comment 5 Matthew Francis 2015-02-22 12:23:55 UTC
Within the range mentioned in comment 4, there are the below two commits which have some effect on the empty document case (rendering the preview gets somewhat slower)

However it seems easy enough to produce the same effect even before the range in question with a sufficiently complex document. It was never instant even before these commits. Given that, I'm not sure if there's anything much to be done here


commit 9058681a8d4f52db18f094994b231e719e9bb6eb
Author:     Tomaž Vajngerl <quikee@gmail.com>
AuthorDate: Sun Mar 3 20:49:18 2013 +0100
Commit:     Tomaž Vajngerl <quikee@gmail.com>
CommitDate: Sun Mar 3 20:57:02 2013 +0100

    Better quality previews in print dialog.
    
    Make a fixed size bitmap of the current document for preview in
    print dialog. The bitmap is scaled when the dialog is resized, which
    is faster and better quality as it uses "BEST" scaling method for
    resizing the bitmap.
    
    Change-Id: I3be0bec30a7f2cd594c56d23fe2b39221aff807c

commit dca9978fdbd96f0b23b3e52431bf074d259ceec1
Author:     Armin Le Grand <alg@apache.org>
AuthorDate: Sun Mar 3 20:21:48 2013 +0100
Commit:     Tomaž Vajngerl <quikee@gmail.com>
CommitDate: Sun Mar 3 20:57:02 2013 +0100

    121687# better preview
    
    Change-Id: I7beca0f3d809e5a2ab3d8ef6c73b970010a47eaf
Comment 6 Matthew Francis 2015-02-22 12:25:31 UTC
Created attachment 113602 [details]
Sample complex document

The attached document is reasonably visually complex, and can be used to show that the print dialog preview can be slow even before the changes mentioned above
Comment 7 Robinson Tryon (qubit) 2015-12-13 11:11:07 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2017-10-23 14:04:57 UTC
** 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