Re: NSTimer "takes over" CPU everytime it repeats?
Re: NSTimer "takes over" CPU everytime it repeats?
- Subject: Re: NSTimer "takes over" CPU everytime it repeats?
- From: Douglas Davidson <email@hidden>
- Date: Tue, 22 Oct 2002 16:36:38 -0700
On Tuesday, October 22, 2002, at 04:18 PM, Cameron Hayne wrote:
On 22/10/02 6:23 pm, "Hisaoki Nishida" <email@hidden> wrote:
The problem is my timer just takes over CPU and completely suspends
user interaction with GUI within the app. I know this shouldn't be
happening. I used an OpenGL draw function (in Cocoa API I think) as
the
selector before in a different app and it worked fine (no GUI
stuttering or anything).
What am I doing wrong? Am I supposed to use a second thread for my
timer, so it doesn't interfere with my other threads? How would I do
this?
Ondra Cada has already responded to this, but here's a rephrasing of
what he
said in case it was too terse:
In general, if you have a lengthy operation and you don't want it to
interfere with the responsiveness of your GUI, you need to do that
operation
in another thread.
All that using a timer buys you is deferring the lengthy operation.
Once the
timer fires, the CPU will be completely occupied by whatever code is
in the
method attached to the timer.
And by the way, it is slightly misleading to say that your "timer
takes over
the CPU" - it isn't the timer but rather the code that is executed
when the
timer fires that is taking over the CPU.
It would be even better not to use a timer at all. It's not clear
exactly what operation the timer is triggering here, but from the
description it sounds rather like polling. It would be better, if
possible, to use a run loop source instead.
Douglas Davidson
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.