New print preview UI very janky scrolling documents with multiple pages
Categories
(Core :: Print Preview, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | --- | disabled |
firefox82 | --- | wontfix |
firefox83 | --- | wontfix |
firefox84 | --- | wontfix |
firefox85 | --- | wontfix |
firefox86 | --- | wontfix |
firefox87 | --- | wontfix |
firefox88 | --- | wontfix |
People
(Reporter: noni, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf, regression, Whiteboard: [print2020][old-ui-] )
Attachments
(1 file)
3.85 MB,
image/gif
|
Details |
Affected versions
- 82.0a1 (Build ID: 20200831091558)
- 81.0b4 (Build ID 20200829200810)
Affected platforms
- Windows 10 64bit (ARM)
- Win 10 64bit (non-ARM)
- Ubuntu 20.04 64bit
- macOS 10.14
Preconditions
- Ensure that the
print.tab_modal.enabled
pref is set totrue
Steps to reproduce
- Launch Firefox.
- Access a PDF containing multiple pages - i.e. http://www.dbsparks.com/research/html/SNRN02.pdf .
- Menu -> Print.
- Scroll the preview up and down.
Expected result
- The preview is displayed without any issues.
Actual result
- The preview is glitchy.
Regression Range
- This seems to be a regression since it does not reproduce with the old UI. Will follow-up with the regression range.
Notes
- This issue is extremely visible on Win 10 ARM (see attached).
- On the other platforms it is only a ~1s glitch and it goes back to normal.
Suggested Severity S2
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
Regression Range
- Last known good: 2020-08-21
- First bad Nightly: 2020-08-22
- Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=432e42cbbc4139efd2319952ec33efe8ff9add3c&tochange=369f72130f3604c85f73a3b03b2b48f33ad9b19e
Comment 2•4 years ago
|
||
(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #1)
Regression Range
- Last known good: 2020-08-21
- First bad Nightly: 2020-08-22
- Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=432e42cbbc4139efd2319952ec33efe8ff9add3c&tochange=369f72130f3604c85f73a3b03b2b48f33ad9b19e
This is an m-c pushlog, but it's very recent - can you narrow it down further?
Updated•4 years ago
|
Comment 3•4 years ago
|
||
You have Color Mode "Black & White" selected. Or, possibly, this is a result of bug 1658833 landing (it's in that range) and causing "Black & White" to be selected for you if Firefox thinks your HP printer doesn't support color printing. We implement "Black & White" mode using a filter in print preview, so that may slow things down for you.
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #2)
(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #1)
Regression Range
- Last known good: 2020-08-21
- First bad Nightly: 2020-08-22
- Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=432e42cbbc4139efd2319952ec33efe8ff9add3c&tochange=369f72130f3604c85f73a3b03b2b48f33ad9b19e
This is an m-c pushlog, but it's very recent - can you narrow it down further?
Unfortunately that is the furthest I could go with mozregression.
Comment 5•4 years ago
|
||
Cornel, can you comment on what I said in comment 5? Is there a difference between the color modes? Also, when you say "glitch" do you mean "janky"? The former would mean that things are rendering incorrectly, the latter means that it's being slow. That's an important difference for us to understand.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
For the moment I'm going to assume "janky" since that's what the recording appears to show.
Reporter | ||
Comment 7•4 years ago
|
||
After analyzing comment 5, this seems to be indeed "janky". I'm seing this for both black& white and color modes.
Comment 8•4 years ago
|
||
(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #7)
After analyzing comment 5, this seems to be indeed "janky". I'm seing this for both black& white and color modes.
Can you collect a performance profile using the profiler tool ( https://profiler.firefox.com/ ) when using the colour mode?
Reporter | ||
Comment 9•4 years ago
|
||
Here is the profile: https://share.firefox.dev/3ids9k6
Note that my printer does not support Color printing but I've used the color mode on print to pdf. On black & white the issue is more visible. Using "Color" the issue is less annoying, but still there.
Comment 10•4 years ago
|
||
(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #9)
Here is the profile: https://share.firefox.dev/3ids9k6
Note that my printer does not support Color printing but I've used the color mode on print to pdf. On black & white the issue is more visible. Using "Color" the issue is less annoying, but still there.
This looks like we're just spending all our time painting and flushing the async paints, and that is what's janking the main thread - though I suspect running GCs in the background isn't helping. Jonathan, any idea if there's something that can be done about this? Could we reduce the granularity of the preview given how small it is, and would that help? Or paint to a series of images and put those in the preview via blob
URIs or something, which I'm guessing would lead to more/better caching?
Updated•4 years ago
|
Updated•4 years ago
|
Comment 11•4 years ago
|
||
I don't think we could improve things here enough by v82 soft freeze, and although this bug sucks I don't think it's essential.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 12•3 years ago
|
||
I'm not sure I can reproduce this -- I'm testing on a 2015-era Microsoft Surface 3 -- which is not an especially powerful machine -- with Ubuntu 21.10.)
The first time I scroll to the very end of the document, I do see some slow paints, but:
- I see similar behavior when scrolling the PDF in the browser itself (no print-preview needed).
- After I've scrolled to the very end (in print-preview), I can scroll back and forth from the start to the end quite rapidly.
This is in current Nightly, but I'm seeing the same ~reasonable behavior even in Nightly 2020-08-22 -- i.e. I can't reproduce the bug in the "first bad" build from comment 1.
Cornel: would you mind seeing if this is still reproducible for you in (a) current Nightly and (b) in your "first bad" build (Nightly 2020-08-22)?
Reporter | ||
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Hello,
I can confirm that the only time I do see some coarseness is when I scroll to the last page, while content is still being painted, however for an insignificant amount of time.
I no longer reproduce this issue with the "first bad" build (Nightly 2020-08-22) as well as with the latest Nightly 99.0a1 (2022-02-17). This issue was tested on Win11x64, Win10 ARM, macOS 11.6.4 ARM, and Ubuntu 20.
Comment 14•3 years ago
|
||
(In reply to Vlad Lucaci, QA (:vlucaci) from comment #13)
Hello,
I can confirm that the only time I do see some coarseness is when I scroll to the last page, while content is still being painted, however for an insignificant amount of time.
I no longer reproduce this issue with the "first bad" build (Nightly 2020-08-22) as well as with the latest Nightly 99.0a1 (2022-02-17). This issue was tested on Win11x64, Win10 ARM, macOS 11.6.4 ARM, and Ubuntu 20.
Based on this, should we resolve this as works-for-me?
Comment 15•3 years ago
|
||
Yup, seems like it. (Thanks, Vlad!)
Description
•