[api-minor] Render high-res partial page views when falling back to CSS zoom (bug 1492303)

[nicolo-ribaudo]

Commit:

Render high-res partial page views when falling back to CSS zoom

When rendering big PDF pages at high zoom levels, we currently fall back to CSS zoom to avoid rendering canvases with too many pixels. This causes zoomed in PDF to look blurry, and the text to be potentially unreadable.

This commit adds support for rendering part of a page (called PDFPageDetailView in the code), so that we can render portion of a page in a smaller canvas without hiting the maximun canvas size limit.

Specifically, we render an area of that page that is slightly larger than the area that is visible on the screen (100% larger in each direction, unless we have to limit it due to the maximum canvas size). As the user scrolls around the page, we re-render a new area centered around what is currently visible.

To play around with this patch, you need to use a large PDF (the one I'm using is https://www.gtt.to.it/cms/risorse/urbana/mappa/mapparete.pdf) and zoom in: in the current release the text becomes blurry, while with this patch it remains sharp. Also, if you set maxCanvasPixels to a smaller value (for example, 8M) you'll more clearly see the effects also at lower zoom levels. Note however that if maxCanvasPixels is set to less than 9 time the number of pixels visible in your window you'll get more frequent re-renders as you scroll.

The PDFPageDetailView class still process every single operation of the PDF, even if many of them will actually be outside of the canvas and thus not be actually rendered. This is acceptable because we are only rendering one "detail view" per page at a time, and we are not splitting the page in multiple tiles that might appear at the same time on the screen. In the future however #19043 could improve the performance of this patch, and it would enable (for example) tiling a page into multiple detail views when printing it.

There are some very minor TODOs that I left in the code, for some areas I need review feedback for. Also, I still need to find the best way to write tests.

Fixes #14147

Before:

After:

https://www.gtt.to.it/cms/risorse/urbana/mappa/mapparete.pdf at 400% zoom

Before:

After:

Fixes #14193

[nicolo-ribaudo]

After discussing this patch with @calixteman, I updated it to prioritize rendering the full css-zoomed canvas rather than the high-resolution one. This means that, when zooming in, you'll first see the css-zoomed canvas, and then it will be replaced by the high-res one once it's ready. It's a slightly worse experience, however it guarantees that we do not regress in cases where the user starts moving around before that we are done rendering the background canvas (because if only the high-res canvas is there, they'll see just white until when the new high-res canvas is rendered).

I also changed the logic that decides when to re-render the high-res canvas to not only do it once the user scrolls past its edges, but when the user is close to scrolling past the edges.

[nicolo-ribaudo]

Unfortunately this approach has a problem right now: since the various SVG paths for drawings are inserted inside the .canvasWrapper, they are now behind the detail layer and thus not visible. Marking as draft until this is fixed.

[nicolo-ribaudo]

Fixing the drawing problem required changing the new canvas to be in the existing .canvasWrapper, rather than in a separate layer. This actually ended up simplifying the code a bit, and the canvasWrapper management logic is now fully contained in PDFPageView.

[Snuffleupagus]

Leaving a few more comments, mostly for the first patch since I've only begun looking at the Render high-res partial page views when falling back to CSS zoom commit (and that one requires careful checking).

Also, is this new functionality anything that we could "easily" test with e.g. integration-tests?

[nicolo-ribaudo]

I'm working on adding some meaningful tests.

[calixteman]

LGTM. Thank you.

[marco-c]

Once @calixteman is OK with this, I'll look through the PR one final time.

@Snuffleupagus could you have another look now that Calixte approved the PR?

[Snuffleupagus]

could you have another look now that Calixte approved the PR?

I'm planning to, once the outstanding review comments are addressed.

[nicolo-ribaudo]

All comments addressed!

[Snuffleupagus]

r=me, this is great stuff; thank you.

[Snuffleupagus]

/botio integrationtest

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_integrationtest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/168af60beed6c91/output.txt

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_integrationtest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/79b6cc7d5de96e4/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.241.84.105:8877/168af60beed6c91/output.txt

Total script time: 11.35 mins

• Integration Tests: FAILED

[nicolo-ribaudo]

Ughhhh the failure seems related, taking a look.

[moz-tools-bot]

From: Bot.io (Windows)

---

Failed

Full output at http://54.193.163.58:8877/79b6cc7d5de96e4/output.txt

Total script time: 28.81 mins

• Integration Tests: FAILED

[Snuffleupagus]

Ughhhh the failure seems related, taking a look.

Maybe not, since I believe that we've very occasionally seen that in other PRs as well.

[nicolo-ribaudo]

Maybe not, since I believe that we've very occasionally seen that in other PRs as well.

Happy to get this merged and keep investigating then.

I can reproduce it locally if I comment out the await awaitPromise(handle) in https://github.com/mozilla/pdf.js/blob/e3ea92603d17595aad4b1c37c7113cb7dee0c90e/test/integration/viewer_spec.mjs#L353C11-L353C55, which makes me think that on the bots sometimes that promise is already resolved due to a pagerendered event triggered from the "zoom reset" in beforeEach (since there we are waiting for the first page to be done rendering, rather than all of them).

I can open another PR to verify if that's indeed the problem and fix it (the easiest solution would be to use a PDF with a single page in those tests, or to only consider pagerendered events for the first page).

[Snuffleupagus]

/botio-linux integrationtest

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_integrationtest from @Snuffleupagus received. Current queue size: 1

Live output at: http://54.241.84.105:8877/16b415b90330787/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.241.84.105:8877/16b415b90330787/output.txt

Total script time: 11.41 mins

• Integration Tests: Passed