JP3425954B2 - グラフィック状態処理 - Google Patents

Description

【発明の詳細な説明】 著作権の告示 この特許出願の一部は、著作権保護のもとにある資料
を含む。著作権者は、複写物が特許文献または特許の開
示のいずれかによるもの、たとえば特許商標庁の特許フ
ァイルまたは記録に現れるようなものならば、異議はな
いが、何であれその他の場合には、すべての著作権を留
保する。

関連出願へのクロス・リファレンス（CROSS−REFERENC
E） この特許出願は、1993年11月３日に出願されたオブジ
ェクト指向グラフィック・システム（OBJECT ORIENTED
GRAPHIC SYSTEM）と称する特許出願に関連し、Taligent
社に譲渡されたものであり、開示は参照によりここに組
み込まれている。

発明の分野 本発明は、一般的にはコンピュータ・システムにおけ
る改良に関し、特にグラフィック状態処理のシステムお
よび方法に関する。

発明の背景 以前のグラフィックス・アーキテクチャでは、あるグ
ラフィックがその状態（たとえば色、転送モード、クリ
ップ領域（clip area）等）を典型的にはプライベート
に（privately）ストアしている。描画（draw）を頼ま
れると、そのグラフィックはこれらの状態変数をGrafPo
rtの中へ手続き的にコピーし、これらの変数はレンダリ
ング・コード（rendering code）によりアクセスされ
る。したがって、このグラフィックの状態が利用可能で
あるのは、この明白な描画操作（drawing operation）
間だけである。これは、オブジェクト指向ではなく、グ
ラフィック・システムが行うことができない制限であ
る。従来技術のグラフィックス・アーキテクチャの別の
問題は、グラフィック階層（hierarchy）をグラフィッ
ク・オブジェクト内に強制することであり、これはその
オブジェクトが、そのグラフィックの描画中にそのオブ
ジェクトと相互作用するためである。Haralick,R.M.等
による“The Image Understanding Environment（画像
理解の環境）”、SPIE、vol.1659,Imaging processing
and Interchangeは、手続き的プログラミング・システ
ムにおけるグラフィック幾何図形の標準を開示してい
る。種々の幾何図形が、特別な幾何図形について、適当
な型のデータを含むものとして定義されている。曲線の
幾何図形のカテゴリの定義は、その論文で示された特定
の情報である。Foley,J.D.による“Computer Graphics:
Principles and Practice（コンピュータ・グラフィッ
クス：原理と実際）”、Addison,Wesley Publishers,19
92,2nd edition,pp.292−4,318−321および332は、リテ
イン・モード・グラフィック・システム（retain mode
graphic system）の簡単な概観を開示する。この論文
は、オブジェクト指向設計の使用について説明も示唆も
していない。まして、オブジェクトが、本発明に関して
以下で説明される特殊化されたグラフィック・オブジェ
クトに関するメソッドおよびデータから成っていること
は、説明も示唆もしていない。また、この論文は、ディ
スプレイ上に現れる各幾何図形において、幾何図形と関
連したすべての情報のコピーを重複する通常のリテイン
・モード・フィーチャ（retain mode features）を要求
している。この論文はまた、継承技術を実現する手続き
的データ構造によって、ディスプレイ上のグラフィック
・エンティティ（entity）の属性を継承する技術を、説
明している。

発明の要約 それゆえに、本発明の第１の目的はグラフィック状態
を処理するシステムと方法を提供することにある。

本発明の第１の目的とは別の目的は、グラフィック状
態を使用するグラフィックとは別のグラフィック状態へ
のアクセスを提供するシステムと方法を提供することに
ある。

本発明のこれらと他の目的は、あるグラフィックによ
りそのグラフィックをレンダ（render）するのに使われ
るグラフィック状態オブジェクトを有する方法およびシ
ステムを実現することにある。グラフィック状態オブジ
ェクトはまた、レンダリング（rendering）・デバイス
および関連するキャッシュ（cache）との関係を確立す
る能力を含むことができる。さらに、状態オブジェクト
は多くのサブ状態（sub−states）を含む。

図面の簡単な説明 図１は、本発明によるコンピュータの典型的なハード
ウェア構成を説明する図である。

図２は、TGrafStateの全構造を示す図である。

図３は、デバイスおよびデバイス・キャッシュにアク
セスするメソッド（method）を追加したTgrafPortを示
す図である。

図４は、グラフィック・オブジェクトが適宜その内容
をTGrafDeviceオブジェクトへ「ダンプ（dump）する」
ことができるTGrafPortを示す図である。

図５は、簡単な階層的グラフィックを示す図である。

図６は、TPolygonのDrawコール内にあるオブジェクト
を示す図である。

図７は、一時的（transient）階層を示す図である。

図８は、各サブ状態についてデフォルト値を含むTRoo
tGrafPortクラス（class）を示す図である。

図９は、「親（parent）」TGrafPortオブジェクトとT
GrafBundleオブジェクトの連結（concatenation）の役
割を果たすTLinkedBundlePortクラスを示す図である。

図10は、TSimpleMatrixStateクラスの関係を示す図で
ある。

図11は、TClipStateサブクラス（subclass）の関係を
示す図である。

図12は、TMatrix3DStateについて確立された関係を示
す図である。

図13は、グラフィック階層の例を示す図である。

図14は、MGraphicの図である。

図15は、TMyGroup::Drawへのコールがされるときに起
こることの例を示すフローチャートである。

発明の詳細な説明 本発明の詳細な実施例はここで開示される。しかしな
がら理解しなければならないのは、この開示された実施
例は本発明の単なる例示にすぎず、種々の形態で実施さ
れるということである。したがって、ここで開示された
詳細は、制限的なものとして解釈されてはならず、単
に、請求の範囲の基礎として、本発明をするおよび／ま
たは使用する方法を当業者に教示する基礎として、解釈
される。

オブジェクト指向プログラミングの歴史とフレームワ
ークの開発は、文献において完全に確立されている。Ｃ
＋＋とSmalltalkはく文献化されているので、詳細はこ
こでは述べない。同様に、オブジェクトの性質、たとえ
ばカプセル化（encapsulation）、多様性（polymorphis
m）、継承（inheritance）は文献および特許において十
分に説明されている。オブジェクト指向システムの良い
概説として、読者はGrady Boochの“Object Oriented D
esign With Applications"を参照するとよい。

多くのオブジェクト指向システムは、基本的な入出力
を実行する基本オペレーティング・システム上で動くよ
うに設計されているが、本システムはシステム・レベル
のサポートを特殊なフィーチャ（feature）に対して提
供するのに使われている。

本発明の好ましい実行状況は、IBM（登録商標）社のP
S/2（登録商標）またはApple（登録商標）社のMacintos
h（登録商標）のようなパーソナル・コンピュータに常
駐するオペレーティング・システムのもとでの実行であ
る。代表的なハードウェア環境は図１に描かれている。
図１は、主たる発明による、コンピュータの典型的ハー
ドウェア構成を描く図であり、中央処理装置100、たと
えば通常のマイクロプロセッサと、システム・バス132
を介して相互に接続した多くの他のユニットを持ってい
る。図１に示されるコンピュータが有するのは、リード
・オンリ・メモリ（ROM）104、ランダム・アクセス・メ
モリ（RAM）106、周辺装置、たとえばディスク・ユニッ
ト108および110により表される他の入出力周辺機器をシ
ステム・バス132へ接続する入出力アダプタ112、キーボ
ード130、マウス126、スピーカ122、マイクロフォン12
4、および／または他のユーザ・インタフェース装置、
たとえばバスへ接続されたタッチ・スクリーン装置（示
されていない）をバスに接続するユーザ・インタフェー
ス・アダプタ128,114で表されるデータ・プロセッシン
グ・ネットワークへワークステーションを接続する通信
アダプタ116である。ディスプレイ・アダプタ120がバス
とディスプレイ装置118を接続する。ワークステーショ
ンは、その上に常駐しているオペレーティング・システ
ム、たとえばApple System/7（登録商標）オペレーティ
ング・システムを有している。

定義 グラフィック状態（Graphic State）−幾何図形を描
画するのに必要な、すべてのグラフィカルな状態変数
（あるときは属性（attribute）と呼ばれる）のことで
あり、ペイント（paint）、転送モード（transfer mod
e）、ペン幾何（pengeometry）、マトリック（matri
x），クリップ領域（clip area）等を含む。

グラフィック階層（Graphic Hierarchy）−グラフィ
カルなプリミティブ（primitive）の階層的配置（arran
gement）であり、座標系およびクリッピング情報のよう
なグラフィック状態は、親グラフィックから子グラフィ
ックへ継承されることができる。

GrafPort−グラフィック状態、デバイス、デバイス・
キャッシュの完全なセットのコンテナ（container）。

開示されたグラフィック状態処理システムは、グラフ
ィック処理の応用の全体的な効率を上げる多くの目標を
達成する。それらの目標の１つは、すべてのグラフィカ
ルな状態の集合（collection）を表現する抽象ベース・
クラス（abstractbase class）をサポートすること、お
よび状態の階層的動作（hierarchical behavior）（con
catination:連結）をサポートすることである。サブク
ラスは、状態変数の記憶と連結についての特定の実現を
提供する。別の目的は、子グラフィック状態の親状態へ
の連結が子において分離（isolate）されていなければ
ならないことを要求することである。親の状態は、連結
によって影響されてはならない。さらに、子はある変数
の最終的な値の決定において、最終的決定権を持つ。し
たがって、親はある変数の値の指示はできない。

また目標であるのは、グラフィック状態がTGrafDevic
eオブジェクトと容易に通信できることである。さらに
別の目標は、グラフィックのDrawコールのコンテキスト
（context）外で、グラフィック状態がアクセスされる
ことを許容するフレームワークをサポートすることであ
る。たとえば、スプライト（sprite）はビュー（view）
の中へ描画するために、グラフィック状態オブジェクト
へアクセスする必要があるであろう。別の目標は、TGra
fDevideクラスの中へグラフィック階層に関するどのよ
うな仮定も焼き固め（bake）ないことである。グラフィ
ック階層は、グラフィック自身の中で自然に実現され
る。したがって、何の特別の設計も、TGarfDeviceによ
る階層上には押しつけられない。

最後に別の目標は、すべてのデバイス依存の（device
−dependent）データ型は、その装置にプライベート（p
rivate）のものとすることである。たとえば、すべての
クリッピングは領域ではなくTGAreasにより指定され
る。

発明の背景において説明されたように、以前のグラフ
ィック・アーキテクチャにおいては、グラフィックはプ
ライベートにその状態（たとえば色、転送モード、クリ
ップ領域等）を典型的にはストアしている。描画が要求
されると、グラフィックはGrafPortの中へこれらの状態
変数を手続き的にコピーし、レンダリング・コードによ
りアクセスされる。したがって、グラフィック状態は、
この明示的な描画操作の間に限り利用可能である。本シ
ステムは、グラフィックがその状態をストアするフレー
ムワークを提供する。このフレームワークがサポートす
るアーキテクチャでは、クライアント（client）が「描
画（draw）」関数のコンテキスト外で、グラフィック状
態にアクセスできる。グラフィック状態のセットは、一
連のコードのかわりに単一のオブジェクトにより表すこ
とができる。これはTGrafPortクラスの目標である。抽
象（abstract）クラスが、状態変数にアクセスするイン
タフェースを定義する。具体化（concrete）サブクラス
は、状態変数の現実のストレージ（storage）と連結動
作（concatenation behavior）を定義する。古い方法
は、 であり、新しい方法は、 である。

TGrafStateおよびTGrafPort 図２は、TGrafStateの全体構造を示す図である。この
構造は、すべてのグラフィック状態を６つの異なるグル
ープに分類し、つぎにTGrafState200と呼ばれる単一の
クラスにまとめている。６つの「サブ状態（sub−state
s）」202は、TAttributeState（グラフィックの外観を
決定する属性の集合）、２つのTMatrixStates（2Dビュ
ーおよびモデル座標系）、TClipState（2Dクリッピング
情報）、TSceneState（3Dカメラと光）、TMatrix3DStat
e（3Dモデル座標系）である。TGrafStateオブジェクト2
00は、全部のグラフィック状態へのアクセスを必要とす
るクラスにより使用される。そのうえ、TGrafStateクラ
スの抽象的設計のために、子グラフィック状態はその親
状態に、親状態を実際に変化させないで連結される。

図２は、網羅的ではないことに留意するべきである。
ここで示された６つのサブ状態は、所望の設計により、
６つより大きくまたは小さくできる。さらに、６つのサ
ブ状態を作っている要素は、網羅的ではない。たとえば
属性は、グラフィック処理において知られているどのよ
うなグラフィック属性も仮想的に含むことができる。

図２においてまた示されているのは、上で概説した６
つのサブ状態202の例示的要素204である。特に、GetAtt
ributeStateはGetDrawOperation、GetFillPaint、GetFr
amePaintおよびGetAntialiasingを有し;GetViewMatrixS
tateはGetMatrixを有し;GetModelMatrixはGetMatrixを
有し;GetClipStateはGetClipAreaを有し;GetSceneState
はGreateLightIteratorとた、サブ状態を備えるこれら
の要素は単なる例であり、多くのものはここに示され説
明されたより多くを含む。

TGrafPortクラスは、TGrafStateのサブクラスであ
る。図３に示されるように、TGrafPortはメソッド302を
追加して、デバイスおよびデバイス・キャッシュへアク
セスする。GetDeviceは、レンダリングがなされるデバ
イスへのポインタを返す。GetCacheは、デバイス依存の
オブジェクトをキャッシュするデバイスにより使用され
る、キャッシュへのポインタを返す。TGrafPortはまた
６つのサブ状態を含む。

６つのサブ状態を含む、TGrafPort300をサブクラス化
する主な目的は、グラフィック状態、デバイス、デバイ
ス・キャッシュのストレージと連結がなされる方法を、
定義することである。サブ状態は、共通に使用されるグ
ループに状態変数を分けるのを支援する。状態変数のよ
り簡単でフラットなグループは、状態変数のサブセット
について、状態連結のカスタム化を認めるほど、十分に
柔軟ではない。たとえば、簡単なグラフィックは、TGra
fBundle（便利なTAttributeStateサブクラス）のみを典
型的に必要とする。より複雑なグラフィック・オブジェ
クトはマトリックスと、場合によりクリップ領域を必要
とする。これらのクラスのより多くの情報については、
サブ状態の章を参照すること。

MGraphicのようなグラフィックス・クラスは、幾何図
形の基本セットによって、TGrafDevideに自分自身を記
述しなければならず、各幾何図形は、それに関連した１
組のTGrafStateオブジェクトの持たなければならない
（必ずしもユニークなものでなくてもよい）。図４に示
されるように、TGrafPort402は、グラフィック・オブジ
ェクト400がその内容をTGrafDeviceオブジェクトに、適
宜「ダンプする」ことを認める。これは、セットのDraw
関数をTGrafPortクラスに供給することにより達成さ
れ、それらの関数はTGrafDeviceクラスで与えられるRen
der関数のセットを反映させたものである。各Draw関数
は幾何図形をとり、それとポート（port）のグラフィッ
ク状態404を、デバイス408の適当なRenderコールに渡
す。便宜のために、オーバライドするバンドル（bundl
e）とモデル・マトリックス（model matrix）は404で渡
すこともできる。TGrafPortクラスは以下に示される。

これらは2D Drawコールである。それらは便宜のため
にのみ存在している。それらは、対応するTGrafDevid
e::Renderコールをコールして、グラフィック状態とデ
バイス・キャッシュを渡す。

多数の、共通部分を持たない（disjoint）コール（多
様的（polymorphic）単一コールの反対）の目的は、基
本的2D幾何図形の小さい良く定義されたセットのみが、
グラフィック・デバイスによりサポートされるという規
則を強制するためである。

これらは、付加的なバンドルおよびモデル・マトリッ
クスをとる2D Drawコールである。それらは、ある種の
特殊の条件のためにのみ便宜上存在している。それら
は、対応するTGrafDevide::Renderコールをコールし
て、グラフィック状態と装置キャッシュを渡す。

適当なTGrafDevice::Render関数が呼ばれる前に、バ
ンドルおよびモデル・マトリックスが、TGrafPortオブ
ジェクトの404において示されるように、状態に連結さ
れる。バンドルおよびオプショナルなマトリックスの目
的は、幾何図形から幾何図形に典型的に変化する状態の
連結を容易にするためである。しかしながら、この連結
はコールされるたびに起きるので、バンドルまたはマト
リックスが多重幾何図形により共用されるときには、こ
れらの使用はすすめられない。

これらは、3D Drawコールである。それらは、便宜の
ためにのみ存在している。それらは、対応するTGrafDev
ice::Renderコールをして、グラフィック状態と装置キ
ャッシュを渡す。

2Dコールと同様に、多数の、共通部分を持たないコー
ルの目的は、基本的3D幾何図形の小さい良く定義された
セットのみが、グラフィック・デバイスによりサポート
されるという規則を強制するためである。

これらは、付加的なバンドルおよび3Dモデル・マトリ
ックスをとる3D Drawコールである。それらは、ある種
の特殊な条件のためにのみ便宜上存在している。それら
は、対応するTGrafDevice::Renderコールをして、グラ
フィック状態とデバイス・キャッシュ406を渡す。キャ
ッシュ406がデバイス408内にあるように示されている
が、これは説明の目的のためにすぎない。キャッシュ40
6は、メモリが与えられるところならばどこでも実際に
あってよく、デバイス408から分離したメモリであって
もよいし、特定のグラフィック・レンダリングが実行さ
れているところに直接的に関連していない別のデバイス
内であってもよい。

適当なTGrafDevice::Render関数が呼ばれる前に、バ
ンドルおよびモデル・マトリックスが、TGrafPortオブ
ジェクトの404において示されるように、状態に連結さ
れる。バンドルおよびオプショナルなマトリックスの目
的は、幾何図形から幾何図形に典型的に変化する状態の
連結を容易にするためである。しかしながら、この連結
はコールされるたびに起きるので、バンドルまたはマト
リックスが多重幾何図形の間で共用されるときには、こ
れらの使用はすすめられない。

A.デバイス・キャッシュ デバイス・キャッシュ406は大きいオブジェクトに潜
在的になり得るので、それらが思いがけずにシステムを
通して増殖しないように保証する配慮が必要である。デ
フォルト動作（behavior）に対する２つのアプローチが
ある。

1.各GrafPortが自分自身のデバイス・キャッシュを持ち
得るが、しかし高価なものになる。まつわりつく非常に
多くのキャッシュが存在することになる。これは、望ま
しいデフォルト動作ではない。

2.各TGrofPartが、親より与えられなかった場合に、自
分自身のキャッシュを生成する。デフォルトにより、こ
れが意味するのは、各グラフィック階層のトップにおけ
るGrafPortのみがキャッシュを持ち得るということであ
る。これは、たぶん受け入れられるデフォルト動作であ
る。同じルートGrafPortが一束の階層として使用される
場合は、この階層はルートGrafPortにおいてキャッシュ
を自動的に共用する。キャッシュが各GrofPortにおいて
求められる場合は、GrafPortサブクラスが、それを実現
するために書かれる。

ある場合には、デフォルトのキャッシュ動作をオーバ
ライドすることが望ましい。ビュー（view）がそう望む
かもしれない。古いビュー・システムでは、各ビューは
デバイス依存の領域をキャッシュした。領域の生成は非
常に高価なものなので、良い最適化であった。本システ
ムでは、ビューは自分自身のデバイス・キャッシュを保
持できる（それは、他のデバイス依存のオブジェクトと
同様に領域をキャッシュする）。

B.グラフィック状態連結（Graphic State Concatenatio
n） 図５は、簡単に階層的グラフィックを提供する。図５
のグラフィックは、グループ500における多角形502およ
び楕円506から成る。階層における各グラフィックは、
グラフィック状態の任意のサブセットをストアできる。
たとえば、多角形と楕円はTGrafBundle504と508を各々
持っているが、TGroupは何のグラフィック状態もストア
しない。

これは、階層的状態、たとえばマトリックスが考慮さ
れるまでは、非常に簡単に思える。正確な、ローカル対
グローバル（local−to−global）・マトリックスを作
成するために、グラフィックのローカル・マトリックス
は、その親のローカル対グローバル・マトリックスと連
結しなければならない。この連結したマトリックスは、
それに提供したグラフィックによりキャッシュされる。
本アーキテクチャは、この型の動作を提供する。

グラフィック状態は、その親グラフィックの状態に
「連結」されなければならず、グラフィックに適用する
状態の新しいフル・セット（full set）を作成する。TG
roup::Drawがコールされると、その新のTGrafPortオブ
ジェクトが渡される。TGroup500は自分自身の状態を持
っていないので、どのような連結も実行しないそれは，
親のTGrafPortオブジェクトを多角形のDrawコールへ、
つぎに楕円のDarwコールへと、単に渡す。

多角形502は、TGrafBundle504を持ちそれはその親のT
GrafPortオブジェクトに連結されなければならない。こ
れは、この連結を実行できる「リンクされた」TGrafPor
tサブクラス（TLinkedBundlePort）を生成することでな
される。つぎに、TLinkedBundlePort::Draw（const TGP
olygons＆）へのコールがなされる。

図６は、TPolygonのDrawコール内にあるオブジェクト
を示す。要素600、602、604、610、612は、図５に関し
てすでに説明された対応する要素を持っている。図６は
またTGafState 608を有する。TLinkedBundlePortオブジ
ェクト606は、TPolygonの602Drawコールに対してローカ
ルに生成されるため、この型の連結は一時的に現存す
る。これはある型のグラフィック階層には必要である。
たとえば、グラフィック階層が、特定のグラフィックに
対して、２つまたはそれ以上の他のグラフィックスによ
り共用されることを許容するならば、その共用されたグ
ラフィックが多重の親を持つために、一時的な連結を実
現しなければならない。

たとえば、図７において、曲線706は、グラフィックB
702およびC710により共用されている。各Graphic B70
2、Graphic C710、TCurve706は、関連するTGrafBundle
704、712、708をそれぞれ持つ。Graphic A700から、分
岐（branch）がGraphic B702またはGraphic C710のいず
れかにとることができる。連結が一時的でなければなら
ないのは、連結の結果が、とられた分岐（ＢまたはＣ）
依存して異なるためである。これが一時的階層の作用の
方法である。

永続的な階層におけるグラフィック・オブジェクト
は、親が実際には描画されないでも、親の状態を使って
グラフィックが描画ができる親情報の知識を要求する。
そのようなグラフィック階層の例として、ビュー・シス
テムがある。

永続的な階層について言える２〜３のことがある。

1.この階層におけるグラフィックは多重の親により共用
されることはできない。

2.特別なセマンティックス（semantics）、たとえばLin
kToおよびUnlinkコール、パラメータ無しのDrawコール
は、この階層において使用されているグラフィック・ク
ラスに追加されなければならない。

3.たとえば2Dビュー・マトリックス状態とクリップ状態
オブジェクトのような、よりプライベートなサブ状態オ
ブジェクトをストアする、TGarfPortサブクラスを使用
することもできる。したがって、各グラフィックは、そ
れ自身のプライベートなデバイス・キャッシュの保持を
望むだろう。

4.マルチタスク・セーフ（mutitask−safe）が必要な
ら、実現される。

効率 多数のグラフィック状態オブジェクトがシステム中を
動き回っているため、効率について注意を向けることは
重要である。２つの重要事項がある。

1.簡単なMGraphicsは、親の状態の「デルタ（delta
s）」または変更のみを含むべきである。たとえば、TPo
lygonオブジェクトは、TGrafBundleオブジェクトのみを
含むべきである。

2.いくつかの状態変数は、多重のグラフィックスにより
共用される。

第１の重要事項は、このアーキテクチャの抽象的な性
質により注意を向けられるものであり、異なるTgrafPor
tサブクラスは、必要な部分のみを含むことを認められ
る。第２の重要事項は、共用された属性を使用すること
により、注意を向けられるものである。

サブ状態（Sub−States） 以下のクラスは、TGrafPortクラスを通してアクセス
される「サブ状態」クラスである。それらは、実際のグ
ラフィック状態変数へのアクセスを提供する。TGrafPor
tのように、それらのほとんどは、「ゲッタ（gette
r）」のみを定義する抽象クラスである。サブクラス
は、状態変数が「得られる（gotten）」方法の実現を提
供する。

サブ状態クラスは、親と連結する異なるセマンティッ
クスを持つ。LinkTo関数は、子オブジェクトからその親
への一時的な結合（connection）を提供して、連結が起
きる。Unlink関数はこの結合の役にたつ。２つの理由に
より、これらのセマンティックスが使用される。

1.連結された値は、子にキャッシュできる。

2.子から親への結合は、より典型的に一時的場合より
も、永続的である必要もある。

LinkToおよびUnlinkに関するより多くの情報について
は、以下の「LinkToおよびUnlinkの使用」の章を参照の
こと。サブ状態は以下に示される。

A.TAttributeState TAttributeStateクラスは、グラフィックスが描画さ
れるときのそれらの外観に関する情報を含む。

このクラス定義は以下に示される。

B.TMatrixState TMatrixStateクラスは2D座標系を定義する。TMatrixS
tateは、ローカル座標系からあるクローバル座標系（典
型的にはワールド座標系（world coordinate syste
m））へ変換するマトリックスへアクセスする、プロト
コルを含む。

TLinkableMatrixStateクラスは、別のTMatrixStateオ
ブジェクトとの、リンキング（linking）または連結を
サポートするプロトコルを定義する。このリンキング動
作は、サブクラスにおいて２つの理由がある。１）マト
リックス（たとえばTGrafDevice）にアクセスするクラ
イアント（client）によって必要とされない。２）異な
るリンギング・インタフェースが、アドバンスド・クラ
イアント（advanced client）により使用されることも
ある。クラス定義は以下に示される。

LinkToおよびUnlinkコールが、TLinkableMatrixStateオ
ブジェクトにその親への一時的なアクセスを与える結
果、マトリックスの連結が起きる。LinkToは、その親と
の結合を確立するためにコールされる。Unlinkは、その
結合を切るためにコールされる。

｝； C.TClipState TClipStateクラスは、クリップする形状（shape）ま
たは境界（boundery）を定義する。それはクリップ領域
にアクセスするプロトコルを含み、レンダリングの間、
デバイスにより使用される。

TLinkableClipStateクラスは、別のTClipStateオブジ
ェクトとのリンキングまたは連結をサポートするプロト
コルを定義する。この連結動作は、サブクラスにおいて
２つの理由がある。１）クリップ領域（たとえばTGrafD
evice）にアクセスするクライアント（client）によっ
て必要とされない。２）異なるリンキング・インタフェ
ースが、アドバンスド・クライアント（advanced clien
t）により使用されることもある。クラス定義は以下に
示される。

LinkToおよびUnlinkコールが、TClipStateオブジェクト
にその親への一時的なアクセスを与える結果、クリップ
領域の連結が起きる。LinkToは、その親との結合を確立
するためにコールされる。Unlinkは、その結合を切るた
めにコールされる。

｝； D.TSceneState TSceneStateクラスは、全体としてシーン（scene）に
関する情報を含む。この情報は、正常には、シーンごと
にただ１度指定される。それは、以下のメンバを含む。

光（Lights） カメラ（Camera） クラス定義は、以下に示される。

E.TMatrix3DState TMatrix3DStateクラスは3D座標系を定義する。TMatri
x3DStateは、ローカル座標系からあるグローバル3D座標
系（典型的には3Dワールド座標系（3Dworld coordinate
system））へ変換するマトリックスへアクセスする、
プロトコルを含む。

TLinkableMatrix3DStateクラスは、別のTMatrix3DSta
teオブジェクトとの、リンキングまたは連結をサポート
するプロトコルを定義する。このリンキング動作は、サ
ブクラスにおいて２つの理由がある。１）マトリックス
（たとえばTGrafDevice）にアクセスするクライアント
（client）によって必要とされない。２）異なるリンキ
ング・インタフェースが、アドバンスド・クライアント
（advanced client）により使用されることもある。ク
ラス定義は以下に示される。

LinkToおよびUnlinkコールが、TLinkableMatrix3DState
オブジェクトにその親への一時的なアクセスを与える結
果、マトリックスの連結が起きる。LinkToは、その親と
の結合を確立するためにコールされる。Unlinkは、その
結合を切るためにコールされる。

｝； F.LinkToおよびUnlinkの使用 LinkToおよびUnlink関数は、「リンクされた」TGrafP
ortオブジェクトの中からのみ典型的にコールされるの
で、それらを直接コールする必要はほとんどないだろ
う。それらを直接コールすることは、例外ホスタイルな
（exception−hostile）コードをもたらす。例外がLink
ToコールおよびUnlinkコールの間でスロー（throw）さ
れると、Unlinkコールがされることはない。悪いニュー
スである。

良いニュースは、コード中で直接コールされる必要が
あるならば、供給されたTgrafPortサブクラスを使用す
ることができるし、または特殊な動作が必要なら自分自
身でTGrafPortをサブクラス化することもできる、とい
うことである。他のリンクされたポート・クラス（port
class）のように、LinkTo関数をコンストラクタ（cons
tructor）の中で、Unlink関数をデストラクタ（destruc
tor）の中でコールするべきである。

システムが提供する（System−Supplied）サブクラス 本グラフィック・システムは、グラフィック状態クラ
スのいくつかの役に立つサブクラスを提供する。以下で
そのいくつかが説明される。

A.TGrafPortサブクラス 図８で示されるように、TRootGrafPortクラス902は各
サブ状態904〜912についてデフォルト値を含む。すべて
のサブ状態は、TRootGrafPort902を経由してTGrafPort
900に到達する。したがって、それは無限のクリップ領
域を有するワールド座標空間（World Coordinate spac
e）を表す。それは、TGrafDeviceオブジェクトへのポイ
ンタを持ち、デバイスから得るデバイス・キャッシュを
所有する。このクラスの使用は、クライアントによりオ
フ・スクリーン（off−screen）のみの描画にするべき
である。オン・スクリーン（on−screen）内の使用は、
全スクリーンを越える描画をもたらす。

図９で示されるように、TLinkedBundlePortクラス100
2は、「親」TGrafPortオブジェクト1000とTGrafBundle
オブジェクト1004の連結としての役に立つ。それが使わ
れるのは、ローカル・バンドルが親TGrafPortオブジェ
クト1000における属性状態オブジェクト（attribute st
ate object）に連結する必要があるときである。親状態
の残りは継承される。

TLinkedViewMatrixPortクラス1006は、親TGrafPortオ
ブジェクト1000と指定されたビュー・マトリックス1008
との連結として役に立つ。それが使用されるのは、ロー
カル・ビュー座標系が所望されるときである。それは、
指定されたマトリックスを、親TGrafPortオブジェクト1
000におけるビュー・マトリックスへ連結する。親の状
態の残りは継承される。連結されたマトリックスのキャ
ッシュ化が所望であれば、代替的に、マトリックス状態
オブジェクトはマトリックスのかわりに渡される。

TLinkedModelMatrixPortクラス1010は、親TGrafPort
オブジェクト1000と指定されたモデル・マトリックス10
12との連結として役に立つ。それが使用されるのは、ロ
ーカル・モデル座標系が所望されるときである。それ
は、指定されたマトリックスを、親TGrafPortオブジェ
クト1000におけるモデル・マトリックスへ連結する。親
の状態の残りは継承される。連結されたマトリックスの
キャッシュ化が所望であれば、代替的に、マトリックス
状態オブジェクトはマトリックスのかわりに渡される。

TLinkedClipAreaPortクラス1014は、親TGrafPortオブ
ジェクト1000とTGArea1016との連結として役に立つ。そ
れが使用されるのは、ローカル・クリップ領域が、親TG
rafPortオブジェクト1000におけるクリップ領域と交差
するる（intersect）必要があるときである。親の状態
の残りは継承される。連結されたクリップ領域のキャッ
シュ化が所望であれば、代替的に、クリップ状態オブジ
ェクトは、クリップ領域のかわりに渡される。

TLinkedScenePortクラス1018は、親TGrafPortオブジ
ェクト1000とTSceneStateオブジェクト1020との連結と
して役に立つ。それが使用されるのは、ローカル・シー
ン状態が、親TGrafPortオブジェクトにおけるシーン状
態と、連結する必要があるときである。親の状態の残り
は継承される。

TLinkedModelMatrix3DPortクラス1022は、親TGrafPor
tオブジェクト1000と指定された3Dモデル・マトリック
ス1024との連結として役に立つ。それが使用されるの
は、ローカル3Dモデル座標系が所望されるときである。
それは、指定されたマトリックスを、親TGrafPortオブ
ジェクトにおける3Dモデル・マトリックスへ連結する。
親の状態の残りは継承される。連結されたマトリックス
のキャッシュ化が所望であれば、代替的に、マトリック
ス状態オブジェクトは、マトリックスのかわりに渡され
る。

B.TAttributeStateサブクラス これらのサブクラスは、グラフィック処理システムの
任意の外観（appearance）属性を仮想的に有する。

C.TMatrixStateサブクラス 図10において示されるように、TSimpleMatrixState11
04は、ローカル2Dマトリックス1106を含む。そのローカ
ル・マトリックスは、1102を経由して親のローカル対グ
ローバルのマトリックスと連結して、それ自身のローカ
ル対グローバルのマトリックス1100を作成する。これ
は、GetMatrixにより返されるものである。

D.TClipStateサブクラス 図11は、TClipStataサブクラス1200の関係を示す図で
ある。TSimpleClipStateクラス1204は、単一のTGAreaオ
ブジェクト1206をそのローカル・クリップ領域として含
む。そのローカル・クリップ領域は、その親のクリップ
領域と交差して、GetClipAreaにより返されるクリップ
領域を作成する。GetClipAreaWithChildrenは、同じク
リップ領域を返す。

ビュー・システムが定義する、より精巧なTLinkableCli
pStateサブクラス1202は、その子らのクリップ領域を等
式の中へ組み込む。それは、子らのクリップ領域を自分
自身から減じて、GetClipAreaにより返される新しいク
リップ領域を作成する。より多くの情報については、ビ
ュー・システム文献を参照のこと。

E.TSceneStateサブクラス TSceneStateサブクラスは、全体としてシーンに関す
る情報を有する。たとえば、このサブクラスは、光とカ
メラを有することもある。

F.TMatrix3DStateサブクラス 図12は、TMatrix3DState1300について確立した関係を
示す図である。TSimpleMatrix3DStateクラス1304はロー
カル3Dマトリックス1306を含む。そのローカル・マトリ
ックスは、親のローカル対グローバルのマトリックスと
連結して、それ自身のローカル対グローバルのマトリッ
クスを作成する。これは、GetMatrixにより返されるも
のである。TLinkkableMatrix3DState 1302はTSimpleMat
rix3DState1304とTMatrix3DState1300をリンクするメカ
ニズム（mechanism）を提供する。

MGraphicによる使用法 MGraphic階層をサポートするために、親の状態は、MG
raphic::Drawコールに渡されなければならず、その結果
子は自分の状態を親の状態と連結できる。

void Draw（TGrafPort＆ parentPort）； MGraphicサブクラスは、より特殊な動作（すなわちビ
ュー）を必要とし、それをサポートするために、特別な
セマンティックスを定義しなければならない。

使用法の例 A.グラフィック階層 特定のマトリックス状態オブジェクトが、「ローカル
対グローバルのモデル・マトリックスを与えてほし
い。」と依頼された場合、その答は、親の状態のローカ
ル対グローバルのモデル・マトリックスに時々依存す
る。図13のグラフィック階層を考慮のこと。このグラフ
ィックは、グラフィックスの小さい２つののグループ、
1400で示されるグループ１、1402で示されるグループ２
から成る。グループ２は、多角形を含み、グループ１内
に置かれていて、グループ１はまた、楕円を含む。双方
のグループが含むTSimpleMatrixStateオブジェクトは、
それらのモデル座標系を定義する。

グループ１はスクリーンを表し、その親マトリックス
は同一であることを意味する。「ローカル対グローバル
のモデル・マトリックスを与えてほしい。」と依頼され
た場合、グループ１は自分自身のローカル・マトリック
スを単に返す。グループ２が同じ質問をされると、自分
自身のローカル・モデル・マトリックスを、グループ１
のローカル対グローバルのモデル・マトリックスとあら
かじめ連結して、その結果を返す。たぶん結果をキャッ
シュするだろう。

B.具体例 上記の抽象クラスの異なるサブクラスは、特殊化され
た動作を表現する。特殊化された動作が有するのは、 1.階層的状態変数の異なる連結動作、たとえばクリップ
領域の計算。

2.非階層的変数の異なるオーバライド動作、たとえばア
ンチエイリアシング（antialiasing）制御。

3.異なるストレージ（storage）要求。状態のサブセッ
トをストアする必要のみがほとんどである。

1.簡単なMGraphics（TPolygon） TPolygonの様な簡単なMGraphicsは、TGrafBundleクラ
スに含まれる属性（描画操作、塗りつぶしとフレーム・
ペイント（fill and frame paints）等）の指定のみを
必要とする。TPolygonのDrawコールは以下に示される。

TGrafPort::Drawコールのオーバライドするバンドル
・パラメータを使用することに留意すること。

2.より複雑なMGraphics いくつかのMGraohicsはTGrafBundleオブジェクトより
多くの状態を要求する。以下に示されるのは、TTGrafBu
ndleとローカル・モデル・マトリックスをストアするグ
ラフィックのDrawコールである。

3.スクリーンへの直接描画 スクリーンへの直接描画はこのようになされる。

4.クリップ境界（Clip Boundaries）を有するスクリー
ンへの直接描画 ネストされた（nested）クリップ境界と座標系を使用
する、スクリーンへの直接描画は、このように実行され
る。

5.バックバッファされた（Back−Buffered）グラフィッ
クの描画 バックバッファリング（back−buffering）グラフィ
ックは、子らの「キャッシュ」としての役割をするデバ
イスを所有する。たとえば、フレーム・バッファについ
て、バック・バッファはTGImageである。親との連結が
起きるとき、バック・バッファは渡されるデバイスに関
して有効化（validate）される。渡されたデバイスにつ
いて有効なバック・バッファであれば、デバイスに描画
される。さもなければ、それは削除されて、新しいバッ
ク・バッファと置き換えられる。この動作は、TLinkedB
ackBufferGrafPortクラスの中に包まれる。以下は、こ
の特徴（feature）が実現されるいくつかの方法の１つ
である。

TBackBufferingGraphicクラスはバックバッファリング
に関してなにも知らない別のMGraphicについての「ラッ
パ（wrapper）」としての役割をすることができること
に留意すること。

C.例 図14のMGraphicを考慮してほしい。それは、単一のTP
olygon1506を含む単一のTGroup1500から成る。双方とも
いくつかのローカル状態を含む。TMyGroup1500は、ロー
カル状態TGrafBundle 1502とTSimpleMatrixState1504を
含む。TPolygon1506は、ローカル状態TGrafBundle 1508
を含む。

図15は、好適実施例による詳細なロジックのフローチ
ャートである。処理は関数ブロック1600において開始す
る。ここでは、関数ブロック1640と1650におけるロジッ
クを使用してマトリックスを連結する、グラフポートが
生成される。関数ブロック1640と1650では、マトリック
ス状態オブジェクトが生成され、親ポートのマトリック
ス状態オブジェクトにリンクされて、連結を容易化す
る。次に、関数ブロック1610において、ループが開始さ
れて、ちょうど生成されたポートの中に描画する。これ
は次のようにして達成される。多角形または他の幾何図
形を、関数ブロック1660におけるグラフポートへ渡す。
順に、グラフポートは、多角形または他の幾何図形と関
数ブロック1670におけるそのグラフィック状態オブジェ
クトを、グラフィック・デバイスへ渡す。次に、関数ブ
ロック1680において、デバイスは、渡されたグラフィッ
ク状態オブジェクトからマトリックスを得る。次に、判
断ブロック1690においてテストが実行されて、連結され
たマトリックスが親マトリックスとローカル・マトリッ
クスに関して古いかどうかを決定する。もし古ければ、
親マトリックスとローカル・マトリックスは、関数1692
において連結されて、その結果が関数ブロック1694にお
いてグラフィック・デバイスに返される。

関数ブロック1610において開始したループは、判断ブ
ロック1620におけるテストを含み、最後のグラフィック
・オブジェクトが処理されたかどうかを決定する。もし
そうなら、関数ブロック1600において生成されたグラフ
ポートは、関数ブロック1630において削除され、グラフ
ポートのマトリックス状態は、関数ブロック1632におい
て親とのリンクがはずされる。

本発明は、好適実施例により説明されてきたが、当業
者は、以下の請求の範囲の精神と範囲内における変更
で、本発明を実施することができることを認めるだろ
う。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ワタナベ リョウジ アメリカ合衆国 95014 カリフォルニ ア州 クパチーノ パーム アヴェニュ 22284 (56)参考文献 特開 平５−210722（ＪＰ，Ａ) 特開 平４−230579（ＪＰ，Ａ) 特開 昭63−36385（ＪＰ，Ａ) 特開 昭64−55676（ＪＰ，Ａ) 特開 平５−101194（ＪＰ，Ａ) 特開 平２−240771（ＪＰ，Ａ) 特開 平４−229376（ＪＰ，Ａ) 特開 昭62−267854（ＪＰ，Ａ) 特開 平５−274419（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06T 1/00 G06F 3/00 G06F 3/14 G06T 11/00 ＣＳＤＢ（日本国特許庁)

Claims (21)

(57)【特許請求の範囲】
1. 【請求項１】ディスプレイと、 描画コマンドに応答して、前記ディスプレイ上に第１イ
   メージを描画するために、第１グラフィックオブジェク
   ト内の情報を使用すると共に、前記描画コマンドに応答
   して、前記ディスプレイ上に第２イメージを描画するた
   めに、第２グラフィックオブジェクト内の情報を使用す
   るレンダリングデバイスと を有し、 前記第１イメージが、前記ディスプレイ上で前記第２イ
   メージに関連付けられたコンピュータシステムにおい
   て、 グラフィック状態情報を記憶し、アクセスするグラフィ
   ック状態システムであって、 前記第１グラフィックオブジェクトに応答して、前記デ
   ィスプレイ上に前記第１イメージを描画するために前記
   レンダリングデバイスによって使用される前記グラフィ
   ック状態情報を含む第１グラフィック状態オブジェクト
   を作成する第１の作成手段と、 前記第２グラフィックオブジェクトに応答して、前記デ
   ィスプレイ上に前記第２イメージを描画するために前記
   レンダリングデバイスによって使用される前記グラフィ
   ック状態情報を含む第２グラフィック状態オブジェクト
   を作成する第２の作成手段と、 前記第１グラフィックオブジェクトにおいて、前記描画
   コマンドに応答して、前記第１グラフィック状態オブジ
   ェクトを前記第２グラフィックオブジェクトに転送する
   転送手段と、 前記第２グラフィックオブジェクトにおいて、前記転送
   された第１グラフィック状態オブジェクトに含まれる前
   記グラフィック状態情報を前記第２グラフィック状態オ
   ブジェクトに含まれる前記グラフィック状態情報に連結
   して、該連結されたグラフィック状態情報を前記レンダ
   リングデバイスへ転送し、該コンピュータシステムが、
   前記第１グラフィックオブジェクトにアクセスすること
   なく、前記第１イメージおよび前記第２イメージを描画
   できるようにする連結手段と を具えたことを特徴とするグラフィック状態システム。
2. 【請求項２】前記第２の作成手段は 前記ディスプレイ上でのグラフィックイメージの外観を
   制御するデータを有するグラフィック状態オブジェクト
   を作成する手段を含むことを特徴とする請求項１記載の
   グラフィック状態システム。
3. 【請求項３】前記第２の作成手段は、 局所座標系から大域座標系にグラフィックイメージを変
   換するマトリクス情報を有する、グラフィック状態オブ
   ジェクトを作成する手段を含むことを特徴とする請求項
   ２記載のグラフィック状態システム。
4. 【請求項４】前記第２の作成手段は、 グラフィックイメージのクリッピング境界を定義するク
   リッピング状態情報を有する、グラフィック状態オブジ
   ェクトを作成する手段を含むことを特徴とする請求項３
   記載のグラフィック状態システム。
5. 【請求項５】前記第２の作成手段は、 シーン情報、ライティング情報およびカメラ配置情報を
   有する、グラフィック状態オブジェクトを作成する手段
   を含むことを特徴とする請求項４記載のグラフィック状
   態システム。
6. 【請求項６】前記第２の作成手段は、 局所座標系から大域3D座標系にグラフィックイメージを
   変換する3Dマトリクス情報を有する、グラフィック状態
   オブジェクトを作成する手段を含むことを特徴とする請
   求項５記載のグラフィック状態システム。
7. 【請求項７】前記第２の作成手段は、 前記第２グラフィック状態オブジェクトを参照する第２
   グラフィックオブジェクト内に、参照属性を提供する手
   段をさらに具えたことを特徴とする請求項１記載のグラ
   フィック状態システム。
8. 【請求項８】前記連結手段は、 前記描画コマンドに応答して、前記第１グラフィック状
   態オブジェクトを参照する第１参照属性と、前記第２グ
   ラフィック状態オブジェクトを参照する第２参照属性と
   を有する、リンクポートオブジェクトを作成する手段を
   含み、 ここで、該連結手段は、前記リンクポートオブジェクト
   を参照するために、前記第２グラフィックオブジェクト
   内に第３参照属性を作成する手段を含むことを特徴とす
   る請求項１記載のグラフィック状態システム。
9. 【請求項９】前記第１の作成手段は、 第１クラスから前記第１グラフィック状態オブジェクト
   を作成し、第２クラスから前記第２グラフィック状態オ
   ブジェクトを作成し、 前記連結手段は、 前記第１クラスの第１サブクラスから、第１リンク可能
   グラフィック状態オブジェクトを生成する手段と、 前記第２クラスの第２サブクラスから、第２リンク可能
   グラフィック状態オブジェクトを生成する手段と をさらに含み、 ここで、前記第２サブクラスは、リンクメンバ関数を有
   し、前記リンクポートオブジェクトを、第１リンク可能
   グラフィック状態オブジェクトと第２リンク可能グラフ
   ィック状態オブジェクトにリンクすることを特徴とする
   請求項８記載のグラフィック状態システム。
10. 【請求項１０】該コンピュータ・システムのタスクに関
    連付けるグラフィックポートオブジェクトを作成する手
    段をさらに具え、 該グラフィックポートオブジェクトは、第１および第２
    グラフィック状態オブジェクトにアクセスする手段を有
    することを特徴とする請求項１記載のグラフィック状態
    システム。
11. 【請求項１１】前記グラフィックオブジェクトによって
    記述した、グラフィックディスプレイ項目をレンダリン
    グするグラフィック装置レンダリングシステムと、 前記描画コマンドに応答して、該レンダリングシステム
    が、グラフィックディスプレイ項目をレンダリングする
    ように、前記グラフィックオブジェクトを提供し、前記
    グラフィック装置レンダリングシステムにグラフィック
    状態オブジェクトを提供する手段 をさらに具えたことを特徴とする請求項１記載のグラフ
    ィック状態システム。
12. 【請求項１２】ディスプレイと、 描画コマンドに応答して、前記ディスプレイ上に第１イ
    メージを描画するために、第１グラフィックオブジェク
    ト内の情報を使用すると共に、前記描画コマンドに応答
    して、前記ディスプレイ上に第２イメージを描画するた
    めに、第２グラフィックオブジェクト内の情報を使用す
    るレンダリングデバイスと を有し、 前記第１イメージが、前記ディスプレイ上で前記第２イ
    メージに関連付けられたコンピュータシステムにおい
    て、 グラフィック状態情報を記憶し、アクセスする方法であ
    って、 前記ディスプレイ上に、前記第１イメージを描画するた
    めに前記レンダリングデバイスによって使用される前記
    グラフィック状態情報を含む第１グラフィック状態オブ
    ジェクトを作成するステップＡと、 前記ディスプレイ上に、前記第２イメージを描画するた
    めに前記レンダリングデバイスによって使用される前記
    グラフィック状態情報を含む第２グラフィック状態オブ
    ジェクトを作成するステップＢと、 前記描画コマンドに応答して、前記第１グラフィック状
    態オブジェクトを前記第２グラフィックオブジェクトに
    転送するステップＣと、 前記第２グラフィックオブジェクトにおいて、前記転送
    された第１グラフィック状態オブジェクトに含まれる前
    記グラフィック状態情報を前記第２グラフィック状態オ
    ブジェクトに含まれる前記グラフィック状態情報に連結
    して、該連結されたグラフィック状態情報を前記レンダ
    リングデバイスへ転送し、該コンピュータシステムが、
    前記第１グラフィックオブジェクトにアクセスすること
    なく、前記第１イメージおよび前記第２イメージを描画
    できるようにするステップＤと を具えたことを特徴とする方法。
13. 【請求項１３】前記ステップＡは、 前記第１イメージの外観を示す情報を含む第１グラフィ
    ック状態オブジェクトを作成するステップA1を含むこと
    を特徴とする請求項12記載の方法。
14. 【請求項１４】前記ステップＡは、 局所座標系から大域座標系に第１グラフィックイメージ
    を変換するマトリクス情報を有する、第１グラフィック
    状態オブジェクトを作成するステップA2を含むことを特
    徴とする請求項12記載の方法。
15. 【請求項１５】前記ステップＡは、 第１グラフィックイメージのクリッピング境界を定義す
    るクリッピング状態情報を有する、第１グラフィック状
    態オブジェクトを作成するステップA3を含むことを特徴
    とする請求項12記載の方法。
16. 【請求項１６】前記ステップＡは、 シーン情報、ライティング情報およびカメラ配置情報を
    有する、第１グラフィック状態オブジェクトを作成する
    ステップA4を含むことを特徴とする請求項15記載の方
    法。
17. 【請求項１７】前記ステップＡは、 局所座標系から大域3D座標系に第１グラフィックイメー
    ジを変換する3Dマトリクス情報を有する、第１グラフィ
    ック状態オブジェクトを作成するステップA5を含むこと
    を特徴とする請求項16記載の方法。
18. 【請求項１８】前記ステップＢは、 前記第２グラフィック状態オブジェクトを参照する第２
    グラフィックオブジェクト内に、参照属性を提供するス
    テップB1を含むことを特徴とする請求項12記載の方法。
19. 【請求項１９】前記ステップＤは、 前記第１グラフィック状態オブジェクトを参照する第１
    参照属性と、前記第２グラフィック状態オブジェクトを
    参照する第２参照属性とを有する、リンクポートオブジ
    ェクトを作成するステップD1と、 前記リンクポートオブジェクトを参照するために、前記
    第２グラフィックオブジェクト内に第３参照属性を作成
    するステップD2と を含むことを特徴とする請求項12記載の方法。
20. 【請求項２０】前記ステップＡは、第１クラスから前記
    第１グラフィック状態オブジェクトを作成するステップ
    を含み、 前記ステップＢは、第２クラスから前記第２グラフィッ
    ク状態オブジェクトを作成するステップを含み、 前記ステップD1は、前記第２クラスの第２サブクラスか
    ら、リンクされたポートサブジェクトを作成するステッ
    プを含むことを特徴とする請求項19記載の方法。
21. 【請求項２１】グラフィックポートオブジェクトを作成
    するステップＥと、 前記グラフィックポートオブジェクトを、該コンピュー
    タシステムのタスクに関連付けるステップＦと、 前記グラフィックポートオブジェクトを用いて、前記第
    １および第２グラフィック状態オブジェクトにアクセス
    するステップＧと をさらに具えたことを特徴とする請求項12記載の方法。