-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Update thumbnails only when they are visible (to improve scrolling through large documents) #5586
Update thumbnails only when they are visible (to improve scrolling through large documents) #5586
Conversation
good first step. i think with regards to reflow there are quite a few optimizations possible. |
really good. is there a reason why we cannot just cancel scrollThumbnailIntoView from 'pagechange' completely when !isThumbnailViewEnabled? (the patch looks a little bit "asymmetrical" IMHO) I'm trying to avoid this.renderingQueue.isThumbnailViewEnabled check and refreshing during its state update from different location (which is still named scrollThumbnailIntoView). |
Maybe not. Returning immediately if Also I'm not too happy with the reference to the rendering queue in |
d5dd27f
to
9aa3b24
Compare
I updated the commit. Now scrollThumbnailIntoView is only called if |
this solves quite a few concerns for us. thanks! |
I've found one small issue with this patch:
Probably the easiest way to solve this is to check |
9aa3b24
to
4271bf4
Compare
@Snuffleupagus: I didn't manage to reproduce the warning, but I added the check anyway. Thanks. |
/botio-linux preview |
From: Bot.io (Linux)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://107.21.233.14:8877/3c8cc003d4850d0/output.txt |
From: Bot.io (Linux)SuccessFull output at http://107.21.233.14:8877/3c8cc003d4850d0/output.txt Total script time: 0.78 mins Published
|
I can confirm that this fixes the issue I was seeing! |
4271bf4
to
6f99d68
Compare
I added a second commit: Update thumbnail images only when sidebar is visible. This finally makes scrolling smooth as butter, as long as thumbnails are off. Updating the thumbnail images causes one or two reflows (setting the image and setting the data-loaded css class), which were causing the lags.
|
/botio-linux preview |
From: Bot.io (Linux)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://107.21.233.14:8877/16397a37e238e5e/output.txt |
From: Bot.io (Linux)SuccessFull output at http://107.21.233.14:8877/16397a37e238e5e/output.txt Total script time: 0.80 mins Published
|
Fixes #3120. Really nice work! |
@@ -1221,6 +1221,23 @@ var PDFViewerApplication = { | |||
} | |||
}, | |||
|
|||
refreshSidebar: function pdfViewOpenSidebar() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: refreshSidebar
seems like a slightly strange name, since the function only updates the thumbnails. How about refreshThumbnailViewer
or something similar?
6f99d68
to
cd22b9b
Compare
@Snuffleupagus I agree. Commit is updated. |
cd22b9b
to
30b3bb4
Compare
I also changed the css style of the hidden sidebar container from |
This is a great idea, but unfortunately it causes the "open sidebar" animation to behave strangely. The sidebar now opens instantaneously, while the toolbar still transitions correctly. Interestingly the "close" animation still works as it should. |
30b3bb4
to
4555b56
Compare
@Snuffleupagus You're right, good point. It seems like this cannot be fixed in pure CSS, because the So I see three possibilities for this change:
Reasons for 1: It's only relevant in edge cases, where documents have thousands of pages and thumbs are off. And performance issues are mostly resolved already in this PR. Solution 2 is kinda hacky. Reasons for 2: A slimmer DOM tree is always welcome, and removing thousands of DOM elements from the layout are definitely noticeable in the UI responsiveness for large documents. Also saves some memory (1KB / page). Any opinions? |
preferring display: none over visibility hidden is a good idea. it should be worked on in a follow up pr. |
My opinion is that we should not regress the current behaviour. I think we can try to implement the |
@fkaelberer Will manually setting the diff --git a/web/viewer.css b/web/viewer.css
index 91e64ea..affcc9a 100644
--- a/web/viewer.css
+++ b/web/viewer.css
@@ -166,7 +166,8 @@ html[dir='rtl'] .innerCenter {
top: 0;
bottom: 0;
width: 200px;
- visibility: hidden;
+ max-height: 0px;
+ max-width: 0px;
-webkit-transition-duration: 200ms;
-webkit-transition-timing-function: ease;
transition-duration: 200ms;
@@ -186,7 +187,8 @@ html[dir='rtl'] #sidebarContainer {
#outerContainer.sidebarMoving > #sidebarContainer,
#outerContainer.sidebarOpen > #sidebarContainer {
- visibility: visible;
+ max-height: inherit;
+ max-width: inherit;
}
html[dir='ltr'] #outerContainer.sidebarOpen > #sidebarContainer {
left: 0px; |
Needs merge. |
4555b56
to
6aa5d5c
Compare
Merged. |
I think together with #5617 this is good to go. |
I reported the scrolling performance regression of FF37 upstream: |
@fkaelberer Could you rebase this since the thumbnail code has been refactored in #5673? |
6aa5d5c
to
d3022e1
Compare
Rebased. |
/botio-windows preview |
From: Bot.io (Windows)ReceivedCommand cmd_preview from @yurydelendik received. Current queue size: 0 Live output at: http://107.22.172.223:8877/a93b27c12834f05/output.txt |
From: Bot.io (Windows)SuccessFull output at http://107.22.172.223:8877/a93b27c12834f05/output.txt Total script time: 0.88 mins Published |
…enVisible Update thumbnails only when they are visible (to improve scrolling through large documents)
Thank you |
…sOnlyWhenVisible Update thumbnails only when they are visible (to improve scrolling through large documents)
This PR postpones highlighting the current page thumbnail in
PDFThumbnailViewer.scrollThumbnailIntoView()
until the thumbnail view is opened. Setting the style of thumbnails can take long and become a bottleneck if the document (and thus, the DOM tree) is very large. Scrolling through very large documents is now smoother with this PR.Good tests:
[1] pdf (2000+ pages) from #5207 and
[2] pdf (3000+ pages) from https://bugzilla.mozilla.org/show_bug.cgi?id=885287#c6.
[3] pdf (5000+ pages)
A benchmark: Scrolling through the first 50 pages of [3] with the
↓
key:Another benchmark: While scrolling through the first 10 pages of [1] with the
↓
key, the frame rates are now much more often at the 60 fps mark (FF Nightly 37.0a1):EDIT: Added correct link to [3] which I had used for benchmarking, added Firefox 34 results (which shows performance regression of Nightly)