[api-minor] Render high-res partial page views when falling back to CSS zoom (bug 1492303) #19128
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
3 times, most recently
from
2f715cb to
5ad7743
Compare
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
3 times, most recently
from
4d80dcc to
074c515
Compare
|
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
force-pushed
the
draw-page-portion
branch
from
074c515 to
b711cf5
Compare
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
2 times, most recently
from
69a98fc to
3408061
Compare
|
Unfortunately this approach has a problem right now: since the various SVG paths for drawings are inserted inside the |
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
from
3408061 to
9c13462
Compare
|
Fixing the drawing problem required changing the new canvas to be in the existing |
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
from
9c13462 to
feea3e4
Compare
There was a problem hiding this comment.
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
force-pushed
the
draw-page-portion
branch
from
feea3e4 to
ad7f77d
Compare
|
I'm working on adding some meaningful tests. |
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
from
db51d7f to
9479f88
Compare
|
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/026343628fae9c8/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/7a79d253a24948d/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/026343628fae9c8/output.txt Total script time: 11.39 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/7a79d253a24948d/output.txt Total script time: 26.77 mins
|
|
The windows-only failure for "PDF viewer CSS-only zoom triggers when going bigger than maxCanvasPixels triggers CSS-only zoom above maxCanvasPixels" could be related, I'm taking a look |
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
from
9479f88 to
e1bba12
Compare
|
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.241.84.105:8877/436dc9e45979302/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.193.163.58:8877/cc74bcfef9fd08a/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/436dc9e45979302/output.txt Total script time: 11.71 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/cc74bcfef9fd08a/output.txt Total script time: 26.34 mins
|
|
Once @calixteman is OK with this, I'll look through the PR one final time. Another small, but probably pointless, optimization would be the following: diff --git a/web/app.js b/web/app.js
index 5dfdbbd0b..08df46093 100644
--- a/web/app.js
+++ b/web/app.js
@@ -2310,7 +2310,7 @@ function onPageRender({ pageNumber }) {
}
}
-function onPageRendered({ pageNumber, error }) {
+function onPageRendered({ pageNumber, isDetailView, error }) {
// If the page is still visible when it has finished rendering,
// ensure that the page number input loading indicator is hidden.
if (pageNumber === this.page) {
@@ -2318,7 +2318,7 @@ function onPageRendered({ pageNumber, error }) {
}
// Use the rendered page to set the corresponding thumbnail image.
- if (this.pdfSidebar?.visibleView === SidebarView.THUMBS) {
+ if (!isDetailView && this.pdfSidebar?.visibleView === SidebarView.THUMBS) {
const pageView = this.pdfViewer.getPageView(/* index = */ pageNumber - 1);
const thumbnailView = this.pdfThumbnailViewer?.getThumbnail(
/* index = */ pageNumber - 1 |
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
from
e1bba12 to
5e27b06
Compare
This base class contains the generic logic for: - Creating a canvas and showing when appropriate - Rendering in the canvas - Keeping track of the rendering state
…SS zoom (bug 1492303) 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.
When scrolling quickly, the constant re-rendering of the detail view significantly affects rendering performance, causing Firefox to not render even the _background canvas_, which is just a static canvas not being re-drawn by JavaScript. This commit changes the viewer to only render the detail view while scrolling if its rendering hasn't just been cancelled. This means that: - when the user is scrolling slowly, we have enough time to render the detail view before that we need to change its area, so the user always sees the full screen as high resolution. - when the user is scrolling quickly, as soon as we have to cancel a rendering we just give up, and the user will see the lower resolution canvas. When then the user stops scrolling, we render the detail view for the new visible area.
nicolo-ribaudo
force-pushed
the
draw-page-portion
branch
from
5e27b06 to
9aedbf9
Compare
|
Rebased to solve conflicts with the autolinking PR. |
|
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/93a86c1affda7c9/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/196968bc509de42/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/93a86c1affda7c9/output.txt Total script time: 11.39 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/196968bc509de42/output.txt Total script time: 27.90 mins
|
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/e2205635278fd08/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/e2205635278fd08/output.txt Total script time: 0.86 mins Published |
Commit:
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
maxCanvasPixelsto a smaller value (for example, 8M) you'll more clearly see the effects also at lower zoom levels. Note however that ifmaxCanvasPixelsis 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
PDFPageDetailViewclass 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