0

I am using the dispatcher source timer update a view at different frame rates. (8, 12 or 24 FPS)

Here is the code that initializes the dispatcherTimer and the function used to create the timer.
(this function is directly taken from apple doc in the subsection "creating a timer": http://developer.apple.com/library/mac/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/GCDWorkQueues/GCDWorkQueues.html)

call:

    self.dispatchTimer = [self createDispatchTimerWithInterval:self.project.frameDuration * NSEC_PER_SEC
                                                    leeway:0.0 * NSEC_PER_SEC
                                                     queue:dispatch_get_main_queue()
                                                     block:displayFrame];

function:

- (dispatch_source_t)createDispatchTimerWithInterval:(uint64_t)interval leeway:(uint64_t)leeway queue:(dispatch_queue_t)queue block:(dispatch_block_t)block {
    dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER,
                                                 0, 0, queue);
    if (timer) {
        dispatch_source_set_timer(timer, dispatch_walltime(NULL, 0), interval, leeway);
        dispatch_source_set_event_handler(timer, block);
        dispatch_resume(timer);
    }
    return timer;
}

My view updates perfectly, but the touch events are not caught. My first bet would be that the block "displayFrame" takes too much processing time because if I reduce the frameDuration to 0.5 second or so, the touch events are caught.

I only tested this on iOS 4 with a iPad 2.

Any help or hint would be greatly appreciated!

Etienne

UPDATE

I have asked a similar question on the apple developper forum, here is the answer I got: https://devforums.apple.com/thread/156633?tstart=0

ebp
  • 61
  • 4
  • Run the code in Instruments with the "Time Profiler" and check the option for "All thread states". When the result comes back, look at the "Threads strategy". What does Instruments tell you that the main thread is doing? Is it busy doing computations or waiting for something? – David Rönnqvist Jun 26 '12 at 20:47

1 Answers1

1

The main run loop drains the main queue after each pass through the runloop. I think you're right when you say your duration is too short. If the source is adding new blocks to the queue faster than they can be drained, I would certainly expect the runloop to never resume processing events (since it's constantly trying to drain the queue).

Lily Ballard
  • 182,031
  • 33
  • 381
  • 347