On Jul 26, 2013, at 4:22 PM, dangerwillrobinsondan...@gmail.com wrote: > > On Jul 26, 2013, at 10:36 PM, Scott Ribe <scott_r...@elevated-dev.com> wrote: > >> >> 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 >> > Hmm, it's a brute force approach, but certainly easier than understanding > mach_time :D > I'm using Core Animation for most of the UI changes, so the main thread won't > be super busy. > > I may not even need the 1 second as the seconds won't add a whole lot of info > when looking at time in different time zones comparatively, but I want to > have this in my tool belt. > For the current tool, I could get by fine with a simple hour and minute hand > analog clock face.
As a compromise, use the Timer's nextFireTime to keep the timer from firing until the next second/minute/whatever you are displaying. I think there was a rule at some time (or was that only Carbon?) where timers only fired at multiples of their interval, so the 0.1 second delay might fix that, while the fire time keeps the battery from being drained. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de _______________________________________________ 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
