At 7:36 AM -0600 7/26/13, Scott Ribe 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".
It's worth noting that's very energy inefficient.
Once the WWDC sessions are back on line, watch
the energy efficiency sessions to see what's
happening with timers in Mavericks.
For what the OP is doing, using NSTimer on the
main event loop with an offset would be a good
implementation -- it might take adjusting the
offset to get the timer to fire a little early
and/or accomodate the actual fire time in the
code.
HTH,
-Steve
_______________________________________________
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
