Re: NSProgressIndicator (CallBacks)
Re: NSProgressIndicator (CallBacks)
- Subject: Re: NSProgressIndicator (CallBacks)
- From: Alastair Houghton <email@hidden>
- Date: Thu, 19 Jul 2007 12:07:47 +0100
On 19 Jul 2007, at 09:31, Barry wrote:
I'll certainly take a good look at Apple's Accelerate framework.
At the moment I'm calling NSProgressIndicator incrementBy AND
displayIfNeeded via a callback at the end of each row of pixels.
Do I need to add a WaitNextEvent (or whatever the latest API call
is) at this time ?
I wouldn't do that, no. (You shouldn't use WaitNextEvent() even in a
Carbon app, by the way; the equivalent in Carbon is ReceiveNextEvent
(). The closest thing in Cocoa is probably NSRunLoop's -
runUntilDate: method (there is also NSWindow's -
nextEventMatchingMask: method, but it'd be a bad idea to try to use
that for this kind of thing IMO).)
This style of coding (with embedded event loops) was the norm on
several co-operative multitasking systems (Win16, GEM, historic Mac
OS), but it suffers from the problem that you can't necessarily
predict exactly how often events get processed, which can make your
program seem sluggish to the user. It's often so bad that the user
actually can't use the "Cancel" button on the progress dialog for the
operation that's in progress. You still sometimes see this kind of
thing happening, especially on Windows (and particularly with scanner
software, I find), but it's not necessary; it's entirely possible to
process and have a responsive UI at the same time, and you'll find
that Mac OS X users *expect* that.
The easiest thing for you to do is almost certainly to use a separate
thread. You'd just make the method that sets all of this off spawn a
thread with NSThread's +detachNewThreadSelector:toTarget:withObject:
method, and then do a -
performSelectorOnMainThread:withObject:waitUntilDone: when the
processing is complete to let the main thread know that you've finished.
As regards progress, what I would do is have the worker thread store
its idea of how far it has got into a variable (which you should set
to zero before spawning the thread). Then run an NSTimer that
updates the progress indicator every so often (maybe every 10th of a
second). The reason for doing it this way is that the chances are
that you can process an entire row of pixels very quickly indeed,
especially on faster machines; you don't need to update the progress
value that fast though, and there's no need to send messages to the
main thread to do it either (doing so will just hold up your
calculations unnecessarily).
BTW, I wouldn't worry too much about synchronising access to the
progress variable. As long as you only update it from the worker
thread (aside from initially zeroing it, which is fine because the
other thread isn't running yet), you should be fine.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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