仅限新iPad 3:wait_fences:未收到回复:10004003 [英] Only on new iPad 3: wait_fences: failed to receive reply: 10004003

查看:68
本文介绍了仅限新iPad 3:wait_fences:未收到回复:10004003的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我知道有很多关于这方面的问题,但据我所知,这是一个独特的情况所以我想我会发布它。希望,这将添加一些信息,最终可以给我们一个答案,为什么这发生在我们身上。我收到错误:wait_fences:无法收到回复:10004003,当我的设备旋转时。我的视图动画从以下开始:

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 that may finally give us an answer as to why this is happening to us. I'm getting the error: wait_fences: failed to receive reply: 10004003, when my device rotates. The animation of my views are initiated from:

- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration

我只是在新iPad上出现错误3.我在原版iPad和iPhone上使用了与3GS一样低的程序。他们都没有得到wait_fences错误,他们都比iPad 3旋转得更快。

I'm only getting the error on the new iPad 3. I've used the exact same program on an original iPad and iPhones as low as a 3GS. They all don't get the wait_fences error and they all rotate faster than the iPad 3 does.

我几乎只使用Core Graphics来绘制视图。我也确保他们重新调整大小,所以我没有得到像素化的视图。如果我在调整大小时禁用重绘,我不会收到此错误(但我得到了拉伸视图)。如果我完全禁用核心图形绘图我没有得到错误(当然,我得到黑色视图)。

I use Core Graphics almost exclusively to draw the views. I also ensure they're redrawn on a resize so I don't get pixilated views. If I disable the redraw on resize, I don't get this error (but I get stretched views). If I disable core graphics drawing altogether I don't get the error (but, of course, I get black views).

我使用Time Profiler并发现挂断主要是绘制渐变:

I used the Time Profiler and found out that the hangup was primarily in drawing gradients:

我已经改变了代码来填充而不是绘制渐变,这确实缓解了问题。我会说渐变是问题,除了我在其他情况下做这些动画(除了响应旋转)并且它工作得很好。

I have altered the code to fill rather than draw gradients and that does alleviate the problem. I would say that the gradients are the problem except I do these animations in other situations (other than in response to rotation) and it works just fine.

我还要注意,我特别注意确保我只为屏幕上的视图制作动画。我知道在屏幕上设置动画视图有时会导致出现此错误。

I would also like to note that I've paid special attention to making sure I only animate views that are actually on the screen. I know that animating views off screen can sometimes cause this error to occur.

我没有包含动画代码

关于为什么会发生这种情况的任何想法?特别是因为它只发生在iPad 3上?

Any ideas as to why this is happening? Especially since it's only happening on the iPad 3?

对于那些会问的人,这是执行动画的代码。它通常包含在UIView动画块中。

For those who will ask, this is the code that performs the animation. It will normally be wrapped in a UIView Animation Block.

- (void) setFramesForFocusView:(CustomControl *)focusView atX:(CGFloat)x showInput:(BOOL)showInput{
    CGSize bSize = self.bounds.size;
    CGRect fRect = focusView.frame;
    fRect.size.width = bSize.width;

    CGRect iRect;
    if (focusView.inputViewIsSystemKeyboard){
        if (_keyboardRect.origin.y < 0 || _keyboardRect.origin.y >= CGRectGetMaxY(self.bounds) || CGRectIsEmpty(_keyboardRect) || CGRectGetMaxY(_keyboardRect) > CGRectGetMaxY(self.bounds)) return;
        iRect = _keyboardRect;
    } else {
        iRect = (focusView.inputUIView && showInput) ? CGRectMake(0, bSize.height / 2, bSize.width, bSize.height / 2) : CGRectZero;
    }

    CGRect iaRect = focusView.inputAccessoryUIView.frame;
    CGFloat availableFieldHeight = iRect.origin.y - iaRect.size.height;

    iRect.size.width = bSize.width;
    iaRect.size.width = bSize.width;

    if (!showInput){
        iRect.origin.y = bSize.height;
    }
    iaRect.origin.y = iRect.origin.y - iaRect.size.height;

    iRect.origin.x = x;
    iaRect.origin.x = x;
    focusView.inputUIView.frame = iRect;
    focusView.inputAccessoryUIView.frame = iaRect;

    if (focusView.expandInput){
        fRect.origin.y = 0;
        fRect.size.height = availableFieldHeight;
    } else {
        if (focusView.labelPlacement != LabelPlacementTop && focusView.labelPlacement != LabelPlacementBottom){
            fRect.size.height = _currentView.storedFrame.size.height + [focusView.label.text sizeWithFont:focusView.label.font].height; 
        }
        fRect.origin.y = availableFieldHeight - fRect.size.height;
    }
    if (fRect.size.height > availableFieldHeight){
        fRect.origin.y = 0;
        fRect.size.height = availableFieldHeight;
    }
    fRect.origin.x = x;
    [focusView setLabelPlacement:LabelPlacementTop toFrame:fRect];
}


推荐答案

那很快。 @RobNapier是正确的,因为这是一个时间问题。我评论了我的动画,哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇!虽然我只是明确地为屏幕视图制作动画,但还有另一个ViewController接收我视图背后的旋转事件而没有我......呃...知识?我的意思是,我应该知道对吗?我写了代码。起初我没有意识到,因为我的一组视图覆盖了整个屏幕。不幸的是,这需要大量的重写。我使用自定义容器控制器,现在我看到我需要重新考虑我的实现。很多东西都在不必要地旋转/动画。但哇......这回答了很多性能问题....

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

所以我认为我遇到的问题与其他视图控制器动画的额外视图有关。然而,虽然这在技术上是正确的,但它并不像我想象的那样真实,也不像我想象的那样真实。我绝对确定没有其他视图通过从窗口中删除整个根视图层次结构并仅用我想要旋转的视图控制器替换它来动画。这绝对有帮助,但并非完全如此。真的,它只是'降低了标准',因此我不太可能得到'wait_fences'错误。在某些情况下,我仍然发现我收到了错误。

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.

我相信我遇到的问题是我使用的是UIScrollView。我的实现具有可管理的可变数量的子视图。特定视图是我自己的UIPickerView自定义实现,因此您可以想象,它管理的视图数量可能会变得非常大。我发现如果这些子视图变得太多,我会开始收到'wait_fences'错误。

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.

所以看起来:如果UIScollView是动画的,那么即使这些子视图不在屏幕上,也会动画所有子视图。这很重要。我宁愿怀疑许多正在努力解决这个错误的人可能没有意识到这一点。这些离屏子视图中的每一个都会让您更接近于发出'wait_fences'错误。我的解决方案是简单:我要将我的UIScrollView转换为UITableView。这意味着重写了很多代码,但至少我知道屏幕外的子视图将从屏幕中删除,因此不会动画。

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.

我还注意到了一些东西其他:核心图形渐变让你很难受。如果他们不使用渐变,我可以在屏幕外观看更多动画。当然,我喜欢渐变,我不愿意放弃它(这就是为什么我要改写我的PickerView),但这很有趣也很重要。

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.

更新2

完成将我的UIScrollView重写为tableView,这似乎完成了诀窍。旋转屏幕时,我没有滞后,没有 wait_fences 错误。

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.

更新2

所以是的,在iPad 3上点击 wait_fences 错误要比其他任何错误容易得多iPad / iPhone的。我已经完成了所有代码,确保我从未动画过任何不在屏幕上的内容,以便解决问题。当我使用'重'绘图程序时,我仍然在iPad 3上得到 wait_fences 错误。我找到的东西让我点击它:

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. 渐变:渐变真的让CPU在视网膜屏幕上工作。

  2. 透明度:如果您的视图不透明,则CPU会努力找出视图的透明区域。

  3. 透明颜色:与视图不同透明度。这是将透明的颜色/渐变层叠在彼此的顶部以获得效果,如光泽,突出显示任何内容。

  4. 纹理:我发现使用纹理使它更有可能点击 wait_fences 错误,但没有像渐变/透明度那样接近。

  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.

这篇关于仅限新iPad 3:wait_fences:未收到回复:10004003的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆