GNOME Bugzilla – Bug 691448
Regression: Scrolling thumbnails in long PDF documents is slow
Last modified: 2017-12-04 07:25:44 UTC
Previously in evince (I think before gnome3-style merge), navigating using thumbnails was fast, where 'fast' is good enough to be bothered. With evince master, using the thumbnails in a long PDF documents does not feel as responsive as it was. The document I checked is PDF reference. The scrollbar goes slower than the mouse and it takes between 1 to 2 seconds to render the thumbnails. The performance improves if I hide the sidebar, but still feels slower than 3.4.0. In the latter the render happens almost immediate. I tested it also with evince 3.4.0/poppler 0.18 and it is more responsive.
Germán... I can't provide a proof, but I believe this is a bug in Gtk+, not in evince. I tried to bisect, but I couldn't get a good-working version of evince (even ones that I think were good before)
Well, we are now rendering the thumbnail frame in the main thread instead of the worker thread, it might be related. German, could you try to disable the frame rendering and check if it's still slow for you?
In fact, I can also reproduce in my Fedora 18 machine (meaning evince 3.6.0 with poppler 0.20) Carlos, can you point me to the commit where the thumbnail render is changed?
http://git.gnome.org/browse/evince/commit/?id=30d1c3f4d71d5f53603076c7c93a5999e65eec5a
It seems to me the regression is in GTK+. While I was compiling 3.6.0 (because I went back while bisecting) I recalled why I thought the regression was introduced after the merge of gnome3-style merge (or around that time). Before that merge, I was compiling evince against my stock GTK in Ubuntu (3.4.2), but later I had to compile GTK 3.7.x and link evince against the new one. FWIW, it was the a11y fix that forced the use of GTK 3.7.5. It seems the commit http://git.gnome.org/browse/evince/commit/?id=b8be5a752 is the last one that can be tested with an older GTK. I suppose GTK 3.6.0 works ok because of José's comment.
Oops, I forgot to mention the most important thing: I can reproduce the regression with 3.6.0 and GTK+ 3.7.5.
Germán, this is older... the f18 evince has this issue (that means 3.6.0 and gtk+3.6) There is clearly a lock contention somewhere, but I am not keen on finding these things
(In reply to comment #7) > Germán, this is older... the f18 evince has this issue (that means 3.6.0 and > gtk+3.6) There is clearly a lock contention somewhere, but I am not keen on > finding these things Oh, I misunderstood your first comment, then :-) The commit that Carlos pointed out is newer than 3.6.0 :-) Anyway, I still can reproduce it with evince 3.4.0 linked to GTK 3.7.5, but not with 3.4.0 and linked to GTK 3.4.2.
So I finally know what's happening... We are using a sort of "lazy loading" on the IconView in the sense that we render the thumbnails async and only visible and near visible ones. In this process we modify twice, for each page, the associated item in the ListStore, thus emitting a row-changed signal. The GtkIconView row-changed signal will trigger a complete relayout of the IconView... which in a document with 400 pages takes around 50ms in my machine. Of course, 50ms is really slow when scrolling... (since this happens for each page that gets rendered)... also this is happening on the main loop. Jikes! So the workaround for this would be to avoid the emission of the row-changed signal... another thing is to make IconView smarter so it does not relayout everything each time some row has changed in the model.
Although still would be slow, it might be alleviated by fixing https://bugzilla.gnome.org/show_bug.cgi?id=342110
According to Alex's post on changes on Gtk drawing model: "Due to the above, old scrolling code is slower, so we do scrolling differently. Containers that scroll a lot (GtkViewport, GtkTextView, GtkTreeView, etc) allocate an offscreen image during scrolling and render their children to it (which is now possible since draw is fully hierarchical). The offscreen image is a bit larger than the visible area, so most of the time when scrolling it just needs to draw the offscreen in a different position. This matches contemporary graphics hardware much better, as well as allowing efficient transparent backgrounds. In order for this to work such containers need to detect when child widgets are redrawn so that it can update the offscreen. This can be done with the new gdk_window_set_invalidate_handler() function." Maybe the icon view needs some update.
The URL of the post is: http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/
The PDF book available here is slow to scroll if thumbnails are shown: http://lepassagerclandestin.fr/catalogue/essais/utopie-du-logiciel-libre.html http://lepassagerclandestin.fr/fileadmin/assets/catalog/essais/Utopie_logiciel_libre__Broca__Le_passager_clandestin.pdf Is slow when page scrolling. One CPU core it at 100% freezing temporary evince 1 or 2 sec at each page scrolling. If I hide the thumbnails pane it becomes fluid. evince 3.10.3 xubuntu 14.04 up to date.
For me, it does not matter if it is icon view or index view. It gets better if sidepane is hidden. Evince 3.18.2-1ubuntu4 on Ubuntu 16.04
*** Bug 756832 has been marked as a duplicate of this bug. ***
Thumbnail generation and the whole thumbnail scrolling is incredibly buggy. As mentioned above, the number one issue is speed of thumbnail generation. Second issue is that if you scroll through the thumbnails, they are constantly regenerated and are not cached. It takes 1-2 seconds to generate a thumbnail of a LibreOffice Presentation generated PDF on a 4 core machine. And when you scroll, every thumbnails previously generated just disappears and is regenerated again when you stop scrolling. I've compared this behavior to every other PDF viewer I could find in AUR and all of them (with the exception of evince forks which suffer from same issues) have outperformed Evince. Other PDF viewers generate thumbnails in a fraction of a second and don't regenerate them when you scroll thumbnails out of the view. Version tested: evince 3.22.1
*** Bug 782891 has been marked as a duplicate of this bug. ***
Created attachment 352756 [details] [review] sidebar-thumbnails: fix clunky scrolling [PATCH] sidebar-thumbnails: fix clunky scrolling Caused by GtkIconView doing an invalidate and relayout of *all* items in the view anytime we update model data in any indiviual item (which happens with all the items that are getting in and out of the scrolling area while we scroll). This caused GtkIconView to machine-gunned us with "size-allocate" signals, a signal we were using to update thumbnails when the sidebar is resized. Fixed by connecting to the GtkTreeModel "row-changed" signal before GtkIconView does it, and stop emission from there. As we don't depend now on "size-allocate" signals to show thumbnails while we scroll, just queue a draw on the icon view when a thumbnail finish rendering. Thanks Jose Aliste for first spotting the problem. https://bugzilla.gnome.org/show_bug.cgi?id=691448
Review of attachment 352756 [details] [review]: Oh. Thanks for this. This is actually quite clever workaround. Of course... in the long term we should switch to more modern widget.
Comment on attachment 352756 [details] [review] sidebar-thumbnails: fix clunky scrolling Ok.
Review of attachment 352756 [details] [review]: It's now committed, thank you!
*** Bug 701537 has been marked as a duplicate of this bug. ***
*** Bug 730280 has been marked as a duplicate of this bug. ***
Shouldn't we commit this to stable branch as well? Carlos?
(In reply to José Aliste from comment #24) > Shouldn't we commit this to stable branch as well? Carlos? Ok, I've just backported it.
*** Bug 768436 has been marked as a duplicate of this bug. ***
*** Bug 783671 has been marked as a duplicate of this bug. ***