Only on new iPad 3: wait_fences: failed to receive reply: 10004003

Question

So I know there\'s a lot of questions regarding this, but so far as I can tell this is a unique situation so I figured I would post it. Hopefully, this will add some info t

Answer 1

Well that was quick. @RobNapier was correct in that it was a timing issue. I commented out my animations and wow there were a lot of other views animating behind there! Even though I was explicitly animating only on-screen views, there was another ViewController receiving the rotation events behind my views without my... uh... knowledge? I mean, I should know right? I wrote the code. I didn't realize at first because my set of views was covering the entire screen. Unfortunately this will require a lot of rewriting. I use Custom Container Controllers and now I see I need to reconsider my implementation. A lot of stuff is getting needlessly rotated/animated. But wow...that answered a lot of performance questions....

Update

So I had thought that the problem I was facing had to do with the extra views being animated by other view controllers. However, while this is technically true, it's not as true as I thought or in the way I thought. I made absolutely sure that no other views were animated by removing the entire root view hierarchy from the window and replacing it with only the view controller I'm wanting to have rotated. This definitely helped, but not completely. Really, it just 'lowered the bar' so that it was less likely for me to get the 'wait_fences' error. I still discovered I was getting the error though in certain situations.

I believe the problem I'm having is my use of a UIScrollView. My implementation has a variable number of of subviews that it manages. The specific view is my own custom implementation of a UIPickerView, so as you can imagine, the number of views it manages can become quite large. I've discovered that if those subviews become too numerous, I start getting the 'wait_fences' error.

So it appears that: If UIScollView is animated, it will animate all of it's subviews, even if those subviews aren't on screen. This is important. I rather suspect that a lot of people who are struggling with this error may not realize this. Each one of those off-screen subviews are pushing you ever closer to hitting the 'wait_fences' error. The solution in my case is "simple": I'm going to convert my UIScrollView to a UITableView. That'll mean rewriting a lot of code, but at least I know that off-screen subviews will be removed from the screen and thus not animated.

I also noted something else: Core-Graphic Gradients hit you hard. I can animate a lot more off-screen views if they don't use gradients. Of course, I love gradients and I'm not willing to give them up (which is why I'm rewriting my PickerView) but it is interesting and important to note.

Update 2

Finished rewriting my UIScrollView as a tableView and that seems to have done the trick. I'm getting no lag and no wait_fences error when I rotate the screen.

Update 2

So yeah, it's a lot easier to hit the wait_fences error on the iPad 3 than any other iPad/iPhone. I've gone through all my code making sure I never animate anything that's not on screen, so that issue's resolved. I still get the wait_fences error on the iPad 3 when I use 'heavy' drawing routines. Stuff I've found that makes me hit it:

1. Gradients: gradients really make the CPU work on the retina screen.
2. Transparency: if your view isn't opaque, the CPU works hard to figure out the transparent areas of the view.
3. Transparent Colors: not the same as view transparency. This is layering transparent colors/gradients over the top of each other to gain an 'effect', like gloss, highlights whatever.
4. Textures: I find using textures makes it a little more likely to hit the wait_fences error, but nothing near like what gradients/transparency does.