バッファをスワップしている多くのOpenGL描画領域が遅くなる問題

Question

gtklexを使ってOpenGLを使用し、アニメーションを実行するとき、私は減速の問題を抱えています。

私は、GTKアプリケーションでOpenGLを使用して特定の表示を行うアプリケーションを基本的に持っています。一度に多くのウィンドウを開くことができます（また、特定のウィンドウには複数の描画領域があります）。したがって、20-30のOpenGL描画領域を画面上に一度に言うことが可能です。図面はあまり重すぎるものではなく、非常に高速です。

私の問題は、これらのすべてのディスプレイがアニメーション化されているために、アプリケーションの速度が遅くなることです。私が問題を引き起こしているのは、OpenGLへのスワップバッファの呼び出しだと私は決定しました。 GTKで描画すると、ウィジェットのすべての描画がイベントを公開します。したがって、描画エリアウィジェットでgtk_widget_queue_drawを呼び出すと、GTKがそのイベントを処理しているときに、描画を必要とするすべてのウィジェットで連続してexposeイベントが呼び出されます。問題が生じるのは、描画が終了した後で、スワップバッファを呼び出して実際のOpenGLを描画する必要がある（ダブルバッファリングのため）。この呼び出しは、モニタが更新されるまで（vysncがオンであるため）ブロックされているようです。画面に3つの描画領域がある場合は問題ありませんが、トンがある場合は、スワップバッファコールが呼び出され、スワップバッファコールが呼び出されるたびにアプリケーションをブロックして実際にスローダウンします自身のイベントを公開し、いずれも同期していません。

私の質問は、スワップバッファの呼び出しをすべて同期する方法があるため、あまりブロックされていません。 vsyncをオフにする（OS/OpenGLの実装に固有の問題があるので、それ自体は問題だが）スピードの問題は解決されるが、問題が引き裂かれる。私はGTK公開イベントでswapbuffersを実行しなければならないので、マルチスレッドがどのように役立つかはわかりません。なぜなら、何か考えていない限り、図面はGTKと同期しているからです。

助けていただけたら幸いです！

Answer 1

20個以上のウィンドウがある場合、何をお探しですか？それぞれのタイミングは画面のリフレッシュと同じタイミングで同期されます。その間にそれぞれのメモリ操作を行う必要があります。すべて同時に。もちろん、減速するでしょう。あなたが20以上のプロセッサを持っていなければ、彼らは他のプロセッサの後ろに1行に入る必要があります。

実際には、ユーザーに表示されるGLウィンドウの数を制限する以外に多くのことができます。

Answer 2

この問題に対処する典型的なアプローチは、各OpenGLコンテキストに独自のスレッドを使用してスワップすることです。

しかし、OpenGLの実装者は、「コーディネートされたスワップ」などを導入する新しい拡張機能を導入することができます。いくつかの同期拡張があります。特に、http://www.opengl.org/registry/specs/OML/glx_sync_control.txt