ピクセルごとのアルファ チャンネルを持つビットマップを含む子コントロールを描画すると、再描画が必要になるたびにかなりちらつきが発生します。実際のブレンドは正しく機能しています。ちらつきの低減に関する多くの情報 (この質問やこのサイトなど) を見つけましたが、この状況に特に当てはまるものは見つからないようです。
たとえば、ボタンの状態に応じて、アルファ ブレンドされ、ウィンドウにブリットされるいくつかの異なるビットマップを持つボタンがあります。それらの状態が変化し、別のビットマップを描画する必要がある場合は、最初に背景を再描画する必要があります。そうしないと、前の状態のビットマップから残ったピクセルとブレンドされます。これは、ちらつきが発生する場所であり、時折背景が少し引き裂かれます.
トップレベルの親ウィンドウが単色ではなくビットマップ背景を描画することと、子コントロールがオーバーラップする可能性があることにより、問題はさらに複雑になります。を使用しているように、下にある色を子のビットマップに乗算するだけでは問題ありませんWS_CLIPCHILDREN。
ウィンドウにはビットマップの背景があるため、上書きされるだけの色を描画しないようtrueに、 に戻ります。WM_ERASEBKGND
もちろん、ダブル バッファリングはこれらすべてを解決するように見えますが、私はそれを正しく機能させることができませんでした。WS_COMPOSITEDトップレベル ウィンドウとWS_TRANSPARENT子ウィンドウを設定しました。新しいビットマップで子ウィンドウを再描画するときが来ると、いくつかの問題が発生します (この状況で描画順序がどのように機能するかを理解していないことが原因である可能性が最も高い):
- 子ハンドルを呼び出し
InvalidateRect()て渡すと、子ウィンドウは実際に再描画されますが、背景は再描画されないため、ピクセルが互いに重なり合ってブレンドされます。 - 子ウィンドウの寸法で構成される四角形を使用して、親ハンドルを呼び出し
InvalidateRect()て渡すと、背景は再描画されますが、子ウィンドウは再描画されません。 - 上記の両方を行うと、子ウィンドウと同様に背景も再描画され、希望どおりに見えますが、そうすることで、再びちらつくことができました (これは「そうではありません」)。そのように2回呼び出すのはひどくハックに見えるので、本当に驚くべきことです。なぜなら
InvalidateRect()、各呼び出しがおそらくバッファを反転させ、目的を無効にするからだと思います)。
私が結論付けたのは、ダブル バッファリングを処理するためにプログラムをどのように変更する必要があるか、またはダブル バッファリングがこの状況に役立つかどうかを本当に理解していないということです。間違いなくそうだと思いますが、すべてを再び適切に再生するには、どのように変更する必要があるのか よくわかりません.