Bug 250787 - PDF preview is very slow and almost not useful.
Summary: PDF preview is very slow and almost not useful.
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: panels: information (show other bugs)
Version: 2.1
Platform: Chakra Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-10 15:37 UTC by Alexander
Modified: 2014-01-06 19:19 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.12.1


Attachments
Example (194.04 KB, image/png)
2010-09-10 15:37 UTC, Alexander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2010-09-10 15:37:44 UTC
Created attachment 51515 [details]
Example

Version:           unspecified (using KDE 4.5.0) 
OS:                Linux

Subj. When I select a .pdf file (9.5 Mb) dolphin slows down the whole system for a long enough time.

Also if select a .pdf file and will not wait, until dolphin will create a preview and select an another .pdf file, after a while, when dolphin deign you to show a preview, it will be for the previous file, not for the currently selected. So, dolphin was unable to abort unnecessary operations and switch to the actual.

Reproducible: Always
Comment 1 Hans-Rudi Denzler 2010-09-10 16:44:38 UTC
What is the URI of brochure.pdf ?
Otherwise one cannot confirm it.
Comment 2 Alexander 2010-09-10 18:44:34 UTC
http://www.megaupload.com/?d=4ADN1X7Q
Also, I can reproduce it with almost all PDF's I have. Particularly bad is when I open a folder, that contain only PDF files and move the mouse pointer over them.
Comment 3 Peter Penz 2010-09-23 14:33:10 UTC
The issue with the outdated preview has been fixed in 4.5.1, however I cannot reproduce the slowdown of the system (I've also recognized that the PDF-preview plugin seems to be slow sometimes, but it did not slow down the rest of KDE or Dolphin). Just to be sure: Do you have the finally tagged 4.5.0 version? The tag has been moved shortly before the release because of a fix that might be related to this issue...
Comment 4 Alexander 2010-09-23 14:57:16 UTC
> but it did not slow down the rest of KDE or Dolphin
I think it could be related to CPU features. For me it is 100% CPU usage.

> Just to be sure: Do you have the finally tagged 4.5.0 version? The
> tag has been moved shortly before the release because of a fix that might be
> related to this issue...

Qt: 4.6.3
KDE: 4.5.1 (KDE 4.5.1)
kde4-config: 1.0

And seems that this problem wasn't fixed in this version. I do not feel free while moving the mouse pointer over PDF files, because every mouse over event for these files cause high CPU usage. And given that dolphin is unable to drop unnecessary operations and creates preview for the every that file I had mouse hovered, one by one... It could take a while...
Comment 5 Alexander 2010-10-03 20:36:51 UTC
How can I disable PDF preview on the information panel? How can I disable PDF previews at all?
Comment 6 Peter Penz 2010-10-04 11:13:28 UTC
You can disable the PDF-previews in Settings -> Configure Dolphin... -> General -> Previews -> [ ] Postscript, PDF and DVI files

Do you have those freezes also for other file-types? If yes, then probably the root-cause is related to an issue in the D-Bus library which
has been reported already. It is fixed in D-Bus 1.3.1 and later:

http://bugreports.qt.nokia.com/browse/QTBUG-7475
https://bugs.freedesktop.org/show_bug.cgi?id=17754
Comment 7 Alexander 2010-10-04 11:44:17 UTC
> You can disable the PDF-previews in Settings -> Configure Dolphin... ->
> General -> Previews -> [ ] Postscript, PDF and DVI files
Yep, i did that, but dolphin still generates previews for information panel.

pdftotext and gs processes eat all CPU.

> Do you have those freezes also for other file-types?
No, only with PDF files. But sometimes dolphin crashes on some XSL files, when hover them.
Comment 8 Alexander 2010-10-12 10:13:13 UTC
This is what I mean — http://www.youtube.com/watch?v=qGOkturkWqs
Comment 9 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:21:33 UTC
Resetting assignee to default as per bug #305719
Comment 10 Adrián Chaves (Gallaecio) 2012-10-27 14:21:29 UTC
The process pdftotext never gets called here, just gs.

But I can confirm that hovering 3 or 4 PDF files in a row (as quick as possible) will result in the picture of the information panel being that of the second book, instead of the one you are finally hovering. The information under the picture is right, though.

So, steps to reproduce:

1. Enter a folder with three PDF files (the bigger the better, I guess).
2. Hover the first one. The Information panel will show its preview in a matter of seconds.
3. Hover the second file. Soon after that, the preview in the panel, of the first PDF, will turn to grayscale.
4. Now, at that point, and before the image turns into the preview of the second PDF, you must hover the third PDF.

Expected results: When you are hovering the third PDF, the preview image should be that of the third PDF.

Actual results: When the image in the Information panel gets updated, it will be the image of the second PDF (you are hovering the third one now), and it will not change. The information under the preview, however, will be the third PDF’s.

On a side note, shouldn’t it be possible to cache the previews so the gs tool is not used for a preview you’ve already generated from a file that has not changes since you generated the preview the last time?
Comment 11 Frank Reininghaus 2013-09-25 16:19:32 UTC
Thanks for the analysis! The reason why the Information Panel might not show a preview of the most recently hovered file might be that, when hovering many files in a row, the function

InformationPanelContent::showItem(const KFileItem& item)

is called multiple times, starts a preview job each time, and connects to the job's gotPreview(KFileItem,QPixmap) signal every time.

I see two possible solutions:

(a) In the slot that is connected to that signal, check if the KFileItem is still the current one, and discard the received preview if that is not the case, or

(b) remember the most recently started preview job, and kill it before starting a new one.

About the caching of the previews: AFAIK, KIO::PreviewJob does use the .thumbnails directory inside the home folder to cache previews. I'm not sure if this only works for previews of images though.
Comment 12 Christoph Feck 2013-10-01 23:28:58 UTC
The .thumbnails cache is not limited to images and videos, but also caches thumbnails of PDF files. I think it caches everything, except folder thumbnails.

Regarding the long/high CPU usage: ghostscript is indeed slow, I guess a poppler-based thumbnailer would be faster (but still need 100% cpu, of course).
Comment 13 Alexander 2013-10-02 06:03:56 UTC
Hi, what about to lover the process priority? Thumbnails generation is not as important as other user/system tasks could be. That should help on systems with single CPU.

Another problem is of course the race conditions. I see them everywhere in KDE. Amarok, Kmail, Dolphin. I am not familiar with QT/KDE platform, but even working with web-based applications I know about race conditions and always take care of them. And I am not sure why KDE developers don't. Once you quickly switch e few tracks in Amarok and it starts to show wrong pictures, wrong lyrics, etc etc. Same in Dolphin. Not only the thumbnails generation is affected. When you select a batch of files, information bar should show info about all selected files, total file size, with the "info" icon. But sometimes it doesn't and display info for the last selected file even though I have 10 files selected.

It is absolutely evident, if there is no way to use result of a task (in case user initiated a new one, hovered another file, etc) the previous task should be stopped. If there are difficulties to follow this pattern then something is badly designed in the application/platform.

I believe at least getting rid of race conditions and lower the process priority should seriously improve the situation.
Comment 14 Frank Reininghaus 2013-10-02 09:20:35 UTC
(In reply to comment #13)
> Hi, what about to lover the process priority? Thumbnails generation is not
> as important as other user/system tasks could be. That should help on
> systems with single CPU.

Sounds like an interesting idea. We cannot change the priority of the "thumbnail" process directly from Dolphin though. We use a KIO::PreviewJob for that, so I guess that this is the place where the priority of the process could be modified.

You might want to report your suggestion to kio/thumbnail (if it's not reported already).

> Another problem is of course the race conditions. I see them everywhere in
> KDE. Amarok, Kmail, Dolphin.

Please discuss problems with Amarok and KMail in the appropriate places. If you see more race conditions in Dolphin, please file separate bug reports for them and make sure that you describe in detail how to reproduce the problem. Thanks.

> I am not familiar with QT/KDE platform, but
> even working with web-based applications I know about race conditions and
> always take care of them. And I am not sure why KDE developers don't.

I would appreciate it if you would not make oversimplifying accusations like "KDE developers don't care about race conditions" here. I do think about such problems in the code that I write, and if I get something wrong, I greatly appreciate it if someone takes the time to report the problem as a bug. Moreover, if you read my comment 11, then you'll see that I did think about the present problem and how to get rid of the race.

Nobody who made major contributions to Dolphin's Information Panel code is still active in KDE, but I assume that they tested it only with file types (like images) for which previews are created so fast that it's very hard to see the race.

You might still ask why the bug is still not fixed 3 years after it has been reported. To give you an idea of how much work it is to deal with the incoming bug reports, I checked how many new bug reports we got during the last 365 days. It's 576 (418 are still assigned to Dolphin [1], 158 were reassigned to other parts of KDE in the mean time [2]).

(By the way, the reason for this large number is not that we cause regressions all the time. The vast majority of these bug reports is about problems that are not new at all. When someone reported a regression that has been caused after I took over Dolphin's maintainership, I always tried to make sure that it is fixed ASAP.)

If you add the feature requests, mailing list traffic, review requests, and user questions in the forum, then it might become clear that it's not really possible for a very small team of volunteers (who have jobs which are completely unrelated KDE) to give every bug the attention it deserves, and that it can sometimes very long, or forever, until a particular bug is fixed.

The situation is getting better though - during the past year, the number of open Dolphin bug reports decreased by more then 50% [3], which is also the reason why I finally had a chance to look at the reports which are buried deep in the pile, including this one (see comment 11). The next time I'm near my development machine with some spare time, and my present list of "in progress" items is cleared, I will try if my idea works. I can't promise when that will be the case though - if anyone else wants to try to fix it, please go ahead.

[1] https://bugs.kde.org/buglist.cgi?list_id=764336&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&chfieldto=2013-10-01&query_format=advanced&chfield=%5BBug%20creation%5D&chfieldfrom=2012-10-02&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=NEEDSINFO&bug_status=VERIFIED&bug_status=CLOSED&product=dolphin

[2] https://bugs.kde.org/buglist.cgi?f1=product&list_id=764339&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&o1=changedfrom&chfieldto=2013-10-01&query_format=advanced&chfield=%5BBug%20creation%5D&chfieldfrom=2012-10-02&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=NEEDSINFO&bug_status=VERIFIED&bug_status=CLOSED&v1=dolphin

[3] https://bugs.kde.org/weekly-bug-summary.cgi?tops=50&days=365
Comment 15 Alexander 2013-10-02 09:42:35 UTC
Yeah, I do clearly understand the situation because also support some open source projects on github and understand how it works ;)

Mentioned Kmail and Amarok just as a reference. That's actually all KDE applications I am using. I didn't want to offend anyone, it's just the fact that all apps I am using have problems with race conditions and there are bugreports that as you mentioned stay opened for years and I am actually lost any hope they'll be fixed.
Comment 16 Frank Reininghaus 2013-12-20 07:53:58 UTC
A proposed fix is at

https://git.reviewboard.kde.org/r/114561/

Anyone who can reproduce the problem and who builds Dolphin from source is invited to test it and report the results. Thanks!
Comment 17 Frank Reininghaus 2014-01-06 19:19:24 UTC
Git commit 8ed499f28fa2954c9b7c5fe0624d5b2b2b5c8630 by Frank Reininghaus.
Committed on 06/01/2014 at 19:15.
Pushed by freininghaus into branch 'KDE/4.12'.

Kill any running preview jobs before starting a new one

If loading a preview takes long, it was possible before this commit
that a preview for a new item was requested before the first preview
was shown. In that case, there was a race condition, and the first
preview to arrive stayed in the Information Panel.

This commit fixes this by keeping a pointer to the preview job and
killing it before starting a new one.
FIXED-IN: 4.12.1
REVIEW: 114561

M  +22   -18   dolphin/src/panels/information/informationpanelcontent.cpp
M  +7    -1    dolphin/src/panels/information/informationpanelcontent.h

http://commits.kde.org/kde-baseapps/8ed499f28fa2954c9b7c5fe0624d5b2b2b5c8630