質問

ライブデータがアプリケーションのビューアに表示されるcustum QGISアプリケーションの構築に携わっています。

使用されているIPCはUNIXメッセージキューです。

データは、指定された間隔(3秒など)で更新されます。

今直面している問題は、表示されるデータの処理に3秒以上かかることです。そのため、アプリが次の更新のためにデータの処理を開始する前に、更新QTimerが停止し、データが処理された後、再度QTimerを再起動します。アプリは、更新/更新(この更新中にアプリが応答しなくなる)の後に、ユーザーが作業を続ける十分な時間を得るように動作します。データが更新されているのを見るだけでなく、ユーザーが作業するのに許容できる一時停止を取得することができます。1つのシナリオで。

ただし、異なるOS(RHEL 5.0からRHEL 5.2)では状況は異なります。タイマーはワイルドになり、連続した更新を行うことなく一時停止せずに起動し続けるため、無限ループに入ります。 3秒以上かかりますが、その理由で処理中にタイマーを停止して再起動しました。同じシナリオが1つのシナリオで機能し、他のシナリオでは機能しません。私が観察した他の事実は、タイマーの発生は、リフレッシュ機能が終了するのにかかる時間が300ミリ秒と非常に短いため、この機能の開始と終了に配置したタイマーの開始と停止はその小さな時間で発生します。データの実際の処理が終了すると、実行待ちのキューにタイマーが3〜4回開始されるため、無限ループの問題は、更新が続くたびに悪化します。

ここで注意すべき重要なことは、1つのOSの同じコードの場合、リフレッシュ時間は約4000ミリ秒(同じ量のデータにかかる実際の処理時間)であり、他のOSの場合は300ミリ秒であるということです

これは更新されたOSの新しいライブラリと関係があるかもしれませんが、それがなぜ起こっているのか手がかりが得られないため、デバッグ方法がわかりません...おそらくpthreadsに関連する何かが変更されましたb / w OSs ??

だから、私の質問は、QTimerは私が何を達成するための良いオプションではないと思うので、QTimerを使用せずに私のアプリの一部の処理がタイマー化される(そしてOSに依存しない)ことを保証する方法があります欲しいですか?

どのようなオプションがありますか?? pthreadsまたはBoostスレッド?スレッドを代替として使用する場合、どちらが良いでしょうか?しかし、更新処理にどれだけ時間がかかっても、連続した更新で少なくとも3秒のギャップを確保するにはどうすればよいですか?

親切なヘルプ。

ありがとう。

役に立ちましたか?

解決

許容できる長期的な解決策を得ようとしている場合は、別のスレッドでディスプレイの更新を調査します。そのスレッドでは、ディスプレイを画像にペイントして、必要な頻度で更新できますが、利用可能な処理時間のすべてがかからないようにスレッドを調整することもできます。次に、UIスレッドで、その画像を読み取って画面に描画できます。これにより、画像のさまざまな部分を表示できるため、パンに対する応答性が向上します。タイマーに基づいて3秒ごとにイメージを更新するか(ソースから再描画するだけ)、新しいデータが完全に更新されるたびに他のスレッドからシグナルを発行させることができます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top