Re: Observing Time
Re: Observing Time
- Subject: Re: Observing Time
- From: Uli Kusterer <email@hidden>
- Date: Fri, 26 Jul 2013 17:03:34 +0200
On Jul 26, 2013, at 4:22 PM, email@hidden wrote:
>
> On Jul 26, 2013, at 10:36 PM, Scott Ribe <email@hidden> wrote:
>
>>
>> On Jul 26, 2013, at 7:06 AM, Ken Thomases <email@hidden> wrote:
>>
>>> On Jul 25, 2013, at 11:37 PM, email@hidden wrote:
>>>
>>>> On Jul 26, 2013, at 12:09 PM, Ken Thomases <email@hidden> 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
>> email@hidden
>> 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 (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