On Jul 26, 2013, at 7:06 AM, Ken Thomases <k...@codeweavers.com> wrote:
> On Jul 25, 2013, at 11:37 PM, dangerwillrobinsondan...@gmail.com wrote: > >> On Jul 26, 2013, at 12:09 PM, Ken Thomases <k...@codeweavers.com> wrote: >> >>> Also, the above code doesn't adjust the timer to fire on the second as Rick >>> suggested. You're asking it to fire every so many seconds (delayInSeconds) >>> but you aren't specifying when during the second to fire. Rather than >>> passing 0 as the second parameter of dispatch_walltime(), you should >>> compute an adjustment to try to get close to a whole second. Since >>> dispatch_walltime() uses gettimeofday() when you pass NULL for the first >>> parameter, I'd use that same call to fill in a timeval structure and then >>> pass NSEC_PER_SEC - (tp.tv_usec * NSEC_PER_USEC) as the second parameter. >>> >>> Regards, >>> Ken >>> >> Thanks Ken, no I hadn't yet bothered to do this, as dispatch_walltime() was >> initially close enough to work on the other bits of the app. >> It would make a difference to reduce some lag. >> What is the part in the second parameter your are doing there… >>> NSEC_PER_SEC - (tp.tv_usec * NSEC_PER_USEC) >> Looks like something to adust it but what is tp.tv_usec ? > > I hypothesized a struct timeval variable named "tp" that you passed to > gettimeofday(). Then you would use the sub-second part (the tv_usec field) > to figure out roughly how far off of a whole second dispatch_walltime() would > be when passed NULL for the first parameter, since it will also use > gettimeofday(). FYI, in the past, for a quick & dirty solution, I've just set a timer to fire every 0.1 seconds. Then in the handler you check if the second changed since the last time, and do nothing if it hasn't. This gets you updating that appears smooth to the user, unless the main thread spends too much time doing something and updates don't happen--and that's a problem that's outside the timers & clocks whose solution is not related to the timers and clocks, whose solution is of course "don't do that". -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
