CODEWITHSUNDEEP
iosswifttimergrand-central-dispatch
Stonetip
Stonetip

Reputation: 1178

Why is decreasing interval not speeding up iOS timer execution?

When I run this timer code for 60 seconds duration/1 sec interval or 6 seconds/.1 sec interval it works as expected (completing 10X faster). However, decreasing the values to 0.6 seconds/.01 seconds doesn't speed up the overall operation as expected (having it complete another 10X faster).

When I set this value to less than 0.1 it doesn't work as expected:

// The interval to use
let interval: NSTimeInterval = 0.01 // 1.0 and 0.1 work fine, 0.01 does not

The rest of the relevant code (full playground here: donut builder gist):

// Extend NSTimeInterval to provide the conversion functions.
extension NSTimeInterval {

    var nSecMultiplier: Double {
        return Double(NSEC_PER_SEC)
    }

    public func nSecs() -> Int64 {
        return Int64(self * nSecMultiplier)
    }

    public func nSecs() -> UInt64 {
        return UInt64(self * nSecMultiplier)
    }

    public func dispatchTime() -> dispatch_time_t {
        // Since the last parameter takes an Int64, the version that returns an Int64 is used.
        return dispatch_time(DISPATCH_TIME_NOW, self.nSecs())
    }
}

// Define a simple function for getting a timer dispatch source.
func repeatingTimerWithInterval(interval: NSTimeInterval, leeway: NSTimeInterval, action: dispatch_block_t) -> dispatch_source_t {

    let timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue())
    guard timer != nil else { fatalError() }

    dispatch_source_set_event_handler(timer, action)

    // This function takes the UInt64 for the last two parameters
    dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, interval.nSecs(), leeway.nSecs())

    dispatch_resume(timer)

    return timer
}

// Create the timer
let timer = repeatingTimerWithInterval(interval, leeway: 0.0) { () -> Void in

    drawDonut()
}

// Turn off the timer after a few seconds
dispatch_after((interval * 60).dispatchTime(), dispatch_get_main_queue()) { () -> Void in
    dispatch_source_cancel(timer)

    XCPlaygroundPage.currentPage.finishExecution()
}

Upvotes: 0

Views: 229

Answers (2)

Hamish
Hamish

Reputation: 80901

This does indeed appear to be a playground limitation. I'm able to achieve an interval of 0.01 seconds when testing on an actual iOS device.

Although I was wrong in my initial answer about the limitation of the run loop speed – GCD is apparently able to work some magic behind the scenes in order to allow multiple dispatch sources to be fired per run loop iteration.

However, that being said, you should still consider that the fastest an iOS device's screen can refresh is 60 times a second, or once every 0.0167 seconds.

Therefore it simply makes no sense to be doing drawing updates any faster than that. You should consider using a CADisplayLink in order to synchronise drawing with the screen refresh rate – and adjusting your drawing progress instead of timer frequency in order to control the speed of progress.

A fairly rudimentary setup could look like this:

var displayLink:CADisplayLink?
var deltaTime:CFTimeInterval = 0
let timerDuration:CFTimeInterval = 5

func startDrawing() {

    displayLink?.invalidate()
    deltaTime = 0

    displayLink = CADisplayLink(target: self, selector: #selector(doDrawingUpdate))
    displayLink?.addToRunLoop(NSRunLoop.mainRunLoop(), forMode: NSRunLoopCommonModes)
}

func doDrawingUpdate() {

    if deltaTime >= timerDuration {
        deltaTime = timerDuration
        displayLink?.invalidate()
        displayLink = nil
    }

    draw(CGFloat(deltaTime/timerDuration))
    deltaTime += displayLink?.duration ?? 0
}

func draw(progress:CGFloat) {
    // do drawing
}

That way you can ensure that you're drawing at the maximum frame-rate available, and your drawing progress won't be affected if the device is under strain and the run loop is therefore running slower.

Upvotes: 0

Dancreek
Dancreek

Reputation: 9544

The interval you set for a timer is not guaranteed. It is simply a target. The system periodically checks active timers and compares their target fire time to the current time and if the fire time has passed, it fires the timer. But there is no guarantee as to how rapidly the system is checking the timer. So the shorter the target interval and the more other work a thread is doing, the less accuracy a timer will have. From Apple's documentation:

A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed. Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds. If a timer’s firing time occurs during a long callout or while the run loop is in a mode that is not monitoring the timer, the timer does not fire until the next time the run loop checks the timer. Therefore, the actual time at which the timer fires potentially can be a significant period of time after the scheduled firing time.

Upvotes: 1

Related Questions