110gc - Users guide

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を提供します。