1722807 - PDF viewer fails to render a page quickly enough and in the meantime it blocks FF UI thread (maybe due to memory usage). It should not block.

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[ISHIKAWA, Chiaki]

Attachment: The memory usage jumps up as soon as the page is loaded and rendering starts.

My hardware: I have 32GB on Windows 10 Pro PC (64bit) with AMD Ryzen 7 1700 Eight-Core Processor 3.00 GHz

A Japanese government website lists the following PDF.
https://www.mhlw.go.jp/content/10900000/000812892.pdf

Trying to render this PDF using FF 90.0.2 (64-bit) results in blocked FF sometimes.
In one instance, for about a dozen minutes I cannot operate on FF since FF UI is blocked.
PDF renderer should not block UI interaction.
I can live with slow rendering as long as FF UI is not blocked.

Most of the times, if I scroll down a page or two using the scroll bar, I get blocked for a dozen seconds or so, and then something is plotted on screen (not complete).
Maybe a couple of minute later, the numerical table is shown, but I am not sure if the table is complete because if I scroll down, again some rendering occurs and quite likely I get blocked again.

I get a crashed tab during a test, too. So there is something wrong with PDF.js when it handles this PDF file.

I found out rendering this page consumes large amount of memory.
FF started to use 32GB memory quickly.
In the instance where the rendering blocked FF for almost a dozen minute, it tried to use all the swap area, too (I think I have swap set to 32 or 33 GB).
When the real memory is used up, the UI of FF gets sluggish, and even system level interaction gets sluggish when the swap limit is reached. too.

But most of the time, the memory usage goes to almost 32GB of memory (maybe 500MB memory left) and then stays there for about a few dozen seconds and the gradually comes down. The appearance of some incomplete images on screen happens when the memory usage started to come down.

In contrast, Google Chrome can render this page in no time flat. The difference is amazing.

I think whatever is causing this inefficient memory usage and blocking due to it should be investigated and fixed.

Comment 1

[ISHIKAWA, Chiaki]

Attachment: A partial table on the screen after a few minutes of activity.

If I let FF to draw continuously for a few minutes, I get a screen like the attachment, but as soon as I try to scroll the image, another memory usage jump and hung UI.

Comment 2

[ISHIKAWA, Chiaki]

Attachment: Example of partial drawing shown on the screen while the drawing stops and UI gets blocked.

But as soon as I scroll the image (after changing the magnification to look at the whole table if possible), the UI gets blocked and some random drawing takes place.

You can use Google Chrome to confirm that the PDF includes a few dozen numerical tables and
Google chrome can show the tables quickly without any discernible delay at all.

Comment 3

[ISHIKAWA, Chiaki]

The crashdump I got during the testing is this.
bp-eb7856fd-d917-4369-8797-e64180210728

TIA.

Comment 4

[Brendan Dahl [:bdahl]]

Changing severity to S3 because it renders, but is very slow.

Comment 5

[Brendan Dahl [:bdahl]]

Is this a regression?

Comment 6

[ISHIKAWA, Chiaki]

(In reply to Brendan Dahl [:bdahl] from comment #5)

Is this a regression?

To be frank I am not sure.

I have experienced slowness, but not as sever as this one before I hit upon this PDF file.

I suspect that there are some constructs in this PDF that trigger inefficient
memory allocation/handling in pdf.js. which is inherent today.

Are old FF binaries for Windows available somewhere?
I may check a few older versions, but I suspect they were slow as well.
Come to think of it, maybe I can simply replace pdf.js versions instead of different FF binaries? (Installing different FF versions creating different profiles is a bit of chore.)

Comment 7

[Jonas Jenwald [:Snuffleupagus]]

(In reply to Brendan Dahl [:bdahl] from comment #5)

Is this a regression?

Yes, this used to perform better (with less memory usage) and mozregression points to the following pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5c402eaa028455bb2c837bb0068741f43d566787&tochange=1a154c35b1b1673c4e9f79c0f38c3d12daa71a6b

Hence this is a regression from bug 1711106, and based on the changelog my guess is that it regressed in PR https://github.com/mozilla/pdf.js/pull/13361

Comment 8

[Brendan Dahl [:bdahl]]

This PDF has hundreds of shading patterns that are slightly different. This causes PDF.js to create many large (same size as the page) pattern canvases that increase the memory usage. I see two ways to fix this:

1. Go back to the old way for the gradient patterns and don't create a pattern canvas, but instead use the gradient directly. This isn't correct for all PDFs and is why I changed it in the regressing bug. However, we can directly use the gradient in the case of this PDF since it has uniform scaling and skewing in the transformation.

2. Track the current fill path bounding box and only create a pattern canvas that matches size of the bounding box. This reduces the memory consumption quite a bit.

Both options have some downsides, so I'm still trying to choose the least bad option.

Comment 9

[ISHIKAWA, Chiaki]

(In reply to Brendan Dahl [:bdahl] from comment #8)

This PDF has hundreds of shading patterns that are slightly different. This causes PDF.js to create many large (same size as the page) pattern canvases that increase the memory usage. I see two ways to fix this:

1. Go back to the old way for the gradient patterns and don't create a pattern canvas, but instead use the gradient directly. This isn't correct for all PDFs and is why I changed it in the regressing bug. However, we can directly use the gradient in the case of this PDF since it has uniform scaling and skewing in the transformation.

2. Track the current fill path bounding box and only create a pattern canvas that matches size of the bounding box. This reduces the memory consumption quite a bit.

Both options have some downsides, so I'm still trying to choose the least bad option.

Thank you for looking at this.

Have you checked how Google chrome handles this PDF?
When the problem was noticed, I tried to use adobe acrobat which could render the PDF very fast, and to my surprise, Google chrome also handled this without much delay or problem. I was quite surprised.
So, as far as this particular PDF is concerned, whatever Google chrome does seem to be a win.

I have no idea why such a PDF is created, but obviously somebody tried to create a numerical table out of the observation of Covid-19 patients across Japan over several months and the large numerical tables were produced. And whoever created the PDF used probably Adobe acrobat which did not have an issue in rendering the pages in a reasonable time.
I am not sure what is "reasonable", but for me, even if I have to wait for drawing to finish, as long as the UI operation is not blocked due to memory swap, I am fine. I can wait.
But if UI operation gets blocked, I get annoyed very much.
That is my definition of "reasonable".

Thank you again.

Comment 10

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/14230

Comment 11

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub master push: https://github.com/mozilla/pdf.js/commit/38efd13a54021651fb7d90ebb4ca5e20609985e4

Commit merged into master by GitHub
Authored by Jonas Jenwald (Snuffleupagus)

Comment 12

[Marco Castelluccio [:marco]]

Fix landed in GitHub, we can close this bug after the next pdf.js update in m-c.

Comment 13

[Monica Chiorean]

Hi Brendan,

I reproduced the slowness and partially loading of the https://www.mhlw.go.jp/content/10900000/000812892.pdf on build 90.0.2 (64-bit) on Win10.
So I tried to verify this issue on latest NB 97.0a1 (20211212214735) but it seems that when loading the site it crashes (https://crash-stats.mozilla.org/report/index/e12aea93-4e53-4eee-b5ff-d6d2b0211213). I also attached a screenshot.

Can I reopen this issue for the crash? Thank you so much.

Comment 14

[Monica Chiorean]

Attachment: Crash from NB 97.0a1

Comment 15

[Marco Castelluccio [:marco]]

(In reply to Monica Chiorean from comment #13)

Hi Brendan,

I reproduced the slowness and partially loading of the https://www.mhlw.go.jp/content/10900000/000812892.pdf on build 90.0.2 (64-bit) on Win10.
So I tried to verify this issue on latest NB 97.0a1 (20211212214735) but it seems that when loading the site it crashes (https://crash-stats.mozilla.org/report/index/e12aea93-4e53-4eee-b5ff-d6d2b0211213). I also attached a screenshot.

Can I reopen this issue for the crash? Thank you so much.

Could you file a new bug for the crash? It seems to be a WebRender crash, so you can file it in the Core::Graphics:: WebRender component.

Comment 16

[Monica Chiorean]

Crash is not reproducing on latest Nightly build 101.0a1 (20220429094842) on Win10, it might get fixed since I first reported it. On Beta 100.0b9(20220421201645) is also loading without issues. So marking issue as verified.