Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set the first pdfPage immediately in {BaseViewer, PDFThumbnailViewer}.setDocument #11374

Merged
merged 1 commit into from
Dec 1, 2019

Conversation

Snuffleupagus
Copy link
Collaborator

This patch is simple enough that I almost feel like I'm overlooking some trivial reason why this would be a bad idea.

Note how in {BaseViewer, PDFThumbnailViewer}.setDocument we're always getting the first pdfPage in order to initialize all pages/thumbnails.
However, once that's done the first pdfPage is simply ignored and rendering of the first page thus requires calling PDFDocumentProxy.getPage yet again. (And in the BaseViewer case, it's even done once more after onePageRenderedCapability is resolved.)

All in all, I cannot see why we cannot just immediately set the first pdfPage and thus avoid an early round-trip to the API in the _ensurePdfPageLoaded method before rendering can begin.

…er}.setDocument`

*This patch is simple enough that I almost feel like I'm overlooking some trivial reason why this would be a bad idea.*

Note how in `{BaseViewer, PDFThumbnailViewer}.setDocument` we're always getting the *first* `pdfPage` in order to initialize all pages/thumbnails.
However, once that's done the first `pdfPage` is simply ignored and rendering of the first page thus requires calling `PDFDocumentProxy.getPage` yet again. (And in the `BaseViewer` case, it's even done once more after `onePageRenderedCapability` is resolved.)

All in all, I cannot see why we cannot just immediately set the first `pdfPage` and thus avoid an early round-trip to the API in the `_ensurePdfPageLoaded` method before rendering can begin.
@timvandermeij
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

pdfjsbot commented Dec 1, 2019

From: Bot.io (Linux m4)


Received

Command cmd_preview from @timvandermeij received. Current queue size: 0

Live output at: http://54.67.70.0:8877/6e5392cc21e8326/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Dec 1, 2019

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/6e5392cc21e8326/output.txt

Total script time: 1.71 mins

Published

@timvandermeij timvandermeij merged commit 514b500 into mozilla:master Dec 1, 2019
@timvandermeij
Copy link
Contributor

However, once that's done the first pdfPage is simply ignored

I'm also a bit puzzled by this and I can't imagine why we wouldn't use it if it's already loaded. The patch looks good to me; thanks!

@Snuffleupagus Snuffleupagus deleted the set-first-pdfPage branch December 1, 2019 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants