6

QTableViewMint Linux 12 で Qt4.8 を使用して、モデルの内容を表示する を含む単純なウィンドウを実装しました。モデル データは継続的に更新され (ログ メッセージ)、dataChanged()シグナルは定期的に (つまり、100 ミリ秒ごとに) 送信されます。

私が目にする問題は、テーブルの視覚的な更新が途切れることです。

タイプのイベントをカウントするウィンドウにイベント フィルタをインストールしましたupdateRequest。これにより、ウィジェットの再描画がトリガーされます (子ウィジェット、つまり にもtableView)。これらは、それらの間の平均時間は〜170ミリ秒で、標準偏差は〜90ミリ秒です（かなり大きいと思います）。しかし、知覚される視覚的な更新レートは 1 秒間に 2 ～ 3 回しかなく、なぜでしょうか。すべてのupdateRequestイベントがウィジェットの再描画をトリガーするわけではないか、ウィンドウ システムが視覚的な更新を飲み込んでしまうようです。

repaint2 番目のテストとして、またはupdate100 ミリ秒ごとにウィンドウを強制的に更新しました。を使用repaintすると、対応するupdateRequestタイプのイベントが増加し、ギャップの標準偏差が減少することがわかりました。でupdate、数は増加しませんでした。ただし、どちらの場合も、認識される更新レートは中程度の増加しかありませんでした。

paintEventまた、ハンドラをオーバーロードすることなく、ウィジェットが実際に再描画される頻度を測定する良い方法はありますか? 多分何かからQTest？

更新:イベント フィルターを拡張して、paintEventタイプのイベントもキャッチできるようにしました。updateRequest1000 を超えるタイプのイベントに対して、それらの数は 1 桁しかありません。

4

2 に答える 2

1

イベント ディスパッチャーのaboutToBlock()とawake()シグナルを計測し、QElapsedTimer. 現在のスレッドのイベント ディスパッチャーのインスタンスは、 static によって返されますQAbstractEventDispatcher::instance()。

イベント ループが時間測定ウィンドウのごく一部でスリープする場合は、GUI スレッドで処理が多すぎることを意味します。たとえば、最後の 1 秒間に、イベント ループがスリープ状態になった時間をカウントできます。10% を下回ると、更新が遅くなるなどの事態が予想されます。更新イベントは でキューに入れられることに注意してQt::LowEventPriorityください。それらは、標準のキューに入れられたシグナルと他のほとんどすべてのイベントによってプリエンプトされます。

于 2012-06-12T16:31:54.380 に答える
0

QApplication::compressEventQEvent::UpdateRequest未処理のものがすでに1つある場合は、を破棄します。したがって、イベントが破棄された場合、再ペイントでさえ、ペイントせずにすぐに戻ることができます。updateRequestを上書きしてイベントが破棄されているかどうかを確認できますcompressEvent。

于 2012-06-12T13:46:45.700 に答える