GNOME Bugzilla – Bug 137439
Big PDF files are too long to open because of thumbnails creation
Last modified: 2006-01-29 21:56:51 UTC
When a bug file is opened, the opening/displayed delay is too long and do not reflect the pdf feature for quick document display (no need to read the whole file). Thumbnails should be adapted to only be created at will, when really needed.
A thought for 2.6.1: The thumbnails are all created in one big loop in one single idle iteration. Can we change that to do, like 10 thumbnails in one idle iteration, then 10 in the next idle iteration? Or is there code that might break if not all thumbnails are ready from the start? And, of course, is your idea just as easy to implement as what I wrote above? Then (because your idea is obviously more elegant) ignore what I wrote ;-)
All following should be really easy to implement Imagine: open a document with sidebar invisible -> no thumbnail creation at all Ask for thumbnail view to be visible -> just need to fill the visible scroll region of the thumbnail sidebar with empty images (from 5 to 20) all in one idle. Then continue with images generation, current page in main thread and other visibles each in one idle. For 2.6 I think we should adopt something like eog thumbnailer architecture (independant component managing threads queues for thumbs generation)
Taking ownership. Gonna prototype it in dev branch
Martin I commited a simple change in head to fix this bug. It is a first step for fixing this bug but the visual result is pretty good and it let use the display pretty quickly. I'd like to commit this also on 2-6 (really a great enhancement for users) ... Can you have a look at head 2004-05-09 Remi Cohen-Scali <rcoscali@cvs.gnome.org> First step for fixing Bug #137439 * xpdf/gpdf-thumbnails-view.cc: Add a counter for keeping track of current thumb generated. (gpdf_thumbnails_view_set_scroll_region): While setting scroll region, the loop is now between page 1 and last generated one (current_gen_thumb) to be able to relayout while generating thumbs. (gpdf_thumbnails_view_create_thumbnail): Added thumb coords. Computation while creating is based on a guess. The layout may be not perfect but it will be correctly relayout as soon as finished. (gpdf_thumbnails_view_populate_idle): Changed idle logic in order to only generate one thumb for each call. This way we never freeze display. (gpdf_thumbnails_view_set_pdf_doc): Moved thumb generation inits from idle. Set guess for page width/height to have a semi correct layout.
Created attachment 27498 [details] [review] Patch for rought change of idle usage at thumb generation Here is a patch for gnome-2-6 branch
I also changed bookmarks to have the same behavior. Now I open a 1000 pages document in 1 or 2 seconds !!!! May I commit on 2-6 (no string changes) ? P.S.: The patch seems huge but most of it is just some code displacement and indentation changes
Created attachment 27512 [details] [review] Thumbs & bookmarks idle fix + a bookmarks fix
Created attachment 27513 [details] [review] Bookmarks & Thumbs idle fix + a Bookmarks fix (all apply smoothly on 2-6)
I haven't read the patch yet, but there seams to be some infinite loop or similar. With a one page pdf (without embedded thumbnails) my processor goes 100% and doesn't go down again. But for large docs, the speedup is great!
Yes I found it. Already fixed. Was because of the bookmarks. When no bookmarks the idle was never finished (always returned TRUE). I just commited the fix, with some feedback for users. A light version (without string change) could be commited for 2.6. Don't you think so ?
Created attachment 27570 [details] [review] Bookmarks & Thumbs idle fix + two Bookmarks fix + light user feedback (for gnome-2-6) The light version without string to translate
All these patches are in CVS now, aren't they? If yes, please close the bug.
The current implementation in CVS is only a quick fix. The next version should : 1) compute/display in the background 2) only compute display the visibles thumbnails 3) have the ability to not store thumbnails, but compute then when needed (gpdf sometimes reach some 200 Mb size for a 10 Mb document) The 1) is in CVS. The 2) & 3) are not but should.
I think that the thumbnail generation/extraction should be optional and it should be a preference (either in GConf or in the program itself). So opening many pdf documents at the same time would be faster and it wouldn't require so much memory.
Gpdf is no longer maintained, closing WONTFIX. Please use Evince for your pdf viewing needs. http://www.gnome.org/projects/evince/
evince has a bad habit of rendering pages in sequence even when you've warped way forward, and of rendering the thumbnails before the currently visible page. This wouldn't matter if it rendered everything instantly, but it doesn't (and probably never will). I think this bug will do nicely as a report of that problem. Reopen, reassign to evince.