110gc -- DataScope Graphics Component

ユーザーズガイド

この110gcで提供する、機能らしい機能は、実は1つしかありません。

short gcBitCopy( gcBit* d, gcBit* s, gcRgn* rgn
      , short dx, short dy, short sx, short sy);
それがgcBitCopy関数です。この関数では、転送元ビットマップから、転送先ビットマップへ、ビットマップをコピーします。 コピー元領域は、描画領域rgnをsx,syだけ移動したものであり、 コピー先領域は、描画領域rgnをdx,dyだけ移動したところです。

ここで出てくる、gcBitがビットマップを示し、gcRgnが描画領域を示していますが、 これらは両方とも次のgcObj構造体と同じ構造をしています。

typedef struct {
  gcObj_v* v; //予約、未使用
  void* d;    //実際のデータへのポインタ
} gcObj;
つまり、gcBitCopy関数へ渡すのは、実際のデータへのポインタではなく、 実際のデータへのポインタへのポインタ、 つまり、ダブルポインタであるハンドルなのです。

なぜこんなに面倒なことになっているのかというと、 すべての根源は描画領域にあります。 描画領域を示す型 … (gcRgn*)->dで指し示される実際のデータは、 画面上の任意の領域を指し示すことができますが、これが可変長のデータだからです。

可変長のデータのため、領域同士の演算ルーチンは、 110gcで管理されるヒープ領域からメモリを確保して、結果を返します。 しかし、ヒープ領域といえどもDS110のこと、 あまり多くのメモリを割り付けることはできません。 そのため、メモリが不足すると、ヒープ領域のコンパクト化を実行します。 コンパクト化というのは、ヒープ領域で使用しているメモリ群をエイャ、と、 連続するヒープ領域にまとめてしまい、ヒープの空き領域を作成することを言います。 このコンパクト化が起こると、 実際の領域データが格納されているアドレスが移動してしまいます。 その位置の追跡が行なえるように、ダブルポインタになっています。

つまり、(gcRgn*)->dの値は、ヒープのコンパクト化に伴い変化しますが、 gcRgn* の値そのものは、コンパクト化されても変化しません。 これにより、gcBitCopy関数は、 いつでも正しい領域データを見つけることができるようになっています。

このようなヒープ領域のサポートを含め、110gcグラフィックスライブラリには現在、 次の5つの関数群(クラス)が提供されています。

gcApp クラス
110gcの初期化などの基本的な処理を受け持ちます。 アプリケーション個別に発生するデータ、アプリケーションコンテキストも、 このクラスで管理されます。
gcHeap クラス
ヒープ領域の管理を行ない、可変長のメモリ領域の割り付けをおこなったり、 あるいはヒープのコンパクト化を実行します。
gcObj クラス
複数のヒープ領域を管理し、ビットマップや描画領域の基本クラスである gcObjクラスを提供します。 (もちろんC++ではありませんので、概念的な話です。)
gcRgn クラス
ビットマップ上の描画領域を管理するクラスです。 描画領域は、任意の形になることができます。 また、開領域や全領域も扱うことができます。
gcBit クラス
ビットマップを管理し、 ビットマップに対する基本的な描画機能であるbitbltを提供します。