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.

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.241.84.105:8877/01b208fd694bf18/output.txt

Total script time: 11.77 mins

• Integration Tests: FAILED

[moz-tools-bot]

From: Bot.io (Windows)

---

Failed

Full output at http://54.193.163.58:8877/f2b8799df1036f9/output.txt

Total script time: 26.62 mins

• Integration Tests: FAILED

[nicolo-ribaudo]

The tests for this PR now passed 🎉

There are some timeouts regarding the FreeText editor tests, and I'm getting flaky timeouts on them locally too (both on this branch, and on 8358ab6, which is the commit that this branch is based on). I'll try rebasing, since I see that there are new commits that touch those tests.

---

EDIT: Rebasing didn't help, at least locally. I'm still getting timeouts from the FreeText tests both with this PR and on master.

[nicolo-ribaudo]

I'm still working on a bug found by @calixteman about some race condition between scrolling and zooming:

Sometimes, when quickly scrolling and zooming, we render the contents of the detail canvas with the right scale, but we use a previous scale to determine how large it should be.

[Snuffleupagus]

Does this PR fix issue #12957 as well?

[nicolo-ribaudo]

Half way. With the current release you can only see that PDF if the zoom is low, and with this PR you can also see if the zoom is high (when the detail view triggers).

I still see it as blank at "medium" zoom level, probably because the canvas is too tall for Firefox but its area is too small for the css-only/detail-view logic to apply. A good fix would be to trigger the css-only/detail-view logic earlier, not just based on the canvas area but also on its width/height.

I'd leave that issue open for now.

[nicolo-ribaudo]

The last commit should fix #19128 (comment). Unfortunately it is very racy behavior and I'm not able to write a test.

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

Make sure that the #detailArea is not used from a previous computation
with a different scale.

The #detailArea can become out of date when very quickly alternating
between scrolling and zooming. This causes the canvas to be too big,
even if then the rendered contents have the right scale.

This commit:

1. changes #shouldRenderDifferentArea so that, whenever the scale
   changes, it forces re-computing what is the size of the new canvas
   to render.
2. making sure to trash the detail area of pages that are not visible
   anymore, so that we don't risk trying to render it before calling
   update().

I have been scrolling and zooming around the Tracemonkey PDF for 5 minutes (with maxCanvasPixels: 2 **20, which makes the issue more present) and the problem didn't happen anymore, while before that commit it was happening in about 1 minute of random scrolling and zooming.

[nicolo-ribaudo]

I was playing with this on Firefox on Android, and noticed that the way this PR handled the detail canvas is quite annoying: when scrolling/zooming, the rendering gets cancelled very often and thus there is no new canvas to replace the old one. The last commit fixes it.

Here is a video with the before/after (before is the before the page reload, after is after the page reload).

Record_2025-01-23-12-26-52.mp4

[calixteman]

nit: -TRESHOLD+THRESHOLD

[Snuffleupagus]

I don't know how much it matters in practice, but won't returning here without trigger rendering effectively stop any possible pre-rendering of other currently invisible pages?

Until either another page becomes more visible or scrolling stops, it seems that the getHighestPriority-method will now always break here.

Would it make (any) sense to e.g. set the detailView-renderingState to FINISHED when renderingCancelled === true such that other pre-rendering can still run?