1668230 - Print preview takes a bit of time to reload all content when changing the number of pages to print

Status: RESOLVED WORKSFORME

(Core :: Print Preview, defect, P2)

Description

[Catalin Sasca, Desktop QA [:csasca]]

Attachment: print preview content laod.gif

Affected versions

• Firefox 82.0b5
• Firefox 83.0a1

Affected platforms

• Windows 10
• macOS 10.13
• Ubuntu 20.04

Steps to reproduce

1. Launch Firefox
2. Access this test pdf
3. Access Print preview and select "Save to PDF" option
4. Select Custom from "Pages"
5. Edit any pages between 3 and 13.

Expected result

• The preview is rendered quickly

Actual result

• When editing a number, the page refreshes and the content takes a couple of seconds to load completely

Regression range

• Will see for a regression if there is one.

Additional notes

• The issue can be seen in the attachment
• First time, when opening print preview, the document will be loaded nearly instantly, only by changing pages, will slow down a bit.

Suggested severity

• S3

Comment 1

[Sean Voisen (:svoisen)]

I'm unable to reproduce locally. This happens quite quickly on my MacBook Pro (13", 3.5 GHz i7) in Nightly 83.

Emilio: Maybe we should get some profiles?

Comment 2

[Jonathan Watt [:jwatt]]

It's very slow for me on my MacBook Pro 16". (Did you use the linked PDF and change the range from page 3 to 8, Sean?)

This is actually expected to be slow right now. Currently we still pass settings changes using an nsIPrintSettings object, and so far the only optimization we have implemented vs. the old implementation is to stop recloning the document every time a new settings object is passed. We do not yet compare the new settings object against the old settings object and try to be smart about the new reflow/layout work we do. There are a bunch of optimizations that could be made depending on which setting has changed. In the case of the page range changing, we should be able to avoid any reflow work in the common case where we have one page per sheet. However, it may be easier to do that if we fix bug 1661868 first (and doing it may make the work for bug 1631452 a bit harder?).

Daniel, maybe you also have some thoughts on this.

Comment 3

[Sean Voisen (:svoisen)]

(In reply to Jonathan Watt [:jwatt] from comment #2)

It's very slow for me on my MacBook Pro 16". (Did you use the linked PDF and change the range from page 3 to 8, Sean?)

Yep, with the linked PDF and any combination of page ranges it's quite snappy (~0.5s) for me. Not sure why if it's mostly about reflow. Tried toggling WebRender but similar results.

Comment 4

[Daniel Holbert [:dholbert]]

The STR are fast for me as well (with Nightly on Linux, Dell XPS 15 9570). ~1s reaction time (And some of that 1s is an intentionally-imposed throttle, I think, to avoid reacting too quickly for each keypress when a user is typing/editing a multi-digit page number, for example.)

I definitely agree that we can & should avoid needless reflow for page-range changes, but it doesn't seem likely that that's the bottleneck here, given the variation in experiences. Could you capture a profile of the slowness & we can see if there might be something else involved?

(Meanwhile, I'll spin off a dedicated bug for avoiding needless reflow)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

(Meanwhile, I'll spin off a dedicated bug for avoiding needless reflow)

(Filed bug 1668400.)

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

(Meanwhile, I'll spin off a dedicated bug for avoiding needless reflow)

In that case I'll revert the change I made to this bug's title.

Comment 7

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

Could you capture a profile of the slowness & we can see if there might be something else involved?

https://share.firefox.dev/2SaBm1j

Comment 8

[Daniel Holbert [:dholbert]]

Thanks! Yeah, reflow barely shows up in that profile. Looks like most of the jank there is from graphics/painting.

Comment 9

[Daniel Holbert [:dholbert]]

Theory: I think this might not have anything to do with page-ranges, and in fact it's just that the article has some complex-to-paint content on its later pages (like page 3). And if you edit the page range, that's just a quick-and-dirty way to instantly "scroll to" page 3. (If you scroll slowly, I think we pre-render content some distance ahead of you -- but if you edit the page range, we don't get a chance to do that.)

I can reproduce what I think is the same bug (~slow/noticeable incremental rendering) if I simply click and drag the scrollbar to the very end of the document, or to a far-away page. (Or if I click the scrollable area to focus it, and then hit the "end" key on my keyboard.)

jwatt, does this theory jive with your experience of this bug? (and do you see the same jank when forcing the scrollbar all the way to the end)?

Comment 10

[Daniel Holbert [:dholbert]]

Also, jwatt: could you test whether the redraw-jank is approximately-as-bad in these alternate STR?

(1) View the PDF ( http://www.dbsparks.com/research/html/SNRN02.pdf ), and be sure it's scrolled all the way to the top.
(2) Don't scroll down at all (that's cheating and prompts us to pre-render further along, which interferes with the results)
(3) Focus the page-selection box at the top left of our PDF.js viewer, and replace its "1" with "3" (to jump immediately to page 3)

When I do these steps, I can definitely see the graphics/text on Page 3 being incrementally drawn.

(If these STR are just-as-bad for you as the original STR, then this bug would seem to just be about PDF.js drawing kinda-slowly for this testcase.)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screencast of jumping directly to page 3 when viewing the PDF directly (no printing involved); similarly bad, I think?

Comment 12

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #10)

(If these STR are just-as-bad for you as the original STR, then this bug would seem to just be about PDF.js drawing kinda-slowly for this testcase.)

Yeah, good call. They basically are. Let's close this then.

Catalin, if you try the steps from comment 10 and disagree with closing this, please reopen it.