Closed Bug 1662135 Opened 4 years ago Closed 2 years ago

New print preview UI very janky scrolling documents with multiple pages

Categories

(Core :: Print Preview, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME
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)

Attached image preview_glitch.gif

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 to true

Steps to reproduce

  1. Launch Firefox.
  2. Access a PDF containing multiple pages - i.e. http://www.dbsparks.com/research/html/SNRN02.pdf .
  3. Menu -> Print.
  4. 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

Type: enhancement → defect
Has Regression Range: --- → no
Has STR: --- → yes
Whiteboard: [old-ui-] → [print2020_v81][old-ui-]
Has Regression Range: no → yes

(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #1)

Regression Range

This is an m-c pushlog, but it's very recent - can you narrow it down further?

Flags: needinfo?(cornel.ionce)
Severity: -- → S2
Priority: -- → P2

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.

(In reply to :Gijs (he/him) from comment #2)

(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #1)

Regression Range

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.

Flags: needinfo?(cornel.ionce)

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.

Flags: needinfo?(cornel.ionce)
Component: Printing → Printing: Output
Product: Toolkit → Core

For the moment I'm going to assume "janky" since that's what the recording appears to show.

See Also: → 1660602
Summary: Print preview UI glitch on scrolling for documents with multiple pages → New print preview UI very janky scrolling documents with multiple pages

After analyzing comment 5, this seems to be indeed "janky". I'm seing this for both black& white and color modes.

Flags: needinfo?(cornel.ionce)

(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?

Flags: needinfo?(cornel.ionce)

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.

Flags: needinfo?(cornel.ionce)

(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?

Flags: needinfo?(jwatt)
Whiteboard: [print2020_v81][old-ui-] → [print2020_v82][old-ui-]

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.

Whiteboard: [print2020_v82][old-ui-] → [print2020_v83][old-ui-]
Flags: needinfo?(jwatt)
Whiteboard: [print2020_v83][old-ui-] → [print2020_v84][old-ui-]
Whiteboard: [print2020_v84][old-ui-] → [print2020_v85][old-ui-]
Whiteboard: [print2020_v85][old-ui-] → [print2020_v87][old-ui-]
Keywords: perf
Whiteboard: [print2020_v87][old-ui-] → [print2020][old-ui-]

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)?

Severity: S2 → S3
Component: Printing: Output → Print Preview
Flags: needinfo?(cornel.ionce)
Flags: needinfo?(cornel.ionce) → needinfo?(vlad.lucaci)

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.

Flags: needinfo?(vlad.lucaci)

(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?

Flags: needinfo?(dholbert)

Yup, seems like it. (Thanks, Vlad!)

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: