JP4630482B2 - 表現ツリーを生成する装置及びラスタ画素イメージを描画する装置 - Google Patents
表現ツリーを生成する装置及びラスタ画素イメージを描画する装置 Download PDFInfo
- Publication number
- JP4630482B2 JP4630482B2 JP2001120228A JP2001120228A JP4630482B2 JP 4630482 B2 JP4630482 B2 JP 4630482B2 JP 2001120228 A JP2001120228 A JP 2001120228A JP 2001120228 A JP2001120228 A JP 2001120228A JP 4630482 B2 JP4630482 B2 JP 4630482B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- binary
- traced
- branch
- active
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T15/00—3D [Three Dimensional] image rendering
- G06T15/10—Geometric effects
- G06T15/40—Hidden part removal
Landscapes
- Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Geometry (AREA)
- Computer Graphics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Image Analysis (AREA)
- Controls And Circuits For Display Device (AREA)
- Image Generation (AREA)
Description
著作権表示
本特許明細書は著作権保護を受ける対象となる内容を含む。著作権所有者は、この特許明細書、もしくは特許庁からの関連する資料をレビューの目的で複製することに異議を唱えるものではないが、他の点においてはあらゆる著作権を保有するものである。
【0002】
発明の技術分野
本発明は、グラフィックオブジェクトベースのイメージの描画に関するものである。特に、本発明は表現ツリーのための命令を生成するための方法と装置に関連する。また、本発明はラスタ画素イメージに表現ツリーを描画するための方法と装置に関連する。また、発明は上述の方法のいずれかを実行するためのコンピュータプログラムを備えたコンピュータ可読媒体に関連する。
【0003】
発明の背景
大部分のオブジェクトベースのグラフィックスシステムでは、ページまたは画面上の画素ベース画像を保持するためにフレームストアまたはページバッファが使用される。通常、グラフィックオブジェクトの輪郭は、計算され、塗り潰され、フレームストアに書き込まれる。二次元グラフィックスの場合、他のオブジェクトの手前にあるオブジェクトは、単純に背景オブジェクトを書き込んだ後にフレームストアに書き込まれ、これによって、画素単位で背景を置換する。これは、当技術分野では、「ペインタのアルゴリズム(Painter's algorithm)」として一般に知られているものである。オブジェクトは、最も奥のオブジェクトから最も手前のオブジェクトという優先順位で考慮され、通常は、各オブジェクトがスキャンラインの順序でラスタ化され、各スキャンラインに沿ったシーケンシャルな並びで画素がフレームストアに書き込まれる。
【0004】
この技法には、基本的に2つの問題がある。第1の問題は、フレームストア内のすべての画素への高速なランダムアクセスが必要であることである。これは、新たに考慮される各オブジェクトが、フレームストア内のどの画素にも影響を及ぼす可能性があるからである。このため、フレームストアは、通常は半導体のランダムアクセスメモリ(RAM)内に保持される。高解像度カラープリンタの場合、必要なRAMの量は非常に多くなり、通常は100Mバイトを超える。このため、コストがかかり、高速での動作が困難である。第2の問題は、多数の画素がペイント(レンダリング)され、その後、時間的に後のオブジェクトによって上塗り(再レンダリング)されることである。このため、時間的に前のオブジェクトによる画素のペイントは、時間の浪費になる。
【0005】
大量のフレームストアの問題を克服するための方法の1つが、「バンディング(banding)」の使用である。バンディングを使用する場合には、フレームストアの一部だけが常時メモリ内に存在することになる。描画されるべきオブジェクトのすべてが「表示リスト」に保持される。画像全体は上記と同様にレンダリングされるが、存在するフレームストアの部分の外側をペイント(レンダリング)しようとする画素ペイント(レンダリング)動作は、「クリップ」アウトされる。オブジェクトのすべてが描画された後、フレームストアの部分をプリンタ(または他の場所)に送り、フレームストアの別の部分を選択し、この処理を繰り返す。この技法には、ペナルティが伴う。たとえば、描画されるオブジェクトは考慮され、何度も(バンドごとに1回)再考慮されなければならない。バンドの数が増えるにつれて、レンダリングが必要なオブジェクトの検査の繰り返し回数も増える。従って、バンディングの技法は、上塗りのコストという問題を解決しない。
【0006】
いくつかの他のグラフィックシステムでは、スキャンラインの順で画像が検討される。やはり、描画されるオブジェクトのすべてが、表示リストに保存される。各スキャンライン上で、そのスキャンラインと交差するオブジェクトが優先順位の順でオブジェクトごとに検討され、オブジェクトのエッジの交差点の間の画素のスパンが、ラインストアにセットされる。この技法も、大量のフレームストアの問題を克服するが、やはり上塗りの問題をこうむる。
【0007】
これらのほかに、大きいフレームストアの問題と上塗りの問題の両方を解決する技法がある。そのような技法の1つでは、各スキャンラインが順番に作られる。やはり、描画されるオブジェクトのすべてが、表示リストに保存される。各スキャンラインでは、そのスキャンラインと交差するオブジェクトのエッジが、スキャンラインとの交差の座標の昇順で保持される。これらの交差の点、すなわちエッジの交点が、順番に検討され、アクティブフィールドの配列のトグルに使用される。そのスキャンライン上での対象となるオブジェクト優先順位ごとに1つのアクティブフィールドがある。考慮されるエッジの対のそれぞれの間で、最初のエッジと次のエッジの間にある各画素の色データが、アクティブフラグに対する優先順位エンコーダを使用してどの優先順位が最も上にあるかを判定すること、および2つのエッジの間のスパンの画素に関するその優先順位に関連する色を使用することによって生成される。次のスキャンラインに備えて、各エッジの交差の座標が、各エッジの性質に応じて更新される。この更新の結果として誤ってソートされた状態になった隣接するエッジは、交換される。新しいエッジも、エッジのリストに合併される。
【0008】
この技法は、フレームストアまたはラインストアがなく、上塗りがなく、オーダーNの回数(このNは優先順位の数)ではなく一定のオーダーの時間でオブジェクト優先順位が処理されるという大きい長所を有する。
【0009】
しかしながら、これらの優先順位エンコーダはツリーベースのグラフィカルな表現に対処するための柔軟性を欠いている。特に、Porter,T、Duff,Tによる「合成ディジタルイメージ(Compositing Digital Images)」(Vol.18、No.3(1984)pp.253-259)で記述されるような、OUTとATOP PorterおよびDuffの合成演算子を含むそれらの表現に対処するための柔軟性を欠く。与えられた画素位置において、合成演算が、その演算によって合成されたグラフィックオブジェクトのどれが有効であるのかに依存するために、問題が生じる。この問題の1つの解決は切取りオブジェクトの複雑な整理を使用することである。それは多くの余分なエッジ処理を必要として、切取りオブジェクトに関する多くのレベルを必要とする。
【0010】
本発明の目的は、既存の構成の1つまたは複数の短所を実質的に克服するか、少なくとも改善することである。
【0015】
本発明の第1の態様によれば、次の装置が提供される。すなわち、表現ツリーを生成する装置であって、前記表現ツリーは、1つ以上のバイナリノードと複数のリーフノードを有する複数のノードを有し、ここで、それぞれの前記バイナリノードはそれにぶらさがる左ブランチと右ブランチとを有して該2つのぶらさがるノードへの2進演算を表し、それぞれの前記ノードは、1個以上のグラフィックオブジェクトが重なったグラフィックオブジェクトを表し、前記グラフィックオブジェクトの重なりの各々が、左ノード領域、共通領域、および右ノード領域を含み、前記装置が、
1つ以上の画素位置のグループを決定する手段と、
それぞれの前記グループについて、前記1つ以上のバイナリノードの左右のブランチが、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの中にあるならばアクティブであると判断し、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの外にあるならば非アクティブであると判断する手段と、
それぞれの前記グループについて、前記表現ツリーをなぞる手段と、ここで、なぞられたバイナリノードの左右ブランチがアクティブである場合、或いは、前記左ノード領域が前記なぞられたバイナリノードの2進演算に必要であり、前記なぞられたバイナリノードの左ブランチがアクティブで右ブランチが非アクティブである場合に、前記なぞられたバイナリノードの左ブランチにぶらさがるノードへなぞられ、また、前記なぞられたバイナリノードの左右ブランチがアクティブである場合、或いは、前記右ノード領域が前記なぞられたバイナリノードの2進演算に必要であり、前記なぞられたバイナリノードの右ブランチがアクティブであり、左ブランチが非アクティブである場合に、前記なぞられたバイナリノードの右ブランチにぶらさがるノードへなぞられ、
それぞれの前記グループのために、前記アクティブな左右ブランチを有する前記なぞられたバイナリノードのための演算子命令、およびなぞられたリーフノードのためのリーフ値命令を生成する手段とを備える。
【0016】
また本発明の第2の態様によれば、次の装置が提供される。すなわち、表現ツリーから、複数の走査線と各走査線に複数の画素位置を有するラスタ画素イメージを描画する装置であって、前記表現ツリーは1つ以上のバイナリノードと複数のリーフノードとを備える複数のノードを有し、ここで前記バイナリノードの各々は下方ノードを有する左ブランチと下方ノードを有する右ブランチを有するとともに2つの前記下方ノードに対する2進演算を表わし、また前記リーフノードの各々は1つ以上のグラフィックオブジェクトが重なったグラフィックオブジェクトを表し、重なっているグラフィックオブジェクトの各々は左ノード領域、共通領域、および右ノード領域を含み、
前記表現ツリーを表すテーブルを生成する手段と、ここで前記テーブルは関連するバイナリノードとリーフノードに対応する複数のレコードを含み、そして、前記関連するバイナリノードのそれぞれの前記レコードは、前記左ノード領域が前記関連するバイナリノードに関連する演算子の動作に必要であるかどうかを示す第1フィールドと、右ノード領域が前記関連するバイナリノードに関連する演算子の動作に必要であるかどうかを示す第2フィールドと、前記関連するバイナリノードの左ブランチがアクティブであるかどうかを示す第3フィールドと、前記関連するバイナリノードの右ブランチがアクティブかどうかを示す第4フィールドとを備え、
1つ以上の画素位置のグループを決定する手段と、
前記グループの各々に関して、前記1つ以上のバイナリノードの左右のブランチが、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの中にあるならばアクティブであると判断し、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの外にあるならば非アクティブであると判断する手段と、
前記グループの各々に関して、前記判断されたアクティブ及び非アクティブのブランチのために、前記テーブルの前記第3及び第4フィールドを更新する手段と、
それぞれの前記グループに関して、前記更新されたテーブルに従って、前記表現ツリーをなぞる手段と、ここで、なぞられたバイナリノードの左右ブランチがアクティブであるか、または、前記左ノード領域がなぞられたバイナリノードの2進演算に必要であり、該なぞられたバイナリノードの左ブランチがアクティブであり、かつ右ブランチが非アクティブである場合に、前記なぞられたバイナリノードの左ブランチがその下方ノードへとなぞられ、また、前記なぞられたバイナリノードの左右ブランチがアクティブであるか、または前記右ノード領域がなぞられたバイナリノードの2進演算に必要であり、該なぞられたバイナリノードの右ブランチがアクティブであり、左ブランチが非アクティブである場合に、なぞられたバイナリノードの右ブランチがその下方ノードへとなぞられ、
前記グループの各々に関して、前記右及び左ブランチがアクティブであるなぞられたバイナリノードに対して演算命令を生成し、なぞられたリーフノードに対してリーフ値命令を生成する手段と、
前記グループの各々に関して、前記イメージを描画するために、前記生成された対応する命令を実行する手段とを備える。
【0020】
発明の実施の形態
添付の1つ又は複数の図面において同一の参照番号が付されたステップ及び/或いは機能は、特に断りのない限り、同じ機能或いは動作を記述するものである。
【0021】
図1は、コンピュータグラフィックオブジェクト画像のレンダリングおよびプレゼンテーションのために構成されたコンピュータシステム1を概略的に示す図である。このシステムには、システムランダムアクセスメモリ(RAM)3に関連するホストプロセッサ2が含まれ、システムRAM3には、不揮発性のハードディスクドライブ5または類似の装置と、揮発性の半導体RAM4を含めることができる。システム1には、システム読取専用メモリ(ROM)6も含まれ、システムROM6は、通常は半導体ROM7をベースとし、多くの場合、コンパクトディスク装置(CD−ROM)8によって補足することができる。システム1には、ラスタ式に動作するビデオ表示装置(VDU)またはプリンタなどの、画像を表示するための手段10も組み込むことができる。
【0022】
システム1に関して上で説明した構成要素は、バスシステム9を介して相互接続され、IBM PC/ATタイプのパーソナルコンピュータおよびそれから発展した構成、Sun Sparcstationsおよびその類似装置など、当技術分野で周知のコンピュータシステムの通常動作モードにて動作可能である。
【0023】
また、図1に図示されているように、画素シーケンシャルレンダリング装置20がバス9に接続される。画素シーケンシャルレンダリング装置20は、好ましい実施形態において、システム1からバス9を介して命令およびデータを供給され、グラフィックオブジェクトベースの記述から導出される画素ベースの画像のシーケンシャルレンダリングを実行する。レンダリング装置20は、オブジェクト記述のレンダリングのためにシステムRAM3を使用することができるが、レンダリング装置20は、通常は半導体RAMから形成される、専用のレンダリング格納部30に関連付けられることが好ましい。
【0024】
本発明の大綱は、有向隣接図表に対する命令を生成すること、具体的には表現ツリーを生成する際のアプリケーションを有する。これは、好適な実施形態においては、画素シーケンシャルレンダリング装置20のアクティビティ判断及び命令生成モジュール500(図5)において実現される。このモジュールは、本明細書のセクション「3.0 アクティビティ判断及び命令生成モジュール」において詳細に説明される。
【0025】
次に図2を参照すると、好ましい実施形態の全体的な機能のデータ流れ図が示されている。図2の機能流れ図は、オブジェクトグラフィック記述11から始まる。このオブジェクトグラフィック記述11は、ホストプロセッサ2によって作り出されるグラフィックオブジェクトに適切な様式で、且つ/又は、システムRAM3内に記憶されたりシステムROM6から導出されるグラフィックオブジェクトに適切な様式でそれらのパラメータを記述するのに使用される。そして、このグラフィックオブジェクト記述は、画素ベースの画像をレンダリングするために、画素シーケンシャルレンダリング装置20によって解釈され得る。たとえば、オブジェクトグラフィック記述11は、ディスプレイ上の1点から別の点までをなぞる直線のエッジ(単純ベクトル)または、直交する線を含む複数のエッジによって二次元オブジェクトが定義される直交エッジフォーマットを含むいくつかのフォーマットによって、エッジを有するオブジェクトを組み込むことができる。これ以外に、連続曲線によってオブジェクトが定義されるフォーマットも適当であり、これらには、乗算を実行する必要なしに二次曲線を単一の出力空間内でレンダリングできるようにする複数のパラメータによって単一の曲線を記述できる二次多項式の線分を含めることができる。それ以外の、三次スプラインやその類似物などのデータフォーマットを使用することもできる。オブジェクトには、多数の異なるエッジタイプの混合物を含めることができる。通常、すべてのフォーマットに共通するのは、それぞれの線(直線であれ曲線であれ)の始点と終点との識別子であり、通常は、これらは、スキャンライン番号によって識別され、したがって、その曲線をレンダリングすることのできる特定の出力空間が定義される。
【0026】
たとえば、図14Aに、線分を適当に記述し、レンダリングするために、2つの線分601および602に分割する必要があるエッジ600に対する従来のエッジ記述を示す。分割の必要が生じるのは、従来のエッジ記述が、二次式を介して簡単に計算されるが、変曲点604に適応することができないからである。したがって、エッジ600は、終点603および604または終点604および605を有する2つの別々のエッジとして扱われた。図14Bに、終点611および612と制御点613および614によって記述される三次スプライン610を示す。このフォーマットでは、レンダリングのために三次多項式の計算が必要であり、したがって、計算時間がかかる。
【0027】
図14C及び図14Dに、好ましい実施形態に適用可能なエッジの例を示す。
好ましい実施形態では、エッジは、単一の実体とみなされ、必要であれば、異なるフォーマットで記述できるエッジの部分を示すために区分されるが、その具体的な目的は、各部分の記述の複雑さが最小限になるようにすることである。
【0028】
図14Cの左側には、スキャンラインA〜Mの間にまたがる単一のエッジ620が示されている。エッジは、start_x、start_y、エッジの次の線分を指すアドレスを含む1つまたは複数の線分記述、および、エッジの終了に使用される最終線分を含む複数のパラメータによって記述される。好ましい実施形態によれば、エッジ620は、3つのステップ線分、1つのベクトル線分および1つの二次線分として記述することができる。ステップ線分は、単純に、xステップ値とyステップ値を有するものとして定義される。図示の3つのステップ線分の場合、線分記述は[0,2]、[+2,2]および[+2,0]である。なお、xステップ値は符号付きであり、これによってステップの向きが示されるが、yステップ値は、必ず、スキャンラインの値が増えるラスタスキャン方向であるから符号なしである。次の線分はベクトル線分であり、通常はパラメータstart_x、start_y、finish_yおよび傾斜(DX)を必要とする。この例では、ベクトル線分がエッジ620の中間線分であるから、start_xおよびstart_yは、前の線分から生じるので、省略することができる。傾斜値(DX)は、符号付きであり、前のスキャンラインのx値に加算されて、現行スキャンラインのx値を与える。図示の例では、DX=+1である。次の線分は、二次線分であり、これは、ベクトル線分に対応する構造を有するが、さらに、やはり符号付きであり、線分の傾斜を変更するためにDXに加算される2階値(DDX)も有する。
【0029】
図14Dの右側の線分は、好ましい実施形態による三次曲線の例を示す図であり、これには上記の二次線分に対応する記述が含まれるが、線分の傾斜の変化の割合を変更するためにDDXに加算される符号付きの3階値(DDDX)が追加されている。他の多数階についても、同様にして実施することができる。
【0030】
上記から、エッジの線分を記述する複数のデータフォーマットを処理する能力があると、複雑で計算コストの高い数学演算に頼らずに、エッジの記述と評価を単純化することができることが明白である。これに対して、図14Aの従来技術のシステムでは、直交、ベクトルまたは二次のいずれであれ、すべてのエッジを二次形式で記述する必要があった。
【0031】
好ましい実施形態の動作を、図8に示された画像78のレンダリングという単純な例に関して説明する。画像78は、2つのグラフィカルオブジェクト、具体的に言うと、不透明の赤色の長方形90とその上にレンダリングされ、これによって長方形90を部分的に隠す、部分的に透明の青色の三角形80を含む。図からわかるように、長方形90には、種々の画素位置(X)とスキャンライン位置(Y)の間で定義された辺(エッジ)92、94、96および98が含まれる。エッジ96および98は、スキャンライン上に形成される(したがってこれらと平行である)ので、長方形90の実際のオブジェクト記述は、図9Aに示されているように、エッジ92および94だけに基づくものとすることができる。図9Aにおいて、エッジ92は、画素位置(40,35)から始まり、ラスタ方向で画面の下側へ延びて、画素位置(40,105)で終わる。同様に、エッジ94は、画素位置(160,35)から位置(160,105)まで延びる。長方形グラフィックオブジェクト90の水平部分は、単にエッジ92からエッジ94へラスタ化された形で走査することによって得ることができる。
【0032】
しかし、青い三角形のオブジェクト80は、3つのオブジェクトエッジ82、84および86によって定義され、各エッジは、三角形の頂点を定義するベクトルとみなされる。エッジ82および84は、画素位置(100,20)から始まり、それぞれ画素位置(170,90)または(30,90)まで延びる。エッジ86は、これら2つの画素位置の間で、従来のラスタ化された左から右への方向に延びる。この特定の例では、エッジ86が、上で述べたエッジ96および98と同様に水平なので、エッジ86が定義されることは必須ではない。というのは、エッジ86が、エッジ82および84の終点をもつという特徴があるからである。エッジ82および84の記述に使用される始点および終点の画素位置のほかに、これらのエッジのそれぞれに、この場合ではそれぞれ+1または−1の傾斜値が関連付けられる。
【0033】
図10に、スキャンライン35で始まる長方形90がレンダリングされる様子と、エッジ82および84がスキャンライン35とどのように交差するかを示す。図10から、画像78のラスタ化には、高い優先順位レベルを有するオブジェクトが、低い優先順位レベルを有するオブジェクトの「上」にレンダリングされる形で2つのオブジェクト90および80が描画される必要のあることがわかる。これを図11に示す。図11は、画像78のレンダリングに使用されるエッジリストレコードを示す図である。図11のレコードには、オブジェクトごとに1つずつの、2つの項目が含まれる。これらの項目は、それぞれのオブジェクトのラスタレンダリング順での始点に対応するスキャンライン値で配置される。図11から、エッジレコードのそれぞれが、オブジェクトに対応する優先順位レベルと、記述されるエッジの性質に関する詳細(たとえば色、傾斜など)を有することがわかる。
【0034】
再び図2に戻って説明する。レンダリングされるグラフィックオブジェクトの記述に必要なデータを識別したので、グラフィックシステム1は、表示リスト生成ステップ12を実行する。
【0035】
表示リスト生成12は、ROM6およびRAM3を有するホストプロセッサ2上で実行されるソフトウェアモジュールとして実施されることが好ましい。表示リスト生成12では、周知のグラフィック記述言語、グラフィックライブラリ呼出しまたは他のアプリケーション固有フォーマットのうちの1つまたは複数で表現されたオブジェクトグラフィック記述を表示リストに変換する。表示リストは、通常は、表示リスト格納部13に書き込まれる。表示リスト格納部13は、一般にRAM4内で形成されるが、レンダリング格納部30内に形成するようにしてもよい。図3からわかるように、表示リスト格納部13には、複数の構成要素を含めることができ、その1つは命令ストリーム14であり、もう1つはエッジ情報15であり、ラスタ画像画素データ16を含めることができる。
【0036】
命令ストリーム14には、特定の画像内で所望される特定のグラフィックオブジェクトをレンダリングするために画素シーケンシャルレンダリング装置20によって読み取られる、命令として解釈可能なコードが含まれる。図8に示された画像の例では、命令ストリーム14が、下記の形になり得る。
【0037】
(1)スキャンライン20までレンダリング(何もしない)、
(2)スキャンライン20で2つの青いエッジ82および84を追加、
(3)スキャンライン35までレンダリング、
(4)スキャンライン35で2つの赤いエッジ92および94を追加、
(5)最後までレンダリング。
【0038】
同様に、図8の例によれば、エッジ情報15には、下記が含まれることになる。すなわち、
・エッジ84は画素位置100から始まり、エッジ82は画素位置100から始まる;
・エッジ92は画素位置40から始まり、エッジ94は画素位置160から始まる;
・エッジ84は70スキャンライン延び、エッジ82は70スキャンライン延びる;
・エッジ84は傾斜=−1を有し、エッジ84は傾斜=+1を有する;
・エッジ92は傾斜=0を有し、エッジ94は傾斜=0を有する;
・エッジ92および94は70スキャンラインだけ延びる。
【0039】
上の命令ストリーム14およびエッジ情報15の例とそれぞれが表現される形から、図8の画像78では、画素位置(X)とスキャンライン値(Y)によって、画像78がレンダリングされる単一の出力空間が定義されることが認められる。しかし、本開示の原理を使用して、他の出力空間構成を実現することもできる。
【0040】
図8には、ラスタ画像画素データが含まれず、したがって、表示リスト13の記憶部分16には何も記憶する必要がない。この特徴については後述する。
【0041】
表示リスト格納部13は、画素シーケンシャルレンダリング装置20によって読み取られる。画素シーケンシャルレンダリング装置20は、通常は集積回路を用いて実施される。画素シーケンシャルレンダリング装置20は、表示リストをラスタ画素のストリームに変換し、このストリームは、たとえばプリンタ、ディスプレイまたはメモリ格納装置などの別の装置に転送され得る。
【0042】
なお、好ましい実施形態においては、画素シーケンシャルレンダリング装置20を集積回路として説明するが、これは、ホストプロセッサ2などの汎用処理ユニット上で同等の処理を実行可能なソフトウェアモジュールによって実施することもできる。このソフトウェアモジュールは、ディスク装置またはコンピュータネットワークなどのコンピュータ可読媒体を介してユーザに配布することのできるコンピュータプログラム製品の一部を形成することができる。
【0043】
図3は、画素シーケンシャルレンダリング装置20、表示リスト格納部13および一時的なレンダリング格納部30の構成を示す図である。画素シーケンシャルレンダリング装置20の処理ステージ22は、
命令実行部300(本明細書の「1.0 命令実行部」においてより詳細に説明する)、
エッジ処理モジュール400(本明細書の「2.0 エッジ処理モジュール」においてより詳細に説明する)、
アクティビティ判断及び命令生成モジュール500(本明細書の「3.0 アクティビティ判断及び命令生成モジュール」においてより詳細に説明する)、
塗潰し色決定モジュール600(本明細書の「4.0 塗潰し色決定モジュール」においてより詳細に説明する)、
画素合成モジュール700(本明細書の「5.0 画素合成モジュール」においてより詳細に説明する)、及び
画素出力モジュール800(本明細書の「6.0 画素出力モジュール」においてより詳細に説明する)を含む。
【0044】
また、本処理動作では一時的格納部30を使用するが、これは、上で述べたように表示リスト格納部13と同一の装置(たとえば磁気ディスクまたは半導体RAM)を共用してもよいし、速度最適化のために個々に格納部(ストア)を用いて実施することができる。エッジ処理モジュール400は、エッジレコード格納部32を使用して、スキャンラインからスキャンラインへ順方向に運ばれるエッジ情報を保持する。アクティビティ判断及び命令生成モジュール500は、レベルアクティベーションテーブル34を使用して演算子性能に関する情報と、スキャンラインがレンダリングされている間のエッジ交差に関する各領域のその時点におけるアクティビティの状態に関する情報とを保持する。塗潰し色決定モジュール600は、塗潰しデータテーブル36を使用して、特定の位置で特定の優先順位の塗潰し色を決定するのに必要な情報を保持する。画素合成モジュール700は、画素合成スタック38を使用して、値を決定するために多数の優先順位からの色を要求する出力画素を決定する間、中間結果を保持する。
【0045】
表示リスト格納部13および上記で詳細を示した他の格納部32乃至38は、RAM内で実現するか、他のデータ記憶技術によって実現することができる。
【0046】
図3の実施形態に示された処理ステップは、処理パイプライン22の形をとる。この場合、パイプラインのモジュールは、以下で説明する形態でそれらの間でメッセージを受け渡しながら、画像データの異なる部分に対して並列に同時に実行することができる。もう1つの実施形態では、以下で説明するメッセージのそれぞれが、下流モジュール制御への同期転送の形をとることができ、上流処理は、下流モジュールがそのメッセージの処理を完了するまで中断される。
【0047】
1.0 命令実行部
命令実行部300は、命令ストリーム14から命令を読み取り、処理し、その命令を、出力398を介してパイプライン22内の他のモジュール400、500、600および700に転送されるメッセージにフォーマットする。好ましい実施形態では、命令ストリーム14に、以下の命令を含めることができる。
【0048】
LOAD_PRIORITY_PROPERTIES:この命令は、レベルアクティベーションテーブル34にロードされるデータと、そのデータがロードされるテーブル内のアドレスに関連する。命令実行部300は、この命令を検出したとき、レベルアクティベーションテーブル34の指定された位置にデータを格納するためのメッセージを発行する。これは、このデータを含むメッセージをフォーマットし、処理パイプライン22を介して、格納動作を実行するアクティビティ判断及び命令生成モジュール500に渡すことによって達成できる。
【0049】
LOAD_FILL_DATA:この命令は、塗潰しデータテーブル36にロードされるデータと、そのデータがロードされるテーブル内のアドレスに関連する。命令実行部300は、この命令を検出したとき、塗潰しデータテーブル36の指定されたアドレスのデータを格納するためのメッセージを発行する。これは、このデータを含むメッセージをフォーマットし、処理パイプライン22を介して、格納動作を実行する塗潰しデータ決定モジュールに渡すことによって達成できる。
【0050】
LOAD_NEW_EDGES_AND_RENDER:この命令は、次のスキャンラインをレンダリングする時にレンダリング処理に導入される新しいエッジ15の表示リスト格納部13内におけるアドレスに関連する。命令実行部300は、この命令を検出すると、このデータを含むメッセージをフォーマットし、エッジ処理モジュール400に渡す。エッジ処理モジュール400は、新しいエッジのアドレスをエッジレコード格納部32に格納する。指定されたアドレスにあるエッジは、次のスキャンラインをレンダリングする前に、最初のスキャンライン交差座標に基づいてソートされる。一つの実施形態では、エッジは、表示リスト生成処理12によってソートされる。また、別の実施形態では、エッジは、画素シーケンシャルレンダリング装置20によってソートされる。
【0051】
SET_SCAN LINE_LENGTH:この命令は、レンダリングされるスキャンラインのそれぞれで作られる画素数に関連する。命令実行部300は、この命令を検出すると、この値をエッジ処理モジュール400および画素合成モジュール700に渡す。
【0052】
SET_OPACITY_MODE:この命令は、画素合成演算で不透明度チャネル(当技術分野ではアルファチャネルとも称する)を使用するかどうかを示すフラグに関連する。命令実行部300は、この命令を検出すると、このフラグの値を画素合成モジュール700に渡す。
【0053】
命令実行部300は、通常は、命令をマッピングし、パイプライン動作に復号して、さまざまなモジュールに渡す、マイクロコードステートマシンによって形成されるが、その代わりに、対応するソフトウェア処理を使用することもできる。
【0054】
2.0 エッジ処理モジュール
スキャンラインのレンダリング動作中のエッジ処理モジュール400の動作を、図4を参照して以下に説明する。スキャンラインのレンダリングのための初期条件は、以下の3つのエッジレコードのリストが使用可能であることである。これら3つのリストのいずれかまたはすべては空でもよい。これらのリストは、エッジ情報15から取得されLOAD_NEW_EDGES_AND_RENDER命令によってセットされる、新しいエッジを含む新エッジリスト402、前のスキャンラインから順方向に運ばれたエッジレコードを含む主エッジリスト404および、やはり前のスキャンラインから順方向に運ばれたエッジレコードを含むスピルエッジリスト406である。各エッジレコードには、下記が含まれ得る。
【0055】
(i)現時点のスキャンラインの交差の座標(本明細書ではX座標と称する)、
(ii)現時点のこのエッジの線分が続くスキャンラインの数(本明細書ではNYと称する。また、いくつかの実施形態では、これをY限界と表現する場合がある)、
(iii)各スキャンラインの後でこのエッジレコードのX座標に加算される値(本明細書ではDXと称する)、
(iv)各スキャンラインの後でこのエッジレコードのDXに加算される値(本明細書ではDDXと称する)、
(v)1つまたは複数の優先順位番号(P)、
(vi)エッジがスキャンラインと上向き(+)に交差するか下向き(−)に交差するかを示す方向フラグ(DIR)、
(vii)リスト内の次のエッジ線分のアドレス(ADD)。
【0056】
このようなフォーマットは、ベクトル、直交配置されたエッジおよび二次曲線に適合する。これ以外のパラメータ、たとえばDDDXの追加によって、このような配置が三次曲線に適合できるようになる。三次ベジェスプラインなど、いくつかの応用分野では、6階多項式(すなわちDDDDDDXまで)が必要になる場合がある。
【0057】
図8のエッジ84および94の例では、スキャンライン20での対応するエッジレコードが、図16において示されるテーブルのようになる。
【0058】
この説明では、レンダリング処理によって生成されつつあるスキャンラインに沿って画素から画素へステップする座標を、X座標と称し、スキャンラインからスキャンラインへとステップする座標を、Y座標と称する。各エッジリストには、メモリ内で連続的に配置された0個以上のレコードが含まれることが好ましい。ポインタチェインの使用を含む他の記憶配置も可能である。3つのリスト402、404および406のそれぞれのレコードは、スキャンライン交差(X)座標の順で配置される。これは、通常は、最初は、エッジ情報を含むメッセージを命令実行部300から受け取るエッジ入力モジュール408によって管理されるソート処理によって得られる。各スキャンライン交差座標の整数部分だけを有意とみなすためにソートを簡易化することが可能である。また、各スキャンラインの交差座標を、現在のレンダリング処理によって作られる最小および最大のX座標にクランプされるとみなすことによってさらにソートを簡易化することが可能である。適切な場合には、エッジ入力モジュール408は、メッセージを、出力498を介してパイプライン22の下流のモジュール500、600および700に受け渡す。
【0059】
エッジ入力モジュール408は、3つのリスト402、404および406のそれぞれへの参照を継続し、これらのリストからエッジデータを受け取る。これらの参照のそれぞれは、スキャンラインの処理の開始時に、各リスト内の最初のエッジを参照するように初期設定される。その後、エッジ入力モジュール408は、3つの参照されるレコードのうちの最小のX座標を有するレコードを選択するべく、3つの参照されたエッジレコードのうちの1つを選択する。複数のレコードのXが等しい場合には、それぞれが任意の順序で処理され、対応するエッジ交差が、下記の形で出力される。そのレコードの選択に使用された参照は、その後、そのリストの次のレコードに進められる。選択されたばかりのエッジは、メッセージにフォーマットされ、エッジ更新モジュール410に送られる。また、エッジのいくつかのフラグ、具体的には現在のX、優先順位番号および方向フラグが、メッセージにフォーマットされ、このメッセージは、エッジ処理モジュール400の出力498としてアクティビティ判断及び命令生成モジュール500に転送される。なお、本明細書に記載されたものより多数または少数のリストを使用する実施形態も可能である。
【0060】
エッジを受け取った時に、エッジ更新モジュール410は、現在の線分が続くスキャンライン数のカウントをデクリメントする。そのカウントが0に達した場合には、次の線分アドレスによって示されるアドレスから新しい線分を読み取る。線分では、下記が指定される。
(i)線分を読み取った直後に現在のX座標に加算される値、
(ii)そのエッジの新しいDX値、
(iii)そのエッジの新しいDDX値、
(iv)新しい線分が続くスキャンライン数の新しいカウント。
【0061】
示されたアドレスに使用可能な次の線分がない場合には、そのエッジに対してそれ以上の処理は実行されない。そうでない場合には、エッジ更新モジュール410は、そのエッジの次のスキャンラインにおけるX座標を計算する。これには、通常は、現在のX座標をとり、これにDX値を加算することが用いられる。DXは、処理されるエッジの種類に応じて、必要であればDDX値を加算される場合がある。その後、エッジは、複数のエッジレコードの配列であるエッジプール412内の使用可能な空きスロットに書き込まれる。空きスロットがない場合には、エッジ更新モジュール410は、スロットが使用可能になるのを待つ。エッジレコードがエッジプール412に書き込まれたならば、エッジ更新モジュール410は、新しいエッジがエッジプール412に追加されたことを、信号線416を介してエッジ出力モジュール414に知らせる。
【0062】
スキャンラインのレンダリングのための初期条件として、エッジ出力モジュール414は、図4には図示されていないが、エッジレコード32内のリスト404および406に関連する次の主エッジリスト420および次のスピルエッジリスト422のそれぞれへの参照を有する。これらの参照のそれぞれは、当初は空のリスト420および422が構築される位置に初期設定される。エッジ出力モジュール414は、エッジがエッジプール412に追加されたことを示す信号416を受け取ったとき、追加されたエッジが、次の主エッジリスト420に最後に書き込まれたエッジ(があれば)より小さいX座標を有するかどうかを判定する。これが真である場合には、順序付けの基準を侵害せずにそのエッジを主エッジリスト404の末尾に追加することができないので、「スピル」が発生したという。スピルが発生したときには、そのエッジは、好ましくはソートされた次のスピルエッジリスト422を維持する形で、次のスピルエッジリスト422に挿入される。たとえば、これは、ソフトウェアソートルーチンを使用して達成することができる。いくつかの実施形態では、スピルが、極端に大きいX座標など、他の条件によってトリガされる場合がある。
【0063】
エッジプール412に追加されたエッジが、次の主エッジリスト420に最後に書き込まれたエッジ(があれば)以上のX座標を有し、エッジプール412に使用可能な空きスロットがない場合には、エッジ出力モジュール414は、エッジプール412から、最小のX座標を有するエッジを選択し、そのエッジを次の主エッジリスト420の末尾に追加し、この処理で次の主エッジリスト420を延長する。エッジプール412内の、そのエッジによって占められていたスロットは、空きとしてマークされる。
【0064】
エッジ入力モジュール408は、これら3つの入力リスト402、404および406のすべてからすべてのエッジを読み取り、転送した後に、スキャンラインの終りに達したことを示すメッセージを形成し、そのメッセージを、アクティビティ判断及び命令生成モジュール500とエッジ更新モジュール410の両方に送る。エッジ更新モジュール410は、そのメッセージを受け取ると、現在実行しているすべての処理が完了するのを待ち、その後、このメッセージをエッジ出力モジュール414に転送する。そのメッセージを受け取ったエッジ出力モジュール414は、エッジプール412からの残りのエッジレコードのすべてを、X順で次の主エッジリスト404に書き込む。その後、次の主エッジリスト420および主エッジリスト404への参照を、エッジ入力モジュール408とエッジ出力モジュール414の間で交換し、同様の交換を、次のスピルエッジリスト422とスピルエッジリスト406に関しても実行する。この形で、次のスキャンラインのための初期条件が確立される。
【0065】
エッジレコードの挿入時に次スピルエッジリスト422をソートするのではなく、そのようなエッジレコードを、単にリスト422の末尾に追加することができ、スキャンラインの末尾であって現在のスピルリスト406との交換の前にソートされたリスト422は、次のスキャンラインのエッジラスタ化でアクティブになる。エッジをソートする他の方法において、より少数またはより多数のリストを使用することができ、また、異なるソートアルゴリズムを使用することができる。
【0066】
上記から、エッジ交差メッセージが、スキャンライン順および画素順(すなわち、まずYでソートされ、次にXでソートされる)でアクティビティ判断及び命令生成モジュール500に送られること、および各エッジ交差メッセージに、それに適用される優先順位のラベルが付けられることを推論できる。
【0067】
図12Aは、エッジの線分が受け取られる時にエッジ処理モジュール400によって作成され得るアクティブエッジレコード418の具体的な構造を示す図である。エッジの最初の線分がステップ(直交)線分である場合には、エッジのX値を、最初の線分の「Xステップ」と称する変数に加算して、アクティブ化されたエッジのX位置を得る。そうでない場合には、エッジのX値を使用する。これは、新しいエッジレコードのエッジが、Xedge+Xstepによってソートされなければならないことを意味する。したがって、最初の線分のXstepは、エッジのソートを単純化するために0でなければならない。最初の線分のY値は、アクティブエッジレコード418のNYフィールドにロードされる。アクティブなエッジのDXフィールドは、ベクトルまたは二次線分のDXフィールド識別子からコピーされ、ステップ線分の場合には0がセットされる。図12Aに示されたuフラグは、線分が上向き(図13Aに関連する説明を参照されたい)である場合にセットされる。qフラグは、線分が二次線分の場合にセットされ、そうでない場合にはクリアされる。iフラグが設けられ、これは、線分が不可視である場合にセットされる。dフラグは、エッジが、関連するクリッピングレベルのない直接的なクリッピングオブジェクトして使用され、閉じた曲線に適用可能である時にセットされる。線分の実際の優先順位レベルまたはレベルアドレスは、新しいエッジレコードの対応するフィールドからアクティブエッジレコード418のレベル(ADDR)フィールド(Level(Addr))にコピーされる。アクティブエッジレコード418の線分アドレス/DDXフィールド(Seg.Addr(DDX))は、線分リスト内の次の線分のアドレスであるか、線分が二次線分の場合にセグメントのDDX値からコピーされるかのいずれかである。線分アドレスは、エッジレコードを終了させるのに使用される。その結果、好ましい実施形態では、全ての二次曲線(すなわち、DDXフィールドを使用する曲線)が、エッジレコードの終端線分になる。
【0068】
図12Aから、他のデータ構造も可能であり、たとえばより高次の多項式の実装が使用される場合にはそれが必要であることを諒解されたい。さらに、線分アドレスおよびDDXフィールドは、異なるフィールドに分離することができ、代替実施態様に合わせて追加のフラグを設けることができる。
【0069】
図12Bは、エッジ処理モジュール400で使用される、上で説明した好ましい実施形態のエッジレコードの配置を示す図である。エッジプール412は、新アクティブエッジレコード428、現アクティブエッジレコード430およびスピルアクティブエッジレコード432によって補足される。図12Bからわかるように、レコード402、404、406、420および422は、ある時点でレンダリングされるエッジの数に応じてそのサイズを動的に変更することができる。各レコードには、新エッジリスト402の場合にはLOAD_EDGES_AND_RENDER命令に組み込まれたSIZE値によって決定される、限界値が含まれる。このような命令が検出された場合には、SIZEを検査し、0でない場合には、新しいエッジレコードのアドレスをロードし、リスト402の限界サイズを決定する限界値を計算する。
【0070】
好ましい実施形態では、エッジレコードの処理のために配列とそれに関連するポインタを使用するが、たとえばリンクリストなどの、他の実施態様を使用することができる。これらの他の実施態様は、ハードウェアベース、ソフトウェアベースまたはその組合せとすることができる。
【0071】
図8に示された画像78の具体的なレンダリングを、図10に示されたスキャンライン34、35および36に関連して以下に説明する。この例では、次のスキャンラインの新しいX座標の計算が、説明を明瞭にするために省略され、図12Cないし図12Iでは、出力エッジ交差が、エッジプール412のレジスタ428、430および432の1つから導出される。
【0072】
図12Cは、スキャンライン34(半透明の青い三角形80の最上部)のレンダリングの終りでの、上で述べたリストの状態を示す図である。スキャンライン34には、新しいエッジがなく、したがって、リスト402が空であることに留意されたい。主エッジリスト404および次主エッジリスト420のそれぞれには、エッジ82および84だけが含まれる。リストのそれぞれには、対応するポインタ434、436および440が含まれ、これらは、スキャンライン34の完了時に、対応するリスト内の次の空きレコードを指す。各リストには、対応するリストの末尾を指すために必要な、アスタリスク(*)によって示される限界ポインタ450も含まれる。リンクリストを使用する場合には、リンクリストに、対応する機能を実行するヌルポインタ終端子が含まれるので、このような限界ポインタは不要になる。
【0073】
上で述べたように、各スキャンラインの始めに、次の主エッジリスト420と主エッジリスト404が交換され、新しいエッジが、新エッジリスト402に受け取られる。残りのリストはクリアされ、ポインタのそれぞれは、各リストの最初のメンバを指すようにセットされる。スキャンライン35の始めでは、配置は図12Dのようになる。図12Dからわかるように、レコードには、4つのアクティブなエッジが含まれ、図10からわかるように、エッジ92、94、84および82に対応する。
【0074】
図12Eを参照すると、レンダリングが開始されるときに、新エッジレコード402の最初の線分が、アクティブエッジレコード428にロードされ、主エッジリスト404およびスピルエッジリスト406の最初のアクティブなエッジレコードが、それぞれレコード430および432にコピーされる。この例では、スピルエッジリスト406は空であり、したがって、ローディングは行われない。レコード428、430および432内のエッジのX位置が比較され、エッジ交差が、最小のX位置を有するエッジについて発行される。この場合、発行されるエッジは、エッジ92に対応するエッジであり、このエッジがその優先順位値と共に出力される。その後、ポインタ434、436および438が、リスト内の次のレコードを指すように更新される。
【0075】
その後、エッジ交差が発行されるエッジが更新され(この場合、その位置にDX=0を加算することによって)、エッジプール412にバッファリングされる。このエッジプール412は、この例では3つのエッジレコードを保持するサイズになる。発行されたエッジが現れたリスト(この場合ではリスト402)内の次の項目が、対応するレコード(この場合ではレコード428)にロードされる。
これを図12Fに示す。
【0076】
さらに、図12Fから明らかなとおり、レジスタ428、430および432の間の比較によって、もう一度最小のX値を有するエッジが選択され、適切な次のエッジ交差(X=85、P=2)として出力される。そして、同様に、選択され出力されたエッジは、更新され、エッジプール412に追加され、適当なポインタのすべてがインクリメントされる。この場合、更新される値は、X←X+DXによって与えられ、ここでは、84=85−1として与えられる。また、図からわかるように、新しいエッジのポインタ434が、この場合では新エッジリスト402の末尾に移動される。
【0077】
図12Gでは、現在の最小のX値を有すると識別された次のエッジが、やはり、レジスタ430から取得され、エッジ交差(X=115、P=2)として出力される。そして、エッジの更新が発生し、図示のように、その値がエッジプール412に追加される。この時、エッジプール412は満杯になり、ここから、最小のX値を有するエッジが選択され、出力リスト420に発行され、対応する限界ポインタが、それに相応して移動される。
【0078】
図12Hからわかるように、次の最小のエッジ交差は、レジスタ428からのものであり、これが出力される(X=160、P=1)。やはりエッジプール412が更新され、次に小さいX値が出力リスト420に発行される。
【0079】
スキャンライン35の終りに、図12Iからわかるように、X値の小さい順で、エッジプール412の内容が出力リスト420にフラッシュされる。図12Jからわかるように、次の主エッジリスト420と主エッジリスト404は、次のスキャンライン36のレンダリングに備えて、ポインタを交換することによって交換される。交換の後に、図12Jからわかるように、主エッジリスト404の内容には、スキャンライン36上の現在のエッジのすべてが含まれ、これらはX位置の順で配置され、これによって、高速のレンダリングを容易にする便利なアクセスが可能になる。
【0080】
通常、新しいエッジは、X位置の昇順でエッジ処理モジュール400によって受け取られる。新しいエッジが現れる時には、その位置が更新され(次にレンダリングされるスキャンラインのために計算され)、これによって、以下の処置が決定される。
(a)更新された位置が信号線498に出力された最後のX位置より小さい場合には、新しいエッジは、主スピルリスト406へのソートされる挿入であり、対応する限界レジスタが更新される。
(b)そうでない場合に、空間があるならば、そのエッジはエッジプール412内で保存される。
【0081】
前述から明白なとおり、エッジプール412は、ラスタ化画像の次のスキャンラインのレンダリングに備えた順序付きの形でのリストの更新を補助する。さらに、エッジプール412のサイズは、多数の順序付けられていないエッジに適合するために変更することができる。しかし、実際には、エッジプール412が、一般にグラフィック処理システムの処理速度および使用可能なメモリに依存する、実用的な限界を有することは明白である。制限的な意味では、エッジプール412を省略することができるが、これは、通常は、更新されたエッジを、次の出力エッジリスト420へのソートされた挿入にすることを必要とする。しかし、好ましい実施形態では、上で述べたスピルリストの使用を介することにより、必然的にこの状況が回避される。スピルリストを設けることによって、好ましい実施形態を、実用的なサイズのエッジプールを用いて実施でき、なおかつ、ソフトウェア集中的なソート手順に頼らずに比較的複雑なエッジ交差を処理することができる。稀ではあるが、エッジプールとスピルリストがエッジ交差の複雑さに適合するのに不十分になった場合では、ソート法を使用するようにしてもよい。
【0082】
スピルリスト手順が使用される場合の例を、図13Aに示す。図13Aでは、3つの任意のエッジ60、61および63が、スキャンラインAおよびBの間の相対的位置で任意のエッジ62と交差する。さらに、スキャンラインAおよびBのそれぞれについて実際に表示される画素位置64が、スパン画素位置C乃至Jとして図示されている。エッジプール412が3つのエッジレコードを保存するサイズであるとした上記の例では、このような配置だけでは、図13Aに示された隣接するスキャンラインの間で発生する3つのエッジの交差に適合するのに不十分であることは明白である。
【0083】
図13Bに、スキャンライン上のエッジ60、61および63をレンダリングした後のエッジレコードの状態を示す。エッジ交差Hは、最も最近に発行されたエッジ交差であり、エッジプール412は、次のスキャンラインであるスキャンラインBのための、それぞれエッジ60、61および63の更新されたX値E、GおよびIで満杯になっている。エッジ62は、現アクティブエッジレコード430にロードされ、エッジプール412が満杯なので、エッジ60に対応する最小のX値が、出力エッジリスト420に出力される。
【0084】
図13Cでは、次のエッジ交差が発行され(エッジ62、X=J)、対応する更新された値、この場合はスキャンラインBのX=Cが決定される。新たに更新された値X=Cは、出力リスト420からコピーされた最も最近の値X=Eより小さいので、現在のエッジレコードとそれに対応する新たに更新された値が、出力スピルリスト422に直接に転送される。
【0085】
図13Dに、スキャンラインBの開始時のエッジレコードの状態を示す。この図では、主リストおよび出力リストと、それらに対応するスピル構成要素が交換されていることがわかる。最初に発行されるエッジを決定するために、エッジ60を現アクティブエッジレジスタ430にロードし、エッジ62を、スピルアクティブエッジレジスタ432にロードする。X値が比較され、最小のX値(X=C)を有するエッジ62が発行され、更新され、エッジプール412にロードされる。
【0086】
エッジの発行と更新は、主エッジリスト404内の残りのエッジについて継続され、スキャンラインの終りに、エッジプール412がフラッシュされて、図13Eに示された状況になる。図13Eからは、エッジ60ないし63のそれぞれが、次のスキャンラインでのレンダリングのために適当に順序付けられ、スキャンラインB上で正しく発行され、レンダリングされたことがわかる。
【0087】
上記から明らかになるように、スピルリストは、複雑なエッジ交差状況の存在のもとで、エッジラスタ化順序の維持をもたらす。さらに、このリストがサイズにおいて動的に変更可能であることによって、エッジ交差の数と複雑さの大きい変化を、例外的に複雑なエッジ交差以外のすべてのエッジ交差でソート手順に頼る必要なしに処理できる。
【0088】
好ましい実施形態では、エッジプール412は、8つのエッジレコードを保存するサイズにされ、リスト404および420のサイズは、それらに関連するスピルリスト406および422と一緒に、動的に変更可能であり、これによって、複雑なエッジ交差要件を有する大きい画像を処理するために十分な範囲が提供される。
【0089】
3.0 アクティビティ判断及び命令生成モジュール
表現ツリーはイメージを形成するのに必要となる合成演算を記述するのにしばしば使用され、通常は、リーフノード、単項ノードおよびバイナリノードを含む多くのノードを備える。リーフノードは表現ツリーの一番はずれのノードであり、これに続く下位のノードを持たず、イメージのプリミティブな構成要素、すなわちグラフィックオブジェクトを表す。単項ノードは、単項演算子の下位のツリーの部分より生じるオブジェクトの画素データを変更する操作を表す。通常、バイナリのノードは左右のサブツリーに分岐する。ここで、サブツリーはそれぞれ少なくとも1つのリーフノードを備える。バイナリのノードは1つのブランチ上の1つのオブジェクトと、他のブランチ上の他のオブジェクトとの間の演算を表す。
【0090】
そのような演算に関する例は「ディジタルイメージの合成(Compositing Digital Images)」(Porter、T及びDuff、T、コンピュータグラフィックス、Vol.18No.3(1984)、253-259ページ)において記述されている。これらのPorterとDuffの合成演算のいくつかを図15に示す。図示を容易にするために、図15で示されるグラフィックオブジェクトは完全に不透明であるとする。図からわかるように、これらの演算子のいくつか(例えば、out)はデータ(例えば、色データ)を、2個のオブジェクトの中央のオーバラッピング領域に提供しない。一般に、2個のオブジェクトの1つもしくは両方が部分的に透明であるならば、これらの演算子(例えば、out)は常にデータ(例えば、色データ)をそれら2個のオブジェクトの中央オーバラッピング領域に提供することになる。しかしながら、2個のオブジェクトの1つもしくは両方が完全に不透明であるならば、特定の演算子がいかなるデータをもこれら2個のオブジェクトの中央オーバラッピング領域に提供しないという特別な場合が生じることになる。
【0091】
次に、図19をみると、単純な表現ツリーとこれに対応する命令リストの典型的な例が示されている。表現ツリーは、それぞれグラフィックオブジェクトA、B、C、DおよびPAGEを記述するリーフノード10、9、7、6及び0−5を備える。また、表現ツリーは、2つのブランチを有し、それぞれ演算、“out”、“in”、“over”および“over”を表わすノード8、11、12、および13を含む。命令リストは表現ツリーを描画するための命令のリストを含んでいる。しかしながら、合成演算が、その演算によって合成されるグラフィックオブジェクトのどれが与えられた画素位置で有効であるかということに影響されるので、与えられた画素位置に対して命令リストを生成するときには問題が生じる。好適なアクティビティ判断及び命令生成モジュール500は、これらの問題を解決しようとするものである。
【0092】
次に、アクティビティ判断及び命令生成モジュール500の動作について図5を参照して説明する。初期化処理段階の間、命令生成部300は、レンダリングされるイメージのオブジェクト図形記述をレベルアクティベーションテーブル生成部502に渡す。このオブジェクト図形記述は、例えば図19で示される表現ツリーのような、表現ツリーの形態をとる。次に、レベルアクティベーションテーブル生成部502は、レベルアクティベーションテーブルを生成する。このテーブルは、表現ツリーの1次形式であり、レベルアクティベーションテーブル格納部34に格納される。生成されたレベルアクティベーションテーブルは複数のレコードを含んでおり、表現ツリーの2項演算子ノード、単項ノード、及びリーフノードの各々に対して一つのノードが割り当てられている。
【0093】
さらに、また、レベルアクティベーションテーブルは2項演算子のある特有な性質に関するデータ格納のためのフィールドと、2項演算子ノードのブランチのアクティビティに関するデータ格納のためのフィールドとを含んでいる。2項演算子の性質に関するデータは静的である。すなわち、現在スキャンされた画素の位置に依存するのではなく、使用される実際の演算子に依存する。その結果、初期化処理段階の間に、このデータは生成され、レベルアクティベーションテーブルの中に格納されることができる。しかしながら、ブランチのアクティビティに関するデータは、現在スキャンされている画素位置に依存する。初期化処理段階の間は、その時点で有効な画素位置はないので、レベルアクティベーションテーブルのブランチアクティビティデータは無効な状態に初期化される。
【0094】
そして、画素順次描画装置20は、ラスタスキャン順次で、イメージの画素位置をスキャンし始める。エッジ処理モジュール400はレベルアクティベーションテーブル更新モジュール504に、スキャンされている現在のスキャンラインのエッジの画素位置を渡す。レベルアクティベーションテーブル更新モジュール504は格納部34からレベルアクティベーションテーブルにアクセスして、どの画素位置が現在スキャンされているのかに依存してテーブルを更新する。実現の容易化のために、テーブルは隣接しているエッジの間のそれらの画素位置に対して一度だけアップデートされる。これは、スキャンラインの2つの隣接するエッジの間の画素位置の1つのグループ内では、表現ツリーをレンダリングするための命令リストは同一であるということの認識に基づいている。或いは、それぞれのスキャンされた画素位置に対してテーブルはアップデートされる構成とすることもできる。
【0095】
トラバーサル及び命令生成モジュール506は、次に、この更新されたレベルアクティベーションテーブルに基づいて命令を生成する。その命令は、次に、塗潰し色決定モジュール600に渡される。イメージが描画されるまで、隣接しているエッジの間の画素位置の各グループに対して、このプロセスは持続される。
【0096】
本実施形態の更なる説明に先立って、本明細書において使用される用語について簡単に説明する。
【0097】
図18Aと18Bをみると、ソースオブジェクトLと目的オブジェクトRの間の2進演算(表現ツリーとして表されている)が示される。表現ツリーには、オブジェクトLへの左のブランチとオブジェクトRへの右のブランチを有するバイナリノードOPが示される。オブジェクトに適用される境界エッジの中に現在スキャンされている画素があるならば、オブジェクトはその画素にアクティブであるとみなされる。境界エッジの外に画素があるならば、オブジェクトはその画素に非アクティブである。こうして、境界エッジの中のそれらの画素のグループを走査する間、そのオブジェクトはアクティブになる。オブジェクトがアクティブである場合、オブジェクトへの演算子のブランチはアクティブであるとみなされる。実際に実行される動作とは関係なく、図18Aの2進演算は以下で示されるような、4つのアクティビティの領域に分解される。すなわち、
領域1:LオブジェクトがアクティブでRオブジェクトが無効(L∩/R)、
領域2:LオブジェクトがアクティブでRオブジェクトもアクティブ(L∩R)、
領域3:Lオブジェクトが無効でRオブジェクトがアクティブ(/L∩R)、
領域4:Lオブジェクトが無効でRオブジェクトも無効(/(L∪R))。
【0098】
ここで、領域4は、常に、無演算(NOP)の実行が要求されることになる。
従って、結果として、バイナリツリーのための有効なレベルとしては3つの異なった組合せが存在することになる。説明の簡単化のために、ここでは、領域(L∩/R)を左のノード領域或いは左の領域と称し、領域(/L∩R)を右のノード領域或いは右の領域と称し、領域(L∩R)を共通の領域と称する。左のノード領域と右ノード領域は、それぞれ親ノードの左及び右ブランチと関連し、イメージにおけるそれらの位置に対応するものではなく、オブジェクト演算子の順序(たとえば、Lop Rといった順序)に対応している。
【0099】
この説明の目的のために、2項演算子がデータをツリーに提供するならば、その2項演算子はアクティブであるとみなされる。2項演算子のアクティビティは演算子自体の特有な性質とその左右のブランチのアクティビティである。
【0100】
例として、図18Aと図15の“out”演算子を比べてみる。“out”演算子には、領域(L∩/R)に関して、先頭のオブジェクト(左ブランチ)が部分的に透明であるか不透明であるかの如何にかかわらずツリーにデータを渡し、そして、共通の領域(L∩R)では、後続のオブジェクト(右のブランチ)が部分的に透明である場合にのみ、ツリーにデータを渡すという特有な性質がある。前者の場合は、現在スキャンされている画素のグループに対して、左ブランチがアクティブに、右ブランチが非アクティブになる場合にのみ発生する。後者の場合は、左右ブランチが、現在スキャンされた画素のグループに対してともにアクティブであるときに発生する。他方、“out”演算子には、後続(右ブランチ)のオブジェクトが部分的に透明であるかまたは不透明であるかにかかわらず、領域(/L∩R)に対して、データをツリーに渡さないという特有な性質がある。
【0101】
別の例として、図18Aと図15の“in”演算子を比べてみる。“in”演算子には、領域(L∩R)に関して、データ(例えば色データ)をツリーに渡す特有な性質がある。しかしながら、これは、その左右ブランチがアクティブであるときにだけ生じる。他方、“in”演算子には、領域(/L∩R)と(L∩/R)に対し、どんなデータもツリーに渡さないという特有な性質がある。
【0102】
別の例として、図18Aと図15の“ROUT”演算子を比較する。“ROUT”演算子には、領域(/L∩R)に関して、先頭の(右ブランチ)オブジェクトが部分的に透明であるか不透明であるかにかかわらずデータをツリーに渡し、共通領域(L∩R)では、後続の(左ブランチ)オブジェクトが部分的に透明である場合にのみデータをツリーに渡す特有の性質がある。前者の場合は、現在スキャンされた画素のグループに対してその左ブランチが非アクティブになり、右のブランチがアクティブになる場合にのみ発生する。後者の場合は、左右ブランチが現在スキャンされた画素のグループに対して共にアクティブであるときにだけ発生する。他方、“ROUT”演算子には、領域(L∩/R)に関して、下側(左ブランチ)のオブジェクトが部分的に透明であるかまたは不透明であるかにかかわらず、いかなるデータもツリーに渡さないという特有な性質がある。
【0103】
2項演算子のパフォーマンスとそのアクティビティの間には区別があることに注意すべきである。その両方のブランチがアクティブである場合にのみ、2項演算子は演算動作を実行する。さもなければ、演算子が要求する場合に、その結果は直接にアクティブなブランチから取得される。
【0104】
アクティビティ判断及び命令生成モジュール500は、2項演算子のアクティビティと、表現ツリーのブランチのアクティビティ、およびグラフィックオブジェクト(リーフノード)のアクティビティに基づいてツリーをなぞり、命令を生成する。
【0105】
これらの命令が生成される方法について、図20で示される例を参照して説明する。図20は、図19の表現ツリーにおいてオブジェクトCがアクティブである状態を示すとともに、アクティビティ判断及び命令生成モジュール500によって生成された、対応する命令リストを示す。モジュール500は、まず最初に、表現ツリーの演算子の前述した特有の性質を判断する。これらの性質は、モジュール500によって、検索と利用のために永久的(不揮発)に格納されている(不図示)。図20において示される例では、モジュール500は、記憶機構から“over”、“in”、および“out”演算子の2項演算子の性質を検索する。これらの性質は論理形式で格納されている。例えば、“over”演算子の性質は(/L∩R)=TRUEかつ(L∩/R)=TRUEとして格納される。すなわち、“over”演算子には、これらの領域に関してデータをツリーに渡す能力がある。別の例では、“in”演算子の性質は(/L∩R)=FALSEかつ(L∩/R)=FALSEとして格納される。すなわち、“in”演算子には、これらの領域に関して、ツリーにデータを渡す能力がない。更に別の例では、“out”演算子の性質は(/L∩R)=TRUEかつ(L∩/R)=FALSEとして格納される。以上の説明より明らかなように、領域(L∩R)の2項演算子の特有の性質はモジュール500のパフォーマンスに対して不要であり、メモリに格納されない。そのノードの2進演算は、左右ブランチがアクティブであるときにいつも実行されるからである。
【0106】
図20の例において、初期化処理段階の後、アクティビティ判断及び生成モジュール500は、スキャンされた画素位置の特定のグループのために、そのオブジェクトCがアクティブで、オブジェクトA、B、およびDが非アクティブであることを判断する。モジュール500はオブジェクトのアクティビティから、それぞれのバイナリノードのブランチのアクティビティを決定する。すなわち、アクティブなリーフノードオブジェクト(例えばオブジェクトC及びPAGE)をルートノード(例えば、13)に直接に結合させている全てのブランチがアクティブとなる。この説明において、アクティブな左ブランチはL Active=TRUEとして示され、非アクティブな左ブランチはL Active=FALSEとして示され、アクティブな右ブランチはR Active=TRUEとして示され、非アクティブな右ブランチはR Active=FALSEとして示される。図20の例において、モジュール500は以下のことを決定する。
【0107】
(i)バイナリノード13の左右ブランチはアクティブである(すなわち、L Active=TRUE、かつR Active=TRUE)、
(ii)バイナリノード12で 左ブランチは非アクティブであり、右ブランチはアクティブである(すなわち、L Active=FALSE、かつR Active=TRUE)、
(iii)バイナリノード11の左右ブランチは非アクティブである(すなわち、L Active=FALSE、かつR Active=FALSE)、
(iv)バイナリノード8で、左ブランチはアクティブであり、右ブランチは非アクティブである(すなわち、L Active=TRUE、かつR Active=FALSE)。
【0108】
この説明の目的のために、本明細書ではシンボル&&、||、及び!を、それぞれバイナリ論理演算子のAND、OR、NOTとして用いる。
【0109】
次に、アクティビティ判断及び命令生成モジュール500は、現在スキャンされた画素位置のグループについてなぞり、命令を生成する。それは2項演算子のアクティビティ、表現ツリーのブランチのアクティビティ、およびグラフィックオブジェクト(リーフノード)のアクティビティに基づいている。モジュール500は、上から下へ、左から右という方法で、ルートノード(例えば、ノード13)で始まる表現ツリーをなぞる。
【0110】
ここで、モジュール500は、以下の条件を満たす表現ツリーのブランチのみをなぞる。すなわち、
(1)先になぞられたバイナリノードに関して、(L active && R active)||((L∩/R)&& L active && !R active)==TRUEである場合は、先になぞられたバイナリノードの左ブランチの下方ノードへなぞる(トラバースする)。
(2)先になぞられたバイナリノードに関して、(L active && R active)||(/L∩R)&& !L active && R active)==TRUEの場合、先になぞられたバイナリノードの右ブランチの下方ノードへなぞる。
【0111】
このなぞり(トラバース)と同時間の間、アクティビティ判断及び命令生成モジュール500は、アクティブな左右ブランチを有するなぞられたバイナリノードのための演算子命令と、なぞられたあらゆるリーフノードのためのリーフ値命令を生成する。
【0112】
図20の例において、アクティビティ判断及び命令生成モジュール500は、ルートノード13からそのトラバースを開始する。ルートノード13の左右のブランチ両方がアクティブであるので、モジュール500は“over”演算子命令を生成する。同じ理由で、モジュール500は、バイナリノード12とバイナリノード0〜5をなぞる。モジュール500が上から下へ、左から右へという方式でなぞるので、最初にバイナリノード12がなぞられる。このバイナリノード12では、バイナリ12の左ブランチが非アクティブであるので、モジュール500は“over”演算を生成しない。同じ理由で、モジュール500は左ブランチであるバイナリノード11をなぞらない。しかしながら、バイナリノード12の右ブランチがアクティブであり、バイナリノード12の左ブランチが非アクティブであり、“over”演算子に関して(/L∩R)=TRUEであるので、モジュール500はバイナリのノード8をなぞる。このバイナリノード8では、その右ブランチが非アクティブであるため、モジュール500は“out”演算を生成しない。同じ理由で、モジュール500は右ブランチであるリーフノード6をなぞらない。しかしながら、バイナリノード8の左ブランチがアクティブであり、バイナリノード8の右ブランチが非アクティブであり、“out”演算子に関する(L∩/R)=TRUEが成立するので、モジュール500はリーフノード7をなぞる。リーフノード7では、モジュール500がリーフ値命令Cを生成する。次に、リーフノード0−5をなぞるために、モジュール500はルートノード13に戻る。リーフノード0−5では、モジュール500がリーフ値命令“PAGE”を生成する。図19と図20を比較すると、モジュール500が、スキャンされた画素位置のその現在のグループに対する表現ツリーに対応する最小量の命令セットを生成していることがわかる。そして、モジュール500は、次の隣接しているエッジの間のスキャンされた画素位置の次のグループのために動作を繰り返す。
【0113】
アクティビティ判断及び命令生成モジュール500の各部の動作について、図5を参照して更に詳細に説明する。
【0114】
上述したように、レベルアクティベーションテーブル生成部502はレベルアクティベーションテーブルを生成する。図21をみると、そのような生成されたレベルアクティベーションテーブルの例が示されている。この特定のLevel Activation Tableは図19で示される表現ツリーのリニアライズされた書式を表す。図21のレベルアクティベーションテーブルは、表現ツリーのそれぞれのノードに関するレコードを有する。これらのレコードは、それぞれ以下のフィールドを有する。“Index”、“L Active”、“R Active”、“(L∩/R)”、“(/L∩R)”、“Leaf/Operator Entry”、“Node Active”、“Parent”、“Node is L”、“Generate L”、“Generate R”、“(L∩R) op used”、および“R Branch Index”がある。“Index”、“(L∩/R)”、“(/L∩R)”、“Leaf/Operator Entry”、“Parent”、“Node is L”、および“R Branch Index”のフィールドの内容は、現在のスキャンされた画素位置に関する関数として変化するものではないので、静的である。一方、“L Active”、“R Active”、“Node Active”、“Generate L”、“Generate R”、および“(L∩R) op used”というフィールドの内容は、現在スキャンされた画素位置によって異なる可能性がある。後者のフィールドは、隣接しているエッジの間の画素位置の各グループのために、レベルアクティベーションテーブル更新モジュール504によってアップデートされる。
【0115】
“Index”フィールドは適切なレコードと関連するノードの数値ラベルを含んでいる。例えば、図19のノード12に対応するレコードは、その“Index”フィールドが12に設定される。“Parent”フィールドはレコードと関連するノードの親ノードの数値ラベルを含んでいる。例えば、図19のノード12に対応するレコードは「親」フィールドを12に設定させる。すなわち、ノード12の親ノードはノード13である。“R branch Index”フィールドはそのレコードに関連するノードの右ブランチにぶら下がるノードの数値ラベルを含んでいる。例えば、図19のノード12に対応するレコードは、8に設定された“R branch Index”フィールドを有する。すなわち、ノード12の右ブランチ上のノードはノード8である。“Node is L”フィールドは、レコードと関連する当該ノードが、その親ノードの左ブランチからぶら下がっているかどうかを示す論理フィールドである。例えば、ノード12に対応するレコードは、TRUE(1)にセットされた“Node is L”フィールドを有する。すなわち、ノード12は親ノード13の左ブランチを通して親ノード13にぶら下がっている。“Leaf/Operator Entry”フィールドは、そのレコードに関連するバイナリノードの2項演算子か、或いはリーフノードのオブジェクトを含んでいる。例えば、図19のバイナリノード12に対応するレコードは、合成演算子“over”にセットされた“Leaf/Operator Entry”フィールドを有する。また、別の例では、図19のリーフノード7に対応するレコードは、オブジェクト“C”がセットされた“Leaf/Operator Entry”フィールドを有する。このようにして、表現ツリーの構造を完全に再建することができる。
【0116】
“L Active”フィールドは、現在スキャンされている画素のグループに依存して、レコードに対応するバイナリノードの左ブランチがアクティブであるかどうかを示す論理フィールドである。同様に、“R Active”フィールドは、現在スキャンされている画素のグループに依存して、レコードに対応するバイナリノードの右ブランチがアクティブであるかどうかを示す論理フィールドである。初期化処理段階の間、スキャン中の画素は存在しないので、バイナリレコードのすべての“L Active”と“R Active”フィールドがFALSE(0)にセットされる。ただし、ルートノードの“R Active”フィールドには例外がある可能性がある。例えば、図19のルートノード13に対抗するレコードの“R Active”フィールドはTRUE(1)に設定される。ノード13の右ブランチが画素のスキャンの如何にかかわらずいつもアクティブだからである。なお、リーフノードはいかなるブランチも有さないので、対応するレコードにおける“L Active”と“R Active”フィールドを設定する必要がない。
【0117】
“(L∩/R)”フィールドは、この領域(L∩/R)からのデータが表現ツリーに渡される必要があるかどうかを示す論理フィールドである。同様に、“(/L∩R)”フィールドは、この領域(/L∩R)からのデータが表現ツリーに渡される必要があるかどうかを示す論理フィールドである。以上のように、これは合成演算子の固有の特性である。例えば、図19のノード12に対応するレコードは、“over”に設定された“Leaf/Operator Entry”を有する。また、(/L∩R)と(L∩/R)の領域の両方からのデータがツリーに渡される必要があるので、TRUE(1)に設定された関連するフィールド“(/L∩R)”と“(L∩/R)”を有する。別の例では、図19のノード11に対応するレコードは、“in”に設定された“Leaf/Operator Entry”を有する。また、領域(/L∩R)と(L∩/R)からのデータがツリーに渡される必要がないので、FALSE(0)に設定された関連するフィールド“(/L∩R)”と“(L∩/R)”を有する。これらのフィールドはバイナリノード(すなわち、合成演算)のみに関連するので、リーフノードに対応するレコードについてはこれらのフィールドを設定する必要はないことに注意されたい。
【0118】
以下の条件、
を満足する場合に、“Node Active”フィールドは、TRUE(1)に設定され、他の場合にはFALSE(0)に設定される。
【0119】
例えば、図19で示されるバイナリノード8、11、及び12の“Node Active”フィールドは、初期化処理段階の間、FALSE(0)に設定される。すべての対応するブランチ(L ActiveとR Active)が非アクティブ(すなわち、 FALSE)だからである。初期化処理段階の間、図19のバイナリノード13のための“Node Active”フィールドはTRUE(1)にセットされる。その右ブランチがアクティブであり(R Active=TRUE)、その左ブランチが非アクティブであり(L Active=FALSE)、その領域が演算子“over”の演算に必要であるからである。このフィールドがバイナリノード(すなわち、合成演算)だけに関連するので、リーフノードに対応するレコードのためのこれらフィールドを設定する必要がないことに注意すべきである。レコードの“Node Active”フィールドは、対応する2項演算子がアクティブであるかどうかを示す。
【0120】
を満たす場合にTRUE(1)に設定され、そうでない場合にFALSE(0)に設定される論理フィールドである。
【0121】
例えば、図19のすべてのバイナリノード13、12、11に関する“Generate L”フィールドは、初期化処理段階の間、FALSE(0)に設定される。この条件がこれらのノードのいずれによっても満たされないからである。すなわち、ノード8、11、12及び13の左ブランチがすべて非アクティブ、すなわちL Active = FALSE (0)である。また、このフィールドがバイナリノード(すなわち、合成演算)だけに関連するので、リーフノードに対応するレコードに対してこれらのフィールドを設定する必要ない。
【0122】
同様に、“Generate R”フィールドは、以下の条件、
が満たされるときにTRUE(1)に設定され、そうでない場合にはFALSE(0)に設定される論理フィールドである。
【0123】
例えば、初期化処理段階の間、上記条件が図19のバイナリノード12、11及び8のいずれによっても満たされないので、これらのノードに対する“Generate R”フィールドはFALSE(0)に設定される。例えば、ノード8、11及び12の右ブランチはすべて非アクティブ、すなわちR Active=FALSE(0)である。しかしながら、バイナリノード13の右のブランチがアクティブであるので、バイナリノード13の“Generate R”フィールドは初期化処理の間TRUE(1)にセットされ、左のブランチは非アクティブにセットされ、(/L∩R)=TRUEである。また、このフィールドがバイナリノードだけ(すなわち、合成演算)に関連するので、リーフノードに対応するレコードにおけるこれらのフィールドを設定する必要はないことに注意されたい。
【0124】
“(L∩R) op used”フィールドは、以下の条件、
(L active && Ractive)==TRUE
が満たされるときにTRUE(1)に設定され、他の場合にはFALSE(0)に設定される論理フィールドである。
【0125】
例えば、初期化処理段階の間、図19のバイナリノードの全ての左ブランチが非アクティブであるので、すべてのバイナリノードに対するこのフィールドはFALSE(0)に設定される。
【0126】
次に、図22を参照すると、レベルアクティベーションテーブルの前述のフィールド、“Node Active”、“Generate L”、“Generate R”、および“(L∩R) op used”を設定するための論理回路が示されている。この論理回路は従来形式の一連の論理ゲートで示されており、その動作は自明であるため、これ以上の説明を省略する。
【0127】
次に、図5に戻って、レベルアクティベーションテーブル生成モジュール502は初期化処理段階の間に作り出されるレベルアクティベーションテーブルをメモリ34に格納する。次に、更新モジュール504は、隣接しているエッジの間のスキャンされている画素位置の各グループに対するこの初期化されたレベルアクティベーションテーブルを取得して、そのテーブルのフィールドを更新する。更新モジュール504は、現在のスキャンされている画素位置のグループに依存して、フィールド“L Active”、“R Active”、“Node Active”、“Generate L”、“Generate R”、および“(L∩R) op used”の状態を変える。更新モジュール504は、所定の方法でレコードを更新する。その更新は、その画素位置においてアクティブなオブジェクトに対応するリーフノードの親ノードのレコードから始める。レコードにおける“Node Active”フィールドの状態を変えるときには、“Node is L”フィールドの状態に依存して、更新モジュール504は親ノードのレコードにおける“L active”或いは“R active”フィールドの状態における変更を引き起こす。そして、この新たに変えられた“L Active”或いは“R Active”フィールドに従って、更新モジュール504は親ノードのレコードの残りのフィールドを更新する。この更新プロセスは、“Node Active”フィールドが変わらずに残るところのレベルまで継続する。1つ以上のアクティブオブジェクトがあるとき、更新モジュールは一度に1つのアクティブオブジェクトについてテーブルをアップデートする。
【0128】
更新モジュール504の更新プロセスについて、図23を参照して説明する。
図23は、図20に示したオブジェクトCがアクティブである表現ツリーのための更新されたレベルアクティベーションテーブルを示す。更新モジュール504は、最初に、オブジェクトCがスキャンされた画素位置の現在のグループに対してアクティブであるかを判断し、次にメモリ34から初期化されたレベルアクティベーションテーブルを取得する。更新モジュール504は、リーフノードCのレコードの“Parent”フィールドから、アクティブオブジェクトCの親ノードを決定する。次に、更新モジュールは、以下の方法でテーブルのレコードを更新するべく処理を進める。これは、オブジェクトCの親ノードより開始される(レコード8)。
【0129】
−親ノード(レコード8)の“L Active”フィールドが設定される;
−これはレコード8における“Generate L”フィールドをアサートする;
−レコード8の“Node Active”フィールドが設定される;
−親ノード(レコード12)の“R active”フィールドが設定される;
−これはれコード12における“Generate R”フィールドをアサートする;
−レコード12の“Node Active”フィールドが設定される;
−親ノード(レコード13)の“L Active”フィールドが設定される;
−これはレコード13における“Generate L”と“L∩R op used”フィールドをアサートする;
−レコード13における“Node Active”フィールドが既に設定されているので、処理を止める。
【0130】
この時点で、テーブルは命令生成のための正しい状態となる。
【0131】
図5に戻り、更新モジュール504は現在スキャンされている画素位置のグループのための、この更新されたレベルアクティベーションテーブルをメモリ34に格納する。そして、このメモリ34より、トラバーサル及び命令生成モジュール506によって、更新されたレベルアクティベーションテーブルが取得される。トラバーサル及び命令生成モジュール506はスタックマシンベースのロボットであり、表現ツリーをトップダウン型でなぞり、更新されたレベルアクティベーションテーブルに従って命令を生成する。スタックは、レコードの“R branch Index”を格納するのに使用される。以下の中間コードに従って、スタックマシンは以下の動作を実行する。
【0132】
【0133】
命令モジュール506のトラバースと命令生成プロセスについて、図23を参照して説明する。図23は、オブジェクトCがアクティブである図20の表現ツリーのための更新されたレベルアクティベーションテーブルを示す。上記の中間コードと図23のレベルアクティベーションテーブルとに従った命令の生成は以下のように進行する。
【0134】
(i)処理はレコード13(ルートノード)より開始する;
(ii)レコード13の“L∩R op used”フィールドがTRUE(1) なので、“over”命令が命令リストに加えられる;
(iii) レコード13の“Generate R”フィールドがTRUE(1)なので、レコード13の“R Branch Index”の内容がスタックに加えられる。その結果、スタックはインデックス(5)を格納する;
(iv)レコード13の“Generate L”フィールドがTRUE(1)であるので、処理はレコード12に進む;
(v)レコード12の“L∩R op used”フィールドがFALSE(0)であるので、いかなる命令も加えられない;
(vi) レコード12の“Generate R”フィールドがTRUE(1)であるので、レコード12の“R Branch Index”の内容がスタックに加えられる。その結果、スタックは、その時点で、インデックス(8,5)を格納する;
(vii) レコード12の“Generate L”フィールドがFALSE(0)であり、その結果、処理は抜け落ちる;
(viii) スタックが空ではないので、インデックス8がスタックからポップされて、処理はインデックス8に対応するレコードへ移動する。その結果、この時点で、スタックはインデックス(5)を格納することになる;
(ix)レコード8の“L∩R op used”フィールドがFALSE(0)であるので、どんな命令も加えられない;
(x) レコード8の“Generate R”フィールドがFALSE(0)であるので、スタックに何も加えられない。その結果、スタックは、この時点でインデックス(5)を格納する;
(xi)レコード8のフィールド“Generate L”がTRUE(1)であるので、処理は次のエントリ、すなわちレコード7に移動する;
(xii)レコード7がリーフであるので、リーフ値命令がリストに加えられて、処理は抜け落ちる;
(xiii)スタックが空でないので、インデックス5がスタックからポップされて、処理はインデックス5へ移動する。スタックはこの時点で空になる。
このプロセスは完了へと続く。
【0135】
この例において生成された命令が図20に示される。
【0136】
このようにして、トラバーサル及び命令生成モジュール506は、あらゆる1つ以上のアクティブオブジェクトのために、表現ツリーの描画に必要な命令の最小限のセットを生成することができる。これらの命令は、次に、色塗潰し決定モジュール600に渡される。
【0137】
アクティビティ判断及び命令生成モジュール500の別の実施形態において、モジュールは、不透明物体がオーバラッピング領域でもう片方のオブジェクトを見えなくするかもしれないという事実を考慮に入れる。実際に、ノードのブランチの一方は、他方によって隠され得る。両方のオブジェクトがアクティブである場合に、オブジェクトが不透明物体によって隠されるならば、そのオブジェクトを生成する必要はない。これらの余分な処理が実行されるのを防ぐために、レベルアクティベーションテーブルを変更することができる。
【0138】
次に図25を参照すると、そのような改造されたレベルアクティベーションテーブルの例が示されている。このテーブルは、2つのフィールド“L obscures R(LはRを隠す)”と“R obscures L(RはLを隠す)”が加わっているという点を除いて、図21のレベルアクティベーションテーブルと同じ構造である。“LはRを隠す”フィールドは論理フィールドであり、左右両方のオブジェクトがアクティブであるときに、左のオブジェクトが右のオブジェクトを隠すかどうかを示す。同様に、フィールド“RはLを隠す”も論理フィールドであり、左右両方のオブジェクトがアクティブであるときに、右のオブジェクトが左のオブジェクトを隠すかどうかを示す。“Generate R”、“L∩R op used”及び“Generate L”フィールドに含まれるデータも、図21のれベルアクティベーションテーブルとは異なる論理に基づく。obscuranceフラグは不透明なオブジェクトと透明なオブジェクトを含む表現ツリーで非常に役に立つ。
【0139】
図24には、改造されたレベルアクティベーションテーブルのフィールド、“Node Active”、“Gnerate L”、“Generate R”、および“(L∩R) op used”を設定するための論理回路が示される。図22に対して“Node Active”の論理が変化しており、その時点のデータがノードによって生成されたかどうかに基づいていることがわかる。回路のクリティカルパスは長いが、これは、同じ論理を使用して実行されるオブジェクトのクリッピングを可能とする。obscuranceフィールドの両方がセットされるならば、どんなデータも論理積領域において生成されない(これは、CLIP OUTの実現の一部である)。
【0140】
これらのobscuranceフィールドは、図25のLevel Activation Tableに示されるように、CLIP IN動作とCLIP OUT動作を実現するのに用いられてもよい。CLIP INとCLIP OUT動作のためのフィールド設定は図25のTableに示されている。
【0141】
CLIP IN動作と単純なin動作との間の違いは、右ブランチ動作が決して実行されないということである。図26に示されるIN動作の真理値表と図27に示されるCLIP IN動作の真理値表との比較からこれを見ることができる。これらの真理値表では、Tは透明(非アクティブ)を表し、Oは不透明を表す。そして、LとRはそれぞれLの不透明が未知であること、Rの不透明が未知であることを表す。違いのあるボックスは強調表示されている。CLIP INの場合では、右オブジェクトの使用開始が左オブジェクトのための命令の生成を可能にするので、左のオブジェクトは切り取られるエッジである。なお、右オブジェクトは任意の多くのオブジェクトの合成であってもよい。この合成には、必要に応じたいかなる組合せ、異なる充てんルールも使用してよい。右オブジェクトのアクティビティ状態は、全てCLIP IN動作によって使用される。従前のシステムでは、切取りオブジェクトは別々の単一レベルから成る。それは、アクティベートされるかまたはディアクティベートされるときに、クリップが適用されるすべてのレベルに対するカウンタに作用した。本構成においては、クリップオブジェクトは特殊なものとして全体図オブジェクトの特殊ケースとして現れ、表現ツリーのノードとして現れる。そして、その結果、あらゆるレベルでカウンタを増加するかまたは減少させる必要性なく、アクティブ化或いは非アクティブ化がクリップを適用する。
【0142】
CLIP OUT動作と単純なout動作との間の違いは、図28に示されるOUT動作の真理値表と図29に示されるCLIP IN動作に関する真理値表との比較から見ることができる。ここでも、Tは透明(非アクティブ)を表し、Oは不透明を表し、LとRは、それぞれLの不透明が未知であること、Rの不透明が未知であることを表す。また、違いの生じているボックスが強調表示されている。CLIP OUTの場合では、右オブジェクトのアクティブ化が左オブジェクトのための命令の生成を防ぐので、左オブジェクトは切り取られるエッジである。CLIP INに関しては、右オブジェクトは必要に応じた異なった充てんルールを有する、オブジェクトの任意の複雑なコレクションとなるかもしれない。クリッピングに使用されるのは、アクティビティの状態だけである。
【0143】
上述したアクティビティ判断及び命令生成モジュール500は、表現ツリーに基づく。しかしながら、モジュール500の本質はDAGs(有向隣接図表:Directed Adjacency Graphs)に一般化され得る。これは、レベルアクティベーションテーブルのレコードの親ノードフィールドが、その親ノードへのテーブルエントリのリストを含むことを許容し、Lインデックスポインタを提供することによって、モジュール500の更なる実施形態によって達成され得る。ノードの状態の変更は、その親ノードのすべてが変更されることを要求し、命令の生成は、単に次のテーブルエントリを探すのではなく、Lインデックスに従うために必要となる。DAGsは、クリッピングオブジェクトとの使用に関して有用である。そこでは、複数のオブジェクトが同じオブジェクトによってクリップされる。
【0144】
更に別の実施形態は、開始ノード、すなわち、演算或いはデータを提供する最初のノード、がその左ブランチからのデータをレンダリングされたページ上に合成するということに基づく。これは、左ブランチをレンダリングされたページと合成するノードを特定するレベルアクティベーションテーブルに“Page”フィールドを加えることによって特定され得る(R is PAGE)。そのページにデータを置いているアクティブなノードを特定するためのテーブルエントリデータを1ビットで提供するために、この“Page”フィールドと“Generate L”フィールドとをANDしてもよい。開始ノードはこれらのうちの最優先ノードであり、命令生成のために、サーチされ得る。これはツリーの幹にある、動作を提供しないノードに関してツリーをなぞることによるオーバヘッドを排除する。
【0145】
次に、図30をみると、レンダリングされたページにそれらの左ブランチを合成するノードを示す模式的な表現ツリー300が示されている。わかるように、ノード302、304、306、および308はそれらの左ブランチがレンダリングされたブランチ上に合成され、これらのノードの各々の“Page”フィールドがTRUE(1)にセットされる。この“Page”フィールドは同じノードの“Generate L”フィールドとのANDであってもよい。ここで、Generate L”フィールドは、ページにデータを置くそれらのアクティブなノードを確認する。表現ツリーの例において、ノード302、306、および308はアクティブであって、ノード304は非アクティブである。したがって、必要な命令を生成するために、アクティブなノード302、306、および308のそれらのサブツリーだけがなぞられる必要がある。こうして、ツリーのトラバーサルを最小にする、
以上、好適な実施形態としてアクティビティ判断及び命令生成モジュール500を集積回路として説明したが、ホストプロセッサ2等のような汎用処理ユニット上で実行可能な等価なソフトウエアモジュールとして実現されてもよい。ソフトウェアモジュールはディスク装置やコンピュータネットワークなどのようなコンピュータ可読媒体を介してユーザに配られ得るコンピュータプログラム製品の一部を形成してもよい。
【0146】
4.0 塗潰し色決定モジュール
塗潰し色決定モジュール600の動作を、図6を参照して、以下に説明する。
アクティビティ判断及び命令生成モジュール500からの着信メッセージ598は、塗潰しデータ設定メッセージ、反復メッセージ、塗潰し優先順位メッセージ、画素の終りメッセージおよびスキャンラインの終りメッセージを含み、まず、塗潰しルックアップ及び制御モジュール604に渡される。塗潰しルックアップ及び制御モジュール604は、塗潰し色決定モジュール600のさまざまな構成要素による使用のために、現行X位置カウンタ614および現行Y位置カウンタ616を維持する。
【0147】
スキャンラインの終りメッセージを受け取った時には、塗潰しルックアップ及び制御モジュール604は、現行X位置カウンタ614を0にリセットし、現行Y位置カウンタ616をインクリメントする。スキャンラインの終りメッセージは、その後、画素合成モジュール700に渡される。
【0148】
塗潰しデータ設定メッセージを受け取ったときには、塗潰しルックアップ及び制御モジュール604は、塗潰しデータテーブル36の指定された位置602にそのデータを記憶する。
【0149】
反復メッセージを受け取ったときには、塗潰しルックアップおよび制御モジュール604は、反復メッセージからのカウントだけ現行X位置カウンタ614をインクリメントする。反復メッセージは、その後、画素合成モジュール700に渡される。
【0150】
画素の終りメッセージを受け取ったときには、塗潰しルックアップ及び制御モジュール604は、やはり現行X位置カウンタ614をインクリメントし、この画素の終りメッセージは、その後、画素合成モジュール700に渡される。
【0151】
塗潰し優先順位メッセージを受け取ったときには、塗潰しルックアップ及び制御モジュール604は、下記の処理を含む動作を実行する。
【0152】
(i)塗潰し優先順位メッセージからの塗潰しタイプを使用して、テーブル36のレコードサイズを選択する、
(ii)塗潰し優先順位メッセージからの塗潰しテーブルアドレスと、上で決定されたレコードサイズを使用して、塗潰しデータテーブル36からレコードを選択する、
(iii)塗潰し優先順位メッセージからの塗潰しタイプを使用して、塗潰し色の生成を実行するサブモジュールを決定し、選択する。サブモジュールには、ラスタイメージモジュール606、フラットカラーモジュール608、リニアランプカラーモジュール610および不透明タイルモジュール612を含めることができる、
(iv)決定されたレコードを、選択されたサブモジュール606乃至612に供給する、
(v)選択されたサブモジュール606乃至612が、供給されたデータを使用して、色と不透明度の値を決定する。
【0153】
(vi)決定された色と不透明度は、塗潰し色メッセージからの残りの情報、すなわち、ラスタ演算コード、アルファチャネル演算コード、ソースポップフラグおよびデスティネーションポップフラグと組み合わされて、色合成メッセージを形成し、この色合成メッセージは、接続698を介して画素合成モジュール700に送られる。
【0154】
好ましい実施形態では、決定された色と不透明度が、8ビットの精度の赤、緑、青および不透明度の4つの組であり、通常の形で32ビット/画素が与えられる。しかし、シアン、マゼンタ、黄および黒の、不透明度を含有する4つの組か、他の多数の既知の色表現のうちの1つを、その代わりに使用することができる。以下では、赤、緑、青および不透明度の場合を説明するが、この説明は、他の場合にも適用することができる。
【0155】
ラスタ画像モジュール606、フラットカラーモジュール608、リニアランプカラーモジュール610および不透明タイルモジュール612の動作を以下に説明する。
【0156】
フラットカラーモジュール608は、供給されたレコードを、3つの8ビットの色成分(通常は赤、緑および青の成分と解釈される)と1つの8ビットの不透明度値(通常は、指定された色によって覆われる画素の割合の尺度と解釈され、0は覆われないすなわち完全な透明を意味し、255は完全に覆われるすなわち完全な不透明を意味する)を含む固定フォーマットのレコードと解釈する。この色と不透明度の値は、接続698を介して直接に出力され、それ以上の処理なしで、決定された色および不透明度を形成する。
【0157】
リニアランプカラーモジュール610は、供給されたレコードを、3つの色成分および1つの不透明度成分に関連する4組の定数cx、cyおよびdと、リニアランプの基準点の座標である2つの位置値xbaseおよびybaseを含む固定フォーマットのレコードと解釈する。基準点では、色成分と不透明度成分が、それに関連付けられたd値を有する。
【0158】
4組のそれぞれについて、結果の値rは、次式を使用して、現在のXY座標とxbaseおよびybase定数に3つの定数を組み合わせることによって計算される。すなわち、
のように定義される。
【0159】
代替の実装では、リニアランプカラーモジュール610は、供給されたレコードを、3つの色成分および1つの不透明度成分に関連する、4組の3つの定数cx、cyおよびdを含む固定フォーマットのレコードと解釈する。これらの4組のそれぞれについて、結果の値rは、次式を使用して、3つの定数を現行Xカウントであるxおよび現行Yカウントであるyと組み合わせることによって、
r=clamp(cx×x+cy×y+d)
により計算される。ここで、関数clampは、上で定義されたものである。
【0160】
以上のように生成された4つの結果は、色と不透明度の値に形成される。この色と不透明度の値は、接続698を介して直接に出力され、それ以上の処理なしで決定された色および不透明度を形成する。
【0161】
同一の結果を与える他の算術計算を使用することができる。
【0162】
不透明タイルモジュール612は、供給されたレコードを、3つの8ビット色成分、1つの8ビット不透明度値、整数のX位相(px)、Y位相(py)、Xスケール(sx)、Yスケール(sy)および64ビットのマスクを含む固定フォーマットのレコードと解釈する。これらの値は、表示リスト生成から発し、通常は、元のページ記述に含まれる。ビットマスク内のビットアドレスaは、以下の式、
a=((x/2sx+px)mod 8)+((y/2sy+py)mod 8)×8
で決定される。
【0163】
ビットマスク内のアドレス「a」のビットが検査される。検査されるビットが1の場合には、レコードからの色と不透明度が、モジュール612の出力に直接にコピーされ、決定された色および不透明度を形成する。検査されるビットが0の場合には、3つの0成分値を有する色と0の不透明度値が形成され、決定された色および不透明度として出力される。
【0164】
ラスタ画像モジュール606は、供給されたレコードを、6つの定数a、b、c、d、xbaseおよびybaseと、サンプリングされるラスタ画像画素データ16の各ラスタライン内のビット数の整数カウント(bpl)と、画素タイプとを含む固定フォーマットのレコードと解釈する。画素タイプは、ラスタ画像画素データ内の画素データ16を、次のうちのどれとして解釈するかを示す。
【0165】
(i)1ビット毎画素の白黒不透明画素
(ii)1ビット毎画素の不透明黒または透明の画素
(iii)8ビット毎画素のグレイスケール不透明画素
(iv)8ビット毎画素の黒不透明スケール画素
(v)24ビット毎画素の不透明3色成分画素
(vi)32ビット毎画素の3色成分と不透明度の画素
他の多くのフォーマットが可能である。
【0166】
ラスタ画像モジュール606は、画素タイプインジケータを使用して、ビット単位の画素サイズ(bpp)を決定する。その後、ラスタ画像画素データ16内のビットアドレスaを、以下の式、
から計算する。
【0167】
レコード602からの画素タイプに従って解釈された画素は、ラスタ画像画素データ16内の計算されたアドレス「a」から取り出される。この画素は、3つの8ビット色成分と1つの8ビット不透明度成分を有するために、必要に応じて展開される。「展開」とは、たとえば、8ビット/画素のグレイスケール不透明ラスタ画像からの画素が、赤、緑および青の成分のそれぞれに適用されるサンプリングされた8ビット値と、完全な不透明がセットされた不透明度成分を持つことを意味する。これが、画素合成モジュール700への決定された色および不透明度の出力698を形成する。
【0168】
その結果、表示可能オブジェクト内で有効なラスタ画素データは、メモリ内の画像画素データ16へのマッピングの決定を介して得られる。これによって、ラスタ画素データのオブジェクトベース画像へのアフィン変換が効率的に実施され、これは、グラフィックオブジェクトとの合成が発生する可能性がある場合に画像ソースからの画素データをフレームストアに転送する従来技術の方法より効率的である。
【0169】
上記に対する好ましい特徴として、任意選択として、ラスタ画像画素データ16内の画素間の補間を、まず中間結果pおよびqを以下の式、
p=a×(x-xbase)+c×(y-ybase)
q=b×(x-xbase)+d×(y-ybase)
に従って計算することによって実行することができる。
【0170】
次に、ラスタ画像画素データ16内の4画素のビットアドレスa00、a01、a10およびa11を、以下の式、
a00=bpp×└p┘+bpl×└q┘
a01=a00+bpp
a10=a00+bpl
a11=a00+bpl+bpp
に従って決定する。
【0171】
次に、各色成分および不透明度成分のそれぞれについて、結果の画素成分値rを、以下の式
r=interp(interp(get(a00),get(a01),p),interp(get(a10),get(a11),p),q)
に従って、決定する。
ここで、関数interpは、
interp(a,b,c)=a+(b-a)×(c-└c┘)
のように定義される。
【0172】
上の諸式で、表現└値┘=floor(値)であり、floor演算では、値の端数部分の切捨が行われる。
【0173】
get関数は、所与のビットアドレスでの、ラスタ画像画素データ16からサンプリングされた現行画素成分の値を返す。いくつかの画像タイプのいくつかの成分について、これが暗黙の値になる可能性があることに留意されたい。
【0174】
上記に対する好ましい特徴として、任意選択として、供給されたレコードから読み取られるタイルサイズを用いる剰余演算によって現行X位置カウンタ614および現行Y位置カウンタ616から導出されるxおよびyの値を上式で使用することによって、画像タイリングを実行することができる。
【0175】
多数の他のこのような塗潰し色生成サブモジュールが可能である。
【0176】
5.0 画素合成モジュール
以下に、画素合成モジュール700の動作を説明する。塗潰し色決定モジュール600からの着信メッセージには、反復メッセージ、色合成メッセージ、画素の終りメッセージおよびスキャンラインの終りメッセージが含まれるが、このメッセージは、順番に処理される。
【0177】
反復メッセージまたはスキャンラインの終りメッセージを受け取った時には、画素合成モジュール700は、それ以上の処理なしで画素出力FIFO702にそのメッセージを転送する。
【0178】
色合成メッセージを受け取った場合の画素合成モジュール700の動作概要を示せば、色合成メッセージからの色と不透明度を、色合成メッセージからのラスタ演算およびアルファチャネル演算に従って、画素合成スタック38からポップされた色および不透明度と組み合わせる。その後、結果を画素合成スタック38にプッシュする。色合成メッセージの受取り時に実行される処理の説明は以下でなされる。
【0179】
画素の終りメッセージを受け取った時には、画素合成モジュール700は、画素合成スタック38から色と不透明度をポップする。ただし、スタック38が空の場合には不透明の白の値が使用される。結果の色と不透明度は、画素出力FIFOに転送される画素出力メッセージに形成される。
【0180】
既知の合成アプローチは、ポーター(Porter,T)およびダフ(Duff,T)著「Compositing Digital Images」、Computer Graphics誌、Vol.18 No.3、1984年、第253〜259ページに記載されている。ポーター−ダフ合成演算の例を、図15に示す。しかし、このようなアプローチでは、合成によって形成される交差領域内のソースおよびデスティネーションの色の処理だけが可能であり、その結果、交差領域内の透明度の影響には適合できないという点で不完全である。その結果、ポーターおよびダフによって定義されたラスタ演算は、透明度の存在下で基本的に動作不能である。
【0181】
色合成メッセージを受け取った時に画素合成モジュール700によって実行される処理を以下に説明する。
【0182】
色合成メッセージを受け取った際に、画素合成モジュール700は、まず、ソースの色と不透明度を形成する。これは、色合成メッセージでポップソースフラグがセットされていない限り、色合成メッセージで供給された色と不透明度が使用され、ポップソースフラグがセットされている場合には、その代わりに画素合成スタック38から色がポップされる。この場合、すなわち、画素合成スタックのポップ中に画素合成スタック38が空であることがわかった場合、エラー表示なしで不透明の白の色値が使用される。次に、デスティネーションの色と不透明度が、画素合成スタック38からポップされる。ただし、色合成メッセージでデスティネーションポップフラグがセットされていない場合には、スタックポインタが「ポップ」動作中に変更されず、その結果スタック38の最上部からの読み取りになる。
【0183】
ソースの色および不透明度をデスティネーションの色および不透明度と組み合わせる方法を、図7Aないし図7Cを参照して以下に説明する。色および不透明度の値は、通常は0から255までの範囲の8ビット値として記憶されるが、ここでは説明の目的のために、0から1までの範囲(すなわち正規化されている)とみなす。2画素を合成する目的のために、各画素が2つの領域、すなわち、完全に不透明な領域と完全に透明な領域に分割されるものとみなし、不透明度値は、これら2つの領域の比率の表示であるとみなされる。図7Aに、図示されない3成分色値と、不透明度値(so)を有するソース画素702を示す。ソース画素702の影付きの領域は、画素702の完全に不透明な部分704を表す。同様に、図7Aの影付きでない領域は、ソース画素702のうちで、完全に透明であるとみなされる部分706を表す。図7Bに、ある不透明度値(do)を有するデスティネーション画素710を示す。デスティネーション画素710の影付きの領域は、画素710の完全に不透明な部分712を表す。同様に、画素710は、完全に透明な部分714を有する。ソース画素702およびデスティネーション画素710の不透明領域は、組合せのために、互いに直交するとみなされる。これら2つの画素のオーバーレイ716を、図7Cに示す。対象の3つの領域が存在し、これには、so×(1-do)の面積を有するデスティネーション外ソース718、面積so×doを有するソースデスティネーション交差720および、(1-so)×doの面積を有するソース外デスティネーション722が含まれる。これら3つの領域のそれぞれの色値は、概念上は独立に計算される。デスティネーション外ソース領域718は、その色をソース色から直接にとる。ソース外デスティネーション領域722は、その色をデスティネーション色から直接にとる。ソースデスティネーション交差領域720では、その色をソース色とデスティネーション色の組合せからとる。上で説明した他の動作とは別個の、ソース色とデスティネーション色の組合せの処理は、ラスタ演算と称され、これは、画素合成メッセージからのラスタ演算コードによって指定される、1組の関数のうちの1つである。好ましい実施形態に含まれるラスタ演算の一部を、図17に示す。
【0184】
各関数は、ソース色およびデスティネーション色の対応する色成分の対のそれぞれに適用されて、結果の色において同様の成分が得られる。多くの他の関数が可能である。
【0185】
画素合成メッセージからのアルファチャネル演算も考慮されている。アルファチャネル演算は、3つのフラグを使用して実行され、フラグのそれぞれは、ソース画素702とデスティネーション画素710のオーバーレイ716内の対象の領域のうちの1つに対応する。領域のそれぞれについて、領域の不透明度値が形成され、この不透明度値は、アルファチャネル演算で対応するフラグがセットされていない場合には0、それ以外の場合にはその領域の面積である。
【0186】
結果の不透明度は、領域の不透明度の合計から形成される。結果の色の各成分は、領域の色と領域の不透明度の対のそれぞれの積の和を結果の不透明度で除算することによって形成される。
【0187】
結果の色および不透明度は、画素合成スタック38にプッシュされる。
【0188】
6.0 画素出力モジュール
画素出力モジュール800の動作を以下に説明する。着信メッセージは、画素出力FIFOから読み取られ、これには、画素出力メッセージ、反復メッセージおよびスキャンラインの終りメッセージが含まれ、順番に処理される。
【0189】
画素出力メッセージを受け取った時に、画素出力モジュール800は、画素を記憶し、その画素をその出力に転送する。反復メッセージを受け取った時には、最後に記憶した画素が、反復メッセージからのカウントによって指定される回数だけ、出力898に転送される。スキャンラインの終りメッセージを受け取った時には、画素出力モジュール800は、そのメッセージをその出力に渡す。
【0190】
出力898は、必要に応じて、画素画像データを使用する装置に接続することができる。このような装置には、ビデオ表示ユニットまたはプリンタなどの出力装置、または、ハードディスク、ラインストア、バンドストアまたはフレームストアを含む半導体RAMなどのメモリ記憶装置、または、コンピュータネットワークが含まれる。
【0191】
多数のレベルにわたるオブジェクトの合成も、本明細書に記載の方法の外挿によって可能であることを、当業者は了解するであろう。さらに、示されたさまざまな操作を、フレームストアベースシステムおよび他のスタックベース、ラインベースまたはバンドベースの合成システムを含む異なる合成パラダイムで使用することができることも諒解されるであろう。
【0192】
前述から、本明細書に記載の方法および装置が、レンダリング処理中の画素画像データの中間記憶を必要とせずに、洗練されたグラフィック記述言語が必要とする機能性のすべてを備えたグラフィックオブジェクトのレンダリングを提供することは、明白であろう。
【0193】
産業上の利用性
本発明の実施形態がコンピュータグラフィックス及び印刷産業に適用可能であることが上述の説明より明らかである。
【0194】
前述は、本発明の一つの或いはいくつかの実施形態を記述したのみであり、それらは説明のために用いられるもので限定的なものではなく、それらに対して本発明の趣旨および範囲を逸脱せずに改造及び変更を行なうことができる。
【図面の簡単な説明】
【図1】好ましい実施形態を組み込まれるコンピュータシステムの概略ブロック図である。
【図2】好ましい実施形態の機能データフローを示すブロック図である。
【図3】好ましい実施形態の画素シーケンシャルレンダリング装置と、関連する表示リストおよび一時ストアの概略ブロック図である。
【図4】図2のエッジ処理モジュールの概略機能図である。
【図5】図2の優先順位決定モジュールの概略機能図である。
【図6】図2の塗潰しデータ決定モジュールの概略機能図である。
【図7】ソースとデスティネーションの間の画素の組合せを示す図である。
【図8】好ましい実施形態の演算を説明するための例として使用される、オブジェクトが2つある画像を示す図である。
【図9】図8のオブジェクトのベクトルエッジを示す図である。
【図10】図8の画像の複数のスキャンラインのレンダリングを示す図である。
【図11】図8の画像のエッジレコードの配置を示す図である。
【図12A】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12B】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12C】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12D】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12E】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12F】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12G】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12H】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12I】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図12J】図10の例のために図4の配置によって実施されるエッジ更新ルーチンを示す図である。
【図13A】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図13B】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図13C】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図13D】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図13E】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図14】2つの従来技術のエッジ記述フォーマットと、好ましい実施形態で使用されるエッジ記述フォーマットを比較するための図である。
【図15】いくつかの合成演算の結果を示す図である。
【図16】図2のエッジレコード格納部における格納のための、エッジレコードの模式的なテーブルを示す図である。
【図17】好適な実施形態において用いられるラスタ演算子のいくつかに関するテーブルを示す図である。
【図18】エクスプレッションツリーとして示される単純な合成式と対応する図を示す図である。
【図19】オブジェクトA,B,C及びD、及び対応する命令リストに関して、一連のPorterとDuffの合成操作を実現するための典型的な表現ツリーを示す図である。
【図20】オブジェクトCが有効な場合の図19の表現ツリーと対応する命令リストを示す図である。
【図21】図5に示したレベルアクティベーションテーブル生成部によって生成される、図20の表現ツリーに関するレベルアクティベーションテーブルを示す図である。
【図22】図5に示したレベルアクティベーションテーブルの更新モジュールにおいて使用される論理回路を示す図である。
【図23】オブジェクトCが有効である、図20の表現ツリーのための更新されたレベルアクティベーションテーブルを示す図である。
【図24】図5に示したレベルアクティベーションテーブルの更新モジュールにおいて使用される論理回路の別の具体例を示す図である。
【図25】図24の更なる実施形態と共に用いるためのレベルアクティベーションテーブルを示す図である。
【図26】IN合成操作のための真理値表を示す図である。
【図27】CLIP IN合成操作のための真理値表を示す図である。
【図28】OUT合成操作のための真理値表を示す図である。
【図29】CLIP OUT合成操作のための真理値表を示す図である。
【図30】左側のブランチを描画されたページに合成するノードを支援す表現ツリーの典型的な例を示す図である。
Claims (5)
- 表現ツリーを生成する装置であって、前記表現ツリーは、1つ以上のバイナリノードと複数のリーフノードを有する複数のノードを有し、ここで、それぞれの前記バイナリノードはそれにぶらさがる左ブランチと右ブランチとを有して該2つのぶらさがるノードへの2進演算を表し、それぞれの前記ノードは、1個以上のグラフィックオブジェクトが重なったグラフィックオブジェクトを表し、前記グラフィックオブジェクトの重なりの各々が、左ノード領域、共通領域、および右ノード領域を含み、前記装置が、
1つ以上の画素位置のグループを決定する手段と、
それぞれの前記グループについて、前記1つ以上のバイナリノードの左右のブランチが、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの中にあるならばアクティブであると判断し、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの外にあるならば非アクティブであると判断する手段と、
それぞれの前記グループについて、前記表現ツリーをなぞる手段と、ここで、なぞられたバイナリノードの左右ブランチがアクティブである場合、或いは、前記左ノード領域が前記なぞられたバイナリノードの2進演算に必要であり、前記なぞられたバイナリノードの左ブランチがアクティブで右ブランチが非アクティブである場合に、前記なぞられたバイナリノードの左ブランチにぶらさがるノードへなぞられ、また、前記なぞられたバイナリノードの左右ブランチがアクティブである場合、或いは、前記右ノード領域が前記なぞられたバイナリノードの2進演算に必要であり、前記なぞられたバイナリノードの右ブランチがアクティブであり、左ブランチが非アクティブである場合に、前記なぞられたバイナリノードの右ブランチにぶらさがるノードへなぞられ、
それぞれの前記グループのために、前記アクティブな左右ブランチを有する前記なぞられたバイナリノードのための演算子命令、およびなぞられたリーフノードのためのリーフ値命令を生成する手段とを備えることを特徴とする装置。 - 前記なぞる手段は表現ツリーをなぞり、前記なぞられたバイナリノードの左右ブランチがアクティブであり、前記なぞられたバイナリノードの右ブランチの下方ノードを表すグラフィックオブジェクトが、前記なぞられたバイナリノードの下方ノードの共通領域において、前記なぞられたバイナリノードの前記左ブランチの下方ノードを表すグラフィックオブジェクトを隠さない場合、前記なぞられたバイナリノードの左ブランチの下方ノードへとなぞられ、また、なぞられたバイナリノードの左右ブランチがアクティブであり、前記なぞられたバイナリノードの前記左ブランチの下方ノードを表すグラフィックオブジェクトが、前記なぞられたバイナリノードの下方ノードを表すグラフィックオブジェクトの共通領域において、前記なぞられたバイナリノードの右ブランチの下方ノードを表すグラフィックオブジェクトを隠さない場合、前記なぞられたバイナリノードの右ブランチの下方ノードへなぞられることを特徴とする請求項1に記載の装置。
- 表現ツリーから、複数の走査線と各走査線に複数の画素位置を有するラスタ画素イメージを描画する装置であって、前記表現ツリーは1つ以上のバイナリノードと複数のリーフノードとを備える複数のノードを有し、ここで前記バイナリノードの各々は下方ノードを有する左ブランチと下方ノードを有する右ブランチを有するとともに2つの前記下方ノードに対する2進演算を表わし、また前記リーフノードの各々は1つ以上のグラフィックオブジェクトが重なったグラフィックオブジェクトを表し、重なっているグラフィックオブジェクトの各々は左ノード領域、共通領域、および右ノード領域を含み、
前記表現ツリーを表すテーブルを生成する手段と、ここで前記テーブルは関連するバイナリノードとリーフノードに対応する複数のレコードを含み、そして、前記関連するバイナリノードのそれぞれの前記レコードは、前記左ノード領域が前記関連するバイナリノードに関連する演算子の動作に必要であるかどうかを示す第1フィールドと、右ノード領域が前記関連するバイナリノードに関連する演算子の動作に必要であるかどうかを示す第2フィールドと、前記関連するバイナリノードの左ブランチがアクティブであるかどうかを示す第3フィールドと、前記関連するバイナリノードの右ブランチがアクティブかどうかを示す第4フィールドとを備え、
1つ以上の画素位置のグループを決定する手段と、
前記グループの各々に関して、前記1つ以上のバイナリノードの左右のブランチが、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの中にあるならばアクティブであると判断し、現在スキャンされている画素がブランチに対応するグラフィックオブジェクトに適用される境界エッジの外にあるならば非アクティブであると判断する手段と、
前記グループの各々に関して、前記判断されたアクティブ及び非アクティブのブランチのために、前記テーブルの前記第3及び第4フィールドを更新する手段と、
それぞれの前記グループに関して、前記更新されたテーブルに従って、前記表現ツリーをなぞる手段と、ここで、なぞられたバイナリノードの左右ブランチがアクティブであるか、または、前記左ノード領域がなぞられたバイナリノードの2進演算に必要であり、該なぞられたバイナリノードの左ブランチがアクティブであり、かつ右ブランチが非アクティブである場合に、前記なぞられたバイナリノードの左ブランチがその下方ノードへとなぞられ、また、前記なぞられたバイナリノードの左右ブランチがアクティブであるか、または前記右ノード領域がなぞられたバイナリノードの2進演算に必要であり、該なぞられたバイナリノードの右ブランチがアクティブであり、左ブランチが非アクティブである場合に、なぞられたバイナリノードの右ブランチがその下方ノードへとなぞられ、
前記グループの各々に関して、前記右及び左ブランチがアクティブであるなぞられたバイナリノードに対して演算命令を生成し、なぞられたリーフノードに対してリーフ値命令を生成する手段と、
前記グループの各々に関して、前記イメージを描画するために、前記生成された対応する命令を実行する手段とを備えることを特徴とする装置。 - 前記テーブルは、前記関連するバイナリノードのそれぞれの前記レコードに関して、前記関連するバイナリノードの右ブランチの下方ノードを表すグラフィックオブジェクトが、前記関連するバイナリノードの下方ノードを表すグラフィックオブジェクトの共通領域において、前記関連するバイナリノードの左ブランチの下方ノードを表すグラフィックオブジェクトを隠すかどうかを表す第5フィールドと、前記関連するバイナリノードの左ブランチの下方ノードを表すグラフィックオブジェクトが、前記関連するバイナリノードの下方ノードを表すグラフィックオブジェクトの共通領域において、前記関連するバイナリノードの右ブランチの下方ノードを表すグラフィックオブジェクトを隠すかどうかを表す第6フィールドとを更に備え、前記なぞる手段は、前記更新されたテーブルに従って、前記表現ツリーをなぞり、ここでなぞられたバイナリノードの左右ブランチがアクティブであり、前記なぞられたバイナリノードの右ブランチの下方ノードを表すグラフィックオブジェクトが、前記なぞられたバイナリオブジェクトの下方ノードを表すグラフィックオブジェクトの共通領域において、前記なぞられたバイナリノードの左ブランチの下方ノードを表すグラフィックオブジェクトを隠さない場合は、なぞられたバイナリノードの左ブランチの下方ノードへ向かってなぞられ、なぞられたバイナリノードの左右ブランチがアクティブであり、前記なぞられたバイナリノードの左ブランチの下方ノードを表すグラフィックオブジェクトが、前記なぞられたバイナリオブジェクトの下方ノードを表すグラフィックオブジェクトの共通領域において、前記なぞられたバイナリノードの右ブランチの下方ノードを表すグラフィックオブジェクトを隠さない場合は、なぞられたバイナリノードの右ブランチの下方ノードへ向かってなぞられることを特徴とする請求項3に記載の装置。
- 前記第5フィールド及び第6フィールドは、CLIP INもしくはCLIPOUT動作を実行するのに使用されることを特徴とする請求項4に記載の装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AUPQ6971A AUPQ697100A0 (en) | 2000-04-18 | 2000-04-18 | Rendering graphic object based images |
AU6971 | 2000-04-18 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2002056396A JP2002056396A (ja) | 2002-02-20 |
JP2002056396A5 JP2002056396A5 (ja) | 2008-06-05 |
JP4630482B2 true JP4630482B2 (ja) | 2011-02-09 |
Family
ID=3821063
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001120228A Expired - Fee Related JP4630482B2 (ja) | 2000-04-18 | 2001-04-18 | 表現ツリーを生成する装置及びラスタ画素イメージを描画する装置 |
Country Status (3)
Country | Link |
---|---|
US (1) | US7277102B2 (ja) |
JP (1) | JP4630482B2 (ja) |
AU (1) | AUPQ697100A0 (ja) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3970102B2 (ja) * | 2001-06-28 | 2007-09-05 | キヤノン株式会社 | 画像処理装置、画像処理方法、及びプログラム |
AUPR860901A0 (en) * | 2001-10-31 | 2001-11-29 | Canon Kabushiki Kaisha | Activating a filling of a graphical object |
US7167184B2 (en) * | 2002-04-11 | 2007-01-23 | Sun Microsystems, Inc. | Method and apparatus to calculate any porter-duff compositing equation using pre-defined logical operations and pre-computed constants |
US7439982B2 (en) * | 2002-05-31 | 2008-10-21 | Envivio, Inc. | Optimized scene graph change-based mixed media rendering |
AU2002951651A0 (en) * | 2002-09-25 | 2002-10-10 | Canon Kabushiki Kaisha | Apparatus for printing using non-overlapping graphic objects |
US7365743B1 (en) * | 2002-10-08 | 2008-04-29 | Adobe Systems Incorporated | Assignments for parallel rasterization |
AU2002952382A0 (en) | 2002-10-30 | 2002-11-14 | Canon Kabushiki Kaisha | Method of Background Colour Removal for Porter and Duff Compositing |
AU2003900772A0 (en) * | 2003-02-21 | 2003-03-13 | Canon Kabushiki Kaisha | Reducing the number of compositing operations performed in a pixel sequential rendering system |
US7538770B2 (en) * | 2003-11-28 | 2009-05-26 | Canon Kabushiki Kaisha | Tree-based compositing system |
US20050195220A1 (en) * | 2004-02-13 | 2005-09-08 | Canon Kabushiki Kaisha | Compositing with clip-to-self functionality without using a shape channel |
US7755629B2 (en) * | 2004-06-30 | 2010-07-13 | Canon Kabushiki Kaisha | Method of rendering graphic objects |
US7436414B2 (en) * | 2004-11-12 | 2008-10-14 | Valve Corporation | Method for accelerated determination of occlusion between polygons |
US7701463B2 (en) * | 2005-05-09 | 2010-04-20 | Autodesk, Inc. | Accelerated rendering of images with transparent pixels using a spatial index |
US7965299B2 (en) * | 2005-10-31 | 2011-06-21 | Canon Kabushiki Kaisha | Implementing compositing operations on images |
US20070216696A1 (en) * | 2006-03-16 | 2007-09-20 | Toshiba (Australia) Pty. Limited | System and method for document rendering employing bit-band instructions |
CN100545831C (zh) * | 2006-09-27 | 2009-09-30 | 北京大学 | 一种透明页面的光栅化处理方法及装置 |
US20090091564A1 (en) * | 2007-10-03 | 2009-04-09 | Raju Thevan | System and method for rendering electronic documents having overlapping primitives |
US20090096792A1 (en) * | 2007-10-15 | 2009-04-16 | Ati Technologies Ulc | Fill mode determination in vector graphics |
AU2011205085B2 (en) * | 2011-07-29 | 2014-05-15 | Canon Kabushiki Kaisha | 2D region rendering |
US9300569B2 (en) * | 2012-07-31 | 2016-03-29 | Cisco Technology, Inc. | Compressing data packet routing information using bloom filters |
AU2013273660A1 (en) * | 2013-12-18 | 2015-07-02 | Canon Kabushiki Kaisha | Method, apparatus and system for generating an intermediate region-based representation of a document |
CN110866964A (zh) * | 2019-11-08 | 2020-03-06 | 四川大学 | 一种gpu加速的椭球裁剪图地形渲染方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08110953A (ja) * | 1994-07-25 | 1996-04-30 | Canon Inf Syst Res Australia Pty Ltd | グラフィカルプログラミング言語の解釈方法 |
JPH08115413A (ja) * | 1994-07-25 | 1996-05-07 | Canon Inf Syst Res Australia Pty Ltd | グラフィカルプログラミング言語の解釈方法 |
JPH11224343A (ja) * | 1998-02-09 | 1999-08-17 | Fuji Xerox Co Ltd | 描画処理装置 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU670941B2 (en) | 1992-04-29 | 1996-08-08 | Canon Kabushiki Kaisha | Object sorting and edge calculation for graphics systems |
US5454071A (en) | 1992-04-29 | 1995-09-26 | Canon Kabushiki Kaisha | Method and apparatus for performing object sorting and edge calculation in a graphic system |
US5471568A (en) * | 1993-06-30 | 1995-11-28 | Taligent, Inc. | Object-oriented apparatus and method for scan line conversion of graphic edges |
US5600763A (en) | 1994-07-21 | 1997-02-04 | Apple Computer, Inc. | Error-bounded antialiased rendering of complex scenes |
AUPM704594A0 (en) * | 1994-07-25 | 1994-08-18 | Canon Information Systems Research Australia Pty Ltd | Efficient methods for the compositing of graphical elements |
US5970496A (en) * | 1996-09-12 | 1999-10-19 | Microsoft Corporation | Method and system for storing information in a computer system memory using hierarchical data node relationships |
US6330003B1 (en) * | 1999-07-30 | 2001-12-11 | Microsoft Corporation | Transformable graphical regions |
-
2000
- 2000-04-18 AU AUPQ6971A patent/AUPQ697100A0/en not_active Abandoned
-
2001
- 2001-04-18 JP JP2001120228A patent/JP4630482B2/ja not_active Expired - Fee Related
- 2001-04-18 US US09/836,226 patent/US7277102B2/en not_active Expired - Lifetime
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08110953A (ja) * | 1994-07-25 | 1996-04-30 | Canon Inf Syst Res Australia Pty Ltd | グラフィカルプログラミング言語の解釈方法 |
JPH08115413A (ja) * | 1994-07-25 | 1996-05-07 | Canon Inf Syst Res Australia Pty Ltd | グラフィカルプログラミング言語の解釈方法 |
JPH11224343A (ja) * | 1998-02-09 | 1999-08-17 | Fuji Xerox Co Ltd | 描画処理装置 |
Also Published As
Publication number | Publication date |
---|---|
US20020015039A1 (en) | 2002-02-07 |
AUPQ697100A0 (en) | 2000-05-11 |
JP2002056396A (ja) | 2002-02-20 |
US7277102B2 (en) | 2007-10-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4630482B2 (ja) | 表現ツリーを生成する装置及びラスタ画素イメージを描画する装置 | |
JP4366387B2 (ja) | 画像処理装置及び方法 | |
JP4343344B2 (ja) | ラスタ形式のグラフィックオブジェクトを用いたイメージの高速レンダリング方法 | |
JP3919754B2 (ja) | 画素順次描画システムにおいて実行される合成演算回数の削減法 | |
JP3797666B2 (ja) | グラフィックオブジェクトの塗りつぶしをアクティブ化する方法および装置 | |
JP3618838B2 (ja) | 画像出力方法 | |
US7714865B2 (en) | Compositing list caching for a raster image processor | |
JP4164204B2 (ja) | 画像生成方法、装置及びコンピュータ可読記憶媒体 | |
JP3618839B2 (ja) | 画像出力方法 | |
JPH0740307B2 (ja) | イメ−ジのウインド−イング方法 | |
US7538770B2 (en) | Tree-based compositing system | |
US20050116955A1 (en) | Pixel accurate edges for scanline rendering system | |
AU760826B2 (en) | Rendering graphic object based images | |
AU744091B2 (en) | Processing graphic objects for fast rasterised rendering | |
AU743218B2 (en) | Fast renering techniques for rasterised graphic object based images | |
AU2005200948B2 (en) | Compositing list caching for a raster image processor | |
AU779154B2 (en) | Compositing objects with opacity for fast rasterised rendering | |
AU2005201868A1 (en) | Removing background colour in group compositing | |
AU2002301643B2 (en) | Activating a Filling of a Graphical Object | |
AU2004200655B2 (en) | Reducing the Number of Compositing Operations Performed in a Pixel Sequential Rendering System | |
EP1306811A1 (en) | Triangle identification buffer | |
AU2005201929A1 (en) | Rendering graphic object images | |
AU2005201931A1 (en) | Rendering graphic object images |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080418 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080418 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100712 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100716 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100913 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101105 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101115 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131119 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4630482 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |