Re: Alternative to Delay()
Re: Alternative to Delay()
- Subject: Re: Alternative to Delay()
- From: Philippe Wicker <email@hidden>
- Date: Tue, 29 Jul 2003 08:05:04 +0200
On Tuesday, July 29, 2003, at 07:09 AM, Geoff wrote:
>
On Mon, 28 Jul 2003 13:24:12 -0500 Chris Reed < email@hidden > said:
>
>
> But please don't do something like this synchronously. It freezes the
>
> UI of your app, and generally makes the user experience less
>
> pleasing. Using run loop timers or other timer mechanisms is not so
>
> hard, really.
>
>
What I would need to have clarifed here then is what the system is
>
doing during a call to Delay() or MPDelayUntil() or usleep(). If it
>
was in fact paralysed, then yes this would be a problem and I wouldn't
>
use them, but I believe they don't chew up the processor while waiting
>
for the time interval requested to elapse so the processor is
>
available for other things in the meantime.
When you call usleep() for say 1 second, the thread (in your case the
UI thread) in which you made that call is waiting for this delay to end
up and then won't go back to the EventLoop for this duration of 1 sec.
Using a CFRunLoopTimer is much better because user events may still be
processed. Here is the code (from a C++ program) to setup a
CFRunLoopTimer.
Somewhere in your initialization routine:
.......
CFRunLoopTimerContext context = { 0, this, NULL, NULL, NULL };
mRunLoopTimerRef = CFRunLoopTimerCreate (
NULL, CFAbsoluteTimeGetCurrent(), 0.1, 0, 0, RunLoopTimerCallBack,
&context);
mRunLoopRef = CFRunLoopGetCurrent();
CFRunLoopAddTimer(mRunLoopRef, mRunLoopTimerRef,
kCFRunLoopCommonModes);
.......
The CFRunLoopTimer callback, it wakes up every 100 ms:
void RunLoopTimerCallBack (CFRunLoopTimerRef timer, void *info)
{
// info is the pointer that you passed in context (in that case the
'this' pointer)
......... your code ........
}
>
>
This is not the same principle as say, checking a mouse state in a
>
while loop which would no doubt spin around at least thousands of
>
times per second which would in fact monopolise the processor. In that
>
case nowadays we can use TrackMouseLocation in a loop which does this
>
without hogging the processor and is an official documentation
>
recommended procedure.
>
>
I don't use a private event loop, I use the Carbon Event Manager with
>
RunApplicationEventLoop() et al under MacOS X and if while waiting for
>
the tune to finish playing the user clicked on another app to do
>
something else they would be free to do so, I would only be making
>
them wait for my app until the tune finished playing.
>
>
I'm not saying I haven't considered that the user might want to do
>
something else in my app before the tune finishes playing and that
>
will involve some extra work disabling things that would conflict with
>
the tune playback (turning them back on when a timer reports) and
>
leaving the rest enabled throughout where there is no conflict, but
>
I'm in a development cycle and I'm looking for the friendliest
>
procedures I can find that will enable me to build the sophistication
>
of my application incrementally.
>
>
Full knowledge of what the above mentioned functions can or can't do
>
will enable me to make better choices in the long run.
>
>
Cheers Geoff %^>
>
_______________________________________________
>
coreaudio-api mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
>
Do not post admin requests to the list. They will be ignored.
>
>
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.