問題タブ [cadisplaylink]

NSTimer によって起動されたメイン ウィンドウに OpenGL アニメーションを描画しています。スクロール可能な UITableView メニューを含むポップオーバー ウィンドウを表示すると、スクロール中にアニメーションがフリーズします。スクロール アニメーションが停止すると、タイマー コールバックが再び開始されます。メイン ウィンドウの更新が停止するのは、ユーザーが積極的にスクロールしようとしたときだけです。

Apple のスクロール アニメーションが何らかの形でメイン ループのディスパッチをブロックしているようです。これは本当ですか、それを修正する方法はありますか?

コードの複雑さが指数関数的に増加するため、できることならマルチスレッドを導入したくありません。

また、NSTimer の代わりに CADisplayLink を使用してみましたが、表示リンクの呼び出しもスクロール アニメーションによってブロックされます。

私はiPhoneアプリで作業していますが、私のアプリには画面の上から下に移動するオブジェクトがあります。これを行うには、CADisplayリンクを使用します。オブジェクトが画面を離れると、ルートを再開することになっています。私が直面している問題は、オブジェクトがルートを再開するたびに速度が上がることです。これは、オブジェクトが非常に速くなり、ほとんど見えなくなるまで続きます。なぜこれが起こっているのか、そしてそれを止める方法はありますか？助けていただければ幸いです。よろしくお願いします。

したがって、これは私にとって実際の問題ではありませんが、なぜこれが起こっているのか誰かが知っているかどうか知りたいです.

画面に一度に表示されるのは 1 つだけですが、2 つのビューが並んでいますが、両方が同時にアクティブになっています (レスポンシブ スワイプが必要なので、ビューが画面から消えたときにビューを破棄したくありません)。1 つのビューだけを作成したとき、a frameIntervalof 2 は 30 fps になり、これは正常です。2 番目のビューを追加すると、a frameIntervalof 2 で 60 fps になりました。両方のビューで 4 に変更すると、意図したとおりに 30 fps になり始めました。

なぜこのようになるのかわかりませんが、知りたいです。私にはバグか何かのように思えます。

注: iOS7 の時点では、この問題はシミュレーターでのみ発生する可能性があります。まだテスト中です。

CADisplayLink の実装があり、表示が実際に更新された場合にのみコードを実行する必要があります

これは起こりません。

以下は、非常に単純なテスト プログラムです。

表示リンクの実行を開始します。最初のフレームで、aLabel は「WordFlash」を表示する必要があります。次の 19 フレームでは "--------" を表示し、次の 100 フレームでは空白にする必要があります。その後、サイクルが繰り返されます。

ときどき (たとえば 8 回に 1 回)、予期せずに、コードが実際に実行されても (カウンターが進んだため)、画面が更新されずに「WordFlash」が表示されません。「WordFlash」が正確に 1 フレームだけ正常に表示された場合にのみ、カウンタを進める必要があります。

何か案は？私は完全に困惑しています。

注: この表示リフレッシュ スキップは、デバイスが単純なコードを実行するのにかかる時間と相関関係なく発生するようです (NSLogged 実行時間のように、コードは 2 つの異なるサイクルで同一である可能性がありますが、1 つのサイクルのみが正常に実行されます。という言葉をひらめいた。

とても感謝しております、

b

以前の投稿 (こちら) で詳しく説明したように、最初の角度から始まり、最後の角度に移動するアニメーションを作成しています。CADisplayLinkユーザー入力中にアニメーションをできるだけ速く実行する必要があるため、このアニメーションに を使用することにしましCALayerたCAKeyframeAnimation。

CADisplayLinkを呼び出す を実装した後setNeedsDisplay、アニメーションは機能しますが、ある角度から次の角度への連続的な流れを作成するのではなく、 endAngle と initialAngle の差を非常に目に見える角度のブロックに分割するため、非常に見栄えが悪くなります。これが私が持っている現在のコードです:

また、kDrawDurationは と定義されているので、 からまで3.0fのアニメーションは3.0 秒かかります。を計算して完全な円 (ラジアン) を等しいセグメントに分割し、できればフレームごとにこれらの角度の 1 つをアニメートしたいのですが、どうにかして考慮に入れる必要があります。initialAngleendAngle2*M_PI2*M_PI / kNumAnglesInAnimationkDrawDurationelapsedTime

これを修正するのを手伝ってくれてありがとう！

設定された進行状況に基づいて UIBezierPath をアニメーション化するプロジェクトがあります。BezierPath は円の形をしており、UIView にあり、アニメーションは現在 CADisplayLink を使用して drawRect で行われています。簡単に言えば、設定の進行状況に基づいてx、パスは放射状に拡張 (x以前よりも大きい場合) または縮小 (x小さい場合) する必要があります。

これは、x前回の更新以降に縮小した場合です。私が経験している問題は、実際にはいくつかあります。

1. 形状は常に45 度から描画を開始します (ビューを回転させない限り)。これを変更する方法が見つかりませんstartAngleでした。-45º に設定しても、常に 45 に「ポップ」されるため、実際には違いはありません。
2. これらのものをアニメーション化する他の方法はありますか? 私は使用について多くのことを読みましたCAShapeLayerが、これら 2 つの方法を使用する場合の実際の違い (欠点と利点の点で) をよく理解していません。誰かが明確にすることができれば、私は非常に義務付けられます!

更新:代わりにコードを CAShapeLayer に移行しましたが、別の問題に直面しています。この画像で最もよく説明されています：

何が起こっているかというと、レイヤーが縮小するはずのときに、薄い外側の線がまだそこにあるということです (移動の方向に関係なく)。バーが縮小しても、1- のデルタは、そのx上に新しい白い形状を明示的に作成しない限り削除されません。このコードは次のとおりです。何か案は？

更新 2:他のバグのほとんどを解決しました。結局のところ、それは私がずっとばかげていて、アニメーション全体を過度に複雑にしていることが判明しました（言うまでもなく、どこでも1を掛けることは何ですか？）。解決できないバグの gif を作成しました。

何か案は？

更新 3: (および閉鎖)。呼び出すことでバグを取り除くことができました

そして今、すべてが正常に機能します。助けてくれてありがとう！

Maybe you don't need all this information to help me with this problem. The core questions is: What can cause a CADisplayLink to delay firing, and how to check for possible reasons?

I'm using a CADisplayLink timer to velocity-/inertia-scroll my own implementation of an audio waveform view:

I'm experiencing problems with the accuracy of the timer. It usually fires 50 or 60 times a second (not sure, but exact number doesn't matter here). During certain actions, this rate goes down to about 3 to 5 fires per second, which is way too low for smooth scrolling. I am unable to identify what causes these delays.

I've tried:

• Completely uncoupling drawing and loading by outsourcing the loading of audio data to a dedicated dispatch queue, which loads the data asynchronously.
• Profiling and optimizing the drawing method. At peaks, it takes a maximum of 6ms.
• Profiling the method called when the timer fires (velocityScroll:). It usually takes less than 1ms to execute, sometimes peaks are at 3ms.
• using NSRunLoopCommonModes instead of NSDefaultRunLoopMode for the CADisplayLink timer

In the caching, I have a lot of dispatch_sync's and a few dispatch_barrier_sync's. Although most of them should be irrelevant, I've

• profiled every dispatch-to-start time in my caching
• profiled every execution time of dispatched blocks in the caching

Although most of them must be irrelevant. I didn't find any waits/blocking which took more than 50ms. This is a bit slow, but still I think it should not get the timer down to 5 fires/second or worse.

For profiling, I've not used a profiling tool (couldn't handle them). Instead, I used the typical approach:

Here is the method executed when the timer fires. The three methods in the middle are mostly plain simple position-calculations which are executed in almost no time, except the last one, which does a dispatch_sync to the main queue. However, this completes extremely quickly (less then 3ms, see above).

I know you guys would like to see more code, but there is a lot of code and I don't want to post all of it. Please ask for individual parts, which I will then post here, if you need them.

What could cause the delays between fires of the CADisplayLink timer or how to find it out?

例

• CoreGraphics を使用してカスタム スピナーを描画するだけの UIView があります。各フレームを描画できるように、CADisplayLink を使用して自分自身を更新しています。
• 別の UIView サブクラスも CoreGraphics を使用して進行状況バーを描画します。また、CADisplayLink を使用して自身を更新しています。

リストは潜在的に続く可能性があります。そして、コードごとにわかるように、各コンポーネントに独自の CADisplayLink があることが明らかに最も簡単です。

多くのCADisplayLinksを持つことは良いですか、それとも悪いですか? (複数の CADisplayLink インスタンスを持つ回避策は、各コールバックを多くのデリゲート/ブロックに送信する 1 つのインスタンスを持つことです)