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

Abstract

(57)【要約】 グラフィックから分離しているグラフィック状態オブジェクトが状態情報を含む、グラフィック状態処理の方法およびシステム。状態オブジェクトは、描画する以外の間にアクセスすることができる。オブジェクトは、特別のグラフィック処理状態を表すサブ状態から成る。グラフィックは、グラフィック階層を送ることのみを必要とし、グラフィック状態オブジェクトは、グラフィック状態をレンダリング装置へ送ることを、自動的に引き受けて処理する。グラフィック状態オブジェクトは、描画されるグラフィックとは分離した実体である。

Description

【発明の詳細な説明】 グラフィック状態処理 著作権の告示 この特許出願の一部は、著作権保護のもとにある資料を含む。著作権者は、複 写物が特許文献または特許の開示のいずれかによるもの、たとえば特許商標庁の 特許ファイルまたは記録に現れるようなものならば、異議はないが、何であれそ の他の場合には、すべての著作権を留保する。 関連出願へのクロス・リファレンス(CROSS-REFERENCE) この特許出願は、１９９３年１１月３日に出願されたオブジェクト指向グラフ ィック・システム(OBJECT ORIENTED GRAPHIC SYSTEM)と称する特許出願に関連し 、Taligent社に譲渡されたものであり、開示は参照によりここに組み込まれてい る。 発明の分野 本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にグラ フィック状態処理のシステムおよび方法に関する。 発明の背景 以前のグラフィックス・アーキテクチャでは、あるグラフィックがその状態（ たとえば色、転送モード、クリップ領域(clip area)等）を典型的にはプライベ ートに(privately)ストアしている。描画(draw)を頼まれると、そのグラフィッ クはこれらの状態変数をGrafPortの中へ手続き的にコピーし、これら の変数はレンダリング・コード(rendering code)によりアクセスされる。したが って、このグラフィックの状態が利用可能であるのは、この明白な描画操作(dra wing operation)間だけである。これは、オブジェクト指向ではなく、グラフィ ック・システムが行うことができない制限である。 従来技術のグラフィックス・アーキテクチャの別の問題は、グラフィック階層 (hierarchy)をグラフィック・オブジェクト内に強制することであり、これはそ のオブジェクトが、そのグラフィックの描画中にそのオブジェクトと相互作用す るためである。 発明の要約 それゆえに、本発明の第１の目的はグラフィック状態を処理するシステムと方 法を提供することにある。 本発明の第１の目的とは別の目的は、グラフィック状態を使用するグラフィッ クとは別のグラフィック状態へのアクセスを提供するシステムと方法を提供する ことにある。 本発明のこれらと他の目的は、あるグラフィックによりそのグラフィックをレ ンダ(render)するのに使われるグラフィック状態オブジェクトを有する方法およ びシステムを実現することにある。グラフィック状態オブジェクトはまた、レン ダリング(rendering)・デバイスおよび関連するキャッシュ(cache)との関係を確 立する能力を含むことができる。さらに、状態オブジェクトは多くのサブ状態(s ub-states)を含む。 図面の簡単な説明 図１は、本発明によるコンピュータの典型的なハードウェア構成を説明する図 である。 図２は、TGrafStateの全構造を示す図である。 図３は、デバイスおよびデバイス・キャッシュにアクセスするメソッド (method)を追加したTgrafPortを示す図である。 図４は、グラフィック・オブジェクトが適宜その内容をTGrafDeviceオブジェ クトへ「ダンプ(dump)する」ことができるTGrafPortを示す図である。 図５は、簡単な階層的グラフィックを示す図である。 図６は、TPolygonのDrawコール内にあるオブジェクトを示す図である。 図７は、一時的(transient)階層を示す図である。 図８は、各サブ状態についてデフォルト値を含むTRootGrafPortクラス(class) を示す図である。 図９は、「親(parent)」TGrafPortオブジェクトとTGrafBundleオブジェクトの 連結(concatenation)の役割を果たすTLinkedBundlePortクラスを示す図である。 図１０は、TSimpleMatrixStateクラスの関係を示す図である。 図１１は、TClipStateサブクラス(subclass)の関係を示す図である。 図１２は、TMatrix3DStateについて確立された関係を示す図である。 図１３は、グラフィック階層の例を示す図である。 図１４は、MGraphicの図である。 図１５は、TMyGroup::Drawへのコールがされるときに起こることの例を示すフ ローチャートである。 発明の詳細な説明 本発明の詳細な実施例はここで開示される。しかしながら理解しなければなら ないのは、この開示された実施例は本発明の単なる例示にすぎず、種々の形態で 実施されるということである。したがって、ここで開示された詳細は、制限的な ものとして解釈されてはならず、単に、請求の範囲の基礎として、本発明をする および／または使用する方法を当業者に教示する基礎として、解釈される。 オブジェクト指向プログラミングの歴史とフレームワークの開発は、文献にお いて完全に確立されている。Ｃ++とSmalltalkはよく文献化されているので、詳 細はここでは述べない。同様に、オブジェクトの性質、たとえばカプセル化 (encapsulation)、多様性(polymorphism)、継承(inheritance)は文献および特許 において十分に説明されている。オブジェクト指向システムの良い概説として、 読者はGrady Boochの“Object Oriented Design With Applications”を参照す るとよい。 多くのオブジェクト指向システムは、基本的な入出力を実行する基本オペレー ティング・システム上で動くように設計されているが、本システムはシステム・ レベルのサポートを特殊なフィーチャ(feature)に対して提供するのに使われて いる。 本発明の好ましい実行状況は、ＩＢＭ（登録商標）社のＰＳ／２（登録商標） またはＡｐｐｌｅ（登録商標）社のMacintosh(登録商標)のようなパーソナル・ コンピュータに常駐するオペレーティング・システムのもとでの実行である。代 表的なハードウェア環境は図１に描かれている。図１は、主たる発明による、コ ンピュータの典型的ハードウェア構成を描く図であり、中央処理装置１００、た とえば通常のマイクロプロセッサと、システム・バス１３２を介して相互に接続 した多くの他のユニットを持っている。図１に示されるコンピュータが有するの は、リード・オンリ・メモリ（ＲＯＭ）１０４、ランダム・アクセス・メモリ（ ＲＡＭ）１０６、周辺装置、たとえばディスク・ユニット１０８および１１０に より表される他の入出力周辺機器をシステム・バス１３２へ接続する入出力アダ プタ１１２、キーボード１３０、マウス１２６、スピーカ１２２、マイクロフォ ン１２４、および／または他のユーザ・インタフェース装置、たとえばバスへ接 続されたタッチ・スクリーン装置（示されていない）をバスに接続するユーザ・ インタフェース・アダプタ１２８，１１４で表されるデータ・プロセッシング・ ネットワークへワークステーションを接続する通信アダプタ１１６である。ディ スプレイ・アダプタ１２０がバスとディスプレイ装置１１８を接続する。ワーク ステーションは、その上に常駐しているオペレーティング・システム、たとえば Apple System/7（登録商標）オペレーティング・システムを有している。 定義 グラフィック状態(Graphic State)−幾何図形を描画するのに必要な、すべて のグラフィカルな状態変数（あるときは属性(attribute)と呼ばれる）のことで あり、ペイント(paint)、転送モード(transfer mode)、ペン幾何(pen geometry ）、マトリック(matrix)，クリップ領域(clip area)等を含む。 グラフィック階層(Graphic Hierarchy)−グラフィカルなプリミティブ(primit ive)の階層的配置(arrangement)であり、座標系およびクリッピング情報のよう なグラフィック状態は、親グラフィックから子グラフィックへ継承されることが できる。 GrafPort−グラフィック状態、デバイス、デバイス・キャッシュの完全なセッ トのコンテナ(container)。 開示されたグラフィック状態処理システムは、グラフィック処理の応用の全体 的な効率を上げる多くの目標を達成する。それらの目標の１つは、すべてのグラ フィカルな状態の集合(collection)を表現する抽象ベース・クラス(abstract ba se class)をサポートすること、および状態の階層的動作(hierarchical behavio r)(concatenation:連結)をサポートすることである。サブクラスは、状態変数の 記憶と連結についての特定の実現を提供する。別の目的は、子グラフィック状態 の親状態への連結が子において分離(isolate)されていなければならないことを 要求することである。親の状態は、連結によって影響されてはならない。さらに 、子はある変数の最終的な値の決定において、最終的決定権を持つ。したがって 、親はある変数の値の指示はできない。 また目標であるのは、グラフィック状態がTGrafDeviceオブジェクトと容易に 通信できることである。さらに別の目標は、グラフィックのDrawコールのコンテ キスト(context)外で、グラフィック状態がアクセスされることを許容するフレ ームワークをサポートすることである。たとえば、スプライト(sprite)はビュー (view)の中へ描画するために、グラフィック状態オブジェクトへアクセスする必 要があるであろう。別の目標は、TGrafDevideクラスの中へグラフィック階層に 関するどのような仮定も焼き固め(bake)ないことである。グラフィック階 層は、グラフィック自身の中で自然に実現される。したがって、何の特別の設計 も、TGarfDeviceによる階層上には押しつけられない。 最後に別の目標は、すべてのデバイス依存の(device-dependent)データ型は、 その装置にプライベート(private)なものとすることである。たとえば、すべて のクリッピングは領域ではなくTGAreasにより指定される。 発明の背景において説明されたように、以前のグラフィック・アーキテクチャ においては、グラフィックはプライベートにその状態（たとえば色、転送モード 、クリップ領域等）を典型的にはストアしている。描画が要求されると、グラフ ィックはGrafPortの中へこれらの状態変数を手続き的にコピーし、レンダリング ・コードによりアクセスされる。したがって、グラフィック状態は、この明示的 な描画操作の間に限り利用可能である。本システムは、グラフィックがその状態 をストアするフレームワークを提供する。このフレームワークがサポートするア ーキテクチャでは、クライアント(client)が「描画(draw)」関数のコンテキスト 外で、グラフィック状態にアクセスできる。グラフィック状態のセットは、一連 のコードのかわりに単一のオブジェクトにより表すことができる。これはTGrafP ortクラスの目標である。抽象(abstract)クラスが、状態変数にアクセスするイ ンタフェースを定義する。具体化(concrete)サブクラスは、状態変数の現実のス トレージ(storage)と連結動作(concatenation behavior)を定義する。古い方法 は、 であり、新しい方法は、 である。 TGrafStateおよびTGrafPort 図２は、TGrafStateの全体構造を示す図である。この構造は、すべてのグラフ ィック状態を６つの異なるグループに分類し、つぎにTGrafState２００と呼ばれ る単一のクラスにまとめている。６つの「サブ状態(sub-states)」２０２は、TA ttributeState（グラフィックの外観を決定する属性の集合）、２つのTMatrixSt ates(２Ｄビューおよびモデル座標系)、TClipState（２Ｄクリッピング情報）、 TSceneState(３Ｄカメラと光)、TMatrix3DState（３Ｄモデル座標系）である。T GrafStateオブジェクト２００は、全部のグラフィック状態へのアクセスを必要 とするクラスにより使用される。そのうえ、TGrafStateクラスの抽象的設計のた めに、子グラフィック状態はその親状態に、親状態を実際に変化させないで連結 される。 図２は、網羅的ではないことに留意するべきである。ここで示された６つのサ ブ状態は、所望の設計により、６つより大きくまたは小さくできる。さらに、６ つのサブ状態を作っている要素は、網羅的ではない。たとえば属性は、グラフィ ック処理において知られているどのようなグラフィック属性も仮想的に含むこと ができる。 図２においてまた示されているのは、上で概説した６つのサブ状態２０２の例 示的要素２０４である。特に、GetAttributeStateはGetDrawOperation、GetFill Paint、GetFramePaintおよびGetAntialiasingを有し；GetViewMatrixStateはGet Matrixを有し；GetModelMatrixはGetMatrixを有し；GetClipStateはGetClipArea を有し；GetSceneStateはCreateLightIteratorと た、サブ状態を備えるこれらの要素は単なる例であり、多くのものはここに示さ れ説明されたより多くを含む。 TGrafPortクラスは、TGrafStateのサブクラスである。図３に示されるように 、TGrafPortはメソッド３０２を追加して、デバイスおよびデバイス・キャッシ ュへアクセスする。GetDeviceは、レンダリングがなされるデバイスへのポイン タを返す。GetCacheは、デバイス依存のオブジェクトをキャッシュするデバイス により使用される、キャッシュへのポインタを返す。TGrafPortはまた６つのサ ブ状態を含む。 ６つのサブ状態を含む、TGrafPort３００をサブクラス化する主な目的は、グ ラフィック状態、デバイス、デバイス・キャッシュのストレージと連結がなされ る方法を、定義することである。サブ状態は、共通に使用されるグループに状態 変数を分けるのを支援する。状態変数のより簡単でフラットなグループは、状態 変数のサブセットについて、状態連結のカスタム化を認めるほど、十分に柔軟で はない。たとえば、簡単なグラフィックは、TGrafBundle(便利なTAttributeStat eサブクラス)のみを典型的に必要とする。より複雑なグラフィック・オブジェク トはマトリックスと、場合によりクリップ領域を必要とする。これらのクラスの より多くの情報については、サブ状態の章を参照すること。 MGraphicのようなグラフィックス・クラスは、幾何図形の基本セットによって 、TGrafDevideに自分自身を記述しなければならず、各幾何図形は、それに関連 した１組のTGrafStateオブジェクトを持たなければならない（必ずしもユニーク なものでなくてもよい）。図４に示されるように、TGrafPort４０２は、グラフ ィック・オブジェクト４００がその内容をTGrafDeviceオブジェクトに、適宜「 ダンプする」ことを認める。これは、セットのDraw関数をTGrafPortクラスに供 給することにより達成され、それらの関数はTGrafDeviceクラスで与えられるRen der関数のセットを反映させたものである。各Draw関数は幾何図形をとり、それ とポート(port)のグラフィック状態４０４を、デバイス４０８の適当なRenderコ ールに渡す。便宜のために、オーバライドするバンドル(bundle)とモデル・マト リックス(model matrix)は４０４で渡すこともできる。TGrafPortクラスは以 下に示される。 これらは２ＤDrawコールである。それらは便宜のためにのみ存在している。そ れらは、対応するTGrafDevide::Renderコールをコールして、グラフィック状態 とデバイス・キャッシュを渡す。 多数の、共通部分を持たない(disjoint)コール（多様的(polymorphic)単一コ ールの反対）の目的は、基本的２Ｄ幾何図形の小さい良く定義されたセットのみ が、グラフィック・デバイスによりサポートされるという規則を強制するためで ある。 これらは、付加的なバンドルおよびモデル・マトリックスをとる２ＤDrawコー ルである。それらは、ある種の特殊な条件のためにのみ便宜上存在している。そ れらは、対応するTGrafDevide::Renderコールをコールして、グラフィック状態 と装置キャッシュを渡す。 適当なTGrafDevice::Render関数が呼ばれる前に、バンドルおよびモデル・マ トリックスが、TGrafPortオブジェクトの４０４において示されるように、状態 に連結される。バンドルおよびオプショナルなマトリックスの目的は、幾何図形 から幾何図形に典型的に変化する状態の連結を容易にするためである。しかしな がら、この連結はコールされるたびに起きるので、バンドルまたはマトリックス が多重幾何図形により共用されるときには、これらの使用はすすめられない。 これらは、３ＤDrawコールである。それらは、便宜のためにのみ存在している 。それらは、対応するTGrafDevice::Renderコールをして、グラフィック状態と 装置キャッシュを渡す。 ２Ｄコールと同様に、多数の、共通部分を持たないコールの目的は、基本的３ Ｄ幾何図形の小さい良く定義されたセットのみが、グラフィック・デバイスによ りサポートされるという規則を強制するためである。 これらは、付加的なバンドルおよび３Ｄモデル・マトリックスをとる３ＤDraw コールである。それらは、ある種の特殊な条件のためにのみ便宜上存在している 。それらは、対応するTGrafDevice::Renderコールをして、グラフィック状態と デバイス・キャッシュ４０６を渡す。キャッシュ４０６がデバイス４０８内にあ るように示されているが、これは説明の目的のためにすぎない。キャッシュ４０ ６は、メモリが与えられるところならばどこでも実際にあってよく、デバイス４ ０８から分離したメモリであってもよいし、特定のグラフィック・レンダリング が実行されているところに直接的に関連していない別のデバイス内であってもよ い。 適当なTGrafDevice::Render関数が呼ばれる前に、バンドルおよびモデル・ マトリックスが、TGrafPortオブジェクトの４０４において示されるように、状 態に連結される。バンドルおよびオプショナルなマトリックスの目的は、幾何図 形から幾何図形に典型的に変化する状態の連結を容易にするためである。しかし ながら、この連結はコールされるたびに起きるので、バンドルまたはマトリック スが多重幾何図形の間で共用されるときには、これらの使用はすすめられない。 Ａ．デバイス・キャッシュ デバイス・キャッシュ４０６は大きいオブジェクトに潜在的になり得るので、 それらが思いがけずにシステムを通して増殖しないように保証する配慮が必要で ある。デフォルト動作(behavior)に対する２つのアプローチがある。 １．各GrafPortが自分自身のデバイス・キャッシュを持ち得るが、しかし高価な ものになる。まつわりつく非常に多くのキャッシュが存在することになる。これ は、望ましいデフォルト動作ではない。 ２．各TGrafPortが、親より与えられなかった場合に、自分自身のキャッシュを 生成する。デフォルトにより、これが意味するのは、各グラフィック階層のトッ プにおけるGrafPortのみがキャッシュを持ち得るということである。これは、た ぶん受け入れられるデフォルト動作である。同じルートGrafPortが一束の階層と して使用される場合は、この階層はルートGrafPortにおいてキャッシュを自動的 に共用する。キャッシュが各GrafPortにおいて求められる場合は、GrafPortサブ クラスが、それを実現するために書かれる。 ある場合には、デフォルトのキャッシュ動作をオーバライドすることが望まし い。ビュー(view)がそう望むかもしれない。古いビュー・システムでは、各ビュ ーはデバイス依存の領域をキャッシュした。領域の生成は非常に高価なものなの で、良い最適化であった。本システムでは、ビューは自分自身のデバイス・キャ ッシュを保持できる（それは、他のデバイス依存のオブジェクトと同様に領域を キャッシュする）。 Ｂ．グラフィック状態連結(Graphic State Concatenation) 図５は、簡単な階層的グラフィックを提供する。図５のグラフィックは、グル ープ５００における多角形５０２および楕円５０６から成る。階層における各グ ラフィックは、グラフィック状態の任意のサブセットをストアできる。たとえば 、多角形と楕円はTGrafBundle５０４と５０８を各々持っているが、TGroupは何 のグラフィック状態もストアしない。 これは、階層的状態、たとえばマトリックスが考慮されるまでは、非常に簡単 に思える。正確な、ローカル対グローバル(local-to-global)・マトリックスを 作成するために、グラフィックのローカル・マトリックスは、その親のローカル 対グローバル・マトリックスと連結しなければならない。この連結したマトリッ クスは、それを提供したグラフィックによりキャッシュされる。本アーキテクチ ャは、この型の動作を提供する。 グラフィック状態は、その親グラフィックの状態に「連結」されなければなら ず、グラフィックに適用する状態の新しいフル・セット(full set)を作成する。 TGroup::Drawがコールされると、その親のTGrafPortオブジェクトが渡される。T Group５００は自分自身の状態を持っていないので、どのような連結も実行しな いそれは，親のTGrafPortオブジェクトを多角形のDrawコールへ、つぎに楕円の Drawコールへと、単に渡す。 多角形５０２は、TGrafBundle５０４を持ちそれはその親のTGrafPortオブジェ クトに連結されなければならない。これは、この連結を実行できる「リンクされ た」TGrafPortサブクラス(TLinkedBundlePort)を生成することでなされる。つぎ に、TLinkedBundlePort::Draw(const TGPolygon&)へのコールがなされる。 図６は、TPolygonのDrawコール内にあるオブジェクトを示す。要素６００、６ ０２、６０４、６１０、６１２は、図５に関してすでに説明された対応する要素 を持っている。図６はまたTGafState６０８を有する。TLinkedBundlePortオブジ ェクト６０６は、TPolygonの６０２Drawコールに対してローカルに生成されるた め、この型の連結は一時的に現存する。これはある型のグラフィック階層には必 要である。たとえば、グラフィック階層が、特定のグラフィックに対して、２つ またはそれ以上の他のグラフィックスにより共用されることを許容するならば、 その共用されたグラフィックが多重の親を持つために、一時的な連結を実現しな ければならない。 たとえば、図７において、曲線７０６は、グラフィックＢ７０２およびＣ７１ ０により共用されている。各GraphicＢ７０２、GraphicＣ７１０、TCurve７０６ は、関連するTGrafBundle７０４、７１２、７０８をそれぞれ持つ。GraphicＡ７ ００から、分岐（branch）がGraphicＢ７０２またはGraphicＣ７１０のいずれか にとることができる。連結が一時的でなければならないのは、連結の結果が、と られた分岐（ＢまたはＣ）依存して異なるためである。こらが一時的階層の作用 の方法である。 永続的な階層におけるグラフィック・オブジェクトは、親が実際には描画され ないでも、親の状態を使ってグラフィックが描画ができる親情報の知識を要求す る。そのようなグラフィック階層の例として、ビュー・システムがある。 永続的な階層について言える２〜３のことがある。 １．この階層におけるグラフィックは多重の親により共用されることはできな い。 ２．特別なセマンティックス(semantics)、たとえばLinkToおよびUnlinkコー ル、パラメータ無しのDrawコールは、この階層において使用されているグラフィ ック・クラスに追加されなければならない。 ３．たとえば２Ｄビュー・マトリックス状態とクリップ状態オブジェクトのよ うな、よりプライベートなサブ状態オブジェクトをストアする、TGarfPortサブ クラスを使用することもできる。したがって、各グラフィックは、それ自身のプ ライベートなデバイス・キャッシュの保持を望むだろう。 ４．マルチタスク・セーフ(mutitask-safe)が必要なら、実現される。 効率 多数のグラフィック状態オブジェクトがシステム中を動き回っているため、効 率について注意を向けることは重要である。２つの重要事項がある。 １．簡単なMGraphicsは、親の状態の「デルタ(deltas)」または変更のみを含 むべきである。たとえば、TPolygonオブジェクトは、TGrafBundleオブジェクト のみを含むべきである。 ２．いくつかの状態変数は、多重のグラフィックスにより共用される。 第１の重要事項は、このアーキテクチャの抽象的な性質により注意を向けられ るものであり、異なるTgrafPortサブクラスは、必要な部分のみを含むことを認 められる。第２の重要事項は、共用された属性を使用することにより、注意を向 けられるものである。 サブ状態(Sub-States) 以下のクラスは、TGrafPortクラスを通してアクセスされる「サブ状態」クラ スである。それらは、実際のグラフィック状態変数へのアクセスを提供する。TG rafPortのように、それらのほとんどは、「ゲッタ(getter)」のみを定義する抽 象クラスである。サブクラスは、状態変数が「得られる(gotten)」方法の実現を 提供する。 サブ状態クラスは、親と連結する異なるセマンティックスを持つ。LinkTo関数 は、子オブジェクトからその親への一時的な結合(connection)を提供して、連結 が起きる。Unlink関数はこの結合の役にたつ。２つの理由により、これらのセマ ンティックスが使用される。 １．連結された値は、子にキャッシュできる。 ２．子から親への結合は、より典型的な一時的場合よりも、永続的である必要 もある。 LinkToおよびUnlinkに関するより多くの情報については、以下の「LinkToおよ びUnlinkの使用」の章を参照のこと。サブ状態は以下に示される。 Ａ．TAttributeState TAttributeStateクラスは、グラフィックスが描画されるときのそれらの外観 に関する情報を含む。 このクラス定義は以下に示される。 Ｂ．TMatrixState TMatrixStateクラスは２Ｄ座標系を定義する。TMatrixStateは、ローカル座標 系からあるグローバル座標系(典型的にはワールド座標系(world coordinate system))へ変換するマトリックスへアクセスする、プロトコルを含む。 TLinkableMatrixStateクラスは、別のTMatrixStateオブジェクトとの、リンキ ング(linking)または連結をサポートするプロトコルを定義する。このリンキン グ動作は、サブクラスにおいて２つの理由がある。１）マトリックス(たとえばT GrafDevice)にアクセスするクライアント(client)によって必要とされない。２ ）異なるリンキング・インタフェースが、アドバンスド・クライアント(advance d client)により使用されることもある。クラス定義は以下に示される。 Ｃ．TClipState TClipStateクラスは、クリップする形状(shape)または境界（boundary）を定 義する。それはクリップ領域にアクセスするプロトコルを含み、レンダリングの 間、デバイスにより使用される。 TLinkableClipStateクラスは、別のTClipStateオブジェクトとのリンキングま たは連結をサポートするプロトコルを定義する。この連結動作は、サブクラスに おいて２つの理由がある。１）クリップ領域(たとえばTGrafDevice)にアクセス するクライアント(client)によって必要とされない。２）異なるリンキング・イ ンタフェースが、アドバンスド・クライアント(advanced client)により使用さ れることもある。クラス定義は以下に示される。 Ｄ．TSceneState TSceneStateクラスは、全体としてシーン(scene)に関する情報を含む。この情 報は、正常には、シーンごとにただ１度指定される。それは、以下のメンバを含 む。 光(Lights) カメラ(Camera) クラス定義は、以下に示される。 Ｅ．TMatrix3DState TMatrix3DStateクラスは３Ｄ座標系を定義する。TMatrix3DStateは、ローカル 座標系からあるグローバル３Ｄ座標系（典型的には３Ｄワールド座標系(3D worl d coordinate system)）へ変換するマトリックスへアクセスする、プロトコルを 含む。 TLinkableMatrix3DStateクラスは、別のTMatrix3DStateオブジェクトとの、リ ンキングまたは連結をサポートするプロトコルを定義する。このリンキング動作 は、サブクラスにおいて２つの理由がある。１）マトリックス(たとえばTGrafDe vice)にアクセスするクライアント(client)によって必要とされない。２）異な るリンキング・インタフェースが、アドバンスド・クライアント(advanced clie nt)により使用されることもある。クラス定義は以下に示される。 Ｆ．LinkToおよびUnlinkの使用 LinkToおよびUnlink関数は、「リンクされた」TGrafPortオブジェクトの中か らのみ典型的にコールされるので、それらを直接コールする必要はほとんどない だろう。それらを直接コールすることは、例外ホスタイルな(exception-hostile )コードをもたらす。例外がLinkToコールおよびUnlinkコールの間でス ロー(throw)されると、Unlinkコールがされることはない。悪いニュースである 。 良いニュースは、コード中で直接コールされる必要があるならば、供給された TgrafPortサブクラスを使用することができるし、または特殊な動作が必要なら 自分自身でTGrafPortをサブクラス化することもできる、ということである。他 のリンクされたポート・クラス(port class)のように、LinkTo関数をコンストラ クタ(constructor)の中で、Unlink関数をデストラクタ(destructor)の中でコー ルするべきである。 システムが提供する(System-Supplied)サブクラス 本グラフィック・システムは、グラフィック状態クラスのいくつかの役に立つ サブクラスを提供する。以下でそのいくつかが説明される。 Ａ．TGrafPortサブクラス 図８で示されるように、TRootGrafPortクラス９０２は各サブ状態９０４〜９ １２についてデフォルト値を含む。すべてのサブ状態は、TRootGrafPort９０２ を経由してTGrafPort９００に到達する。したがって、それは無限のクリップ領 域を有するワールド座標空間(World Coordinate space)を表す。それは、TGrafD eviceオブジェクトへのポインタを持ち、デバイスから得るデバイス・キャッシ ュを所有する。このクラスの使用は、クライアントによりオフ・スクリーン(off -screen)のみの描画にするべきである。オン・スクリーン(on-screen)内の使用 は、全スクリーンを越える描画をもたらす。 図９で示されるように、TLinkedBundlePortクラス１００２は、「親」TGrafPo rtオブジェクト１０００とTGrafBundleオブジェクト１００４の連結としての役 に立つ。それが使われるのは、ローカル・バンドルが親TGrafPortオブジェクト １０００における属性状態オブジェクト(attribute state object)に連結する必 要があるときである。親状態の残りは継承される。 TLinkedViewMatrixPortクラス１００６は、親TGrafPortオブジェクト１０００ と指定されたビュー・マトリックス１００８との連結として役に立つ。 それが使用されるのは、ローカル・ビュー座標系が所望されるときである。それ は、指定されたマトリックスを、親TGrafPortオブジェクト１０００におけるビ ュー・マトリックスへ連結する。親の状態の残りは継承される。連結されたマト リックスのキャッシュ化が所望であれば、代替的に、マトリックス状態オブジェ クトはマトリックスのかわりに渡される。 TLinkedModelMatrixPortクラス１０１０は、親TGrafPortオブジェクト１００ ０と指定されたモデル・マトリックス１０１２との連結として役に立つ。それが 使用されるのは、ローカル・モデル座標系が所望されるときである。それは、指 定されたマトリックスを、親TGrafPortオブジェクト１０００におけるモデル・ マトリックスへ連結する。親の状態の残りは継承される。連結されたマトリック スのキャッシュ化が所望であれば、代替的に、マトリックス状態オブジェクトは マトリックスのかわりに渡される。 TLinkedClipAreaPortクラス１０１４は、親TGrafPortオブジェクト１０００と TGArea１０１６との連結として役に立つ。それが使用されるのは、ローカル・ク リップ領域が、親TGrafPortオブジェクト１０００におけるクリップ領域と交差 するる(intersect)必要があるときである。親の状態の残りは継承される。連結 されたクリップ領域のキャッシュ化が所望であれば、代替的に、クリップ状態オ ブジェクトは、クリップ領域のかわりに渡される。 TLinkedScenePortクラス１０１８は、親TGrafPortオブジェクト１０００とTSc eneStateオブジェクト１０２０との連結として役に立つ。それが使用されるのは 、ローカル・シーン状態が、親TGrafPortオブジェクトにおけるシーン状態と、 連結する必要があるときである。親の状態の残りは継承される。 TLinkedModelMatrix3DPortクラス１０２２は、親TGrafPortオブジェクト１０ ００と指定された３Ｄモデル・マトリックス１０２４との連結として役に立つ。 それが使用されるのは、ローカル３Ｄモデル座標系が所望されるときである。そ れは、指定されたマトリックスを、親TGrafPortオブジェクトにおける３Ｄモデ ル・マトリックスへ連結する。親の状態の残りは継承される。連結されたマトリ ックスのキャッシュ化が所望であれば、代替的に、マトリックス状態オブジェク トは、マトリックスのかわりに渡される。 Ｂ．TAttributeStateサブクラス これらのサブクラスは、グラフィック処理システムの任意の外観(appearance) 属性を仮想的に有する。 Ｃ．TMatrixStateサブクラス 図１０において示されるように、TSimpleMatrixState１１０４は、ローカル２ Ｄマトリックス１１０６を含む。そのローカル・マトリックスは、１１０２を経 由して親のローカル対グローバルのマトリックスと連結して、それ自身のローカ ル対グローバルのマトリックス１１００を作成する。これは、GetMatrixにより 返されるものである。 Ｄ．TClipStateサブクラス 図１１は、TClipStateサブクラス１２００の関係を示す図である。TSimpleCli pStateクラス１２０４は、単一のTGAreaオブジェクト１２０６をそのローカル・ クリップ領域として含む。そのローカル・クリップ領域は、その親のクリップ領 域と交差して、GetClipAreaにより返されるクリップ領域を作成する。GetClipAr eaWithChildrenは 同じクリップ領域を返す。ビュー・システムが定義する、よ り精巧なTinkableClipStateサブクラス１２０２は、その子らのクリップ領域を 等式の中へ組み込む。それは、子らのクリップ領域を自分自身から減じて、GetC lipAreaにより返される新しいクリップ領域を作成する。より多くの情報につい ては、ビュー・システム文献を参照のこと。 Ｅ．TSceneStateサブクラス TSceneStateサブクラスは、全体としてシーンに関する情報を有する。たとえ ば、このサブクラスは、光とカメラを有することもある。 Ｆ．TMatrix3DStateサブクラス 図１２は、TMatrix3DState１３００について確立した関係を示す図である。TS impleMatrix3DStateクラス１３０４はローカル３Ｄマトリックス１３０６を含む 。そのローカル・マトリックスは、親のローカル対グローバルのマトリックスと 連結して、それ自身のローカル対グローバルのマトリックスを作成する。これは 、GetMatrixにより返されるものである。TLinkkableMatrix3DState１３０２ はTSimpleMatrix3DState１３０４とTMatrix3DState１３００をリンクするメカニ ズム(mechanism)を提供する。 MGraphicによる使用法 MGraphic階層をサポートするために、親の状態は、MGraphic::Drawコールに渡 されなければならず、その結果子は自分の状態を親の状態と連結できる。 void Draw(TGrafPort& parentPort)； MGraphicサブクラスは、より特殊な動作（すなわちビュー）を必要とし、それ をサポートするために、特別なセマンティックスを定義しなければならない。 使用法の例 Ａ．グラフィック階層 特定のマトリックス状態オブジェクトが、「ローカル対グローバルのモデル・ マトリックスを与えてほしい。」と依頼された場合、その答は、親の状態のロー カル対グローバルのモデル・マトリックスに時々依存する。図１３のグラフィッ ク階層を考慮のこと。このグラフィックは、グラフィックスの小さい２つののグ ループ、１４００で示されるグループ１、１４０２で示されるグループ２から成 る。グループ２は、多角形を含み、グループ１内に置かれていて、グループ１は また、楕円を含む。双方のグループが含むTSimpleMatrixStateオブジェクトは、 それらのモデル座標系を定義する。 グループ１はスクリーンを表し、その親マトリックスは同一であることを意味 する。「ローカル対グローバルのモデル・マトリックスを与えてほしい。」と依 頼された場合、グループ１は自分自身のローカル・マトリックスを単に返す。グ ループ２が同じ質問をされると、自分自身のローカル・モデル・マトリックスを 、グループ１のローカル対グローバルのモデル・マトリックスとあらかじめ連結 して、その結果を返す。たぶん結果をキャッシュするだろう。 Ｂ．具体例 上記の抽象クラスの異なるサブクラスは、特殊化された動作を実現する。特殊 化された動作が有するのは、 １．階層的状態変数の異なる連結動作、たとえばクリップ領域の計算。 ２．非階層的変数の異なるオーバライド動作、たとえばアンチエイリアシング(a ntialiasing)制御。 ３．異なるストレージ(storage)要求。状態のサブセットをストアする必要のみ がほとんどである。 １．簡単なMGraphics(TPolygon) TPolygonの様な簡単なMGraphicsは、TGrafBundleクラスに含まれる属性（描画 操作、塗りつぶしとフレーム・ペイント(fill and frame paints)等）の指定の みを必要とする。TPolygonのDrawコールは以下に示される。 TGrafPort::Drawコールのオーバライドするバンドル・パラメータを使用する ことに留意すること。 ２．より複雑なMGraphics いくつかのMGraohicsはTGrafBundleオブジェクトより多くの状態を要求する。 以下に示されるのは、TTGrafBundleとローカル・モデル・マトリックスをストア するグラフィックのDrawコールである。 ３．スクリーンへの直接描画 スクリーンへの直接描画はこのようになされる。 ４．クリップ境界(Clip Boundaries)を有するスクリーンへの直接描画 ネストされた(nested)クリップ境界と座標系を使用する、スクリーンへの直接 描画は、このように実行される。 ５．バックバッファされた(Back-Buffered)グラフィックの描画 バックバッファリング(back-buffering)グラフィックは、子らの「キャッシュ 」としての役割をするデバイスを所有する。たとえば、フレーム・バッファにつ いて、バック・バッファはTGImageである。親との連結が起きるとき、バック・ バッファは渡されるデバイスに関して有効化(validate)される。渡されたデバイ スについて有効なバック・バッファであれば、デバイスに描画される。さもなけ れば、それは削除されて、新しいバック・バッファと置き換えられる。この動作 は、TLinkedBackBufferGrafPortクラスの中に包まれる。以下は、この特徴(feat ure)が実現されるいくつかの方法の１つである。 TBackBufferingGraphicクラスはバックバッファリングに関してなにも知らない 別のMGraphicについての「ラッパ(wrapper)」としての役割をすることができる ことに留意すること。 Ｃ．例 図１４のMGraphicを考慮してほしい。それは、単一のTPolygon１５０６を含む 単一のTGroup１５００から成る。双方ともいくつかのローカル状態を含む。TMyG roup１５００は、ローカル状態TGrafBundle１５０２とTSimpleMatrixState１５ ０４を含む。TPolygon１５０６は、ローカル状態TGrafBundle１５０８を含む。 図１５は、好適実施例による詳細なロジックのフローチャートである。処理は 関数ブロック１６００において開始する。ここでは、関数ブロック１６４０と１ ６５０におけるロジックを使用してマトリックスを連結する、グラフポートが生 成される。関数ブロック１６４０と１６５０では、マトリックス状態オブジェク トが生成され、親ポートのマトリックス状態オブジェクトにリンクされて、連結 を容易化する。次に、関数ブロック１６１０において、ループが開始されて、ち ょうど生成されたポートの中に描画する。これは次のようにして達成される。多 角形または他の幾何図形を、関数ブロック１６６０におけるグラフポートへ渡す 。順に、グラフポートは、多角形または他の幾何図形と関数ブロック１６７０に おけるそのグラフィック状態オブジェクトを、グラフィック・デバイスへ渡す。 次に、関数ブロック１６８０において、デバイスは、渡されたグラフィック状態 オブジェクトからマトリックスを得る。次に、判断ブロック１６９０においてテ ストが実行されて、連結されたマトリックスが親マトリックスとローカル・マト リックスに関して古いかどうかを決定する。もし古ければ、親マトリックスとロ ーカル・マトリックスは、関数１６９２において連結されて、その結果が関数ブ ロック１６９４においてグラフィック・デバイスに返される。 関数ブロック１６１０において開始したループは、判断ブロック１６２０にお けるテストを含み、最後のグラフィック・オブジェクトが処理されたかどうかを 決定する。もしそうなら、関数ブロック１６００において生成されたグラフポー トは、関数ブロック１６３０において削除され、グラフポートのマトリックス状 態は、関数ブロック１６３２において親とのリンクがはずされる。 本発明は、好適実施例により説明されてきたが、当業者は、以下の請求の範囲 の精神と範囲内における変更で、本発明を実施することができることを認めるだ ろう。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年１１月２０日 【補正内容】 （原文明細書第１頁） 明細書 グラフィック状態処理 著作権の告示 この特許出願の一部は、著作権保護のもとにある資料を含む。著作権者は、複 写物が特許文献または特許の開示のいずれかによるもの、たとえば特許商標庁の 特許ファイルまたは記録に現れるようなものならば、異議はないが、何であれそ の他の場合には、すべての著作権を留保する。 関連出願へのクロス・リファレンス(CROSS-REFERENCE) この特許出願は、１９９３年１１月３日に出願されたオブジェクト指向グラフ ィック・システム(OBJECT ORIENTED GRAPHIC SYSTEM)と称する特許出願に関連し 、Taligent社に譲渡されたものであり、開示は参照によりここに組み込まれてい る。 発明の分野 本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にグラ フィック状態処理のシステムおよび方法に関する。 発明の背景 以前のグラフィックス・アーキテクチャでは、あるグラフィックがその状態（ たとえば色、転送モード、クリップ領域(clip area)等）を典型的にはプラ イベートに(privately)ストアしている。描画(draw)を頼まれると、そのグラフ ィックはこれらの状態変数をGrafPortの中へ手続き的にコピーし、これらの変数 はレンダリング・コード(rendering code)によりアクセスされる。したがって、 このグラフィックの状態が利用可能であるのは、この明白な描画操作(drawing o peration)間だけである。これは、オブジェクト指向ではなく、グラフィック・ システムが行うことができない制限である。従来技術のグラフィックス・アーキ テクチャの別の問題は、グラフィック階層(hierarchy)をグラフィック・オブジ ェクト内に強制することであり、これはそのオブジェクトが、そのグラフィック の描画中にそのオブジェクトと相互作用するためである。Haralick,R.M．等によ る“The Image Understanding Environment(画像理解の環境)”、SPIE、vol.165 9,Imaging processing and Interchangeは、手続き的プログラミング・システム におけるグラフィック幾何図形の標準を開示している。種々の幾何図形が、特別 な幾何図形について、適当な型のデータを含むものとして定義されている。曲線 の幾何図形のカテゴリの定義は、その論文で示された特定の情報である。Foley, J.D.による“Computer Graphics：Principles and Practice（コンピュータ・グ ラフィックス：原理と実際）”、Addison,Wesley Publishers,1992,2nd edition ,pp.292-4,318-321および332は、リテイン・モード・グラフィック・システム(r etain mode graphic system)の簡単な概観を開示する。この論文は、オブジェク ト指向設計の使用について説明も示唆もしていない。まして、オブジェクトが、 本発明に関して以下で説明される特殊化されたグラフィック・オブジェクトに関 するメソッドおよびデータから成っていることは、説明も示唆もしていない。ま た、この論文は、ディスプレイ上に現れる各幾何図形において、幾何図形と関連 したすべての情報のコピーを重複する通常のリテイン・モード・フィーチャ(ret ain mode features)を要求している。この論文はまた、継承技術を実現する手続 き的データ構造によって、ディスプレイ上のグラフィック・エンティティ(entit y)の属性を継承する技術を、説明している。 発明の要約 それゆえに、本発明の第１の目的はグラフィック状態を処理するシステムと方 法を提供することにある。 本発明の第１の目的とは別の目的は、グラフィック状態を使用するグラフィッ クとは別のグラフィック状態へのアクセスを提供するシステムと方法を提供する ことにある。 本発明のこれらと他の目的は、あるグラフィックによりそのグラフィックをレ ンダ(render)するのに使われるグラフィック状態オブジェクトを有する方法およ びシステムを実現することにある。グラフィック状態オブジェクトはまた、レン ダリング(rendering)・デバイスおよび関連するキャッシュ(cache)との関係を確 立する能力を含むことができる。さらに、状態オブジェクトは多くのサブ状態(s ub-states)を含む。 請求の範囲 １．グラフィック状態処理の装置（１０−３８）において、 （ａ）プロセッサ手段と、 （ｂ）前記プロセッサ手段（１０）に付けられたストレージ手段（１６、１４ ）と、 （ｃ）前記プロセッサ手段（１０）の制御下にあるグラフィック・デバイス（ ３６、３８）手段と、 （ｄ）１つまたはそれ以上の幾何図形（３０２）の性質および前記１つまたは それ以上の幾何図形（１４０２）と関連したグラフィック状態情報（９０４、９ ０６、９０８、９１０、および９１２）を定義する論理およびデータを含むグラ フィック・オブジェクト（４００）と、 （ｅ）アプリケーション手段であって、前記グラフィック・オブジェクト（１ ６１０）に置かれている幾何図形（１６００、１６６０）を処理し、かつ、該ア プリケーション手段（１６００）および該グラフィック・オブジェクト（１６１ ０）から前記グラフィック状態（１６８０）を利用して前記グラフィック・デバ イス（１６７０、３６、３８）上に前記幾何図形（１６６０）を提示するアプリ ケーション手段 を備えたことを特徴とする装置。 ２．請求項１記載の装置において、前記グラフィック状態（９０４、９０６、９ ０８、９１０および９１２）に複数のサブ状態を含むことを特徴とする装置。 ３．請求項２記載の装置において、前記グラフィック状態（９０４、９０６、９ ０８、９１０および９１２）のサブ状態に外観のレンダリング手段を含むことを 特徴とする装置。 ４．請求項２記載の装置において、前記グラフィック状態（９０６、９１０）の サブ状態に座標手段を含むことを特徴とする装置。 ５．請求項２記載の装置において、前記グラフィック状態（９０８）のサブ状態 にクリッピング手段を含むことを特徴とする装置。 ６．請求項２記載の装置において、前記グラフィック状態（９１２）のサブ状態 にシーン手段を含むことを特徴とする装置。 ７．請求項１記載の装置において、該装置（３４、２３）に付けられた１組のデ バイスに属する情報を通信する通信手段を含むことを特徴とする装置。 ８．請求項１記載の装置において、グラフィック情報（４０６）をストアするキ ャッシュ手段を含むことを特徴とする装置。 ９．請求項１記載の装置において、 （ａ）前記アプリケーション（１４）から描画する関数を受け取るストレージ 手段と、 （ｂ）グラフィック状態の情報（１４）を受け取るストレージ手段と、 （ｃ）該装置（４０４、３４および２３）に付けられた装置の前記組へ、前記 描画する関数と前記グラフィック状態を送る手段と を含むことを特徴とする装置。 １０．請求項９記載の装置において、情報（４０６）をキャッシュする手段を含 むことを特徴とする装置。 １１．請求項９記載の装置において、前記グラフィック・デバイスがディスプレ イ（３８）であることを特徴とする装置。 １２．請求項１記載の装置において、グラフィック状態オブジェクト（１００２ 、１００６、１０１０、１０１４、１０１８および１０２４）の連結を実行する 手段を含むことを特徴とする装置。 １３．請求項９記載の装置において、前記グラフィック・デバイスがプリンタ（ ２０）であることを特徴とする装置。 １４．請求項９記載の装置において、前記グラフィック・デバイスがプロッタ（ ２１）であることを特徴とする装置。 １５．付けられたストレージおよびディスプレイを有するプロセッサにおけるグ ラフィック状態処理の方法において、 （ａ）１つまたはそれ以上の幾何図形（３０２）の性質および前記１つまたは それ以上の幾何図形（１４０２）と関連したグラフィック状態情報（９０４、９ ０６、９０８、９１０、および９１２）を定義する論理およびデータを含むグラ フィック・オブジェクト（４００）を定義するステップと、 （ｂ）前記グラフィック・オブジェクト（１６１０）に置かれた幾何図形（１ ６００、１６６０）を処理するステップと、 （ｃ）前記グラフィック・オブジェクト（１６１０）から前記グラフィック状 態（１６８０）を利用して前記グラフィック・デバイス（１６７０、３６、３８ ）上に前記幾何図形（１６６０）を提示するステップと を備えたことを特徴とする方法。 １６．請求項１５記載の方法において、前記グラフィック状態（９０４、９０６ 、９０８、９１０および９１２）に複数のサブ状態をストアするステップを含む ことを特徴とする方法。 １７．請求項１６記載の方法において、前記グラフィック状態（９０４、９０６ 、９０８、９１０および９１２）のサブ状態に基づいて外観のレンダリングを実 行するステップを含むことを特徴とする方法。 １８．請求項１６記載の方法において、前記グラフィック状態（９０６、９１０ ）のサブ状態における情報に基づいて座標処理を実行するステップを含む ことを特徴とする方法。 １９．請求項１６記載の方法において、前記グラフィック状態（９０８）のサブ 状態における情報に基づいて前記グラフィック上のクリッピングを実行するステ ップを含むことを特徴とする方法。 ２０．請求項１６記載の方法において、前記グラフィック状態（９１２）のサブ 状態にストアされた情報に基づいてシーンのレンダリングを実行するステップを 含むことを特徴とする方法。 ２１．請求項１５記載の方法において、１組の装置（３４および２３）に属する 情報を通信するステップを含むことを特徴とする方法。 ２２．請求項１５記載の方法において、キャッシュ（４０６）にグラフィック情 報をストアするステップを含むことを特徴とする方法。 ２３．請求項１５記載の方法において、 （ａ）アプリケーション（１４）から描画する関数を受け取るステップと、 （ｂ）グラフィック状態の情報（１４）を受け取るステップと、 （ｃ）１組の装置（４０４、３４および２３）へ前記描画する関数および前記 グラフィック状態を送るステップと を含むことを特徴とする方法。 ２４．請求項２３記載の方法において、前記キャッシュ手段（４０６）へ前記グ ラフィック状態を送るステップを含むことを特徴とする方法。 【図２】

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ (72)発明者 ワタナベ リョウジ アメリカ合衆国 95014 カリフォルニア 州 クパチーノ パーム アヴェニュ 22284

Claims (1)

1. 【特許請求の範囲】 １．グラフィック状態処理の装置において、 （ａ）プロセッサ手段と、 （ｂ）前記プロセッサ手段に付けられたストレージ手段と、 （ｃ）前記プロセッサ手段の制御下にあるグラフィック・デバイス手段と、 （ｄ）グラフィック状態を有する前記ストレージ手段中のグラフィック状態オ ブジェクトと、 （ｅ）アプリケーション手段であって、前記ストレージ手段に置かれている幾 何図形を処理し、かつ、該アプリケーション手段および前記グラフィック状態を 利用して前記グラフィック・デバイス上に前記幾何図形を提示するアプリケーシ ョン手段と を備えたことを特徴とする装置。 ２．請求項１記載の装置において、前記グラフィック状態に複数のサブ状態を含 むことを特徴とする装置。 ３．請求項２記載の装置において、前記グラフィック状態のサブ状態に外観のレ ンダリング手段を含むことを特徴とする装置。 ４．請求項２記載の装置において、前記グラフィック状態のサブ状態に座標手段 を含むことを特徴とする装置。 ５．請求項２記載の装置において、前記グラフィック状態のサブ状態にクリッピ ング手段を含むことを特徴とする装置。 ６．請求項２記載の装置において、前記グラフィック状態のサブ状態にシーン手 段を含むことを特徴とする装置。 ７．請求項１記載の装置において、該装置に付けられた１組のデバイスに属する 情報を通信する通信手段を含むことを特徴とする装置。 ８．請求項１記載の装置において、グラフィック情報をストアするキャッシュ手 段を含むことを特徴とする装置。 ９．請求項１記載の装置において、 （ａ）前記アプリケーションから描画する関数を受け取るストレージ手段と、 （ｂ）グラフィック状態の情報を受け取るストレージ手段と、 （ｃ）該装置に付けられた装置の前記組へ、前記描画する関数と前記グラフィ ック状態を送る手段と を含むことを特徴とする装置。 １０．請求項９記載の装置において、情報をキャッシュする手段を含むことを特 徴とする装置。 １１．請求項９記載の装置において、前記グラフィック・デバイスがディスプレ イであることを特徴とする装置。 １２．請求項１記載の装置において、グラフィック状態オブジェクトの連結を実 行する手段を含むことを特徴とする装置。 １３．請求項９記載の装置において、前記グラフィック・デバイスがプリンタで あることを特徴とする装置。 １４．請求項９記載の装置において、前記グラフィック・デバイスがプロッタで あることを特徴とする装置。 １５．付けられたストレージおよびディスプレイを有するプロセッサにおけるグ ラフィック状態処理の方法において、 （ａ）前記ストレージにグラフィック状態を有するグラフィック状態オブジェ クトを構築するステップと、 （ｂ）前記ストレージ手段に置かれたグラフィックを処理するステップと、 （ｃ）前記グラフィック状態に基づいて前記ディスプレイ上に前記グラフィッ クをディスプレイするステップと を備えたことを特徴とする方法。 １６．請求項１５記載の方法において、前記グラフィック状態に複数のサブ状態 をストアするステップを含むことを特徴とする方法。 １７．請求項１６記載の方法において、前記グラフィック状態のサブ状態に基づ いて外観のレンダリングを実行するステップを含むことを特徴とする方法。 １８．請求項１６記載の方法において、前記グラフィック状態のサブ状態におけ る情報に基づいて座標処理を実行するステップを含むことを特徴とする方法。 １９．請求項１６記載の方法において、前記グラフィック状態のサブ状態におけ る情報に基づいて前記グラフィック上のクリッピングを実行するステップを含む ことを特徴とする方法。 ２０．請求項１６記載の方法において、前記グラフィック状態のサブ状態にスト アされた情報に基づいてシーンのレンダリングを実行するステップを含むことを 特徴とする方法。 ２１．請求項１５記載の方法において、１組の装置に属する情報を通信するステ ップを含むことを特徴とする方法。 ２２．請求項１５記載の方法において、キャッシュにグラフィック情報をストア するステップを含むことを特徴とする方法。 ２３．請求項１５記載の方法において、 （ａ）アプリケーションから描画する関数を受け取るステップと、 （ｂ）グラフィック状態の情報を受け取るステップと、 （ｃ）１組の装置へ前記描画する関数および前記グラフィック状態を送るステ ップと を含むことを特徴とする方法。 ２４．請求項２３記載の方法において、前記キャッシュ手段へ前記グラフィック 状態を送るステップを含むことを特徴とする方法。 ２５．請求項２３記載の方法において、該方法に付けられた装置の前記組へ特殊 化された条件を送るステップを含むことを特徴とする方法。 ２６．請求項１５記載の方法において、グラフィック状態オブジェクトの連結を 実行するステップを含むことを特徴とする方法。