2

バッチ レイアウト モードでQListWidgetを使用している場合、バッチ サイズよりも多くの項目が追加されると、古いリストから新しいリストに切り替えるときにリスト ウィジェットが短時間点滅します。つまり、リスト ウィジェットにはアイテムが表示されず、スクロール バー ハンドルは一見ランダムなサイズに設定されます。

これに遭遇したことはありますか、これはどうにかして解決できますか? Qt 4.7.4 を使用しています。おそらく、隠しアイテムを使用していないことを付け加えておく必要があります。

4

1 に答える 1

5

私もこの問題を抱えており、Qtウィジェットのレンダリングである海をくまなく調べていました。最終的に、あなたと同じように、問題を QListView のバッチ処理にまでさかのぼります。バッチ処理が有効になっている場合、Qt は内部タイマーを起動して、基になるスクロール ビューの段階的なレイアウト調整を実行するようです。これらのインクリメンタル レイアウトの間、スクロール バーが表示されていると、更新領域が正しく計算されません (大きすぎて、スクロール ウィジェット自体が占める領域を考慮していません)。その結果、不適切な更新領域が発生し、後でビューポートの更新に移行します。これは、ListViewItem をレンダリングせずにクライアント領域全体をクリアするという不幸な副作用があります。

バッチ処理が完了すると、最終的なビューポートの更新により、(スクロール バーを使用して) レイアウト ジオメトリが正しく計算され、有効な更新領域が生成されます。次に、リスト内の可視要素が再描画されます。

リスト内のアイテムの数が増えると (バッチ サイズと比較して)、動作が悪化します。たとえば、リストが 500 から 50000 アイテムに増加し、バッチ サイズが 50 の場合、トリガーされる「不適切な再描画」イベントの数が比例して増加し、ビューが目に見えてさらにちらつきます。:(

これらのインクリメンタル（および失敗）ビューポートの更新も、説明したスクロールバーハンドル位置で明らかなスパズモディックな動作を引き起こしているようです。

この問題の根本は、ここにコメントされているように QListView::doItemsLayout() に追加されたこの「ハック」に関連しているようです。

// showing the scroll bars will trigger a resize event,
// so we set the state to expanding to avoid
// triggering another layout
QAbstractItemView::State oldState = state();
setState(ExpandingState);

QListView::doItemsLayout() をオーバーライドして、スクロール バーを適切に処理する独自のバッチ処理を提供できると思いますが、個人的には年を取りすぎて怠け者なので、他の人のうんちを掃除することはできません。SinglePass に切り替えることで、問題は完全に解消されました。ちらつきのないシームレスなレンダリングと、ユーザーが期待し愛用するようになったスクロール バーの動作。わーい。

于 2013-01-26T02:10:52.733 に答える