Re: NSTimer questions
Re: NSTimer questions
- Subject: Re: NSTimer questions
- From: Christoffer Lerno <email@hidden>
- Date: Wed, 22 Sep 2004 23:50:57 +0200
On Sep 22, 2004, at 14:38, j o a r wrote:
Timers will only fire when their thread is not busy. In other words, if you want the timer to fire at 60 Hz, you need to make sure that the stuff you do in response to the timer (or anything else that you do in that thread) takes upp less than 1/60 s.
I don't think that's the whole problem though. There seems to be a problem with the granularity of NSTimer. Of course, the documentation warns exactly of that, but how does one get around the problem of NSTimer?
I tries using an NSThread (this also ties in with the suggestion by Rustam Muginov to check out the o'reilley tutorial - this is essentially following the multithreading scheme in the last part) but it turns out that NSThread's sleepUntilDate also suffers from the same problem in resolution. It is tempting to suggest that NSTimer is using NSThread's sleepUntilDate or at least that the two are sharing the same underlying call to delay execution.
No matter the reason, neither NSTimer nor NSThread seem like they can be relied on for delays in the order of 10 ms - they're simply too inaccurate.
I tried using select() as well, but ran into similar problems. Maybe it's simply because the second thread holds too low priority, but once you start doing other things (moving the window around for example) the processor starts to see the delay as a guide rather than a rule, and even an empty loop drops "frames" very quickly.
One might suppose that running a select with say 1 microsecond, could work. That way one could yield repeatedly until (for example) 10 ms has passed. Unfortunately, running a select seems to take a minimum of 10 ms no matter what delay I enter, this delay might in some cases extend to 50 ms.
I am not sure how to avoid this problem. Obviously the thread scheduler seem to think that as long as my thread is yielding it should be at liberty to steal up to 10 ms of time from the thread no matter what.
Maybe this whole things should be seen as a problem with the thread scheduler than any actual problem with the implementation of NSTimer and NSThread? I'm starting to suspect that one of the reasons NSTimer isn't guaranteeing milisecond resolution is because the thread scheduler doesn't allow for that. Or maybe I'm just out there blaming everyone else but myself ;)
/Christoffer
P.S. It would seem that better control is confined to kernel-only stuff. With that you have things like IODelay/IOSleep, tsleep and so on to draw from.
P.P.S. Running this in a thread should demonstrate the problem:
- (void)testThreading
{
int poll = 0;
double minFPS = 1000000;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSDate *date = [NSDate date];
NSDate *lastDate = [NSDate date];
while (YES)
{
date = [date addTimeInterval:(NSTimeInterval)30.0];
struct timeval value = { 0, 1 };
[NSThread sleepUntilDate:date];
double timing = -[lastDate timeIntervalSinceNow];
lastDate = [NSDate date];
if (1/timing < minFPS) minFPS = 1/timing;
if (++poll == 100)
{
NSLog(@"minFPS %f fps",minFPS);
minFPS = 1000000;
poll = 0;
}
}
[pool release];
}
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden