After auto-update to 4002, all icons initially appear as blank white documents

[siracusa]

After auto-updating from build 4000 to 4002, each new icon that appears while typing shows up as a blank white "generic document" icon for a second or two before being replaced by the actual icon for the item. Quitting and relaunching Quicksilver seems to fix it temporarily, but the behavior eventually returns.

[skurfer]

I'll tell you what's changed (mostly from #1490), and you can tell me if you think it explains what you see.

There are three images involved here: The icon for a type, the icon for a file, and the Quick Look preview for a file.

Previously, we were loading a file's icon first, then getting a Quick Look preview in the background and replacing it in the UI when it became available. This was still a problem if you had a slow disk connected, because by asking for the file's actual icon (even if it was small and pre-generated), we were hitting the disk where the file was stored.

In the new release we initially show the icon for the file's type, which will often be in memory, but worst-case it'll need to be pulled from the main system disk which should be much faster than FireWire/USB/network disks.

Then, as before, the UI will be updated with the Quick Look preview when it becomes available. If there is no Quick Look preview, or if you've disabled them via hidden prefs, the file's icon will be shown instead.

So depending on the speed of the disk these files are on, and what the icon for that type is, what you're seeing could be normal. If you're seeing this for all files, something is wrong.

(As for the impact of restarting Quicksilver, it's probably a coincidence since the OS handles all the caching for Quick Look previews.)

[siracusa]

I use Quicksilver to launch applications, and I'm seeing the generic white document icon (vertical rectangular piece of paper with the corner folded) which is eventually replaced by the actual application icon. This isn't even the correct "type" icon for an application.

Also, I have 16GB of RAM. I'd be happy to have Quicksilver preload some or all of the icons for the items in my catalog (maybe 300 items) at launch time.

[skurfer]

I use Quicksilver to launch applications, and I'm seeing the generic white document icon (vertical rectangular piece of paper with the corner folded) which is eventually replaced by the actual application icon. This isn't even the correct "type" icon for an application.

Agreed, but it's what [[NSWorkspace sharedWorkspace] iconForFileType:@"app"] returns. We hard-coded an exception for folders, since they have no extension to go on and they're pretty common. It looks like we need one for applications as well.

But it's still odd that it takes so long for locally installed application icons to load. Or to put it another way, it's odd that Quicksilver wasn't unusably slow before we made this change, since that “second or two” delay was theoretically blocking the UI thread in 1.0.0. Maybe it's because we now try to load the Quick Look preview before falling back to the file's icon, where before, the file's icon was thrown out there unconditionally.

I could change that behavior pretty easily, but I don't have a non-SSD machine to test with. 😢 🎻 Would you be willing to run a test build?

Also, I have 16GB of RAM. I'd be happy to have Quicksilver preload some or all of the icons for the items in my catalog (maybe 300 items) at launch time.

Quite a few people complain about the memory footprint as it is, but I'm with you.

Note that some effort was made in #1488 to keep icons in memory if they never change, but predicting which ones will never change (especially for files) can be tricky.

[siracusa]

Yes, trying to load the Quick Look preview first sounds like it could explain the behavior. I can try a test build when I'm at home. I'm all SSDs at work, although I did see white document icons even here this morning (albeit for shorter periods of time). Especially for .app files, never even trying to load a Quick Look preview sounds like the right policy to me.

[skurfer]

OK, give this a whirl and see if it's any better.

http://cl.ly/163V3Y0l0Z44

Note that I've left the build number at 4002. If you're happy with this build, just keep using it and you should still get the next update.

Especially for .app files, never even trying to load a Quick Look preview sounds like the right policy to me.

Yeah, but we don't want icon loading to become [even more of] a rat's nest of special cases.

For what it's worth, you can control which types get Quick Look previews via hidden prefs, but it's a list of types to include, so doing “all but one” is problematic. If you literally only use it for applications, you could turn off Quick Look previews entirely (also via a hidden pref documented in the wiki).

[siracusa]

Which pref disabled the previews entirely? Setting QSLoadImagePreviews to NO?

That new build seems fine here in SSD land. I'll try it when I get home.

[skurfer]

Which pref disabled the previews entirely? Setting QSLoadImagePreviews to NO?

That's the one.

[siracusa]

The new build seemed to do the trick. No more white documents even on my slow spinning disk while Time Machine is running.

[pjrobertson]

Away from my Mac right now, but just chiming in to say I agree with
everything that's been said. Ron: feel free to make a pull. Should be able
to check if (and some of the other 1.0.1 problems) within the next 24hrs

On Tuesday, August 6, 2013, siracusa wrote:

The new build seemed to do the trick. No more white documents even on my
slow spinning disk while Time Machine is running.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1552#issuecomment-22145950
.

[skurfer]

Ron: feel free to make a pull.

Thanks, Mat. I did. 😉

[skurfer]

The new build seemed to do the trick.

Thanks for letting us know, @siracusa. The changes should be in the next pre-release build.

[pjrobertson]

Cool Bob I'll take a look when I'm back (stupid iPod keyboard!)

On Tuesday, August 6, 2013, Rob McBroom wrote:

The new build seemed to do the trick.

Thanks for letting us know, @siracusa https://github.com/siracusa. The
changes should be in the next pre-release build.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1552#issuecomment-22154758
.

[pjrobertson]

This will be in the next pre-release, out soon