preview in dolphin is slow with many pictures

Hi,

I have a folder with thousands of pictures (comics from sinfest.net, it's
addictive) in it and if I open that folder with preview enabled, dolphin is
extremely slow and tries to create all the thumbnails for the pictures. If I
open the folder with gwenview, it feels very fast, because only the thumbnails
for the pictures that are in the window are created.
Is it possible to do it in dolphin the same way and shall a fill a report on
b.k.o?

Thanks, Mathias

Saturday, 24. May 2008 12:35:50 Mathias Kraus wrote:
Hi,
>
I have a folder with thousands of pictures (comics from sinfest.net, it's
addictive) in it and if I open that folder with preview enabled, dolphin is
extremely slow and tries to create all the thumbnails for the pictures. If
I open the folder with gwenview, it feels very fast, because only the
thumbnails for the pictures that are in the window are created.
Is it possible to do it in dolphin the same way and shall a fill a report
on b.k.o?

Which Dolphin version did you use? Dolphin for KDE 4.1 should be as fast as
Gwenview, Dolphin vor 4.0.x was very slow in this case

Thanks,
Peter

>
Thanks, Mathias

Saturday, 31. May 2008 16:21:34 Peter Penz wrote:
Saturday, 24. May 2008 12:35:50 Mathias Kraus wrote:
Hi,
>
I have a folder with thousands of pictures (comics from sinfest.net, it's
addictive) in it and if I open that folder with preview enabled, dolphin
is extremely slow and tries to create all the thumbnails for the
pictures. If I open the folder with gwenview, it feels very fast, because
only the thumbnails for the pictures that are in the window are created.
Is it possible to do it in dolphin the same way and shall a fill a report
on b.k.o?
>
Which Dolphin version did you use? Dolphin for KDE 4.1 should be as fast as
Gwenview, Dolphin vor 4.0.x was very slow in this case

(sorry for replying to myself all the time today)

I've just tested Dolphin in KDE 4.1 with thousand images where no previews
have been cached before. Although Dolphin for KDE 4.1 creates the previews
for the visible area first when opening a directory, it still does not
recognize when the user scrolls down to the bottom. (Bad) result: the
previews for 9xx images are created first before the previews of the new
visible area get created

I'll try to fix this for KDE 4.1, thanks for the report!

Cheers,
Peter

>
Thanks,
Peter
>
Thanks, Mathias

Hi Mathias,

Saturday, 24. May 2008 12:35:50 Mathias Kraus wrote:
Hi,
>
I have a folder with thousands of pictures (comics from sinfest.net, it's
addictive) in it and if I open that folder with preview enabled, dolphin is
extremely slow and tries to create all the thumbnails for the pictures. If
I open the folder with gwenview, it feels very fast, because only the
thumbnails for the pictures that are in the window are created.

I've just submitted a patch which resolves this issue. When the user scrolls
down, the generating of previews is paused and resumed again for the new
visible area. I've tested it with 1000 items and it seems to work very well.

In opposite to Gwenview Dolphin also created previews for the invisible items
in background.

Please note that when testing it in trunk that due to the debug mode the
performance of previews in general is quite slow. E. g. when I suspend the
previews when touching the scrollbar I've a small delay, which does not occur
in the release mode.

Best regards,
Peter

Is it possible to do it in dolphin the same way and shall a fill a report
on b.k.o?
>
Thanks, Mathias

Monday, 9. June 2008 20:50:14 Rafael F L wrote:
Hi,
>
Just a few thoughts; no action item for anyone if you fixed it in dolphin
already :) [as long as kfiledialog doesn't have inline previews in its
icon view]
>
We had a patch somewhere in kcd from nefertum, that Peter (and I don't
remember if somebody else) asked him to improve.
>
He hasn't too many time but if you guys want to take a look at his
patch, it could be a very good point of start.

I'd say let's postpone this until KDE 4.1 is out. If we want inline previews
in kfiledialog I think a good approach would be moving Dolphin's IconManager
into kdelibs.

I'm not sure whether merging IconManager and KMimeTypeResolver is a good idea.
Although both classes use a similar approach to handle the visible area
first, I think the main complexity in the case of previews is not the
visible-area-part. E. g. the IconManager also takes care about cut items and
exchanges the icons in blocks to the item-view to improve the performance
(the blockwise handling is not required in KMimeTypeResolver as there the new
mimetype icon has always the same size and hence no relayout gets triggered
for the item view).

Regards,
Peter

He is nefertum on IRC, if you want I can poll him anyways.
>
>
Regards,
Rafael F L

Monday, 9. June 2008 22:44:10 David Faure wrote:
[]
I see. K then. thing we could do for more performance and to make
things more reliable then, would be to disable KMimeTypeResolver when
previews are enabled - there's no point in replacing an unknown icon with a
resolved-mimetype icon, to *then* replace it with a preview (and as I
mentionned, the mimetype resolver isn't needed when having previews anyway,
assuming IconManager ends up calling KFileItem::mimetype)

I just committed a fix in Dolphin for this. Nice side effect: Dolphin's
IconManager now uses KMimeTypeResolver internally, so there's no need anymore
for the views to take care on this :-)

Regards,
Peter

Tuesday, 10. June 2008 20:48:39 Rafael F L wrote:
Hi,
>
I just committed a fix in Dolphin for this. Nice side effect: Dolphin's
IconManager now uses KMimeTypeResolver internally, so there's no need
anymore for the views to take care on this :-)
>
Sorry for not replying to this thread before
>
Thanks Peter for your fix (and David too). I wonder, could this have a side
effect on detailed views with previews on (and type column shown) ?

IconManager indirectly uses PreviewJob from kdelibs, which has to determine
the mimetype anyhow, so there should not be any problem :-) I just did some
tests and everything seems to work fine.

I mean, I don't know the side effect of not resolving MIME types when the
previews are on.
>
Actually, even on icon mode, we could have the "Type" information shown on
the delegate by "View" ="Additional Information" ="Type".
>
What problems could bring us not resolving mime types ? (If the default
view is with previews, they would never be resolved) ?
>
>
Regards,
Rafael F L

Peter Penz schrieb am Monday 02 June 2008:
Hi Mathias,
>
Saturday, 24. May 2008 12:35:50 Mathias Kraus wrote:
Hi,
>
I have a folder with thousands of pictures (comics from sinfest.net, it's
addictive) in it and if I open that folder with preview enabled, dolphin
is extremely slow and tries to create all the thumbnails for the
pictures. If I open the folder with gwenview, it feels very fast, because
only the thumbnails for the pictures that are in the window are created.
>
I've just submitted a patch which resolves this issue. When the user
scrolls down, the generating of previews is paused and resumed again for
the new visible area. I've tested it with 1000 items and it seems to work
very well.
There is no change for me. I rebuild KDE in release mode, but when preview is
switched on, I have a delay of several seconds. If I switch preview off, the
delay is still there until I leave and then enter the folder again, then it is
really fast. You can try it for example in /usr/bin, there are usually also
many files.

In opposite to Gwenview Dolphin also created previews for the invisible
items in background.
Is it maybe possible to move it into an other thread, or just disable the
preview creation if number of items is bigger than x? I also noticed, that the
CPU is very high, when dolphin creates the previews.

Best regards,
Mathias
Please note that when testing it in trunk that due to the debug mode the
performance of previews in general is quite slow. E. g. when I suspend the
previews when touching the scrollbar I've a small delay, which does not
occur in the release mode.
>
Best regards,
Peter
>
Is it possible to do it in dolphin the same way and shall a fill a report
on b.k.o?
>
Thanks, Mathias

Tuesday, 10. June 2008 23:25:30 Mathias Kraus wrote:
[]
I've just submitted a patch which resolves this issue. When the user
scrolls down, the generating of previews is paused and resumed again for
the new visible area. I've tested it with 1000 items and it seems to work
very well.
>
There is no change for me. I rebuild KDE in release mode, but when preview
is switched on, I have a delay of several seconds. If I switch preview off,
the delay is still there until I leave and then enter the folder again,
then it is really fast. You can try it for example in /usr/bin, there are
usually also many files.

It works very well here with folders having a lot of images (1000 images),
but I agree that turning on previews in /usr/bin is a huge problem (I was not
aware about this). I guess this is an issue in kdelibs PreviewJob, where it
is timeconsuming to retrieve the MIME-type from the files in usr/bin

In opposite to Gwenview Dolphin tries to create previews for each MIME-type.

In opposite to Gwenview Dolphin also created previews for the invisible
items in background.
>
Is it maybe possible to move it into an other thread, or just disable the
preview creation if number of items is bigger than x?

It is already done this way. The previews are generated by a different thread
and the user interface is (at least in the case of image previews) not
blocked. The creating of previews is paused as soon as the user touches the
scrollbars.

I also noticed, that
the CPU is very high, when dolphin creates the previews.

Sure, creating/loading 1000 previews is resource intensive :-)

>
Best regards,
Mathias
>
Please note that when testing it in trunk that due to the debug mode the
performance of previews in general is quite slow. E. g. when I suspend
the previews when touching the scrollbar I've a small delay, which does
not occur in the release mode.
>
Best regards,
Peter
>
Is it possible to do it in dolphin the same way and shall a fill a
report on b.k.o?
>
Thanks, Mathias

Wednesday, 11. June 2008 02:13:02 Peter Penz wrote:
[]
It works very well here with folders having a lot of images (1000
images), but I agree that turning on previews in /usr/bin is a huge problem
(I was not aware about this). I guess this is an issue in kdelibs
PreviewJob, where it is timeconsuming to retrieve the MIME-type from the
files in usr/bin

Update: I just checked how Dolphin for KDE 4.0 behaves in this regard. There I
just pass the URLs of the items to the PreviewJob and before the job is
started, Dolphin gets blocked too for a few seconds

I'll do some profiling if I have more time again, I hope I can find a solution
for KDE 4.1.

BTW: can you confirm in your environment that when going into a folder with e.
g. 1000 images that no blocking of the GUI occurs?

Thanks!
Peter

>
In opposite to Gwenview Dolphin tries to create previews for each
MIME-type.
[]