On 03/06/2012, at 3:03 AM, Ken Thomases wrote: > That said, I don't know that OP requires strict LIFO order. He just wants > the operations associated with images which are scrolled into view to have > higher priority than those which aren't. That can just be accomplished by > setting the priority of operations as their associated images are scrolled > into and out of view. The problem, as I understand it, is that IKImageView > doesn't make it easy to detect that.
This. The problem is not that setting the priority of an operation doesn't work, it's that manipulating the priority based on what is visible at a given moment is hard. The exact order of execution is unimportant - but it's "nicer" if what's actually visible right now is given a higher priority than others that might be queued but have scrolled out of view. Having a LIFO execution order helps somewhat with that. With IKImageBrowserView, the view requests an item from its dataSource, presumably because it has become visible (though it seems it asks for others out of view as well, by some logic of its own - perhaps it tries to fill in as many as it can for future display when things are otherwise idle - I can't really tell). This request can kick off an asynchronous request to generate the image. Because of queuing these requests, and the relatively long time they take to run, by the time the actual task to generate the thumbnail comes to execute, it may no longer be needed, or can be given a lower priority. This could be because the user has scrolled the view. The difficulty is that the code responsible for queuing and generating the thumbnails has no knowledge of the view that asked for them to be created. However, it does have a delegate, so I've extended the delegate protocol so that it can ask it "do you still need this?" just before it executes. The delegate can return yes or no based on its visibility within the view, and the task is either discarded if it hasn't run yet and it isn't needed, or its priority can be bumped up if it is. This works, but is becoming somewhat complex, but so far I haven't managed to think of a better/cleaner/more elegant solution. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
