Re: Observing Time
Re: Observing Time
- Subject: Re: Observing Time
- From: Scott Ribe <email@hidden>
- Date: Sat, 27 Jul 2013 08:46:35 -0600
On Jul 27, 2013, at 7:29 AM, email@hidden wrote:
> k so I went and looked at sys/time.h and friends and the man page for gettimeofday()
> And now understand how this struct works.
> It's literally the same as the NSDate method timeIntervalSince1970
> The only difference is NSTimeInterval is representing the values if these struct fields as the respective sides of the decimal point.
> I grok this.
> If I want to fire my timer at the second, just supply a tp with tp.tv_usec as zero.
> If I could verify any consistent lag under load I could offset my timer to fire slightly early to compensate for the lag.
> I get it. Awesome.
> But with that in mind, if I care or if the lag becomes significant enough per analog clock displayed for given time zones , then I will measure how the lag increases per additional displayed clock I add.
> I'll get the rest if the thing built now the way I want it and save this optimization for last.
Assuming your update code runs very very fast (which it probably does):
What you want to do is check the time and set the timer *after* you have updated all your clocks. That way, if your update took 0.01 seconds, you'd be delaying 0.99 seconds, and so on.
But you can neither predict nor control other things that would cause the timer to fire later than you request. The only thing you can do is try to make sure that whatever other code you have to run does not hog the main thread for long.
So, roughly speaking, after you have updated your clocks you set a timer for:
1.0 - fmod([[NSDate date] timeInterval], 1);
But if your code is not really fast, your delay might need to be:
double start = [[NSDate date] timeInterval];
// do all your updates
double end = [[NSDate date] timeInterval];
if (end - start > 1)
// you're screwed, give up ;-)
else
// setup timer for 1.0 - fmod([[NSDate date] timeInterval], 1) - (end - start)
I don't remember why all the UNIXy stuff entered the discussion; it's really not necessary for this.
--
Scott Ribe
email@hidden
http://www.elevated-dev.com/
(303) 722-0567 voice
_______________________________________________
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