Strange problem: touch methods and multitasking

Dear all,

I’m experiencing some very strange issues on iOS 4.3. Haven’t noticed anything like this before, so it’s possible it got introduced in this update.

The issue: I launch an empty app, with only an NSLog in every touch method. When I drag my finger everything is fine, the output is exactly as expected. I press the home-button to return to the home screen and tap the app-icon to open the app again. Everything is still fine and the amount of time between logs is around 0.02 seconds (50 fps). I repeat this one more time, and suddenly the amount of time between logs is no less then 0.3 seconds! The framerate of the rest of my app is normal, animations work fine but as I keep repeating this process it only gets worse and the startup time of the app increases. After about 10 times it just crashes on startup (I think iOS kills it because it’s taking too long).

Instruments can’t find any leaks or other problems, and it seems to me that applicationWillResignActive and applicationDidEnterBackground don’t do anything other than firing an alert, which I discard by not responding to it. I’m using the 0062 iPhone release, I can’t get the iPhone branch on gitHub to play nice with my apps - or the emptyExample included. Does anyone have an idea where this is coming from and how one would go about solving it? :slight_smile:

Take care,

Have you tested this in release build and not hooked up to the computer?

I did, nothing changed.

Nobody else experienced this problem? I noticed that in at least some of the example-projects’ info.plist has “Application does not run in background” set to “YES”. Is this because of the problems with the touch-methods? I could of course save everything when the app enters background and reload it when it launches again, but I’d rather not use any time and resources when there is another way.

I forgot to mention, but I’m seeing this behaviour on both iPad (first gen, 4.3.3), iPhone (3Gs, 4.3.3) and even in the simulator.

When I get a chance i’ll try this, but I haven’t seen it happen personally. I have an app on the app store using 0062 and haven’t heard of any issues nor have any of the beta testers mentioned anything. I unchecked the app enter background from the plist so that it doesn’t exit on close and things seem fine. Of course, I also haven’t put in a FPS reader to check either.

I don’t know if this is related or not, but I’m noticing some delays in touch events when ofSetFrameRate is set to 60. When dragging an object on screen, it drags very slowly although the update and draw commands seem to be running at full fps.

To test this, you can put this in touchMoved event:

cout << ofGetFrameNum() << " " << ofGetFrameRate() << endl;  

When the frame rate is set to 60 it’ll print something like:

115 60.1532  
148 59.8324  
181 60.1234  
213 59.1253  

When the frame rate is set to 30 it’ll print something like:

72 30.1532  
72 30.8324  
73 30.1234  
74 30.1253  
74 30.1253  

Based on that, when at 60fps, the touch events are going 33fps (although from the looks it’s more like 10fps).

I’m not really sure if the frame rate is related to the original issue or not, but it would be worth testing by lowering the fps and see if the problem continues. This may all be fixed in the 007 release, but I haven’t tested it.

I’m also noticing in if I comment out where it sets displayLinkSupported = TRUE; so that it runs with NSTimer instead of displayLink that the touch event slowdown doesn’t occur at 60fps. Keep in mind you have to set the fps to either 60 or 30 because it seems iOS doesn’t support in between.

If you can try that and see what happens, that would be great.

I tried running at 30fps but it had no effect on the touch slowdown, but after commenting out the displayLink did the trick. I can now run the app at 60fps without any problems when multitasking. Thanks a lot Seth! Any idea where this is coming from?

Not sure where this is coming from because I did some research and there’s conflicting statements. Some say displayLink can cause lag in events and others say NSTimer can. It’s pretty confusing especially because displayLink is supposed to be the ‘best’ way to render to screen (because it’s more accurate). Personally, I didn’t notice this in relationship to multitasking since I would get lag regardless if it was the 10th time opening or the 1st time.

I added this to github: since I’m not sure if it’s fixed in 007 or not (I’ve only tested in 006x).

Personally I don’t have any experience using display link. I’ve never really used runloops in such a direct way (because hey, we have OF! And if we don’t have OF, we still have CG… :slight_smile: ) but it seems weird that it should cause issues like this.

Touch events aren’t polled on this timer are they? I see the EAGLView keeps a dict of activeTouches, which is updated in the touch methods of the view. I also see mouse-positions of the app being updated in those methods. I just tried logging a message from touchesMoved, and after 3 times home button / startup it is very problematic. It just stops receiving for 3 seconds, and then fires touch events it just missed (but all with the same position). Well, I’m just glad it’s working OK with the NSTimer method…