問題タブ [doublebuffered]

私の目的は、グラフィックスオブジェクトのメソッドを使用して描画された視覚要素を、ちらつきやアーティファクトなしでフォーム全体に移動することです（.NET 3.5の場合）。自動ダブルバッファリング（フォームのDoubleBufferedプロパティをtrueに設定）を使用するか、自分でバックバッファを実装することで、ちらつきのない動きを実現できます。しかし、はっきりと見えるアーティファクトを表示せずに、どちらの方法を使用する方法を見つけるのにも苦労しています。

自動ダブルバッファリングを使用すると、ページティアリング効果が明らかになります。60Hz LCDを3回更新すると、バックバッファがゆっくりと、徐々にフォームに上から下にコピーされているように見えます。

自分でダブルバッファリングを実装すると（詳細はコードブロックを参照）、ページティアリングが発生しないほど高速にバックバッファがフォームにコピーされているように見えます。ただし、別の種類のアーティファクトが表示される場合があります。以下のコードは、矢印キーを使用してフォームの白い背景の青い長方形を左右に移動できるようにするもので、長方形の左右の端に時々表示される一連の水平方向の白い帯として効果を再現する必要があります。動かされるのと同じように。

if（他の人が効果を再現できる）{
    私は何か間違ったことをしているのでしょうか、おそらく
    ペイントコードで何らかの競合状態を引き起こしているのでしょうか、それともこれは私が     生き
    なければならないランタイムの動作にすぎないのでしょうか？ } else {     それは私のディスプレイカードの特性か、     バグのあるディスプレイドライバでしょうか？ }

ルーレット ホイールのあるパネルがあり、ちらつきを止めるためにパネルをダブル バッファリングする必要があります。誰でも私を助けることができますか？

編集：

はい、試してみました。

panel1.doublebuffered は存在せず、this.doublebuffered のみです。そして、フォームだけをバッファリングする必要はありません。パネルだけです。

いくつかの「カスタム コントロール」のライブラリがあります。基本的に、独自のボタン、丸みを帯びたコーナー パネル、カスタム ペイントを使用したいくつかのグループボックスがあります。OnPaint メソッドの「数学」にもかかわらず、コントロールはかなり標準的です。ほとんどの場合、角を丸くして背景にグラデーションを追加するだけです。そのすべてに GDI+ を使用します。

これらのコントロールは問題ありません (顧客によると非常に見栄えが良い) が、DoubleBuffer にもかかわらず、特に同じフォームに 20++ ボタン (たとえば) がある場合に、再描画が見られることがあります。フォームをロードすると、ボタンが描画されるのが見えます…これは面倒です。

私たちのボタンが地球上で最速のものではないことは確かですが、私の質問は、ダブルバッファが「オン」の場合、すべての再描画がバックグラウンドで行われ、Windows サブシステムが結果を「即座に」表示するべきではないということです。

一方、ラベルを作成する「複雑な」foreach ループがある場合は、ループの前にパネルのレイアウトを一時停止し、ループが終了したときにパネルのレイアウトを再開する場合は、ラベルをパネルに追加し (ダブル バッファー)、それらのプロパティを変更します。これらのコントロール (ラベルとボタン) はすべて「ほぼ瞬時に」表示されるべきではないでしょうか? これはそのようには起こりません。パネルがいっぱいになっているのがわかります。

なぜこれが起こっていないのですか？サンプル コードなしで評価するのは難しいことはわかっていますが、それを再現するのも難しいです。私はカメラでビデオを作ることができましたが、これで私を信頼してください、それは速くありません:)

ピクセルごとのアルファ チャンネルを持つビットマップを含む子コントロールを描画すると、再描画が必要になるたびにかなりちらつきが発生します。実際のブレンドは正しく機能しています。ちらつきの低減に関する多くの情報 (この質問やこのサイトなど) を見つけましたが、この状況に特に当てはまるものは見つからないようです。

たとえば、ボタンの状態に応じて、アルファ ブレンドされ、ウィンドウにブリットされるいくつかの異なるビットマップを持つボタンがあります。それらの状態が変化し、別のビットマップを描画する必要がある場合は、最初に背景を再描画する必要があります。そうしないと、前の状態のビットマップから残ったピクセルとブレンドされます。これは、ちらつきが発生する場所であり、時折背景が少し引き裂かれます.

トップレベルの親ウィンドウが単色ではなくビットマップ背景を描画することと、子コントロールがオーバーラップする可能性があることにより、問題はさらに複雑になります。を使用しているように、下にある色を子のビットマップに乗算するだけでは問題ありませんWS_CLIPCHILDREN。

ウィンドウにはビットマップの背景があるため、上書きされるだけの色を描画しないようtrueに、 に戻ります。WM_ERASEBKGND

もちろん、ダブル バッファリングはこれらすべてを解決するように見えますが、私はそれを正しく機能させることができませんでした。WS_COMPOSITEDトップレベル ウィンドウとWS_TRANSPARENT子ウィンドウを設定しました。新しいビットマップで子ウィンドウを再描画するときが来ると、いくつかの問題が発生します (この状況で描画順序がどのように機能するかを理解していないことが原因である可能性が最も高い):

• 子ハンドルを呼び出しInvalidateRect()て渡すと、子ウィンドウは実際に再描画されますが、背景は再描画されないため、ピクセルが互いに重なり合ってブレンドされます。
• 子ウィンドウの寸法で構成される四角形を使用して、親ハンドルを呼び出しInvalidateRect()て渡すと、背景は再描画されますが、子ウィンドウは再描画されません。
• 上記の両方を行うと、子ウィンドウと同様に背景も再描画され、希望どおりに見えますが、そうすることで、再びちらつくことができました (これは「そうではありません」)。そのように2回呼び出すのはひどくハックに見えるので、本当に驚くべきことです。なぜならInvalidateRect()、各呼び出しがおそらくバッファを反転させ、目的を無効にするからだと思います)。

私が結論付けたのは、ダブル バッファリングを処理するためにプログラムをどのように変更する必要があるか、またはダブル バッファリングがこの状況に役立つかどうかを本当に理解していないということです。間違いなくそうだと思いますが、すべてを再び適切に再生するには、どのように変更する必要があるのか​​ よくわかりません.

アプリケーションを MFC から Qt に移行しています。

MFC アプリは、GDI 呼び出しを使用してウィンドウ (基本的にはグラフ プロット) を構築します。メモリ ビットマップ バック バッファーに描画し、それを BitBlt して画面に描画します。ただし、Qt はすでにダブル バッファリングを行っています。

ユーザーがグラフをクリックしてドラッグすると、ウィンドウのそのセクションが反転するようにしたいと思います。

これを行うための最良の方法を見つけたいと思います。画面ではなく、ウィジェットのバック バッファから取得するgrabWindow()のようなことを行う方法はありますか? ...多分 BitBlt(..., DST_INVERT) と同等ですか？

QPainter で setCompositionMode() を見ましたが、QImage で動作するペインターでのみ機能するとドキュメントに記載されています。(それ以外の場合は、反転効果のようなものを得るために派手な構成モードでウィジェットに塗りつぶされた長方形の画像を合成することができます)

QImage バック バッファにペイントする MFC と同じことを実行できますが、この方法ではハードウェア アクセラレーションが機能しない可能性があることを読みました。Qt で既に提供されているダブル バッファリングを再実装するのはもったいないようです。また、ウィジェットのダブル バッファリングをオフにした場合の副作用についてもよくわかりません (トリプル バッファリングを避けるため)。

ある時点で、それを保護する再帰防止フラグを使用した複雑な QPixmap::grabWidget() 呼び出しがありましたが、それはすべてを 2 回レンダリングし、QImage に描画するよりも明らかに悪いです。（そして、それは特にドキュメントで警告されています）

基本的にMFCで行ったように、あきらめてすべてをQImageに描画する必要がありますか?

編集：

さて、QPixmap ペインタは現在のダイレクトとほぼ同じ速度で実行されます。そのため、QPixmap バックバッファーを使用することがこれを行うための最良の方法のようです。

解決策は私には明らかではありませんでしたが、おそらくもっと多くの例 (Ariya の Monster デモなど) を見れば、予想どおりにコーディングしただけで、問題なく動作したはずです。

これが違いです。これを使用したヘルプ システムのデモを見ました。

paintEvent() の先頭。したがって、QPixmap へのダブル バッファリングを行ってから画面にペイントするには、次のようにする必要があることに自然に従うように思われました。

実際、明らかにこれを行うことになっている場合：

私のやり方には、同時に 2 人のアクティブなペインターがいたことがわかります。なぜ速いのかは完全にはわかりませんが、直感的には後者の方が好きです。これは単一の QPainter オブジェクトであり、一度に 1 つのことしか行いません。誰かが最初の方法が悪い理由を説明できるでしょうか? (Qt レンダリング エンジンの壊れた仮定に関して)

FormDoubleBuffered プロパティ (bool、Control から継承) があります。

これが true に設定されている場合、すべてのコントロールは、フォーム上にあるという理由で、ダブル バッファ方式で画面に描画されるフォームに配置されますか? それとも、独自の DoubleBuffered プロパティについて心配する必要がありますか?

フォームの 4 つの側面すべてに固定されている CheckedListBox (WinForms) コントロール (ListBox から継承されます。Google では ListBox に問題があることを示しています) があります。フォームのサイズが変更されると、ListBox に見苦しいちらつきが生じます。CheckedListBox を継承して ctor に設定しようとDoubleBufferedしtrueましたが (この手法は ListView や DataGridView などの他のコントロールでも機能します)、効果はありませんでした。

WS_EX_COMPOSITEDにスタイルを追加しようとしCreateParamsましたが、これは役に立ちましたが、フォームのサイズ変更が遅くなります。

このちらつきを防ぐ他の方法はありますか？

ペイント コードのレンダリング中に BlackBerry でダブル バッファリングを行う必要がありますか? それとも BlackBerry が処理しますか? それを自分で行う必要がある場合、どうすればよいでしょうか。

新しいフォームを作成した後、私は通常、この儀式を実行します。

1. 名前を意味のあるものに変更します。
2. a Caption;と入力します。
3. 位置プロパティを変更します（DefaultPosOnlyはユーザーが期待するものではありません）。
4. ShowHintに設定true;
5. DoubleBufferedに設定true;

なぜデフォルト値が「False」なのか、しばらく疑問に思っていました。私にはそれはローテクでくだらないように見えます、そして私の新しいマシンではパフォーマンスの違いに気づきません。

古いマシン、VNC、リモートデスクトップ、または仮想マシンでダブルバッファリングに問題がありますか？

オンのままにしますか、それともオフのままにしますか？何かお勧めはありますか？

私は最近、通常のオブジェクトに対して二重にバッファリングされたスレッドセーフキャッシュを実装する方法を探していました。

リクエストごとに何度もヒットし、非常に大きなドキュメントからキャッシュからリロードする必要があるキャッシュされたデータ構造があり（1秒以上のアンマーシャリング時間）、それによってすべてのリクエストを遅延させる余裕がなかったため、必要が生じました。毎分長い。

良いスレッドセーフな実装を見つけることができなかったので、私は自分で書いたのですが、それが正しいかどうか、そしてそれを小さくすることができるかどうか疑問に思っています...ここにあります：