No more “unknown” icons

UnknownIconsIn recent versions of Dolphin, the view sometimes looked like this just after entering a directory.

Some of the files and sub-directories have “unknown” icons, which are replaced by the correct icons later.

This will not happen any more in Dolphin 4.11.

Why did we show you “unknown” icons at all in the first place?

Dolphin can show you a lot of information about your files. Some of this information can be obtained quite easily, like, e.g., the name, the file size, and the modification time.

However, some other properties of a file or directory might be more expensive to determine. Examples are:

  • The type of a file: if it cannot be determined unambiguously from the file name, we have no choice but to read the contents of the file.
  • The icon that has to be shown for a file depends on the type. A directory icon, on the other hand, can be chosen by the user in the “Properties” dialog. The chosen custom icon is then stored in a file named “.directory” inside the directory, so determining the icon for a directory always requires a disk access (because we don’t know in advance if there is a .directory file or not).
  • If previews are enabled, the preview for each item has to be retrieved from the .thumbnails directory in your home folder. If no cached preview can be found there, it gets worse, and the (possibly large) file must be read from disk to generate a new preview image.
  • Counting the number of files inside a directory also requires a disk access. It is shown, e.g., in the “Size” column in Details View.
  • Meta data provided by Nepomuk.

To make things more complicated, some of these properties can have “preliminary” and “final” values. For example, the preliminary icon for any directory is the generic “folder” icon, but the final icon is only known after checking the contents of the corresponding .directory file.

We obviously cannot determine the final values of all these properties synchronously, i.e., blocking the application’s main thread, for all files and directories. In large directories, it might take very long until this process is finished. Therefore, we have to find some compromise between “show the items in the view as quickly as possible” and “only show any kind of information if we know what its final state is”.

What happened in earlier Dolphin versions

We have a class called KFileItemModelRolesUpdater (.h, .cpp) which is responsible for determining the data that are possibly expensive to retrieve.

When you enter a directory, it tries to determine the final icons for the visible items for up to 200 milliseconds. It then then returns to the event loop, such that the view can be painted, mouse events can be processed, etc. The remaining icons and other data are determined asynchronously – first for the visible items in ascending order, then for all invisible ones in random order. We still do it in the main thread, but only for one item at a time, such that it never blocks for too long until the next events can be processed. Moreover, the asynchronous processing of the remaining items is suspended if the view is scrolled. This ensures that scrolling feels smooth.

This approach has two downsides:

  1. Some “unknown” icons can remain if 200 milliseconds are not sufficient to determine the final icons for all visible items. This can happen easily if there are many directories in the view, whose final icons can only be determined by accessing the contents of the directory.
  2. It wastes resources when viewing large directories. Loading previews for thousands of images (I know from user feedback at bugs.kde.org and forum.kde.org that it is not uncommon to have hundreds of thousands of images in one directory) can easily make the hard drive and the CPU busy for a few minutes, even though it is very unlikely that the user will ever scroll through all these images in the view. Moreover, the previews need a lot of memory.

Improvements in Dolphin 4.11

KFileItemModelRolesUpdater still only tries to load the final icons for 200 milliseconds. However, just before an item is shown on the screen, Dolphin will check if its final icon has been determined already. If that is not the case, it will use the “preliminary” icon, which can be determined very fast. In many cases, the preliminary icons are actually equal to the final ones. Notable exceptions are directories with custom icons, and most of the files in /usr/bin.

Some changes in kdelibs were required to make this possible, see this discussion on the mailing list for details about this, and how “Poor Man’s Profiling” helped to solve the problem. Many thanks to David Faure for his help!

Thanks to this modification, Dolphin will never show you “unknown” icons again for items which do have a valid icon.

Moreover, Dolphin will not try to load icons/previews/etc. for all items in the directory asynchronously any more. It will just do that for the items which are currently visible, and those which can be reached quickly by scrolling up or down a few pages or to the top or bottom of the view (up to 500 at a time).

This greatly reduces the amount of memory and CPU cycles that we use to load and show a directory.

Some more information about the code changes that were required for this can be found in the corresponding review requests: 1, 2, 3, 4, 5, 6.

About these ads

8 thoughts on “No more “unknown” icons

  1. I have often wondered on unknown icon behavior. Good to know that it got fixed. Thanks for all the hard work. I think, pretty obvious, that the icons for applications will be based on the default file associations set.
    An aside – Just checking on the issue I raised earlier https://bugs.kde.org/show_bug.cgi?id=322023.
    Is this a nepomuk issue that for some files relevant properties are not shown?
    Pardon me, if I am shamelessly hi-jacking this thread asking for an update on another issue.

    • I don’t know. Maybe a package that Nepomuk needs to read meta data from video files isn’t installed on your system. But please do not continue the discussion here – post any relevant information in the bug report instead.

  2. It’s been a while that I’d like to dig into the code that generates the icons for images, if you look at windows/osx both show images previews _much_ faster than dolphin/kde does.
    One of the reason is the .thumbsdb in each directory instead of a /home/.config dir that has so many previews files that fetching the preview starts to become slower than generating it on the fly (not to mention disk space).
    And the other reason is that it doesn’t seem to use the preview meta-data of the images.
    Some time ago I started Photobook but stopped since I wanted QML2, but it provided me proof enough that it’s much faster getting the image meta-data than the cached image. (You can see by yourself how a huge collection of files nearly shows zero loading time, something not comparable to gwenview or dolphin)
    Do you think such a change would need to go in kdelibs or could dolphin change it’s behavior?
    And thanks for your improvements :D

    • We use KIO::PreviewJob from kdelibs to get the previews. If I’m not mistaken, this class is responsible for the location where they are stored.

      About using “preview meta data”: the code that creates the previews is in kde-runtime/kioslave/thumbnail/.

  3. Haha… it’s the fixes for these little things I love. Like how Valve fixed the HTML checkboxes in Steam for Linux this month. They looked like they were checked when they were unchecked and vice-versa.

    Thanks for your great work!

  4. As this has been a thorn in our sides for a long time. Does this work for first time initializing of Dolphin after logging in?

    Great job!

    • Dolphin 4.11 will never show you “unknown” icons (provided that there is a valid icon for the file/folder). I hope that this answers your question – I’m not quite sure if I understand it correctly.

Comments are closed.