This question was asked 5 years ago here What is the precision of the UITouch timestamp in iOS? and I'm wondering if anyone has any further information or if things have moved on.
To summarize my very rough understanding, an app gets notified once every screen refresh cycle about any touch events, and the refresh cycle used to be 60Hz, and on some devices may be 120Hz.
This would suggest that there are two possibilities.
The timestamp coincides with the screen refresh cycle, meaning that the timestamp approximately has the resolution of 60Hz or 120Hz - ie, if you get a touch at 0 milliseconds, the next timestamp you could possibly get from another touch would be at 16 milliseconds on a 60Hz device or at 8 milliseconds on a 120Hz device.
Alternatively, it could be that the screen hardware stores the (more or less) exact time of the tap into a buffer somewhere, and then the refresh cycle picks up all the timestamps that have occurred since the last cycle, but these timestamps could fall anywhere in that period. So you could have a tap at 0 milliseconds, or 5 milliseconds or 9 or whatever.
Obviously I'd prefer option 2 to be the case, because in my app I want to know the precise time that the user touched the screen, rather than a value rounded to the nearest 16 millisecond multiple.
Very grateful for any input - thanks!
Related
This question already has answers here:
Format realtime stopwatch timer to the hundredth using Swift
(2 answers)
Closed 7 years ago.
I've got a 9 figure number that needs to be incremented by 500 each second, but i decided to increment the number each milliseconds and update the label that displays the number. I'm using a NSTimer but as i've read everywhere around they're not accurate nor meant to be. I've tried using CFAbsoluteTimeGetCurrent but couldn't get it to work. Simply using NSTimer yields and inaccurate value. The incrementation doesn't stop each time the user opens the app it simply adds up the value and starts incrementing again.
Any Ideas?
Update:
Even though most answers point in the right direction, i solved my issue a little bit different. Thanks to all who answered and Martin.
I used a CADisplayLink instead of a NSTimer and got pretty accurate and constant results. Now notice i say pretty because the results are not totally accurate, but since in my case i'm incrementing a 9 figure number they're not noticeable, and my numbers are corrected as soon as the view appears again.
You can get Accuracy
timer = [NSTimer scheduledTimerWithTimeInterval:0.001 target:self selector:#selector(countup)userInfo:nil repeats:YES];
Use a timer only as a trigger to update the screen, do not rely on the exact time between each fire.
Keep an NSDate which represents the start time and use the current date when the timer fires to calculate the difference and update the label.
Consider using CADisplayLink to update your interface — it gives you very accurate numbers of the time passed since the previous frame was drawn, so you can always keep your UILabel up to date, regardless of how high or low your framerate is.
The Time won't be very accurate - but it doesn't need to be, if you get the accurate current time each time you go into the loop and add 500 x (whole number of seconds), you will get a display that increases by 500 each second (plus / minus 50-100 milliseconds)
The advantage of this approach is that you won't get an ever-increasing discrepancy in the timing, only ever 50-100 milliseconds.
If you want the timer to stop when the user switches out of the app, then you need to disable the timer when the app becomes inactive - have a look at this tutorial on the Ray Wenderlich site http://www.raywenderlich.com/92428/background-modes-ios-swift-tutorial
How precise is the timestamp property of the UITouch class in iOS? Milliseconds? Tens of milliseconds? I'm comparing an iPad's internal measurements with a custom touch detection circuit taped on the screen, and there is quite a bit of variability between the two (standard deviation ~ 15ms).
I've seen it suggested that the timestamp is discretized according to the frame refresh interval, but the distribution I'm getting looks continuous.
Prior to the iPad Air 2, the touch detection polling of the iDevices is 60 Hz. The iPad Air 2 is for the first time able to poll touches at 120 Hz.
So while the numbers of the timestamp seem to be very precise (many digits after the dot), they are not.
This is a WWDC video, it's the best WWDC video I've ever seen and it explains everything in detail:
https://developer.apple.com/videos/wwdc/2015/?id=233
Just because I'm curious: What kind of custom touch detection circuit do you have?
I'm trying to implement a countdown feature for my program. It's a second-timer, so I use a NSTimer object with a time interval of 1.0 second to update the UI. But in order not to accumulate error (every 1.0-second interval will incur a little bit of lag), the program caculates the absolute difference between current time and beginning time for the remaining time displayed in the UI.
The problem is, after the NSTimer object runs for a significant time (say half an hour), it's no longer "synced" with the absolute time due to accumulated error: the UI update happens between two "absolute" seconds. For example, if the countdown starts at 00:00:00.000, at first UI updates at 00:00:01.000, 00:00:02.000 ... but after a while it becomes 00:30:03.567 or something like that.
Any idea how I can deal with this? Are there any other better ways to implement this? Thanks!
One high level idea is to detect when the timer is getting too far out of sync based on your absolute time calculation. When it gets past a specific threshold, say 0.01 seconds or whatever you desire, cancel the current timer and start a new one after an appropriate delay that gets it back "in sync".
From what I've researched online, the iPhone screen refresh rate is 60Hz (not sure if this applies to iPhone 6 as well) - meaning, it can refresh an image up to 60 times a second.
However, I have a project in which I need a very fast blinking animation - to animate a view back-and-forth (from visible to invisible), more than 60 times a second. I thought about using CADisplayLink, so I'll get called every time the screen refreshes, but unfortunately, as stated above, this is not fast enough (gets called 60 times a second only).
Is there something I'm missing here, or is there a way to achieve a higher blinking rate? Do iOS games achieve better rates than this?
Thanks
There's no way to achieve a faster display rate than the screen refresh itself, mainly because the screen can't refresh as fast, so people won't see it anyway.
Hence all iOS games are effectively vsynced at 60 fps.
That said, depending on what you're doing, you might not be getting 60 fps. Have you profiled your app to determine the fps it's running?
If it's not doing 50+, there's probably some optimization that you can do to get it as close to 60 as possible.
Im writing an app that functions much like RunKeeper. Im tracking CLLocations every x seconds to figure out the total distance.
However, if the user moves on a really straight freeway for 10 minutes (Think USA), there is no point in saving 60 tracking points.
What kind of filtering do you use in your apps to reduce the number of track points?
Im thinking about checking the course delta from the last good position and discarding the new posotion if course hasnt changed by more than x degrees. There would of course also be a longer time limit to get a point every now and then anyway.