| 月刊ソフト作り！ |
『ＧＤＩの知識』
2002.Apr.25
2003.Mar.25 一部修正
|
| ＧＤＩとは |
Graphics Device Interface
の略です。
英語に詳しい人ならなんとなく分かるかもしれません。
簡単に言えば「デバイスに絵を描く為の道具や材料」だと言えます。
デバイスとは「対象物」のことです。
例えばデバイスをディスプレイだと考えてみましょう。
そしてそのディスプレイにカラーのビットマップを表示したいと思います。
するとまず必要になってくるのが色です。これがデバイスのもっているパレット（物理パレット）になります。
次に必要なのが、表示させたい画像の情報です。これがビットマップ（ＨＢＩＴＭＡＰ）です。
上の情報に合わせたその画像の実際の色の値がピクセルビットとなります。
そしてそれらの情報を元に実際にディスプレイに描いてくれる関数となります。BitBltとか。
これら全てはＧＤＩオブジェクトと呼ばれます。（関数は除いて）
|
| デバイスコンテキストってなんなの？ |
これには筆者も随分頭を悩まされたものです。
一体なんの事を指しているんでしょう。
答えは簡単です。
そのデバイスに対する描画属性のあらゆる情報で、全てのＧＤＩオブジェクトの中核を担っています。
私たちはこのデバイスコンテキストを使って間接的にデバイスに画像を描画する事ができます。
そのデバイスコンテキスにアクセスする為のハンドルが、デバイスコンテキストハンドルです。
では「デバイスに対する情報」という事は、その情報を取得する事ができるはずです。
それを実現してくれるのが、有名な「GetDeviceCaps」API関数です。
逆にＧＤＩオブジェクトを設定したい時には「SelectObject」を使います。
デバイスコンテキストハンドルを取得するには、「GetDC」関数や「BeginPaint」関数などを使います。
関係ありませんが、こないだデバイスコンテキストの事を「デバコン」と略している人をみました。
|
| メモリデバイスコンテキスト |
これは前述したデバイスコンテキストをメモリ上に作成したものの事を指します。
メモリ上で扱うという事は、例えばディプレイに互換のあるデバイスコンテキストをメモリ上に作成したとします。
すると実際のディスプレイと全く同じ情報をもったデバイスがパソコンの中（つまりメモリ内に）存在するという事になります。
そのメモリデバイスコンテキストにアクセスする為のハンドルが、長ったらしい名前のメモリデバイスコンテキストハンドルとなります。
ではデバイスコンテキスト（以下DC）をメモリ上で扱ってなにかメリットはあるのか？
ありありです。
ここではわかりやすいVBを例にあげてみましょう。
VBのフォームオブジェクトには「AutoRedraw」というプロパティがあります。
MSDNには「再描画を勝手にやる」とありますが、実はこれ。内部でメモリデバイスコンテキスト（以下メモリDC）を作成してるんですね。
んでそのメモリDCに画像を描画し、Windowsから再描画命令がきたら内部でメモリDCの内容をフォーム（本来のデバイス）に描画します。
メモリDCはメモリ内に画像を展開するので、当たり前な話実際に画面に表示はされません。
AutoRedrawはこの方法で自動再描画を実現しています。
あと、HDCプロパティもメモリＤＣのハンドルとなります。
AutoRedrawをTrueにした場合、Refreshメソッドを実行するのはこの為なんですね。
ちなみになぜ再描画が必要なのかというと、２つのウィンドウがＡとＢあったとして、ＡがＢに重なっていたとします。（Ａが前面、Ｂが後面）
するとＢウィンドウの一部はＡウィンドウに邪魔されて隠れています。
今度はＢウィンドウを見たくなったので、Ｂウィンドウをアクティブしました。
するとどうでしょう。ＢウィンドウとＡウィンドウの重なっていた部分が真っ白くなってしまいました。
これはＢウィンドウを作った人が「再描画」するプログラムをサボったからです。
ウィンドウが一旦画面から見えなくなってしまうと、その部分のビットマップ情報は消えてしまいます。
ですので内部で再描画を行わなければならないのです。
ＶＢユーザの方のほとんどが「AutoRedraw」をTrueに設定して「自動再描画」としていると思いますが、実は「手動再描画」する事も可能なんです。
メモリＤＣを作成するには「CreateCompatibleDC」関数、再描画命令は「WM_PAINT」メッセージ。VBなら「Form_Paint」イベントです。
そのイベント内でメモリＤＣの内容をフォームに描画してやります。
しかしこの２つだけでは「手動再描画」は実現できません。
メモリDCを作っただけではビットマップまでは作成されませんので、作成後ビットマップをメモリDCに「SelectObject」させ、フォームが閉じられたら「DeleteDC」でメモリDCを解放します。
読んだだけではなかなか理解できないので、次回のサンプルに組み込もうかと思います。
|
| ＤＩＢとＤＤＢ |
前回まででDIBの表示はやりました。
関数は「SetDIBitsToDevice」を使いました。
たぶん
「DIBとDDBって結局なにがどう違うんだ！」
と思っている人は結構いると思います。
「デバイスに依存するとかしないとかで分かるか！」
そうなんですよね。そんな読者の声（？）に筆者も分かる範囲で説明したいと思います。
DIBとDDBの構造は「ビットマップビューアを作る（その１）」で説明しました。
そこで構造体を見てわかる通り、デバイスに依存をしないDIBの構造体の方があきらかに要素が多いです。
という事は、デバイスに依存しないが為、描画に必要な情報が多いからです。
一方DDBの方は、デバイスに依存するので色や高さ、幅などといった情報のみでいいのです。
2003.Mar.26 修正
DDBとは「デバイスに依存する」つまりデバイスによって形式が異なるという事です。
デバイスが変わると、全く違う表示になってしまうということです。
それじゃあ困る！という事で、DIBという「デバイスに依存しない」形式が作られました。
前回、前々回と渡ってDIBの表示をやりましたが、実は画像を画面に表示するにはそのDIBをDDBに変換してやる必要があるんです。
DIBはデバイスに依存しない、つまり互換がありませんのでDIBをDIBのまま表示する事は不可能です。
というより、ＤＩＢはビットマップファイルの事を指しているんです。
ＤＤＢは画面に表示したビットマップの事をさしています。
「依存するしない」と言っているのはこの事なんです。
これでもうお分かりでしょう。
ですので通常私たちがウィンドウに表示させた画像を操作するという事は、「ＤＤＢを操作する」という事になるんです。
BitBlt、StrechBlt関数などは全てのＧＤＩ関数はＤＤＢを操作します。
|
| なぜ２つに分けてるんだ？ |
知りません。(O_o)/~
いろいろと説はあるようですが、現在のウィンドウズではＤＤＢの方が扱いやすいんでしょう。
そのうち、ビットマップは全てＤＩＢに移り変わるといっている人もいます。
そうなった場合、古くからビットマップを扱ってるプログラマさんは「また変わるんかい・・・」などと呟いたりするんでしょうかね？
ちなみに筆者は、これを書いている現在でプログラム歴たった２年です。
１６ビットプログラムすら組んだことがないので、ビットマップの移り変わりの歴史は見てきていませぬ。
|
終わり
|
今回はこれで終わりです。
何か気がついた事があったら随時追加していく予定です。
|
PROGRAM