• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Observing Time
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Observing Time


  • Subject: Re: Observing Time
  • From: Scott Ribe <email@hidden>
  • Date: Fri, 26 Jul 2013 07:36:00 -0600

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





_______________________________________________

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


  • Follow-Ups:
    • Re: Observing Time
      • From: email@hidden
    • Re: Observing Time
      • From: Steve Sisak <email@hidden>
References: 
 >Observing Time (From: email@hidden)
 >Re: Observing Time (From: Rick Mann <email@hidden>)
 >Re: Observing Time (From: email@hidden)
 >Re: Observing Time (From: Ken Thomases <email@hidden>)
 >Re: Observing Time (From: email@hidden)
 >Re: Observing Time (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: Observing Time
  • Next by Date: Re: Observing Time
  • Previous by thread: Re: Observing Time
  • Next by thread: Re: Observing Time
  • Index(es):
    • Date
    • Thread