-
Notifications
You must be signed in to change notification settings - Fork 285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load web search icons asynchronously (fixes #637) #805
Load web search icons asynchronously (fixes #637) #805
Conversation
Move web search icon setting into QSObject_URLHandling
Awesome. We should wait on a B67 pre-release for this. (I’ll try to get it in quickly.) Between this and the moreComing/timers changes, we’ll have some pretty big performance improvements. |
So all in all, this is a pretty small change. Just one question (related to this, but nothing to do with your changes). I was poking around trying to understand this better and I noticed in
From the documentation:
Any reason we shouldn’t use that instead of 1? Edit: I should @ mention @HenningJ since he’ll be better able to answer that. |
Cool. I'll try and comment on the Prefs clean up stuff so we can try and P.S. I've committed a couple of things to master - the QSURLTypeParsers got Seems like Xcode 4 doesn't like the On 11 April 2012 13:44, Rob McBroom <
|
I think it was @HenningJ who created this code, so it would be best to find On 11 April 2012 14:02, Rob McBroom <
|
For the Quicklook Icon creation thing, 1 made sense, since that works one at a time anyways. But for this one, I think they should be separate anyways, and not use the same queue. |
I personally don't know enough about NSOperations to do that, and actually don't think it's necessary to create a whole new queue for the perhaps 20 or so icons that typical users will require to be loaded. From my point of view this is 'complete', unless we decide to go for Henning - you're saying that the quicklook task ( |
Where do you see that? And will that always be the case? Is there any downside to using the default and letting the system manage this on-the-fly?
Since the existing |
I've been thinking about this, but I can't remember where I got this from. I'm sure there was a good reason for it, but maybe I'm wrong. Just try setting it to
Primarily, because it seems cleaner. Apart from that: If you just browsed through a folder with lots of big files, it takes a while to process all the preview icons. If you then try to create the web search icon, it has to wait until the preview icon processing is completed. But since all of that happens in the background anyway, it might not be a big deal. So go ahead, do whatever you like. :-) |
I did and it does, so I say we flip it on here.
Probably not enough to justify the changes. These delays are very small anyway. They’re awful if you have to sit and wait for them, but if they just happen as you work, it’s hardly noticeable. FYI, in testing this I’ve seen a problem that I hadn’t noticed before. When icon loading completes, the interface doesn’t actually update unless you select an item, or scroll it off screen and back. (If part of the icon was off screen, just that part will be updated.) I went back and found that this started in B61, so it was almost certainly introduced in #388. I think the problem is in the |
…urrentOperationCount` for preview image loading
I had a play with I've added another commit |
Load web search icons asynchronously (fixes #637)
Merged |
This uses bits of Henning's code (thanks!) which was originally used to make the loading of file icons asynchronous.
Also - general tidy up and I've moved the web search icon methods into QSObject_URLHandling.
There's also a memory leak fix in the
getFavIcon
method