WinAPI デバイスコンテキストの取得・解放について

Question

質問

デバイスコンテキストの取得はBeginPaintやGetDCなどがありますが私が以前書いたWinAPI BITMAPを読み込んでBITMAPの描画・UI (正しいかはわかりませんが)のようなWM_PAINT外部でHDCをCompatibleさせたいときにはBegonPaintは使えないだろうとGetDCをWM_CREATEで用いて上のスコープでstatic HDCに代入しました.しかしBeginPaint/EndPaintでDCハンドルはWM_PAINT内のスコープで完結していますが先ほどのほうだとHDCを長い間保持していることになります.MSDN : GetDC functionのRemarksには

After painting with a common DC, the ReleaseDC function must be called to release the DC.

と書かれています.GetDCで取得したハンドルはCompatibleさせるときまで生かしておかなければならないですが解放しなくていいのでしょうか?

また先ほどの提示したコードはGetDCを使いInvalidRect/ValidRectで領域の有効無効を切り替えているつもりですがファイルドロップで違う画像を読み込んだ時,前の画像が再描画で消えません.BeginPaintはInvalidRectで生じた無効領域を塗りなおすと思いますがGetDCでは領域全体の再描画はなされないのでしょうか

補足情報

Windows10 Pro
VisualStudio2019 Community

Answer 1

先の回答者様より既に指摘されていましたが、質問が閉じていなかったので質疑応答をうながす意味も含め、回答します。

GetDCで取得したハンドルはCompatibleさせるときまで生かしておかなければならないですが解放しなくていいのでしょうか?

いえ、ReleaseDCで解放しなければなりません。アプリケーションが終了すれば自動的に解放されるでしょうが、作法としてはNGです。

Win32ネイティブAPIのウィンドウアプリケーションのプログラミングの一般的作法としては、GetDCで取得したデバイスコンテキストを保存して使いまわすことは余り無く、ウィンドウプロシージャ内において、各メッセージのハンドリング中にGetDC～ReleaseDCで完結させることが多いです。多くのサンプルプログラムもそのようになっています。絶対にそうしなければならないかと問われると自信は無いですが、実際、マイクロソフトのMSDNのサンプルDrawing at Timed Intervalsでは使いまわしています。ただ、あろうことかReleaseDCで解放すらしていませんが。サンプルプログラム自体にバグや問題があることもあるので、この辺り、描画関連処理に疎い私の知識では、ちょっとどれを信じて良いか分かりません。

確実に言えることは、GetDCで取得するデバイスコンテキストは通常、ウィンドウに関連付けられたWindowsのGDIオブジェクトであり、ReleaseDCで解放しないとリソースリークとなり、枯渇します。実際、以下のようなコードを書くとGDIオブジェクトが解放されないままになります。これは、特に常駐モノのプログラムでは許されないコードだと思います。尚、実行中のアプリケーションが利用しているGDIオブジェクトの個数は、タスクマネージャーで簡単に確認できます。

for (int i = 0; i < 100; i++) {
    char s[32];
    HDC hdc = GetDC(hDlg);

    // まかり間違ってもコンパイル時の最適化でコードが消えないよう、とにかくhdcを使う
    wsprintfA(s, "hdc=%X\n", hdc);
    OutputDebugStringA(s);
}

BeginPaintはInvalidRectで生じた無効領域を塗りなおすと思いますがGetDCでは領域全体の再描画はなされないのでしょうか

通常、InvalidateRectで無効化された領域を描画する場合は、無効化領域ができたことによって発生するWM_PAINTメッセージ受信時の処理で、BeginPaintで返るHDCを使うのが正規の方法です。Weaponさんの例では、ウィンドウプロシージャのごく初期にGetDCで取得したデバイスコンテキストを使おうとしていることで、その時に使うべきデバイスコンテキストが適切ではない可能性があることも相まって、、要望どおりの動作をしていないものだと思われます。これに関して、先のご質問#183738 - WinAPI BITMAPを読み込んでBITMAPの描画・UIのコードでプロジェクトを作成し、動作確認を試みましたが、当方で試したビットマップファイルが不適切だったのか、動作しなかったので意見を述べるにとどめます。

Comments

[atata0319]

DWM 採用以前は使い回そうにも使い回せませんでした。当時は GetDC した後でウインドウを動かすと、DC で出力する位置はウインドウに追随しませんでした。そのような動作でも WindowFromDC で関連付けられた HWND は取得できていたので、関連はあったのだとは思います。

なお、提示のサンプルが解放していないのは多分誤りではありません。英語のドキュメントを読んでいただくとわかりますが、解放が必要なのは common dc のみとなります。private dc は解放の必要はありません。サンプルのコメントに private dc と記載があるのでそうであると思いましょう。他に class dc と parent dc があります。parent dc 以外については ReleaseDC を呼び出しても何も起こりません。ですので、呼び出しても問題ありません。parent dc については同一 DC で他の子ウインドウを描画する可能性があるので ReleaseDC すべきではありません。ただし、Windows10 でもそうであるかは検証していません。Weapon さんとしては呼び出しても問題がないので常に ReleaseDC を呼び出すものと考えてもらった方が良いと思います。parent dc は使わない方向ですね。

なお、DC を維持したままにする WGL は例外的なものと考えてもらった方が良いです。

[dodox86]

atata0319さん、詳しい情報のフォロー、誠にありがとうございます。デバイスコンテキストについては私の認識がこれまであやふやだったこともあり、解説のおかげでかなりすっきりしました。
> DWM 採用以前は使い回そうにも使い回せませんでした。
なるほど、私の場合は作法を逸脱する検討を迫られたことが無いものばかり作っていましたので、気がつきませんでした。（速やかに解放する、と言う認識でいて、今回試して使いまわせて、アレレ？思ってたのと違う？と感じてました）

[fana]

とりあえず前の質問のコードを見る限り，質問者のコードでGetDC()で取得されるのはcommon dc（解放が必要）ってことですね．

[atata0319]

はい。その通りです。BeginPaintの件も合わせて fana さんの提示されている回答でだいたい解決できると思っています。

Answer 2

解放しなくていいのでしょうか?

調べたらMSDNに「解放しろ」と書かれていた，と．
で，それに対して「解放しなくていいかも」とか思う根拠は何なのでしょう？

「WM_CREATEでどうのこうのだから長い間保持…」という点に関しては，
そもそもWM_CREATEで作ってずっと保持しておくなんてことをわざわざしなければよい，
すなわち，普通に「必要な時に作って使って用が済んだら解放」すれば良いだけなのではないかと思うのですが．

あと，（前の質問で指摘済みのようですが）WM_PAINTの処理を普通の(BeginPaintを使う)形に書いたら，消えるとか消えないとかいう類の不具合も減るかもしれません．