On Jul 27, 2013, at 11:46 PM, Scott Ribe <[email protected]> wrote:
> On Jul 27, 2013, at 7:29 AM, [email protected] 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. point taken! > > 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. Indeed... > > 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. Well, maybe not necessary to do it, but appropriate for understanding the mechanism, as it's all based on that UNIXy stuff, even NSDate and timeInterval … _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
