「GDI」の編集履歴（バックアップ）一覧はこちら

「GDI」(2010/10/23 (土) 14:35:41) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

Windowsのグラフィクス全般を扱うサブシステムで、その内容は比較的広範囲で難易度は高め。

Windowsではすべてのグラフィクスはデバイスコンテキストというハンドル(ポインタ)
によって示されるメモリー領域にアクセスする。
このデバイスコンテキストは、デバイスに依存しない形でデータを保存している。
データタイプが汎用的で特定のグラフィクスデバイスに依存しないが、やや抽象的で
実体がないデータだ。これをDIBといい、デバイス非依存ビットマップという。
通常、ウインドウズ上でグラフィクスを扱う時は、このDIBを扱っている事になる。

これに対し、DDBというものがある。これはデバイス依存ビットマップと呼ぶ。
データの構造がディスプレイデバイスに強く依存したもので、ウインドウズでは、
これらのDDB,DIBというレイヤーを通してグラフィクスを扱っている。

普段、画面の解像度を気にせずにソフトウエアを扱えるのも、こうした抽象レイヤーの存在が大きい。
例えば、画面の色数のプロパティが16bit(6万色)しかないのに、ほぼ全てのアプリケーション
が32bit色数で作られても変更無く動作するのは、抽象的なDIBに対してグラフィクスを描画し、DDBに
変換し、グラフィクスドライバがグラフィックチップへ書き込んでいるため。

これに対して、DDBであるDirectXなどのプログラミングでは、アプリケーションの初期化時に、
必ず画面の解像度や色数を指定する。
DirectXでは高速な画面描画が必要になるため、デバイスに強く依存したディスプレイ構造を扱う。
同じように、SVGAグラフィックやN88Basicの頃のグラフィックは、Screen命令を使い、
画面モードを強く意識するのでDDBの一種とも言える。

DIBは、抽象的なデータなので、プリンターに関係したり、BMP画像フォーマットになっている。
BMP形式の非圧縮画像データは、まさにDIBの構造をそのままファイル形式とした仕様となっている。


GetDC()で得られるものは、デバイスコンテキストに対するハンドルだ。これは単なるDWordポインタ。
ReleaseDC()なるものが存在するのは、デバイスコンテキストの中には共有ロック
してハンドルを排他制御するものがあるので、この関数がある。

通常、DIB形式のグラフィクスを新規に作る場合は、CreateDC()やCreateCompatibleDC()
などを使う。これらによって作成されたデバイスコンテキストは、メモリ内に
作成されるため、メモリデバイスコンテキスト等と呼ぶ。

これに対して、CreateBitmap(),CreateComatibleBitmap()関数は、DDB形式のデータを
作成する。一つのDIBデバイスコンテキストにDDBを作る場合には、SelectObject()
を使う。

これらのデバイスコンテキストはビットマップでメモリーを消費するので、使用後はメモリーを開放する。
DeleteDC()などがそれ。

通常、Windowsなどの描画は、ウインドウなどの枠がシステムによって書かれるが、クライアント領域は
アプリケーション依存なので関与しない。
ウインドウ関連の描画について、前者をコントロール、といい、後者をビューという事もある。ビューは最初から
備わっているわけではなく、アプリケーションを作成する者が必要に応じて作成し、画面を描く事になる。
アプリケーションのロジックは、モデルと呼び、三つの頭文字をとってMVCと呼ぶ。