preview in dolphin is slow with many pictures

Hi Mathias,

I think I've some good news for you :-)

Thursday, 12. June 2008 23:46:03 Mathias Kraus wrote:
[]
some suggestions for preview:
-start from top left, instead from bottom right, if easy doable
-start with images that are completely in the visible area, not only
partly, but I think this will be more expensive
[]

I've spend quite a lot of time during the last days to do some profiling and
find the bottlenecks for the preview generation. The following improvements
are now in SVN:

- the previews are always generated for the visible area first from the
top-left to the bottom-right (no matter which kind of sorting is used)

- if the previews for the invisible items are generated, the UI is not blocked
anymore and the generation is done now very fast (even in the debugging mode)

In my tests when having a folder with 1000 images and scrolling through the
view during preview generation resulted in no blocking of the UI. Dolphin in
KDE 4.0.x took 19 seconds for generating previews of 772 images (release
mode) and Dolphin for KDE 4.1 only takes around 4 seconds (debug mode) for
the same task although nicer (and more expensive) image frames are drawn and
the visible area is considered too.

I did also some tests with a folder having 10000 items and here some blocking
is done when opening the folder or after moving the visible area, but the
root here is a combination how QListView receives the maximum size of an item
and how Dolphin calculates this size and not the preview generation itself.

However I think this is a good base for KDE 4.1 and hope you'll like it :-)

Best regards,
Peter

Peter Penz schrieb am Monday 30 June 2008:
Hi Mathias,
>
I think I've some good news for you :-)

Hi Peter,

just two words you rock!

Thursday, 12. June 2008 23:46:03 Mathias Kraus wrote:
[]
>
some suggestions for preview:
-start from top left, instead from bottom right, if easy doable
-start with images that are completely in the visible area, not only
partly, but I think this will be more expensive
>
[]
>
I've spend quite a lot of time during the last days to do some profiling
and find the bottlenecks for the preview generation. The following
improvements are now in SVN:
>
- the previews are always generated for the visible area first from the
top-left to the bottom-right (no matter which kind of sorting is used)

did I already said that you rock. BTW, I just suggested the top-left to bottom
right direction because LTR is the natural way in Europe, Kanada, USA and so
on, but if you get bored sometime and just don't know anything to do in
Dolphin or any other project you have, I think our friends that are more
familiar with RTL would enjoy a top-right to bottom-left preview generation
from row to row and our Asian friends might enjoy a preview generation column
wise. But that would just be the dot on the i or the cherry on top of the cake
:)

- if the previews for the invisible items are generated, the UI is not
blocked anymore and the generation is done now very fast (even in the
debugging mode)

Nice. I tried openSUSE on the weekend and noticed that Dolphin was much faster
than on Kubuntu, e.g. I had absolutely no freeze while opening /usr/bin. I'll
rebuild trunk for Kubuntu to enjoy the speed improvement also on my day to day
distribution. BTW, you rock :)

In my tests when having a folder with 1000 images and scrolling through the
view during preview generation resulted in no blocking of the UI. Dolphin
in KDE 4.0.x took 19 seconds for generating previews of 772 images (release
mode) and Dolphin for KDE 4.1 only takes around 4 seconds (debug mode) for
the same task although nicer (and more expensive) image frames are drawn
and the visible area is considered too.

Did I already mentioned that you rock. I don't know, but while I was a student
my memory got worse from semester to semester. I guess it's because of the
huge amount of information I'm sure it can't be the huge amount of beer :)

I did also some tests with a folder having 10000 items and here some
blocking is done when opening the folder or after moving the visible area,
but the root here is a combination how QListView receives the maximum size
of an item and how Dolphin calculates this size and not the preview
generation itself.
>
However I think this is a good base for KDE 4.1 and hope you'll like it :-)

I definitely like it. Thank you very much for your hard work. I think there are
also many other users that appreciate the work you do.

Best regards,
Mathias

Best regards,
Peter