の 4 つの個別のインスタンスを持つ階層を含むカスタム QDialog がありますQOpenGLWidget
。
これらQOpenGLWidget
の はそれぞれ独自の GL コンテキストを持ち、異なるシーンをレンダリングします。
update()
私は定期的にそれぞれに(それらを再描画するための推奨される方法)を呼び出すループを持っています(QOpenGLWidget
より定期的に焦点を当てたものですが、これは問題とは無関係だと思います)。
私の問題は、最終的にランダムな時間が経過した後 (すぐに発生する場合もあれば、10 分以上発生しない場合もあります)、が呼び出されたQOpenGLWidget
ときに 1 つ以上の が再描画を停止することです。update()
QOpenGLWidget
ただし、ストールのサイズを変更すると、単一の再描画イベントがトリガーされることに気付きました。
update()
すべての で呼び出されているデバッガーで確認できますQOpenGLWidget
が、これは停止したウィジェットに対してトリガーpaintGL()
(再描画メソッド) することはありません。再描画をトリガーしているかどうかに関係なく、updatesEnabled()
常に true を返します。update()
また、QT はエラーや警告をコンソールに出力しません。
これらのウィジェットを含むダイアログは、トリガーするスレッドとは別のスレッドで実行されているため、(独自のイベント ループを作成せずに) 直接update()
呼び出すことはできません。repaint()
QApplication::sync()
トリガーするメソッドに追加してupdate()
も違いはありません。
使用可能な RAM が少ない場合に発生する傾向がありますが、RAM が 800 MB 程度であり、アプリケーションが使用する RAM はそれよりも大幅に少なくなります。だから私の腸はおそらく間違っています。
私はQTの大規模なユーザーではないので、ここから問題をさらにデバッグする場所がよくわかりません。提案があれば歓迎します。エラーの再現性には、不明な時間の待機と、より複雑でマルチスレッドのプロジェクトが含まれていることを考えると、コードの小さなスニペットでバグを再現しようとすることに大きなメリットがあるとは想像できません。
アップデート:
を呼び出すときにまったく同じ問題が発生しupdate()
ましたQGraphicsScene
が、毎回数回の更新後に発生していました。
代わりにビューポートを更新するこの提案が見つかりviewport()->update()
、問題が修正されたようです。
QOpenGLWidget
ただし、同じ方法で更新するビューポートがありません。