For instance, as far as I know, there is no way to change the
period of an NSTimer that's already in existence. Since both the
simulation update rate and the frame update rate are timer-driven
and dynamically changeable by the user, I expect lots of NSTimer
objects to be created.
I think you can reuse it using -[NSTimer setFireDate:] to set the
next fire date. The doc is not very clear about it. If this is not
the case, you can use CFRunLoopTimerSetNextFireDate (as NSTimer and
CFRunLoopTimer are tool free bridged), which has a better
documentation:
"Resetting a timer’s next firing time is a relatively expensive
operation and should not be done if it can be avoided; letting
timers autorepeat is more efficient. In some cases, however,
manually-adjusted, repeating timers are useful. For example, if you
have an action that will be performed multiple times in the future,
but at irregular time intervals, it would be very expensive to
create, add to run loop modes, and then destroy a timer for each
firing event. Instead, you can create a repeating timer with an
initial firing time in the distant future (or the initial firing
time) and a very large repeat interval—on the order of decades or
more—and add it to all the necessary run loop modes. Then, when you
know when the timer should fire next, you reset the firing time with
CFRunLoopTimerSetNextFireDate, perhaps from the timer’s own callback
function. This technique effectively produces a reusable,
asynchronous timer."
Ha! Great, I'll try that. Thanks!
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
