Re: NSOperationQueue
Re: NSOperationQueue
- Subject: Re: NSOperationQueue
- From: Graham Cox <email@hidden>
- Date: Sat, 02 Jun 2012 15:34:50 +1000
On 02/06/2012, at 2:36 PM, Julius Oklamcak wrote:
> Potentially you could end up queuing up hundreds (or thousands) of thumbnail
> generation requests (depending on how many SVG files the user has). If the
> user was to close the browser to do something else, or switch to another
> app, you would continue generating those thumbnails. My solution, in an iOS
> app FWIW, was to cancel the thumbnail generation operations for the
> thumbnails that scrolled out of view.
Yes, this is an issue I'm needing to consider.
Right now, Kyle's suggestion, while it certainly sounds interesting and workable, is difficult for a couple of reasons. Chief among these is that the view in question is an IKImageBrowserView, and I'm supplying it with images on demand through its dataSource protocol. This protocol does not keep you up to date with view changes as scrolling takes place, so it's currently quite difficult to keep track of the set of visible items in order to prioritise them. I'm hoping I can avoid having to subclass the view.
At the moment, when the datasource gets asked for an image, I kick off the asynchronous fetch if needed and return nil. When the image arrives, I am able to check if it's still visible and refresh the given cell of the view, which requests the image again. Another source of difficulty is that the image supplier item (implementing the IKImageBrowserItem protocol) is not strongly linked to the object that handles the file parse to generate the thumbnail. It is its delegate, and gets called back when the image is available, but it cannot actively go to that object and cancel it - it simply doesn't know what it is. This isn't a showstopper - I could make the browser item own the thumbnail generator for a while, but that's a bit of a redesign.
My simple priority stack sorts out the problem of prioritising the visible items without really needing to know what they are, though I think Kyle's idea would work better if I could make it work. But it doesn't bother cancelling items no longer required.
Need to think this through a bit more - any ideas or experiences of something similar welcomed.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden