Linux 用の Qt ベースの組み込みソリューションを開発しているときに、いくつかの問題に直面しています。基本的に、私のアプリケーションは、最大 8 個の QwtPlotCurves が添付された QwtPlot グラフをプロットします。QwtPlot::replot() は 1 秒ごとに呼び出されます。データは、同じシステム内の別の .c アプリに接続されたソケット接続から到着します。ハードウェアはテキサスの OMAP です。
問題は、構成によっては、再プロットが非常に遅くなることです。具体的には、4 つのカーブを表示すると遅延は感じられませんが、8 つのカーブを表示すると 400 ～ 500 ミリ秒の遅延が発生し始めます。
システムのデバッグを開始して、ボトルネックの可能性がある場所を見つけました (3 つの段階があります。最初の段階ではポイントを受け取り、その間にほとんど処理を行わずに一時バッファー内でそれらを保護します。2 番目はそれらのポイントをプロット ポイント ベクトルにコピーし、3 番目はそれらのポイントをプロット ポイント ベクトルにコピーします。 QwtPlot::replot() を呼び出してグラフを更新するタイマーのようなものです) そして、最初の 2 つの段階を破棄した後、実際の問題は replot() メソッドを取り囲んでいると思いました: 呼び出す前にタイマーを開始することを期待しますそれと QTime::elapsed() を呼び出して、どれくらいの時間がかかったかを調べると、大きな数字が見つかりました。
しかし、間違っています！この方法は、私が直面している 400 ～ 500 ミリ秒の遅延と比較して、10 ～ 15 ミリ秒しかかかりません。これを念頭に置いて、私は質問をしました: QwtPlot::replot() は何かが起こるように呼び出してから次に進みますか.再プロットを行うのに膨大な時間がかかるのは、その作業を適切に処理できないハードウェアのせいですか?
ところで、OpenGL (Qwt はそのような可能性を提供します) を使用すると、私の問題を解決できますか? 他のタスクのためにプロセッサを強制終了するという欠点はありませんか?
編集：
- オブス。1：OpenGLに関しては、プロセッサにGPUやOpenGLを使用する他の方法がないため、現在の特定の組み込み状況ではOpenGLを使用できないことをすでに学びました（SOの別の質問で）実際には役に立ちません (詳細については、このリンクを参照してください)。
- オブス。2: replot の更新は 1 秒に 1 回行われるため、replot の過剰な呼び出しが原因で問題が発生することはなく、(QwtPlotDirectPainter などによる) 部分的な replot を使用しても無駄です。
オブス。3: QwtPlot::replot() メソッドを再実装したので、現在は 3 つのメソッドしか呼び出されません。
updateAxes(); poCanvas->invalidateBackingStore(); poCanvas->update();