Delayed icon loading in KFileItem and dolphin

[Emmanuel Pescosta]

Hello Frank,
I did some experiments with KFileItemModelRolesUpdater some time ago. I
removed all the timer stuff and replaced it by a threading-based solution
(QtConcurrent). It works really fast, also with large folders and many
enabled (nepomuk-) roles - should be much faster with a two-step resolving
solution, which the current dolphin version already does (my implementation
resolves all roles at once).

But the code is in a really experimental stage (was just a proof of concept
;) ).

Regards
Emmanuel
 Am 02.04.2013 11:35 schrieb "Frank Reininghaus" <frank78ac at googlemail.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130402/ab1799cb/attachment.htm>