Delayed icon loading in KFileItem and dolphin

[Frank Reininghaus]

Hi,

sorry for the late response - I moved to a new flat last week, which
still keeps me quite busy and has no working internet connection yet
:-(

2013/3/28 David Faure:
> On Thursday 28 March 2013 14:00:59 Frank Reininghaus wrote:
>> at the moment, we indeed determine mime types, icons and/or previews
>> asynchronously for *all* items
>
> Not all, surely?
>
> For icons from desktop files, it's only asynchronous on slow mounts.
>
> For mimetype determination, it's only asynchronous when the extension is
> unknown, or conflicting.

Sorry, me earlier statement was not quite precise. What Dolphin
actually does when a new folder is entered is the following: for 200
ms, KFileItemModelRolesUpdater tries to determine mime types and icons
synchronously. If that is not sufficient to deal with all files, the
rest is done asynchonously.

The order in which the items are handled is: first the visible ones in
ascending order, then the rest in random order. However, I found out
recently that it can happen that KFileItemModelRolesUpdater does not
know yet which items are visible when it's doing the synchronous
information retrieval. In that case, it spends the 200 ms on *all*
items in random order, which is probably the reason why we sometimes
see the "unknown icons turn into nice icons" thing when entering a
large folder - there were some unhandled visible items left after the
200 ms.

>> , which can make the CPU and hard drive
>> busy for quite some time. I'm actually planning to change this and
>> only do that for the items that are either currently visible
>
> This sounds almost like my very old code in KMimeTypeResolver which isn't used
> anymore... Well, it would end up determining all files, but it was definitely
> doing the visible icons first. However the code isn't used anymore, AFAIK.
>
>> reachable by scrolling up/down one or two pages or by pressing
>> Home/End. I hope that I will get it done in time for KDE 4.11. The
>> current approach is a huge waste of resources in directories with many
>> items because it's extremely unlikely that the user will scroll
>> through all of them.
>
> At the same time, if the user moves the scrollbar to the bottom, or types a
> letter to search for a specific file, he/she will get the ugly experience of
> seeing "unknown icons turn into nice icons".... so I wonder if we really want
> that.

About "moving the scroll bar to the bottom": yes, I think we should
definitely not only determine icons/previews for the currently visible
items and those which are close to the visible area, but also for
those at the top and at the bottom because these can be reached
quickly.

About "seeing unknown icons turn into nice icons": you're right, we
want to avoid that if it's possible. However, if handling all items
takes more than a few seconds, this will happen anyway if the user
presses a letter to quickly jump to another location.

In Pierre's example folder with 140000 images, it takes a minute to
load all icons/previews. I guess that we don't want to optimise for
the use case "user enters a large folder, then waits for a minute and
is happy that all icons/previews are done then, so he can scroll
through the entire view quickly" ;-)

So my plan is to rewrite some parts of KFileItemModelRolesUpdater and

1. Fix the problem that we don't always handle the visible items first, and

2. Do not determine icons/previews for all items, at least not if
there are more than a few hundred. In that case, handling all items is
IMHO pointless because it won't be done fast enough to prevent the
"unknown icons turn into nice icons" issue anyway.

Best regards,
Frank