デバイスコンテキストに関する考察（想像）

デバイスコンテキスト（DCと略されることが多い）は、よく出てくる割に分かりにくい代物だと思います。 僕もいまだによく分かっていませんが、使っているうちに「こういうことではないか」と思うようになったので、 それについて書いておきたいと思います。 以下、断定口調で書いていますが、あくまで単なる想像なので、間違っている可能性がいつにも増して大ですので注意して下さい。

デバイスコンテキストとは、プリンタや画面等に描画するためのインターフェースです。
プログラマからすれば、画面に描画してあるものをプリンタに描画するなら 画面もプリンタも同じようなものですが、 実際のハードウェアは異なるものです。その差異を埋め、同じようなものとして扱うのがデバイスコンテキストです。

デバイスコンテキストは あくまでアプリケーションと画面を結ぶインターフェース つまり受け渡し役に過ぎず、 描画されたデータを保持しているわけではありません。
その関係は、次の様になります。

以下、もう少し具体的に見ていきましょう。

普通にAppWizardを使ってSDIやMDIのアプリケーションを作ると、以下の様なコーディングがされています。

/////////////////////////////////////////////////////////////////////////////
// CDcView クラスの描画

void CDcView::OnDraw(CDC* pDC)
{
	CDcDoc* pDoc = GetDocument();
	ASSERT_VALID(pDoc);

	// TODO: この場所にネイティブ データ用の描画コードを追加します。
}

CViewの派生クラスのOnDrawに「CDC *pDC」が渡されています。 CDCがデバイスコンテキストを扱うクラスです。これを使って描画するのはご存知の通りです。
具体的なやり方はどこの入門書を見ても載っていますが、例えば下の様になります。

void CDcView::OnDraw(CDC* pDC)
{
	CDcDoc* pDoc = GetDocument();
	ASSERT_VALID(pDoc);

	//ペンを作成
	CPen pen(PS_SOLID,1,RGB(0,0,255));

	//作成したペンをDCに選択（同時に、古いペンを保管）
	CPen *pOldPen=pDC->SelectObject(&pen);

	//ペンを使って線を描く
	pDC->MoveTo(0,0);
	pDC->LineTo(64,64);

	//DCのペンを元に戻す
	pDC->SelectObject(pOldPen);

	//作成したペンを削除
	pen.DeleteObject();
}

このときの動作を、OnDrawが呼ばれる前の処理から見ていきます。

ペンを作って保持しているのは、あくまでアプリケーション（システム）です。
デバイスコンテキストは、アプリケーションが保持しているペンを「これを使え」と指示されて そのペンの場所を記憶しているだけです。
しかも記憶力は貧弱で、ペンやブラシ等の種類毎に１つずつしか記憶できません。
そこでSelectObjectでは、現在記憶しているペンと新しく指示されたペンを交換する形をとります。
古いペンはアプリケーション側に覚えておいてもらい、後でそれを教えてもらうのです。
デバイスコンテキストが記憶しているペンやブラシは アプリケーションでは削除できないので、 古いペンを元に戻すことで、アプリケーションが指示したペンを解放させることになります。

画面が実際に変更になっているのは、LineToが実行された時だけです。 ペン等がいくら交換されても、実際の画面には何ら関係無いのです。
MoveToも、デバイスコンテキストが保持している描画用の座標を変更しているだけです。

よく使われるデバイスコンテキストには、画面用・プリンタ用の他に メモリデバイスコンテキスト（メモリＤＣ）というものがあります。
これは通常「裏画面」と呼ばれる、画面と同等の構造を持つデータをメモリ上に作るためのものです。
これは、以下の様にコーディングされます。

void CDcView::OnDraw(CDC* pDC)
{
	CDcDoc* pDoc = GetDocument();
	ASSERT_VALID(pDoc);

	//メモリＤＣを作成
	CDC memDC;
	memDC.CreateCompatibleDC(pDC);

	//メモリＤＣの実体となるビットマップを作成
	CBitmap memBmp;
	memBmp.CreateCompatibleBitmap(pDC,128,64);

	//メモリＤＣにビットマップを選択
	CBitmap *pOldBmp=memDC.SelectObject(&memBmp);

	//メモリＤＣ（即ちビットマップ）に描画
	memDC.FillSolidRect(0,0,128,64,RGB(0,0,255));

	//メモリＤＣの画像（即ちビットマップの内容）を実際の画面に転送
	pDC->BitBlt(32,32,128,64,&memDC,0,0,SRCCOPY);

	//メモリＤＣのビットマップを戻す
	memDC.SelectObject(pOldBmp);

	//ビットマップを削除
	memBmp.DeleteObject();

	//メモリＤＣを削除
	memDC.DeleteDC();
}

CDC::CreateCompatibleDCを使うことで、メモリＤＣを作成できます。 使える色数等は、引数に指定したpDCと同じになります。
重要な点は、画面用ＤＣが「画面に対して描画等を行う」のに対し、 メモリＤＣは「自分の中に指定されたビットマップに対して描画等を行う」ということです。 したがって、メモリＤＣには別途ビットマップを指定してやる必要があります。
実はCreateCompatibleDCを行った時点でデフォルトのビットマップが メモリＤＣ内部で指定されているのですが、このビットマップはモノクロで、サイズが1×1ドットしかありません。 これでは使い物にならないので、自分でビットマップを指定するのです。 デフォルトで1×1サイズのビットマップを持つくらいなら、サイズも指定してビットマップを作ってくれれば 良さそうなものなのに…。
なお、これで分かる通り、デバイスコンテキスト自体は画像サイズを持っていません。

ビットマップはCreateCompatibleBitmapで作るのが一番簡単です。
引数のpDCで指定された画面と同等の色数等を持てるようになりますが、 サイズは画面のものが引き継がれないので 別途指定することになっています。

メモリＤＣにビットマップを指定するには、ペンと同じでSelectObjectを使います。
ペンとの大きな違いは、デバイスコンテキスト内部での使われ方です。 ペンが 線の「描かれ方」として使われるのに対し、メモリＤＣのビットマップは 「描かれる対象」そのものです。

また、画面用ＤＣは「描かれる対象」が画面なので、意味のあるビットマップは持っていません。
画面用ＤＣである「OnDrawの引数pDC」に対してビットマップを選択してやっても、 画面がそのビットマップの画像に替わるわけではないのです。 pDCにビットマップを選択することはできますが、そうしてから描画命令を出しても ビットマップには何も影響なく、きちんと画面に描画されます。
逆に、画面に描かれている画像を取得するつもりで、SelectObjectの返り値であるビットマップを使おうとしても無理です。 NULLが返って来るだけです。
したがって、画面とビットマップ間で画像をやりとりするには、 画面用ＤＣとメモリＤＣを介してCDC::BitBltを使うしかないのです。

ちなみに本筋とは関係ありませんが、DeleteObjectやDeleteDCは それぞれCBitmapやCDCのデストラクタで呼ばれるので、特にコーディングする必要はありません。