JP4365950B2 - 高速ラスタ形式レンダリングのためのグラフィックオブジェクト処理方法および装置 - Google Patents
高速ラスタ形式レンダリングのためのグラフィックオブジェクト処理方法および装置 Download PDFInfo
- Publication number
- JP4365950B2 JP4365950B2 JP25512399A JP25512399A JP4365950B2 JP 4365950 B2 JP4365950 B2 JP 4365950B2 JP 25512399 A JP25512399 A JP 25512399A JP 25512399 A JP25512399 A JP 25512399A JP 4365950 B2 JP4365950 B2 JP 4365950B2
- Authority
- JP
- Japan
- Prior art keywords
- edge
- record
- records
- current
- value
- 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
- G06T11/00—2D [Two Dimensional] image generation
- G06T11/40—Filling a planar surface by adding surface attributes, e.g. colour or texture
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/42—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of patterns using a display memory without fixed position correspondence between the display memory contents and the display position on the screen
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Image Generation (AREA)
Description
【発明の属する技術分野】
本発明は、オブジェクト・グラフィック要素のラスタ画素画像へのレンダリングに関し、具体的には、レンダリング処理の一部としての画素データのフレーム記憶装置またはライン記憶装置を使用しない、そのようなオブジェクト・グラフィック要素の画素画像データへの効率的なレンダリングに関する。
【0002】
【従来の技術】
ほとんどのオブジェクト・ベース・グラフィックス・システムでは、ページまたは画面の画素ベース画像を保持するためにフレーム・ストアまたはページ・バッファが使用される。通常、グラフィック・オブジェクトの輪郭は、計算され、塗り潰され、フレーム・ストアに書き込まれる。二次元グラフィックスの場合、他のオブジェクトの手前にあるオブジェクトは、単純に背景オブジェクトの書込み後にフレーム・ストアに書き込まれ、これによって、画素単位で背景を置換する。これは、当技術分野では、「ペインタのアルゴリズム(Painter's algorithm)」として一般に知られている。オブジェクトは、最も奥のオブジェクトから最も手前のオブジェクトという優先順位で検討され、通常は、各オブジェクトが、スキャン・ラインの順序でラスタ化され、画素が、各スキャン・ラインに沿ったシーケンシャルな並びでフレーム・ストアに書き込まれる。
【0003】
この技法には、基本的に2つの問題がある。第1の問題は、フレーム・ストア内のすべての画素への高速なランダム・アクセスが必要であることである。これは、新たに検討されるオブジェクトのそれぞれが、フレーム・ストア内のどの画素にも影響する可能性があるからである。このため、フレーム・ストアは、通常は半導体のランダム・アクセス・メモリ(RAM)内に保持される。高解像度カラー・プリンタの場合、必要なRAMの量は非常に多くなり、通常は100Mバイトを超えるが、これは、コストがかかり、高速での動作が困難である。第2の問題は、多数の画素がペイント(レンダリング)され、時間的に後のオブジェクトによって上塗り(再レンダリング)されることである。時間的に前のオブジェクトによる画素のペイントは、時間の浪費になる。
【0004】
大量のフレーム・ストアの問題を克服するための方法の1つが、「バンディング(banding)」の使用である。バンディングを使用する時には、一時にフレーム・ストアの一部だけがメモリ内に存在する。描画されるオブジェクトのすべてが、「表示リスト」に保存される。画像全体は上記と同様にレンダリングされるが、存在するフレーム・ストアの部分の外側をペイント(レンダリング)しようとする画素ペイント(レンダリング)動作は、「クリップ」アウトされる。オブジェクトのすべてが描画された後に、フレーム・ストアの部分を、プリンタ(または他の位置)に送り、フレーム・ストアの別の部分を選択し、この処理を繰り返す。この技法には、ペナルティが伴う。たとえば、描画されるオブジェクトは検討され、何度も(バンドごとに1回)再検討されなければならない。バンドの数が増えるにつれて、レンダリングが必要なオブジェクトの検査が繰り返されるし回数も増える。バンディングの技法は、上塗りのコストという問題を解決しない。
【0005】
いくつかの他のグラフィック・システムでは、スキャン・ラインの順で画像が検討される。やはり、描画されるオブジェクトのすべてが、表示リストに保存される。各スキャン・ライン上で、そのスキャン・ラインと交差するオブジェクトが優先順位の順でオブジェクトごとに検討され、オブジェクトの辺の交差点の間の画素のスパンが、ライン・ストアにセットされる。この技法も、大量のフレーム・ストアの問題を克服するが、やはり上塗りの問題をこうむる。
【0006】
これらのほかに、大きいフレーム・ストアの問題と上塗りの問題の両方を解決する技法がある。そのような技法の1つでは、各スキャン・ラインが順番に作られる。やはり、描画されるオブジェクトのすべてが、表示リストに保存される。各スキャン・ラインでは、そのスキャン・ラインと交差するオブジェクトの辺が、スキャン・ラインとの交差の座標の昇順で保持される。これらの交差の点または辺の交点が、順番に検討され、アクティブ・フラグの配列のトグルに使用される。そのスキャン・ライン上での対象となるオブジェクト優先順位ごとに1つのアクティブ・フラグがある。検討される辺の対のそれぞれの間で、最初の辺と次の辺の間にある各画素の色データが、アクティブ・フラグに対する優先順位エンコーダを使用して、どの優先順位が最も上にあるかを判定すること、および2つの辺の間のスパンの画素に関するその優先順位に関連する色を使用することによって生成される。次のスキャン・ラインに備えて、各辺の交差の座標が、各辺の性質に応じて更新される。この更新の結果として誤ってソートされた状態になった隣接する辺は、交換される。新しい辺も、辺のリストに合併される。
【0007】
この技法は、フレーム・ストアまたはライン・ストアがなく、上塗りがなく、位数N倍(このNは優先順位の数)ではなく定数位数の時間でオブジェクト優先順位が処理されるという大きい長所を有する。
【0008】
【発明が解決しようとする課題】
しかし、この技法には下記の複数の制限がある。
【0009】
(i)この技法は、辺からオブジェクトの内外の状態を決定するための、当技術分野で既知の「奇数−偶数」塗潰し規則だけをサポートする。多数のグラフィック記述言語の必須機能である「非ゼロ・ワインディング」塗潰し規則は、この技法によってサポートされない。
【0010】
(ii)単純な交換技法が修復に不適切である場合に、大量の誤ったソートが発生する可能性がある。各スキャン・ライン上で辺リスト全体のブルート・フォース・ソート(brute-force sort)を実行することができるが、これは非常に低速である。
【0011】
(iii)この技法は、オブジェクト・タイプとしてのラスタ(画素ベース)画像をサポートしない。このような画像は、ほとんどのグラフィック記述言語の必須機能である。
【0012】
(iv)この技法は、ペイントされる画素のそれぞれが、より低い優先順位のオブジェクトの画素を厳密に隠す、不透明のオブジェクトだけをサポートする。よって、この技法は、複数のグラフィック・オブジェクトの色が相互作用するラスタ演算をサポートしない。このような演算には、XORモードでの描画または部分的に透明なオブジェクトの合成が含まれる。これらの変更演算は、ほとんどのグラフィック記述言語の必須機能である。
【0013】
(v)この技法は、1つまたは複数のクリップ形状によって、クリップ形状の境界の内側(または外側)にあるいくつかの他のグラフィック・オブジェクトを削除する、クリッピングをサポートしない。クリッピングは、ほとんどのグラフィック記述言語の必須機能である。
【0014】
(vi)この技法では、オブジェクトの辺の、具体的にはテキストに関する、大量の非効率的な符号化が使用される。このようなグラフィック記述の極端に一般的な要素は、より単純な形で表現されることが望ましい。
【0015】
(vii)この技法は、いくつかの場合に、1つまたは複数のオブジェクトのアクティビティが変数である複雑な合成式の正確な評価を提供しない。
【0016】
この技法は、既存のグラフィック記述言語が必要とする多数の機能を実施できないので、その使用が極度に制限されている。
【0017】
さらに、既存のレンダリング・インターフェースの中には、複数のグラフィック・オブジェクトの色のビット単位の論理組合せの実装を要求するものがあり、複数のグラフィック・オブジェクトの色のアルファ・チャネル(透明度、不透明度またはマットと称する)に基づく組合せの実装を要求するものもある。現在の技法では、この2つの機能を統一された形で実装することができない。
【0018】
【課題を解決するための手段】
本発明の目的は、従来技術のシステムに伴う1つ又は複数の欠陥を、実質的に克服するか、少なくとも改善することである。
【0019】
本発明の一つの態様によれば、ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する方法であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、該処理は前記辺レコードの処理の間に、
限られた数の処理された辺レコードを順序付けされていない第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて、順序付け可能な前記辺レコードを漸進的に順次に第2バッファへ送るステップと、
順序付けできない処理済の辺を、第3バッファにおいて並べるために該第3バッファへ送るステップと、
前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定するステップとを備える方法が開示される。
【0020】
また、本発明の他の態様によれば、グラフィックオブジェクト描画システムにおいて、ラスター画素イメージを形成するべくグラフィックオブジェクトを処理する方法であって、該処理は、前記グラフィックオブジェクトの辺と前記ラスター画素イメージの現在のスキャンラインとの交差の順序を決定する第1処理を備え、
前記システムが、
現在のスキャンラインと後続のスキャンラインの各々に関する複数の辺レコードと、該辺レコードの各々は少なくとも対応するスキャンライン上の対応する辺の画素位置の値を保持し、前記現在の辺レコード及び後続の辺レコードの各々は、少なくとも主部分とスピル部分に分割され、少なくとも前記現在の辺レコードの主部分はラスター画素順に並べられ、
少なくとも一つの現在のアクティブ辺レコードと、
スピルアクティブ辺レコードと、
制限された所定数の辺レコードを含むプールとを備え、
前記方法が、
(a)前記現在の辺レコードの前記主部分及びスピル部分の各々からの第1の辺レコードを対応するアクティブ辺レコードに送るステップと、
(b)前記ラスタ画素順において最も低い値を有するアクティブ辺レコードを決定し、現在の辺の値及びレコードとしてその値とレコードを出力するために、前記アクティブ辺レコードの値を比較するステップと、
(c)前記現在の辺レコードを、前記後続のスキャンラインのための対応する辺の値で更新するステップと、
(d)更新された辺の値を前記プール内の辺の値と比較するステップと、ここで、更新された辺の値が前記プール内の辺の値より小さい場合に、
(da)前記更新された現在の辺レコードが後続の辺レコードのスピル部分へ送られ、さもなければ、
(db)(dba)最小の辺値を有する辺レコードが前記プールから、前記後続の辺レコードの主部分の次のレコードへ送られ、
(dbb)前記更新された辺レコードは、前記サブステップ(dba)で空になった前記プールのレコードへ送られ、
(dc)更なる辺レコードが、現在の辺レコードの対応する部分から更新された辺レコードによって空にされたアクティブ辺レコードへ送られ、
(e)前記プール内の前記レコードの各々が占領されるまで、ステップ(b)乃至(d)を繰り返すステップと、これによって前記プールの最小の辺値レコードが前記後続の辺レコードの前記主部分へ送られ、
(f)前記現在のレコードの全てのレコードが更新されるまで前記ステップ(b)乃至(e)を繰り返し、次いで、前記プールからのレコードを順次に前記後続のレコードの前記主部分内の次のレコードへフラッシュするステップと、
(g)前記レコードを、前記後続のレコードにおける前記スピル部分において、ラスタ画素順にソートするステップと、
(h)前記後続の辺レコードを前記現在の辺レコードへ送るステップと、
(i)前記ラスタ画素イメージの更なるスキャンラインの各々に関して、前記ステップ(a)乃至(h)を繰り返すステップとを備える方法が開示される。
【0021】
また、本発明の他の態様によれば、ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する装置であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、
未整列の第1バッファ、第2バッファ及び第3バッファを有するメモリと、
限られた数の処理された辺レコードを順序付けされていない前記第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて順序付け可能な前記辺レコードを漸進的に順次に前記第2バッファへ送り、順序付けできない処理済の辺を前記第3バッファにおいて並べるために該第3バッファへ送り、前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定するプロセッサとを備える装置が開示される。
【0022】
また、本発明の他の態様によれば、ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する装置であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、
限られた数の処理された辺レコードを順序付けされていない第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられのに応じて、順序付け可能な前記辺レコードを漸進的に順次に第2バッファへ送る手段と、
順序付けできない処理済の辺を、第3バッファにおいて並べるために該第3バッファへ送る手段と、
前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定する手段とを備える装置が開示される。
【0023】
また、本発明の他の態様によれば、ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する装置のためのプログラムを格納するコンピュータ可読媒体であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、該プログラムが、
限られた数の処理された辺レコードを順序付けされていない第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて、順序付け可能な前記辺レコードを漸進的に順次に第2バッファへ送る保持ステップのコードと、
順序付けできない処理済の辺を、第3バッファにおいて並べるために該第3バッファへ送る転送ステップのコードと、
前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定する処理ステップのコードとを備えるコンピュータ可読媒体が開示される。
【0024】
本発明の更に他の態様は以下の説明から明らかとなる。
【0025】
【発明の実施の形態】
以下、添付の図面を参照して本発明の実施形態を説明する。なお、以下の実施形態の記載において、数学記号を下記のように表記する。
【表1】
図1は、コンピュータ・グラフィック・オブジェクト画像のレンダリングおよびプレゼンテーションのために構成されたコンピュータ・システム1を概略的に示す図である。このシステムには、システム・ランダム・アクセス・メモリ(RAM)3に関連するホスト・プロセッサ2が含まれ、システムRAM3には、不揮発性のハード・ディスク・ドライブ5または類似の装置と、揮発性の半導体RAM4を含めることができる。システム1には、システム読取専用メモリ(ROM)6も含まれ、システムROM6は、通常は半導体ROM7を基礎とし、多くの場合に、コンパクト・ディスク装置(CD−ROM)8によって補足することができる。システム1には、ラスタ式に動作するビデオ表示装置(VDU)またはプリンタなどの、画像を表示するための手段10も組み込むことができる。
【0026】
システム1に関して上で説明した構成要素は、バス・システム9を介して相互接続され、IBM PC/ATタイプのパーソナル・コンピュータおよびそれから発展した構成、Sun Sparcstationsおよび類似物など、当技術分野で周知のコンピュータ・システムの通常動作モードで動作可能である。
【0027】
やはり図1に図示されているように、画素シーケンシャル・レンダリング装置20は、バス9に接続され、好ましい実施形態では、システム1からバス9を介して命令およびデータを供給されるグラフィック・オブジェクト・ベースの記述から導出される画素ベースの画像のシーケンシャル・レンダリングのために構成される。装置20は、オブジェクト記述のレンダリングのためにシステムRAM3を使用することができるが、レンダリング装置20は、通常は半導体RAMから形成される、専用のレンダリング・ストア配置30と関連付けられることが好ましい。
【0028】
次に図2を参照すると、好ましい実施形態の機能データ流れ図が示されている。図2の機能流れ図は、オブジェクト・グラフィック記述11から始まる。このオブジェクト・グラフィック記述11は、ホスト・プロセッサ2によって生成されるか、且つ/又は、システムRAM3内に記憶されるかシステムROM6から導出され、グラフィック・オブジェクトのパラメータを記述するのに使用され、そこから画素ベース画像をレンダリングするために、画素シーケンシャル・レンダリング装置20によって解釈され得る。たとえば、オブジェクト・グラフィック記述11には、ディスプレイ上の1点から別の点まで横断する直線の辺(単純ベクトル)または、直交する線を含む複数の辺によって二次元オブジェクトが定義される直交辺フォーマットを含むいくつかのフォーマットで辺を有するオブジェクトを組み込むことができる。これ以外に、連続曲線によってオブジェクトが定義されるフォーマットも、適当であり、これらには、乗算を実行する必要なしに二次曲線を単一の出力空間内でレンダリングできるようにするいくつかのパラメータによって単一の曲線を記述できる二次多項式の線分を含めることができる。三次スプラインや類似物などのそれ以外のデータ・フォーマットを使用することもできる。オブジェクトには、多数の異なる辺タイプの混合物を含めることができる。通常、すべてのフォーマットに共通するのは、それぞれの線(直線であれ曲線であれ)の始点と終点の識別子であり、通常は、これらは、スキャン・ライン番号によって識別され、したがって、その曲線をレンダリングすることのできる特定の出力空間が定義される。
【0029】
たとえば、図16Aに、線分を適当に記述し、レンダリングするために、2つの線分601および602に分割する必要がある辺600の従来技術の辺記述を示す。分割の必要が生じるのは、従来技術の辺記述が、二次式を介して簡単に計算されるが、変曲点604に適応することができないからである。したがって、辺600は、それぞれ終点603および604または終点604および605を有する2つの別々の辺として扱われた。図16Bに、終点611および612と制御点613および614によって記述される三次スプライン610を示す。このフォーマットでは、レンダリングのために三次多項式の計算が必要であり、したがって、計算時間がかかる。
【0030】
図16Cに、好ましい実施形態に適用可能な辺の例を示す。好ましい実施形態では、辺は、単一の実体とみなされ、必要であれば、異なるフォーマットで記述できる辺の部分を示すために区分されるが、その具体的な目的は、各部分の記述の複雑さが最小限になるようにすることである。
【0031】
図16Cの左側には、スキャン・ライン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)も有する。
【0032】
図16Cの右側の線分は、好ましい実施形態による三次曲線の例を示す図であり、これには上記の二次線分に対応する記述が含まれるが、線分の傾斜の変化の割合を変更するためにDDXに加算される符号付きの3階値(DDDX)が追加されている。同様に、多数の他の階も実施することができる。
【0033】
上記から、辺の線分を記述する複数のデータ・フォーマットを処理する能力があると、複雑で計算コストの高い数学演算に頼らずに、辺の記述と評価を単純化することができることが明白である。これに対して、図16Aの従来技術のシステムでは、直交、ベクトルまたは二次のいずれであれ、すべての辺を二次形式で記述する必要があった。
【0034】
好ましい実施形態の動作を、図8に示された画像78のレンダリングという単純な例に関して説明する。画像78は、2つのグラフィカル・オブジェクト、具体的に言うと、不透明の赤色の長方形90とその上にレンダリングされ、これによって長方形90を部分的に隠す、部分的に透明の青色の三角形80を含む。図からわかるように、長方形90には、種々の画素位置(X)とスキャン・ライン位置(Y)の間で定義された横の辺92、94、96および98が含まれる。辺96および98は、スキャン・ライン上に形成される(したがってこれらと平行である)ので、長方形90の実際のオブジェクト記述は、図9Aに示されているように、横の辺92および94だけに基づくものとすることができる。これに関連して、辺92は、画素位置(40,35)から始まり、ラスタ方向で画面の下側へ延びて、画素位置(40,105)で終わる。同様に、辺94は、画素位置(160,35)から位置(160,105)まで延びる。長方形グラフィック・オブジェクト90の水平部分は、単に辺92から辺94へラスタ化された形で走査することによって得ることができる。
【0035】
しかし、青い三角形のオブジェクト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の傾斜値が関連付けられる。
【0036】
図10に、スキャン・ライン35で始まる長方形90がレンダリングされる様子と、辺82および84がスキャン・ライン35とどのように交差するかを示す。図10から、画像78のラスタ化には、高い優先順位レベルを有するオブジェクトが、低い優先順位レベルを有するオブジェクトの「上」にレンダリングされる形で2つのオブジェクト90および80が描画される必要のあることがわかる。これを図11に示す。図11は、画像78のレンダリングに使用される辺リスト・レコードを示す図である。図11のレコードには、オブジェクトごとに1つずつの、2つの項目が含まれる。これらの項目は、それぞれのオブジェクトのラスタ・レンダリング順での始点に対応するスキャン・ライン値で配置される。図11から、辺レコードのそれぞれが、オブジェクトの関連する優先順位レベルと、記述される辺の性質に関する詳細(たとえば色、傾斜など)を有することがわかる。
【0037】
再び図2に戻って説明する。レンダリングされるグラフィック・オブジェクトの記述に必要なデータを識別したので、グラフィック・システム1は、表示リスト生成ステップ12を実行する。
【0038】
表示リスト生成12は、取り付けられたROM6およびRAM3を有するホスト・プロセッサ2上で実行されるソフトウェア・モジュールとして実施されることが好ましい。表示リスト生成12では、周知のグラフィック記述言語、グラフィック・ライブラリ呼出しまたは他のアプリケーション固有フォーマットのうちの1つまたは複数で表現されたオブジェクト・グラフィック記述を表示リストに変換する。表示リストは、通常は、表示リスト・ストア13に書き込まれる。表示リスト・ストア13は、一般にRAM4内で形成されるが、その代わりにレンダリング・ストア30内で形成することもできる。図3からわかるように、表示リスト・ストア13には、複数の構成要素を含めることができ、その1つは命令ストリーム14であり、もう1つは辺情報15であり、ラスタ画像画素データ16を含めることができる。
【0039】
命令ストリーム14には、特定の画像内で所望される特定のグラフィック・オブジェクトをレンダリングするために画素シーケンシャル・レンダリング装置20によって読み取られる、命令として解釈可能なコードが含まれる。図8に示された画像の例では、命令ストリーム14が、下記の形になり得る。
(1)スキャン・ライン20までレンダリングする(何もしない)
(2)スキャン・ライン20で2つの青い辺82および84を追加する
(3)スキャン・ライン35までレンダリングする
(4)スキャン・ライン35で2つの赤い辺92および94を追加する
(5)最後までレンダリングする。
【0040】
同様に、図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スキャン・ラインだけ延びる。
【0041】
上の命令ストリーム14および辺情報15の例とそれぞれが表現される形から、図8の画像78では、画素位置(X)とスキャン・ライン値(Y)によって、画像78がレンダリングされる単一の出力空間が定義されることが認められる。しかし、本開示の原理を使用して、他の出力空間構成を実現することもできる。
【0042】
図8には、ラスタ画像画素データが含まれず、したがって、表示リスト13の記憶部分16には何も記憶する必要がない。この特徴については後で説明する。
【0043】
表示リスト・ストア13は、画素シーケンシャル・レンダリング装置20によって読み取られる。画素シーケンシャル・レンダリング装置20は、通常は集積回路として実施される。画素シーケンシャル・レンダリング装置20は、表示リストをラスタ画素のストリームに変換し、このストリームは、たとえばプリンタ、ディスプレイまたはメモリ・ストアなどの別の装置に転送することができる。
【0044】
好ましい実施形態では、集積回路として画素シーケンシャル・レンダリング装置20を説明するが、これは、ホスト・プロセッサ2などの汎用処理ユニット上で実行可能な同等のソフトウェア・モジュールとして実施することができる。このソフトウェア・モジュールは、ディスク装置またはコンピュータ・ネットワークなどのコンピュータ可読媒体を介してユーザに配布することのできるコンピュータ・プログラム製品の一部を形成することができる。
【0045】
図3は、画素シーケンシャル・レンダリング装置20、表示リスト・ストア13および一時的レンダリング・ストア30の構成を示す図である。画素シーケンシャル・レンダリング装置20の処理ステージ22には、命令実行機構300、辺処理モジュール400、優先順位決定モジュール500、塗潰し色決定モジュール600、画素合成モジュール700および画素出力モジュール800が含まれる。処理動作では、一時的ストア30を使用するが、これは、上で述べたように表示リスト・ストア13と同一の装置(たとえば磁気ディスクまたは半導体RAM)を共用するか、速度最適化のために個々の格納部(ストア)として実施することができる。辺処理モジュール400は、辺レコード・ストア32を使用して、スキャン・ラインからスキャン・ラインへ順方向に運ばれる辺情報を保持する。優先順位決定モジュール500は、優先順位特性および状況テーブル34を使用して、各優先順位に関する情報と、スキャン・ラインがレンダリングされている間の辺交差に関する各優先順位の現在の状態を保持する。塗潰し色決定モジュール600は、塗潰しデータ・テーブル36を使用して、特定の位置で特定の優先順位の塗潰し色を決定するのに必要な情報を保持する。画素合成モジュール700は、画素合成スタック38を使用して、出力画素の値を決定するために複数の優先順位からの色が必要になる出力画素の、決定中の中間結果を保持する。
【0046】
表示リスト・ストア13および上で詳細を示した他のストア32ないし38は、RAM内で実施するか、他のデータ記憶技術で実施することができる。
【0047】
図3の実施形態に示された処理ステップは、処理パイプライン22の形をとる。この場合、パイプラインのモジュールは、以下で説明する形でそれらの間でメッセージを受け渡しながら、画像データの異なる部分に対して並列に同時に実行することができる。もう1つの実施形態では、以下で説明するメッセージのそれぞれが、下流モジュールへの制御の同期転送の形をとることができ、上流処理は、下流モジュールがそのメッセージの処理を完了するまで中断される。
【0048】
命令実行機構300は、命令ストリーム14から命令を読み取り、処理し、その命令を、出力398を介してパイプライン22内の他のモジュール400、500、600および700に転送されるメッセージにフォーマットする。好ましい実施形態では、命令ストリーム14に、以下の命令を含めることができる。
【0049】
LOAD_PRIORITY_PROPERTIES: この命令は、優先順位特性および状況テーブル34にロードされるデータと、そのデータがロードされるテーブル内のアドレスに関連する。命令実行機構300は、この命令に出会った時に、優先順位特性および状況テーブル34の指定された位置でのデータの記憶のためのメッセージを発行する。これは、このデータを含むメッセージをフォーマットし、処理パイプライン22を介して、ストア動作を実行する優先順位決定モジュール500に渡すことによって達成できる。
【0050】
LOAD_FILL_DATA: この命令は、塗潰しデータ・テーブル36にロードされるデータと、そのデータがロードされるテーブル内のアドレスに関連する。命令実行機構300は、この命令に出会った時に、塗潰しデータ・テーブル36の指定されたアドレスでのデータの記憶のためのメッセージを発行する。これは、このデータを含むメッセージをフォーマットし、処理パイプライン22を介して、ストア動作を実行する塗潰しデータ決定モジュールに渡すことによって達成できる。
【0051】
LOAD_NEW_EDGES_AND_RENDER: この命令は、次のスキャン・ラインをレンダリングする時にレンダリング処理に導入される新しい辺15の表示リスト・ストア13内のアドレスに関連する。命令実行機構300は、この命令に出会った時に、このデータを含むメッセージをフォーマットし、辺処理モジュール400に渡す。辺処理モジュール400は、新しい辺のアドレスを辺レコード・ストア32に記憶する。指定されたアドレスにある辺は、次のスキャン・ラインをレンダリングする前に、最初のスキャン・ライン交差座標に基づいてソートされる。一実施形態では、辺は、表示リスト生成処理12によってソートされる。別の実施形態では、辺は、画素シーケンシャル・レンダリング装置20によってソートされる。
【0052】
SET_SCAN LINE_LENGTH: この命令は、レンダリングされるスキャン・ラインのそれぞれで作られる画素数に関連する。命令実行機構300は、この命令に出会った時に、この値を辺処理モジュール400および画素合成モジュール700に渡す。
【0053】
SET_OPACITY_MODE: この命令は、画素合成演算で不透明度チャネル(当技術分野ではアルファ・チャネルとも称する)を使用するかどうかを示すフラグに関連する。命令実行機構300は、この命令に出会った時に、このフラグの値を画素合成モジュール700に渡す。
【0054】
命令実行機構300は、通常は、命令をマッピングし、パイプライン動作に復号して、さまざまなモジュールに渡す、マイクロコードステートマシンによって形成される。或いは、その代わりに、対応するソフトウェア処理を使用することもできる。
【0055】
スキャン・ラインのレンダリング動作中の辺処理モジュール400の動作を、図4を参照して以下に説明する。スキャン・ラインのレンダリングのための初期条件は、以下の3つの辺レコードのストが使用可能であることである。これら3つのリストのいずれかまたはすべては空でもよい。これらのリストは、辺情報15から取得されLOAD_NEW_EDGES_AND_RENDER命令によってセットされる新しい辺を含む新辺リスト402、前のスキャン・ラインから順方向に運ばれた辺レコードを含む主辺リスト404および、やはり前のスキャン・ラインから順方向に運ばれた辺レコードを含むスピル辺リスト406である。各辺レコードには、下記が含まれ得る。
【0056】
(i)現在のスキャン・ライン交差座標(本明細書ではX座標と称する)
(ii)この辺の現在の線分が続くスキャン・ライン数のカウント(本明細書ではNYと称する。いくつかの実施形態では、これをY限界と表現する場合がある)
(iii)各スキャン・ラインの後でこの辺レコードのX座標に加算される値(本明細書ではDXと称する)
(iv)各スキャン・ラインの後でこの辺レコードのDXに加算される値(本明細書ではDDXと称する)
(v)1つまたは複数の優先順位番号(P)
(vi)辺がスキャンラインと上向き(+)に交差するか下向き(−)に交差するかを示す方向(DIR)フラグ
(vii)リスト内の次の辺線分のアドレス(ADD)。
【0057】
このようなフォーマットは、ベクトル、直交配置された辺および二次曲線に適合する。これ以外のパラメータ、たとえばDDDXの追加によって、このような配置が三次曲線に適合できるようになる。三次ベジェ・スプラインなど、いくつかの応用分野では、6階多項式(すなわちDDDDDDXまで)が必要になる場合がある。
【0058】
図8の辺84および94の例では、スキャン・ライン20での対応する辺レコードが、以下の表1に示されたものになる。
【0059】
【表2】
【0060】
この説明では、レンダリング処理によって生成されつつあるスキャン・ラインに沿って画素から画素へステップする座標を、X座標と称し、スキャン・ラインからスキャン・ラインへとステップする座標を、Y座標と称する。各辺リストには、メモリ内で連続的に配置された0個以上のレコードが含まれることが好ましい。ポインタ・チェインの使用を含む他の記憶配置も可能である。3つのリスト402、404および406のそれぞれのレコードは、スキャン・ライン交差(X)座標の順で配置される。これは、通常は、当初は辺入力モジュール408によって管理されるソート処理によって得られ、辺入力モジュール408は、辺情報を含むメッセージを命令実行機構300から受け取る。各スキャン・ライン交差座標の整数部分だけを有意とみなすためにソートを緩和することが可能である。また、各スキャン・ライン交差座標を、現在のレンダリング処理によって作られる最小および最大のX座標にクランプされるとみなすことによってさらにソートを緩和することが可能である。適当な場合には、辺入力モジュール408は、メッセージを、出力498を介してパイプライン22の下流のモジュール500、600および700に受け渡す。
【0061】
辺入力モジュール408は、3つのリスト402、404および406のそれぞれへの参照を維持し、これらのリストから辺データを受け取る。これらの参照のそれぞれは、スキャン・ラインの処理の開始時に、各リスト内の最初の辺を参照するように初期設定される。その後、辺入力モジュール408は、選択されるレコードが3つの参照されるレコードからの最小のX座標を有するものになるように、3つの参照された辺レコードのうちの1つから辺レコードを選択する。複数のXレコードが等しい場合には、それぞれが任意の順序で処理され、対応する辺交差が、下記の形で出力される。そのレコードの選択に使用された参照は、その後、そのリストの次のレコードに進められる。選択されたばかりの辺は、メッセージにフォーマットされ、辺更新モジュール410に送られる。また、辺のいくつかのフィールド、具体的には現在のX、優先順位番号および方向フラグが、メッセージにフォーマットされ、このメッセージは、辺処理モジュール400の出力498として優先順位決定モジュール500に転送される。なお、本明細書に記載されたものより多数または少数のリストを使用する実施形態も可能である。
【0062】
辺を受け取った時に、辺更新モジュール410は、現在の線分が続くスキャン・ライン数のカウントをデクリメントする。そのカウントが0に達した場合には、次の線分アドレスによって示されるアドレスから新しい線分を読み取る。線分では、下記が指定される。
(i)線分を読み取った直後に現在のX座標に加算される値
(ii)その辺の新しいDX値
(iii)その辺の新しいDDX値
(iv)新しい線分が続くスキャン・ライン数の新しいカウント。
【0063】
示されたアドレスに使用可能な次の線分がない場合には、その辺に対してそれ以上の処理は実行されない。そうでない場合には、辺更新モジュール410は、その辺の次のスキャン・ラインのX座標を計算する。これには、通常は、現在のX座標をとり、これにDX値を加算することが用いられる。DXは、処理される辺の種類に応じて、必要であればDDX値を加算される場合がある。その後、辺は、複数の辺レコードの配列である辺プール412内の使用可能な空きスロットに書き込まれる。空きスロットがない場合には、辺更新モジュール410は、スロットが使用可能になるのを待つ。辺レコードが辺プール412に書き込まれたならば、辺更新モジュール410は、新しい辺が辺プール412に追加されたことを、信号線416を介して辺出力モジュール414に知らせる。
【0064】
スキャン・ラインのレンダリングのための初期条件として、辺出力モジュール414は、図4には図示されていないが、辺レコード32内のリスト404および406に関連する次主辺リスト420および次スピル辺リスト422のそれぞれへの参照を有する。これらの参照のそれぞれは、当初は空のリスト420および422が構築される位置に初期設定される。辺が辺プール412に追加されたことを示す信号416を受け取った時に、辺出力モジュール414は、追加された辺が、次主辺リスト420に最後に書き込まれた辺(があれば)より小さいX座標を有するかどうかを判定する。これが真である場合には、順序付けの基準を侵害せずにその辺を主辺リスト404の末尾に追加することができないので、「スピル」が発生したという。スピルが発生した時には、その辺は、好ましくはソートされた次スピル辺リスト422を維持する形で、次スピル辺リスト422に挿入される。たとえば、これは、ソフトウェア・ソート・ルーチンを使用して達成することができる。いくつかの実施形態では、スピルが、極端に大きいX座標など、他の条件によってトリガされる場合がある。
【0065】
辺プール412に追加された辺が、次主辺リスト420に最後に書き込まれた辺(があれば)以上のX座標を有し、辺プール412に使用可能な空きスロットがない場合には、辺出力モジュール414は、辺プール412から、最小のX座標を有する辺を選択し、その辺を次主辺リスト420の末尾に追加し、この処理で次主辺リスト420を延長する。辺プール412内の、その辺によって占められていたスロットは、空きとしてマークされる。
【0066】
辺入力モジュール408は、これら3つの入力リスト402、404および406のすべてからすべての辺を読み取り、転送した後に、スキャン・ラインの終りに達したことを示すメッセージをフォーマットし、そのメッセージを、優先順位決定モジュール500と辺更新モジュール410の両方に送る。そのメッセージを受け取った時に、辺更新モジュール410は、それが現在実行しているすべての処理が完了するのを待ち、その後、このメッセージを辺出力モジュール414に転送する。そのメッセージを受け取った時に、辺出力モジュール414は、辺プール412からの残りの辺レコードのすべてを、X順で次の主辺リスト404に書き込む。その後、次主辺リスト420および主辺リスト404への参照を、辺入力モジュール408と辺出力モジュール414の間で交換し、同様の交換を、次スピル辺リスト422とスピル辺リスト406に関しても実行する。この形で、次のスキャン・ラインのための初期条件が確立される。
【0067】
辺レコードの挿入時に次スピル辺リスト422をソートするのではなく、そのような辺レコードを、単にリスト422の末尾に追加することができ、スキャン・ラインの末尾で、現在のスピル・リスト406との交換の前にソートされるリスト422は、次のスキャン・ラインの辺ラスタ化でアクティブになる。エッジをソートする他の方法では、より少数またはより多数のリストを使用することができ、また、異なるソート・アルゴリズムを使用することができる。
【0068】
上記から、辺交差メッセージが、スキャン・ライン順および画素順(すなわち、まずYでソートされ、次にXでソートされる)で優先順位決定モジュール500に送られること、および各辺交差メッセージに、それに適用される優先順位のラベルが付けられることを推論することができる。
【0069】
図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フィールドを使用する曲線)が、辺レコードの終端線分になる。
【0070】
図12Aから、他のデータ構造も可能であり、たとえばより高次の多項式の実装が使用される場合にはそれが必要であることを諒解されたい。さらに、線分アドレスおよびDDXフィールドは、異なるフィールドに分離することができ、代替実施態様に合わせて追加のフラグを設けることができる。
【0071】
図12Bは、辺処理モジュール400で使用される、上で説明した好ましい実施形態の辺レコードの配置を示す図である。辺プール412は、新アクティブ辺レコード428、現アクティブ辺レコード430およびスピル・アクティブ辺レコード432によって補足される。図12Bからわかるように、レコード402、404、406、420および422は、ある時点でレンダリングされる辺の数に応じて、サイズを動的に変更することができる。各レコードには、新辺リスト402の場合にはLOAD_EDGES_AND_RENDER命令に組み込まれたSIZE値によって決定される、限界値が含まれる。このような命令に出会った時には、SIZEを検査し、0でない場合には、新しい辺レコードのアドレスをロードし、リスト402の限界サイズを決定する限界値を計算する。
【0072】
好ましい実施形態では、辺レコードの処理のために配列とそれに関連するポインタを使用するが、たとえばリンク・リストなどの、他の実施態様を使用することができる。これらの他の実施態様は、ハードウェア・ベース、ソフトウェア・ベースまたはその組合せとすることができる。
【0073】
図8に示された画像78の具体的なレンダリングを、図10に示されたスキャン・ライン34、35および36に関連してこれから説明する。この例では、次のスキャン・ラインの新しいX座標の計算が、説明を明瞭にするために省略され、図12Cないし図12Iでは、出力辺交差が、辺プール412のレジスタ428、430および432の1つから導出される。
【0074】
図12Cは、スキャン・ライン34(半透明の青い三角形80の最上部)のレンダリングの終りでの、上で述べたリストの状態を示す図である。スキャン・ライン34には、新しい辺がなく、したがって、リスト402が空であることに留意されたい。主辺リスト404および次主辺リスト420のそれぞれには、辺82および84だけが含まれる。リストのそれぞれには、対応するポインタ434、436および440が含まれ、これらは、スキャン・ライン34の完了時に、対応するリスト内の次の空きレコードを指す。各リストには、対応するリストの末尾を指すために必要な、アスタリスク(*)によって示される限界ポインタ450も含まれる。リンク・リストを使用する場合には、リンク・リストに、対応する機能を実行するヌル・ポインタ終端子が含まれるので、このような限界ポインタは不要になる。
【0075】
上で述べたように、各スキャン・ラインの始めに、次主辺リスト420と主辺リスト404が交換され、新しい辺が、新辺リスト402に受け取られる。残りのリストはクリアされ、ポインタのそれぞれは、各リストの最初のメンバを指すようにセットされる。スキャン・ライン35の始めでは、配置は図12Dのようになる。図12Dからわかるように、レコードには、図10から辺92、94、84および82に対応することがわかる4つのアクティブな辺が含まれる。
【0076】
図12Eを参照すると、レンダリングが開始される時に、新辺レコード402の最初の線分が、アクティブ辺レコード428にロードされ、主辺リスト404およびスピル辺リスト406の最初のアクティブな辺レコードが、それぞれレコード430および432にコピーされる。この例では、スピル辺リスト406は空であり、したがって、ローディングは行われない。レコード428、430および432内の辺のX位置が比較され、辺交差が、最小のX位置を有する辺について発行される。この場合、発行される辺は、辺92に対応する辺であり、この辺がその優先順位値と共に出力される。その後、ポインタ434、436および438が、リスト内の次のレコードを指すように更新される。
【0077】
その後、辺交差が発行される辺が更新され(この場合、その位置にDX=0を加算することによって)、辺プール412にバッファリングされ、この辺プール412は、この例では3つの辺レコードを保持するサイズになる。発行された辺が現れたリスト(この場合ではリスト402)内の次の項目が、対応するレコード(この場合ではレコード428)にロードされる。これを図12Fに示す。
【0078】
さらに、図12Fから明らかなとおり、レジスタ428、430および432の間の比較によって、もう一度最小のX値を有する辺が選択され、適切な次の辺交差(X=85、P=2)として出力される。そして、同様に、選択され出力された辺は、更新され、辺プール412に追加され、適当なポインタのすべてがインクリメントされる。この場合、更新される値は、X←X+DXによって与えられ、ここでは、84=85−1として与えられる。また、図からわかるように、新しい辺のポインタ434が、この場合では新辺リスト402の末尾に移動される。
【0079】
図12Gでは、最小の現行X値を有すると識別された次の辺が、やはり、レジスタ430から取得され、辺交差(X=115、P=2)として出力される。そして、辺の更新が発生し、図示のように、その値が辺プール412に追加される。この時、辺プール412は満杯になり、ここから、最小のX値を有する辺が選択され、出力リスト420に発行され、対応する限界ポインタが、それ相応に移動される。
【0080】
図12Hからわかるように、次の最小の辺交差は、レジスタ428からのものであり、これが出力される(X=160、P=1)。やはり辺プール412が更新され、次に小さいX値が出力リスト420に発行される。
【0081】
スキャン・ライン35の終りに、図12Iからわかるように、X値の小さい順で、辺プール412の内容が出力リスト420にフラッシュされる。図12Jからわかるように、次主辺リスト420と主辺リスト404は、次のスキャン・ライン36のレンダリングに備えて、ポインタを交換することによって交換される。交換の後に、図12Jからわかるように、主辺リスト404の内容には、スキャン・ライン36上の現在の辺のすべてが含まれ、これらはX位置の順で配置され、これによって、高速のレンダリングを容易にする便利なアクセスが可能になる。
【0082】
通常、新しい辺は、X位置の昇順で辺処理モジュール400によって受け取られる。新しい辺が現れる時には、その位置が更新され(次にレンダリングされるスキャン・ラインのために計算され)、これによって、以下の処置が決定される。
【0083】
(a)更新された位置が信号線498に出力された最後のX位置より小さい場合には、新しい辺は、主スピル・リスト406へのソートされる挿入であり、対応する限界レジスタが更新される。
【0084】
(b)そうでない場合に、空間があるならば、その辺は辺プール412内で保存される。
【0085】
前述から明白なとおり、辺プール412は、ラスタ化画像の次のスキャン・ラインのレンダリングに備えた順序付きの形でのリストの更新を助ける。さらに、辺プール412のサイズは、多数の順序付けられていない辺に適合するために変更することができる。しかし、実際には、辺プール412が、一般にグラフィック処理システムの処理速度および使用可能なメモリに依存する、実用的な限界を有することは明白である。制限的な意味では、辺プール412を省略することができるが、これは、通常は、更新された辺を、次出力辺リスト420へのソートされた挿入にすることを必要とする。しかし、好ましい実施形態では、上で述べたスピル・リストの使用を介する通常の出来事として、この状況が回避される。スピル・リストを設けることによって、好ましい実施形態を、実用的なサイズの辺プールを用いて実施でき、なおかつ、ソフトウェア集中的なソート手順に頼らずに比較的複雑な辺交差を処理することができる。辺プールとスピル・リストが辺交差の複雑さに適合するのに不十分になる場合では、これは稀な場合であるが、ソート法を使用することができる。
【0086】
スピル・リスト手順が使用される場合の例を、図14Aに示す。図14Aでは、3つの任意の辺60、61および63が、スキャン・ラインAおよびBの間の相対位置で任意の辺62と交差する。さらに、スキャン・ラインAおよびBのそれぞれについて実際に表示される画素位置64が、スパン画素位置CないしJとして図示されている。辺プール412が3つの辺レコードを保存するサイズである、上で説明した例では、このような配置だけでは、図14Aに示された隣接するスキャン・ラインの間で発生する3つの辺の交差に適合するのに不十分であることは明白である。
【0087】
図14Bに、スキャン・ライン上の辺60、61および63をレンダリングした後の辺レコードの状態を示す。辺交差Hは、最も最近に発行された辺交差であり、辺プール412は、次のスキャン・ラインであるスキャン・ラインBのための、それぞれ辺60、61および63の更新されたX値E、GおよびIで満杯になっている。辺62は、現アクティブ辺レコード430にロードされ、辺プール412が満杯なので、辺60に対応する最小のX値が、出力辺リスト420に出力される。
【0088】
図14Cでは、次の辺交差が発行され(辺62のX=J)、対応する更新された値、この場合はスキャン・ラインBのX=Cが決定される。新たに更新された値X=Cは、出力リスト420からコピーされた最も最近の値X=Eより小さいので、現在の辺レコードとそれに対応する新たに更新された値が、出力スピル・リスト422に直接に転送される。
【0089】
図14Dに、スキャン・ラインBの開始時の辺レコードの状態を示す。この図では、主リストおよび出力リストと、それらに対応するスピル構成要素が交換されていることがわかる。最初に発行される辺を決定するために、辺60を現アクティブ辺レジスタ430にロードし、辺62を、スピル・アクティブ辺レジスタ432にロードする。X値が比較され、最小のX値(X=C)を有する辺62が発行され、更新され、辺プール412にロードされる。
【0090】
辺の発行と更新は、主辺リスト404内の残りの辺について継続され、スキャン・ラインの終りに、辺プール412がフラッシュされて、図14Eに示された状況になる。図14Eからは、辺60ないし63のそれぞれが、次のスキャン・ラインでのレンダリングのために適当に順序付けられ、スキャン・ラインB上で正しく発行され、レンダリングされたことがわかる。
【0091】
上記から明らかになるように、スピル・リストは、複雑な辺交差状況の存在のもとで、辺ラスタ化順序の維持をもたらす。さらに、このリストがサイズにおいて動的に変更可能であることによって、辺交差の数と複雑さの大きい変化を、例外的に複雑な辺交差以外のすべての辺交差でソート手順に頼る必要なしに処理できる。
【0092】
好ましい実施形態では、辺プール412は、8つの辺レコードを保存するサイズにされ、リスト404および420のサイズは、それらに関連するスピル・リスト406および422と一緒に、動的に変更可能であり、これによって、複雑な辺交差要件を有する大きい画像を処理するために十分な範囲が提供される。
【0093】
優先順位決定モジュール500の動作を、図5を参照して以下に説明する。辺処理モジュール400からの着信メッセージ498は、優先順位データ設定メッセージ、塗潰しデータ設定メッセージ、辺交差メッセージおよびスキャン・ラインの終りメッセージが含まれる可能性があるが、優先順位更新モジュール506によって読み取られる前に、まず先入れ先出し(FIFO)バッファ518を通過する。FIFO518は、辺処理モジュール400の動作と優先順位決定モジュール500の動作を分離するように働く。優先順位状態テーブル502は、上で述べたテーブル34の一部を含むが、各オブジェクトの優先順位に関する情報を保持するのに使用される。FIFO518は、エッジ交差のスキャン・ライン全体の辺処理モジュール400からの受取りと優先順位状態テーブル502への転送を単一の処置で可能にするサイズであることが好ましい。これによって、優先順位決定モジュール500が、同一の画素(X)位置での複数の辺交差を効率的に処理できるようになる。優先順位状態テーブル502の各レコードには、以下が記録される。
【0094】
(i)この優先順位が、奇数−偶数塗潰し規則または非ゼロ・ワインディング塗潰し規則の適用によって決定される内部/外部状態を有するかどうかを示す塗潰し規則フラグ
(ii)この優先順位をもたらす辺が交差するたびに塗潰し規則によって示される形で変更される塗潰しカウント
(iii)この優先順位がクリッピングと塗潰しのどちらに使用されるかを示すクリッパ・フラグ
(iv)クリッパ・フラグがセットされている辺について、クリッピング・タイプが「クリップ・イン」と「クリップ・アウト」のどちらであるかを記録するクリップ・タイプ・フラグ
(v)この優先順位をもたらすクリップ・イン・タイプのクリップ領域に入る時にデクリメントされ、出る時にインクリメントされ、この優先順位をもたらすクリップ・アウト・タイプのクリップ領域に入る時にインクリメントされ、出る時にデクリメントされる、クリップ・カウント
(vi)「ニード・ビロウ」フラグと称する、この優先順位がそれ未満のレベルを最初に計算することを必要とするかどうかを記録するフラグ。
【0095】
クリッピング・オブジェクトは、当技術分野で既知であり、特定の新しいオブジェクトを表示するように働くのではなく、画像内の別のオブジェクトの形状を変更するように働く。クリッピング・オブジェクトは、さまざまな視覚的効果を達成するために、オンにし、オフにすることもできる。たとえば、図8のオブジェクト80は、オブジェクト90に対して、オブジェクト90のうちでクリッピング・オブジェクト80の下にある部分を除去するように働くクリッピング・オブジェクトとして構成することができる。これは、クリッピング境界内における、オブジェクト90の下にある、クリッピングされていなければオブジェクト90の不透明さによって隠されるオブジェクトまたは画像を見せるという効果を有する。
【0096】
図13Aおよび図13Bに、奇数−偶数規則と非ゼロ・ワインディング規則の応用例を示す。非ゼロ・ワインディング規則の目的のために、図13Aに、オブジェクト70の辺71および72が、辺が下向きと上向きのどちらであるかに従って概念上の向きをどのように割り振られるかを示す。閉じた境界を形成するために、辺は、境界に沿って始点と終点が重なる形でリンクする。塗潰し規則(後で適用され、説明される)の目的のために辺に与えられる向きは、線分が定義される順序と独立である。辺の線分は、レンダリングの方向に対応する、追跡される順序で定義される。
【0097】
図13Bに、2つの下向きの辺73および76と、3つの上向きの辺74、75および77を有する単一のオブジェクト(五線星形)を示す。奇数−偶数規則は、各辺が対象のスキャン・ラインと交差するたびにブール値を単純にトグルし、したがって、効果的にオブジェクト色をオンにするかオフにすることによって動作する。非ゼロ・ワインディング規則では、交差する辺の向きに応じて塗潰しカウント値をインクリメントまたはデクリメントする。図13Bでは、このスキャン・ラインで出会う最初の2つの辺73および76が下向きであり、したがって、これらの辺の横断によって、塗潰しカウントがインクリメントされ、それぞれ+1および+2になる。このスキャン・ラインが出会う次の2つの辺74および77は、上向きであり、したがって、塗潰しカウントがそれぞれ+1および0にデクリメントされる。
【0098】
いくつかの実施形態では、この情報の一部が、表示リスト13および前に説明したさまざまな辺リストの辺に関連し、辺交差メッセージの一部として優先順位決定モジュール500に転送される。具体的に言うと、塗潰し規則フラグ、クリッパ・フラグ、クリップ・タイプ・フラグおよびニード・ビロウ・フラグを、この形で処理することができる。
【0099】
図5に戻って、優先順位更新モジュール506は、それが処理を完了したものまでのスキャン・ライン交差座標を記録するカウンタ524を維持する。これを、優先順位更新モジュール506の現行Xと称する。スキャン・ラインの開始時の初期値は0である。
【0100】
FIFO518の先頭で受け取った辺交差メッセージを検査する際に、優先順位更新モジュール506は、辺交差メッセージのX交差値とその現行Xを比較する。辺交差メッセージのX交差値が、優先順位更新モジュール506の現行X以下の場合には、優先順位更新モジュール506は、その辺交差メッセージを処理する。辺交差メッセージの処理は、2つの形態になり、「通常辺処理」(下で説明する)は、辺交差メッセージの最初の優先順位によって示される優先順位状態テーブル502内のレコードが、クリップ優先順位でないことを示すクリッパ・フラグを有する時に使用され、そうでない場合には、「クリップ辺処理」(下で説明する)が実行される。
【0101】
優先順位がある画素でアクティブになるのは、その画素が、その優先順位の塗潰し規則に従って優先順位に適用される境界辺の内部にあり、その優先順位のクリップ・カウントが0の場合である。優先順位は、それが最も上のアクティブな優先順位である場合、または、それより上位のアクティブな優先順位のすべてが、対応するニード・ビロウ・フラグをセットしている場合に、公開される。この形で、画素値を、公開された優先順位の塗潰しデータだけを使用して生成することができる。
【0102】
ある優先順位のニード・ビロウ・フラグは、表示リストの情報内で確立され、そのフラグがセットされていなければ、問題の優先順位の下のアクティブな優先順位のすべてが、レンダリング中の画素値に寄与しないことを画素生成システムに知らせるのに使用される。このフラグは、最終的な画素値に全く寄与しないはずの余分な合成演算を防ぐのに適当な場合にクリアされる。
【0103】
「通常辺処理」には、辺交差メッセージ内の優先順位のそれぞれについて、その優先順位によって示される優先順位状態テーブル・レコードのフィールドに関して、以下のステップが含まれる。
【0104】
(i)現在の優先順位の現在の塗潰しカウントを記録し、
(ii)現在の優先順位の塗潰し規則が、
(a)奇数−偶数である場合には、塗潰しカウントが現在0以外であれば塗潰しカウントに0をセットし、そうでない場合には0以外の値をセットし、
(b)非ゼロ・ワインディングである場合には、塗潰しカウントをインクリメントまたはデクリメント(辺の方向フラグに応じて)し、
(iii)新しい塗潰しカウントと記録された塗潰しカウントを比較し、一方が0で他方が0以外の場合には、現在の優先順位に対して「アクティブ・フラグ更新」(下で説明する)動作を実行する。
【0105】
いくつかの実施形態では、辺交差メッセージのそれぞれに複数の優先順位を置くのではなく、優先順位ごとに別々の辺交差メッセージを使用することができる。
【0106】
アクティブ・フラグ更新動作には、まず現在の優先順位のための新しいアクティブ・フラグを確立することが含まれる。アクティブ・フラグは、優先順位状態テーブル502のその優先順位の塗潰しカウントが0以外であり、その優先順位のクリップ・カウントが0の場合に0以外になり、そうでない場合には、アクティブ・フラグは0になる。アクティブ・フラグ更新動作の第2ステップは、アクティブ・フラグ配列508内の現在の優先順位によって示される位置に、決定されたアクティブ・フラグを格納し、現在の優先順位の優先順位状態テーブルのニード・ビロウ・フラグが0の場合には、不透明アクティブ・フラグ配列510の現在の優先順位によって示される位置にもアクティブ・フラグを格納することである。
【0107】
「クリップ辺処理」には、辺交差メッセージの最初の優先順位によって示される優先順位状態テーブル・レコードのフィールドに関して、以下のステップが含まれる。
【0108】
(i)現在の優先順位の現在の塗潰しカウントを記録し、
(ii)現在の優先順位の塗潰し規則が、
(a)奇数−偶数である場合には、塗潰しカウントが現在0以外であれば塗潰しカウントに0をセットし、そうでない場合には0以外の値をセットし、
(b)非ゼロ・ワインディングである場合には、塗潰しカウントをインクリメントまたはデクリメント(辺の方向フラグに応じて)し、
(iii)新しい塗潰しカウントと記録された塗潰しカウントを比較し、
(a)新しい塗潰しカウントが0であり、記録された塗潰しカウントが0である場合、または、新しい塗潰しカウントが0以外であり、記録された塗潰しカウントが0以外である場合には、0、
(b)現在の優先順位のクリップ・タイプ・フラグがクリップ・アウトであり、記録された塗潰しカウントが0であり、新しい塗潰しカウントが0以外である場合、または、現在の優先順位のクリップ・タイプ・フラグがクリップ・インであり、記録された塗潰しカウントが0以外であり、新しい塗潰しカウントが0である場合には、+1、
(c)それ以外の場合には、−1
のクリップ・デルタ値を決定し、
(iv)辺交差メッセージの最初の優先順位の後のすべての後続優先順位について、その後続優先順位によって示される優先順位状態テーブル内のレコードのクリップ・カウントに決定されたクリップ・デルタ値を加算し、その処理で、クリップ・カウントが、0以外から0になった場合または0から0以外になった場合に、その後続優先順位に対して上で説明したアクティブ・フラグ更新動作を実行する。各クリップ・カウントの初期値は、前に説明したLOAD_LEVEL_PROPERTIES命令によってセットされることに留意されたい。クリップ・カウントは、通常は、各優先順位に影響するクリップ・イン優先順位の数に初期設定される。
【0109】
いくつかの実施形態では、優先順位がクリップに関連付けられず、その代わりに、辺交差メッセージで与えられるすべての優先順位のクリップ・カウントが直接にインクリメントまたはデクリメントされる。この技法は、たとえば、クリップ形状が単純であり、複雑な塗潰し規則の適用が不要な時に使用することができる。この特定の応用例では、辺によって制御されるレベルのクリップ・カウントは、上向きの辺の場合にインクリメントされ、下向きの辺の場合にデクリメントされる。反時計回りに記述された単純な閉じた曲線は、クリップ・インとして働き、時計回りに記述された単純な閉じた曲線は、クリップ・アウトとして働く。
【0110】
辺交差メッセージのX交差値が、優先順位更新モジュール506の現行Xを超える時には、優先順位更新モジュール506は、生成する画素数のカウントすなわち、辺交差メッセージのX交差値と現行Xの間の差を形成し、このカウントを優先順位生成メッセージにフォーマットし、接続520を介して優先順位生成モジュール516に送る。その後、優先順位更新モジュール506は、所与の個数の画素の処理が完了したことを示す優先順位生成モジュール516からの信号522を待つ。信号522を受け取った時に、優先順位更新モジュール506は、その現行Xに、辺交差メッセージのX交差値をセットし、上で説明した処理を継続する。
【0111】
優先順位生成モジュール516は、テーブル34内でも形成される、各優先順位に関する情報を保持するのに使用される、優先順位データ・テーブル504に関して動作する。優先順位データ・テーブル504の各レコードには、以下が含まれる可能性がある。
【0112】
(i)塗潰しテーブル・アドレス
(ii)塗潰しタイプ
(iii)ラスタ演算コード
(iv)アルファ・チャネル演算コード
(v)「ソース・ポップ」フラグ
(vi)「デスティネーション・ポップ」フラグ
(vii)本明細書で「x独立」フラグと称する、この優先順位の色が所与のYに対して一定であるかどうかを記録するフラグ。
【0113】
優先順位生成メッセージの受取り520の際に、優先順位生成モジュール516は、供給されたカウントによって示される回数だけ「画素優先順位生成動作」(下で説明する)を実行し、その後すぐに、動作を完了したことを知らせる信号522を優先順位更新モジュール506に送る。
【0114】
各画素の優先順位生成動作には、まず不透明アクティブ・フラグ配列510に対して優先順位エンコーダ514(たとえば、4096対12ビット優先順位エンコーダ)を使用して、最高の不透明アクティブ・フラグの優先順位の数を決定することが含まれる。この優先順位(もし存在すれば)は、優先順位データ・テーブル504のインデクシングに使用され、そのように参照されたレコードの内容は、優先順位生成モジュール516から塗潰し優先順位メッセージ出力598に形成され、塗潰し色決定モジュール600に送られる。さらに、優先順位が前のステップによって決定された(すなわち、少なくとも1つの不透明アクティブ・フラグがセットされた)場合には、決定された優先順位が保持され、これを「現行優先順位」と称する。優先順位が決定されなかった場合には、現行優先順位に0をセットする。その後、優先順位生成モジュール516は、アクティブ・フラグ配列508に対して変更済み優先順位エンコーダ512を繰り返し使用して、現行優先順位を超える最小のアクティブ・フラグを決定する。そのように決定された優先順位(があれば)は、優先順位データ・テーブル504のインデクシングに使用され、そのように参照されたレコードの内容は、塗潰し優先順位メッセージに形成され、塗潰し色決定モジュール600に送られ598、その後、決定された優先順位が、現行優先順位の更新に使用される。このステップは、優先順位が決定されなくなる(すなわち、現行優先順位を超える、アクティブ・フラグでフラグを立てられた優先順位がなくなる)まで、繰り返し使用される。その後、優先順位生成モジュール516は、画素の終りメッセージを形成し、塗潰し色決定モジュール600に送る。
【0115】
上で説明した基本動作に対する好ましい特徴として、優先順位生成モジュール516は、シーケンスの最初の画素を処理する間に、塗潰し色決定モジュール600に転送する各メッセージのx独立フラグの値を記録する。転送されるメッセージのすべてでx独立フラグが指定されている場合には、隣接する辺交差の間の画素のスパンのすべての後続メッセージを、カウント−1の単一の反復指定によって置換することができる。これは、反復メッセージを作り、このシーケンスのその後の処理のすべての代わりに塗潰し色決定モジュール600に送ることによって行われる。
【0116】
上で説明した基本動作に対するもう1つの好ましい特徴として、優先順位生成モジュール516は、各レベル生成メッセージの後に、接続522を介して優先順位更新モジュール506に最高の不透明優先順位を送る。優先順位更新モジュール506は、これをストア526に保持する。その後、優先順位更新モジュール506は、メッセージのX交差が現行Xより大きいことを単純にテストするのではなく、画素優先順位生成メッセージを作る前に、メッセージのX交差が現行Xより大きいこと、およびメッセージ内のレベルのうちの少なくとも1つが、最高の不透明優先順位以上であることをテストする。これを行うことによって、より少ない数の画素優先順位決定動作を実行することができ、より長い反復シーケンスを生成することができる。
【0117】
いくつかの実装で所望されるように、動作の反復メッセージまたはシーケンスが使用されない場合、同様の機能を、優先順位生成モジュール516の出力にキャッシュまたはFIFO(図示せず)を組み込むことを介して達成できる。これは、たとえば4セル・キャッシュによって実施できる。キャッシュを用いると、優先順位更新モジュール506が、キャッシュがロードされると同時に作業を継続でき、これによって、出力598へのキャッシュのフラッシュと独立に次の優先順位レベルを生成できるようになる。
【0118】
図8および図9A,Bに示されたグラフィック・オブジェクトの例を使用して、上で説明した優先順位更新処理を、図12Cないし図12Jおよび図15Aないし図15Eに示された辺の交差を使用して、スキャン・ライン35に関して示すことができる。
【0119】
図15Aないし図15Eは、優先順位テーブル502および504の動作を示す図であり、優先順位テーブル502および504は、好ましい実施形態では、配列508および510とエンコーダ512および514と共に、レベル・アクティブ化テーブル530と称する単一のテーブルに合併される。図15Aからわかるように、辺交差メッセージは、辺処理モジュール400からスキャン・ラインの順で受け取られ、テーブル530にロードされ、テーブル530は、優先順位の順で配置される。辺交差メッセージには、この例では、辺横断の非ゼロ・ワインディング規則に従うインクリメント方向が含まれる。優先順位テーブル530内の項目をセットしないことも可能である。
【0120】
図示のレベル・アクティブ化テーブル530には、非ゼロ・ワインディング規則または、適当な場合には奇数−偶数規則に従って辺から決定される塗潰しカウントのための列項目が含まれる。ニード・ビロウ・フラグは、優先順位の特性であり、LOAD_PRIORITIES_PROPERTIES命令の一部としてセットされる。ニード・ビロウは、テーブル530がロードされる時に、すべての優先順位レベルについてセットされる。「クリップ・カウント」および「塗潰しインデックス・テーブル」などの他の列を使用することができるが、この例では、説明を簡単にするために省略する。どのレベルもアクティブでない場合、対応する項目に0がセットされる。さらに、配列510および508の値は、後続の辺交差を受け取った後に、テーブル530から更新される。
【0121】
図15Aから、便宜上、複数のレコードが明瞭さのために省略されていることは明白である。通常、レベル・アクティブ化テーブル530には、優先順位の順で配置された、以下のレコードが含まれるはずである。
【0122】
・塗潰しカウント
・クリップ・カウント
・塗潰しタイプ
・下記を含むアクティブ化条件およびフラグ
(i)ニード・ビロウ・フラグ
(ii)クリップ・タイプ
(iii)クリッパ・フラグ
・下記を含む合成用グラフィック演算およびフラグ
(i)ラスタ演算コード
(ii)アルファ・チャネル演算コード
(iii)「ソース・ポップ」フラグ
(iv)「デスティネーション・ポップ」フラグ
(v)x独立フラグ
・塗潰し規則
・属性
・塗潰しテーブル・インデックス。
【0123】
テーブル530の内容は、優先順位決定モジュール500で使用されない場合に、画素生成用の塗潰し色決定モジュール600と合成演算用の画素合成モジュール700のそれぞれにメッセージとして渡される。
【0124】
スキャン・ライン35の最初の辺交差(図12E)を図15Aに示すが、図15Aでは、P=1の場合に、塗潰しカウントが、非ゼロ・ワインディング規則に従って辺の値に更新される。下のオブジェクトは存在しないので、「ニード・ビロウ」は、0にセットされるレベルである。
【0125】
テーブル530の前の状態はセットされていないので、配列510および508は、セットされないままになり、優先順位エンコーダ514は、優先順位の出力をディスエーブルされる。これは、優先順位生成モジュール516によって解釈され、優先順位生成モジュール516は、スキャン・ライン35の最初の空白の部分である「オブジェクトなし」優先順位(たとえばP=0)のカウントn=40(画素)を出力する。
【0126】
図15Bは、図12Fの辺交差を受け取った時の配置を示す図である。塗潰しカウントが更新される。その後、配列510および508は、テーブル530からの前の最高レベルを用いてセットされる。この時点で、モジュール516は、半透明の三角形80との交差の前の不透明な赤いオブジェクト90の辺96を表す、カウントn=45、P=1を出力する。
【0127】
図15Cは、図12Gの辺交差を受け取った時の配置を示す図である。非ゼロ・ワインディング規則のゆえに、塗潰しカウントが下向きに調節されていることに留意されたい。現在の辺交差を受け取る前に有効であるオブジェクトは、不透明ではないので、変更済み優先順位エンコーダ512が、n=(115−85)=30画素の現行として出力される最高のアクティブ・レベルとして優先順位P=2を選択するのに使用される。
【0128】
図15Dは、図12Hの辺交差を受け取った時の配置を示す図である。前に変更されたP=2の「ニード・ビロウ」が、アクティブ配列508に転送され、したがって、優先順位エンコーダが、n=(160−115)=45画素の現行である値P=1を出力することができることに留意されたい。
【0129】
図15Eは、図12Iの辺交差を受け取った時の結果を示す図であり、n=(180−160)=20画素のP=0の出力が供給される。
【0130】
したがって、優先順位モジュール500は、スキャン・ラインのすべての画素に関する、画素のカウントと、対応する優先順位表示値を出力する。
【0131】
塗潰し色決定モジュール600の動作を、図6を参照して、以下に説明する。優先順位判定モジュール500からの着信メッセージ598は、塗潰しデータ設定メッセージ、反復メッセージ、塗潰し優先順位メッセージ、画素の終りメッセージおよびスキャン・ラインの終りメッセージを含み、まず、塗潰しルックアップおよび制御モジュール604に渡される。塗潰しルックアップおよび制御モジュール604は、塗潰し色決定モジュール600のさまざまな構成要素による使用のために、現行X位置カウンタ614および現行Y位置カウンタ616を維持する。
【0132】
スキャン・ラインの終りメッセージを受け取った時には、塗潰しルックアップおよび制御モジュール604は、現行X位置カウンタ614を0にリセットし、現行Y位置カウンタ616をインクリメントする。スキャン・ラインの終りメッセージは、その後、画素合成モジュール700に渡される。
【0133】
塗潰しデータ設定メッセージを受け取った時には、塗潰しルックアップおよび制御モジュール604は、塗潰しデータ・テーブル36の指定された位置602にそのデータを記憶する。
【0134】
反復メッセージを受け取った時には、塗潰しルックアップおよび制御モジュール604は、反復メッセージからのカウントだけ現行X位置カウンタ614をインクリメントする。反復メッセージは、その後、画素合成モジュール700に渡される。
【0135】
画素の終りメッセージを受け取った時には、塗潰しルックアップおよび制御モジュール604は、やはり現行X位置カウンタ614をインクリメントし、この画素の終りメッセージは、その後、画素合成モジュール700に渡される。
【0136】
塗潰し優先順位メッセージを受け取った時には、塗潰しルックアップおよび制御モジュール604は、下記の処理を含む動作を実行する。
【0137】
(i)塗潰し優先順位メッセージからの塗潰しタイプを使用して、テーブル36のレコード・サイズを選択する。
【0138】
(ii)塗潰し優先順位メッセージからの塗潰しテーブル・アドレスと、上で決定されたレコード・サイズを使用して、塗潰しデータ・テーブル36からレコードを選択する。
【0139】
(iii)塗潰し優先順位メッセージからの塗潰しタイプを使用して、塗潰し色の生成を実行するサブモジュールを決定し、選択する。サブモジュールには、ラスタ画像モジュール606、フラット・カラー・モジュール608、リニア・ランプ・カラー・モジュール610および不透明タイル・モジュール612を含めることができる。
【0140】
(iv)決定されたレコードを、選択されたサブモジュール606ないし612に供給する。
【0141】
(v)選択されたサブモジュール606ないし612が、供給されたデータを使用して、色と不透明度の値を決定する。
【0142】
(vi)決定された色と不透明度は、塗潰し色メッセージからの残りの情報、すなわち、ラスタ演算コード、アルファ・チャネル演算コード、ソース・ポップ・フラグおよびデスティネーション・ポップ・フラグと組み合わされて、色合成メッセージを形成し、この色合成メッセージは、接続698を介して画素合成モジュール700に送られる。
【0143】
好ましい実施形態では、決定された色と不透明度が、8ビットの精度の赤、緑、青および不透明度の4つ組であり、通常の形で32ビット/画素が与えられる。しかし、シアン、マゼンタ、黄および黒の、不透明度を含有する4つ組か、他の多数の既知の色表現のうちの1つを、その代わりに使用することができる。赤、緑、青および不透明度の場合を、下の説明で使用するが、この説明は、他の場合にも適用することができる。
【0144】
ラスタ画像モジュール606、フラット・カラー・モジュール608、リニア・ランプ・カラー・モジュール610および不透明タイル・モジュール612の動作を、これから説明する。
【0145】
フラット・カラー・モジュール608は、供給されたレコードを、3つの8ビットの色成分(通常は赤、緑および青の成分と解釈される)と1つの8ビットの不透明度値(通常は、指定された色によって覆われる画素の割合の尺度と解釈され、0は覆われないすなわち完全な透明を意味し、255は完全に覆われるすなわち完全な不透明を意味する)を含む固定フォーマットのレコードと解釈する。この色と不透明度の値は、接続698を介して直接に出力され、それ以上の処理なしで、決定された色および不透明度を形成する。
【0146】
リニア・ランプ・カラー・モジュール610は、供給されたレコードを、3つの色成分および1つの不透明度成分に関連する4組の定数cx、cyおよびdと、リニア・ランプの基準点の座標である2つの位置値xbaseおよびybaseを含む固定フォーマットのレコードと解釈する。基準点では、色成分と不透明度成分が、それに関連付けられたd値を有する。
【0147】
4組のそれぞれについて、結果の値rは、次式を使用して、現在のXY座標とxbaseおよびybase定数に3つの定数を組み合わせることによって計算される。
【0148】
r=clamp(cx×(X−xbase)+cy×(Y−ybase)+d)
ここで、関数clampは、次のように定義される。
【0149】
【0150】
代替実装では、リニア・ランプ・カラー・モジュール610は、供給されたレコードを、3つの色成分および1つの不透明度成分に関連する、4組の3つの定数cx、cyおよびdを含む固定フォーマットのレコードと解釈する。これらの4組のそれぞれについて、結果の値rは、次式を使用して、3つの定数を現行Xカウントであるxおよび現行Yカウントであるyと組み合わせることによって計算される。
【0151】
r=clamp(cx×x+cy×y+d)
ここで、関数clampは、上で定義されたものである。
【0152】
そのように作られた4つの結果は、色と不透明度の値に形成される。この色と不透明度の値は、接続698を介して直接に出力され、それ以上の処理なしで決定された色および不透明度を形成する。
【0153】
同一の結果を与える他の算術計算を使用することができる。
【0154】
不透明タイル・モジュール612は、供給されたレコードを、3つの8ビット色成分、1つの8ビット不透明度値、整数のX位相(px)、Y位相(py)、Xスケール(sx)、Yスケール(sy)および64ビットのマスクを含む固定フォーマットのレコードと解釈する。これらの値は、表示リスト生成から発し、通常は、元のページ記述に含まれる。ビット・マスク内のビット・アドレスaは、次の式で決定される。
【0155】
a=((x/2sx+px)mod 8)+((y/2sy+py)mod 8)×8 。
【0156】
ビット・マスク内のアドレス「a」のビットが検査される。検査されるビットが1の場合には、レコードからの色と不透明度が、モジュール612の出力に直接にコピーされ、決定された色および不透明度を形成する。検査されるビットが0の場合には、3つの0成分値を有する色と0の不透明度値が形成され、決定された色および不透明度として出力される。
【0157】
ラスタ画像モジュール606は、供給されたレコードを、6つの定数a、b、c、d、xbaseおよびybaseと、サンプリングされるラスタ画像画素データ16の各ラスタ・ライン内のビット数の整数カウント(bpl)と、画素タイプとを含む固定フォーマットのレコードと解釈する。画素タイプは、ラスタ画像画素データ内の画素データ16を、次のうちのどれとして解釈するかを示す。
【0158】
(i)1ビット毎画素の白黒不透明画素
(ii)1ビット毎画素の不透明黒または透明の画素
(iii)8ビット毎画素のグレイ・スケール不透明画素
(iv)8ビット毎画素の黒不透明スケール画素
(v)24ビット毎画素の不透明3色成分画素
(vi)32ビット毎画素の3色成分と不透明度の画素
他の多くのフォーマットが可能である。
【0159】
ラスタ画像モジュール606は、画素タイプ・インジケータを使用して、ビット単位の画素サイズ(bpp)を決定する。その後、ラスタ画像画素データ16内のビット・アドレスaを、次式から計算する。
【0160】
a=bpp*└a×(x−xbase)+c×(y−ybase)┘
+bpl×└b×(x−xbase)+d×(y−ybase)┘ 。
【0161】
レコード602からの画素タイプに従って解釈された画素は、ラスタ画像画素データ16内の計算されたアドレス「a」から取り出される。この画素は、3つの8ビット色成分と1つの8ビット不透明度成分を有するために、必要に応じて展開される。「展開」とは、たとえば、8ビット/画素のグレイ・スケール不透明ラスタ画像からの画素が、赤、緑および青の成分のそれぞれに適用されるサンプリングされた8ビット値と、完全な不透明がセットされた不透明度成分を持つことを意味する。これが、画素合成モジュール700への決定された色および不透明度の出力698を形成する。
【0162】
その結果、表示可能オブジェクト内で有効なラスタ画素データは、メモリ内の画像画素データ16へのマッピングの決定を介して得られる。これによって、ラスタ画素データのオブジェクト・ベース画像へのアフィン変換が効率的に実施され、これは、グラフィック・オブジェクトとの合成が発生する可能性がある場合に画像ソースからの画素データをフレーム・ストアに転送する従来技術の方法より効率的である。
【0163】
上記に対する好ましい特徴として、任意選択として、ラスタ画像画素データ16内の画素間の補間を、まず中間結果pおよびqを次式に従って計算することによって実行することができる。
【0164】
p=a×(x−xbase)+c×(y−ybase)
q=b×(x−xbase)+d×(y−ybase) 。
【0165】
次に、ラスタ画像画素データ16内の4画素のビット・アドレスa00、a01、a10およびa11を、次式に従って決定する。
a00=bpp×└p┘+bpl×└q┘
a01=a00+bpp
a10=a00+bpl
a11=a00+bpl+bpp 。
【0166】
次に、結果の画素成分値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┘) 。
【0167】
上の諸式で、表現└値┘=floor(値)であり、floor演算では、値の端数部分の切捨が行われる。
【0168】
get関数は、所与のビット・アドレスでの、ラスタ画像画素データ16からサンプリングされた現行画素成分の値を返す。いくつかの画像タイプのいくつかの成分について、これが暗黙の値になる可能性があることに留意されたい。
【0169】
上記に対する好ましい特徴として、任意選択として、供給されたレコードから読み取られるタイル・サイズを用いる剰余演算によって現行X位置カウンタ614および現行Y位置カウンタ616から導出されるxおよびyの値を上式で使用することによって、画像タイリングを実行することができる。
【0170】
多数の他のこのような塗潰し色生成サブモジュールが可能である。
【0171】
画素合成モジュール700の動作をこれから説明する。塗潰し色決定モジュール600からの着信メッセージには、反復メッセージ、色合成メッセージ、画素の終りメッセージおよびスキャン・ラインの終りメッセージが含まれるが、このメッセージは、順番に処理される。
【0172】
反復メッセージまたはスキャン・ラインの終りメッセージを受け取った時には、画素合成モジュール700は、それ以上の処理なしで画素出力FIFO702にそのメッセージを転送する。
【0173】
色合成メッセージを受け取った時には、画素合成モジュール700は、概要を示せば、色合成メッセージからの色と不透明度を、色合成メッセージからのラスタ演算およびアルファ・チャネル演算に従って、画素合成スタック38からポップされた色および不透明度と組み合わせる。その後、結果を画素合成スタック38にプッシュする。色合成メッセージの受取り時に実行される処理の説明は、下で与える。
【0174】
画素の終りメッセージを受け取った時には、画素合成モジュール700は、画素合成スタック38から色と不透明度をポップする。ただし、スタック38が空の場合には不透明の白の値が使用される。結果の色と不透明度は、画素出力FIFOに転送される画素出力メッセージに形成される。
【0175】
既知の合成アプローチは、ポーター(Porter,T)およびダフ(Duff,T)著「Compositing Digital Images」、Computer Graphics誌、Vol.18 No.3、1984年、第253〜259ページに記載されている。ポーター−ダフ合成演算の例を、図21に示す。しかし、このようなアプローチでは、合成によって形成される交差領域内のソースおよびデスティネーションの色の処理だけが可能であり、その結果、交差領域内の透明度の影響に適合できないという点で、不完全である。その結果、ポーターおよびダフによって定義されたラスタ演算は、透明度の存在下で基本的に動作不能である。
【0176】
色合成メッセージを受け取った時に画素合成モジュール700によって実行される処理を、これから説明する。
【0177】
色合成メッセージを受け取った時に、画素合成モジュール700は、まず、ソースの色と不透明度を形成する。これは、色合成メッセージでポップ・ソース・フラグがセットされていない限り、色合成メッセージで供給された色と不透明度が使用され、ポップ・ソース・フラグがセットされている場合には、その代わりに画素合成スタック38から色がポップされる。この時、すなわち、画素合成スタックのポップ中に、画素合成スタック38が空であることがわかった場合、エラー表示なしで不透明の白の色値が使用される。次に、デスティネーションの色と不透明度が、画素合成スタック38からポップされる。ただし、色合成メッセージでデスティネーション・ポップ・フラグがセットされていない場合には、スタック・ポインタが「ポップ」動作中に変更されず、その結果スタック38の最上部からの読み取りになる。
【0178】
ソースの色および不透明度をデスティネーションの色および不透明度と組み合わせる方法を、図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つである。好ましい実施形態に含まれるラスタ演算の一部を、表2に示す。
【0179】
【表3】
【0180】
各関数は、ソース色およびデスティネーション色の対応する色成分の対のそれぞれに適用されて、結果の色において同様の成分が得られる。多くの他の関数が可能である。
【0181】
画素合成メッセージからのアルファ・チャネル演算も考慮されている。アルファ・チャネル演算は、3つのフラグを使用して実行され、フラグのそれぞれは、ソース画素702とデスティネーション画素710のオーバーレイ716内の対象の領域のうちの1つに対応する。領域のそれぞれについて、領域の不透明度値が形成され、この不透明度値は、アルファ・チャネル演算で対応するフラグがセットされていない場合には0、それ以外の場合にはその領域の面積である。
【0182】
結果の不透明度は、領域の不透明度の合計から形成される。結果の色の各成分は、領域の色と領域の不透明度の対のそれぞれの積の和を結果の不透明度で除算することによって形成される。
【0183】
結果の色および不透明度は、画素合成スタック38にプッシュされる。
【0184】
エクスプレッションツリーは、画像の形成に必要な合成演算を記述するのにしばしば使用され、通常は、葉ノード、単項ノードおよび2項ノードを含む複数のノードが含まれる。葉ノードは、エクスプレッションツリーの最も外側のノードであり、子ノードを持たず、画像のプリミティブ要素を表す。単項ノードは、ツリーの単項演算子の下の部分から来る画素データを変更する演算を表す。2項ノードは、通常は、左と右のサブツリーに分岐し、各サブツリー自体は、少なくとも1つの葉ノードを含むエクスプレッションツリーである。
【0185】
任意の形状のオブジェクトとの合成の時には、上で述べたさまざまなスタック演算が、画像の異なる区域について異なり、特定の位置でアクティブなオブジェクトに依存するという問題が生じる。
【0186】
図17Aおよび図17Bに、ソース(S)とデスティネーション(D)の間の通常の2項演算(エクスプレッションツリーとして図示)を示す。実際に実行される演算とは無関係に、図17Aの2項演算は、下に示すアクティビティの4つの場合または領域に分解される。
【0187】
1.(A)Sがアクティブ、(B)Dが非アクティブ
2.(A)Sがアクティブ、(B)Dがアクティブ
3.(A)Sが非アクティブ、(B)Dがアクティブ
4.(A)Sが非アクティブ、(B)Dが非アクティブ。
【0188】
ケース4は、必ず無演算(NOP)が実行される必要があることをもたらし、その結果、2進木のアクティブ・レベルには3つの異なる組合せが存在することになる。この概念の3項、4項およびさらに高次の木への拡張は、当業者には明白である。
【0189】
その結果、合成スタック38(2項の例の場合)を構築する時に、上で識別した3つの演算のうちの1つを、スタックによって実施する必要がある。さらに、スタック内の各オブジェクトに関連する異なる演算は、レベル・アクティブ化テーブルでそのオブジェクトの下にあるものに依存する。ペインタのアルゴリズムで発生する、単純なOVER演算を使用するオブジェクトのレンダリングの場合に、これは問題にならない。しかし、他の合成演算に関して、スタック演算は、合成演算のオペランドのアクティビティに依存して変更される必要がある。これは、スタック演算を提供するレベルをクリッピングすることによって行うことができるが、各レベルに適用されるクリップの数が、急激に増加し、スタック演算の処理が困難になる。問題になる演算の例が、あるオブジェクト(オペランド)が、他方のオブジェクトをクリッピング(その境界を変更)し、交差領域で可変透明度を有する場合の、図21に示されたポーター−ダフ演算のOUTおよびROUTである。
【0190】
この問題に対処するために、本明細書で「アクティビティ」テーブルと称するもう1つのテーブルを設ける。このテーブルは、レベル・アクティブ化テーブルの付属品として働いて、上で述べた代替処置の論理的決定をもたらす。
【0191】
図18Aに、基本的に3つの部分を含む、包括的なアクティビティ・テーブル800を示す。第1部分802は、処理中の特定の塗潰しレベルのアクティブ化条件を提供する。第2部分804には、それぞれのレベル(具体的には2項の例の)に適当な、上で参照した異なる処置のそれぞれが含まれる。第3部分806は、ソース・オブジェクトまたはデスティネーション・オブジェクトが特定のレベルでアクティブであるかどうかを示す。処置部分804に含まれる項目は、具体的な演算そのものとするか、その代わりに、適当な場合にレベル・アクティブ化テーブルへのポインタとすることができることに留意されたい。
【0192】
また、さまざまな演算によって、他の演算にデータを供給することができる場合と、できない場合があることに留意されたい。その結果、アクティビティ・テーブル800は、演算がデータを供給するさまざまな条件を示すフラグを組み込むように変更することができる。
【0193】
アクティビティ・テーブルの好ましい形態のデータ構造を、図18Bにテーブル810として示す。テーブル810には、そのデータを使用する次の演算の項目へのポインタ814(Next_Level)と、その演算がデータを提供するエクスプレッションツリーの枝(Src_Active/Dest_active)を示すフラグ806(または、3項以上のツリーが使用される場合にはフラグの組)が含まれる。テーブル810には、その演算がソース枝またはデスティネーション枝にデータを供給するかどうかを示すフラグ816も含まれる。そうである場合には、次のレベルの項目のSrc_activeまたはDest_Activeフラグ806は、この演算のアクティビティ状態818が変化した時に、それ相応に調節される。演算は、特定の組合せにおいてのみデータを供給するので、これを示すために、別のフラグ812(data_in_*)が設けられる。フラグ812とSrc/Dest_Activeフラグ806の組合せによって、あるレベルのアクティビティ状態が決定される。さらに、どの演算も、それ自体のアクティビティ状態が変化した場合には次のレベルの状態を変更するだけでよいので、ノード・アクティブ・フラグ818が、そのような状況を監視するために設けられる。
【0194】
したがって、右側の葉ノードについて、Push動作と、次の演算レコードのDest_activeフラグをアクティブ化することが必要である。左側の葉ノードについて、デスティネーションがすでにアクティブである可能性があることに留意して、辺交差のSrc_activeフラグをアクティブ化することが必要である。
【0195】
図18Bでは、アクティブ化条件802に、葉ノードのアクティブ化を決定する塗潰し規則と、レベル・アクティブ化テーブルについて上で説明した形で使用される塗潰しカウントが含まれる。クリップ・カウントも、上で説明した形で動作する。辺の交差によって、テーブル810の(ソース)レベルがアクティブ化される。
【0196】
レベルのアクティブ化状態が変化した時には、その変化が、Next_Level項目814によって指されるレベルに伝播される。Data_is_Srcフラグ816の状態に応じて、Src_Active/Dest_Activeフラグ806が、次のレベルで変更される。この変更は、次のレベルの状態も変化する場合に伝播される。テーブル項目には、それぞれ場合1、2および3の演算が格納される。これは、レベル・アクティブ化テーブル内のレベルへのポインタとするか、実際の演算(たとえば、アルファ演算、カラー演算、塗潰しタイプおよびスタック演算フラグ)とすることができる。その代わりに、演算が必要でない場合には、これらをNULLにすることができる。
【0197】
あるノード・レベルのアクティブ化状態は、S∩D ̄op、S∩Dop、S ̄∩Dopのそれぞれのdata_inフラグ群812と、そのノード・レベルのSrc/Dest_activeフラグ806によって決まる、エクスプレッションツリーの次の演算のためのデータがあるかどうかによって決定される。これは、このテーブルではNode_Activeフラグ818として図示されている。
【0198】
この実装の具体的な例を、図19に示されるエクスプレッションツリー830について、図20Aに示される、対応する初期アクティビティ・テーブル820を用いて示す。
【0199】
エクスプレッションツリー830は、オペランドA、BおよびCのページへのレンダリングを提供し、後者は、図示の完全さのために、ツリー830では右の葉ノード、PAGEとして示されている。PAGEは、常にアクティブであり、画像出力空間全体を含み、したがって、アクティビティ・テーブル820から省略することができる。
【0200】
BとCは葉ノードなので、これらは、テーブル820の低位レベルを形成し、それぞれが、それぞれの演算子の合成スタックへのプッシュを引き起こすことのできるアクティブ化演算804をもたらす。これらのそれぞれが右側の葉ノードなので、まずCがプッシュされ、オペランドCに対する演算がないので、S ̄∩DopはNOPになる。data_in_*opフラグ812、Next_Levelフラグ814およびData_is_Srcフラグ816も更新される。オペランドBは、対応する処置をもたらす。
【0201】
アクティビティ・テーブル820の次のレベルは、左の葉ノードAとそれに対応する演算子Op2によって形成される。このレベルのアクティブ化演算804は、それぞれが演算の間の差を表す修飾子aまたはbによってそれぞれが変更されるAop2BであるS ̄∩DopおよびS∩Dopのそれぞれを用いて更新される。演算Op2は、Sのデータを提供するだけであり、これは、DがアクティブでSがアクティブでない(すなわちS ̄∩Dop)場合にスタックからBをポップするアクティビティによって表される。
【0202】
テーブル820の次のレベルは、Op1に関し、アクティブ化演算804でのそれぞれ修飾された結果a、bおよびcを作る。最後のレベルoverでは、PAGEが常にアクティブなので、S∩D ̄opとS ̄∩Dopは、スタックにプッシュされるNOPをもたらす。単純な交差S∩Dop内だけで、overがアクティブになる。
【0203】
この例について、A、BおよびCが、当初は非アクティブであり、これらのオぺランドが、その後、順番にアクティブ化される場合に何が起きるかを検討する。
【0204】
Aが最初にアクティブ化される場合、AOp2aがこのレベルでアクティブ化され、Src_Activeフラグ806の設定に反映される。S∩D ̄フラグ812がセットされているので(Bがまだアクティブではないので)、Node_Activeフラグ818が、このレベルについてセットされる。Node_Activeの状態が変化したので、Op1レベルのSrc_Activeフラグ806がセットされる。Data_is_Src816は、AOp2レベルでセットされることに留意されたい。Op1レベルは、Src_Activeと(Dest_Active) ̄を有するので(Cがまだアクティブではないので)、Op1aが、このレベルでアクティブ化される。S∩D ̄がセットされているので、Node_Active818が、Op1レベルについてセットされる。Node_Active818の状態が変化したので、overレベルのSrc_Activeフラグ806がセットされる。overレベルはSrc_activeとDest_Activeを有する(PAGEが常にアクティブなので)ので、overはこのレベルでアクティブ化される。S∩Dがセットされているので、Node_Activeがセットされ、Node_Activeの状態は変化しない。その後、これ以上の処置は不要である。合成スタック38は、この段階で、テーブル820から確立でき、図20Bに示されたものになる。
【0205】
図20Cに移って、Bが次にアクティブ化される場合、S∩D ̄がセットされている(いずれにせよDは関係ない)ので、このレベルでPush Bがアクティブ化される。Node_Active818は、このレベルについてセットされる。Node_Activeの状態が変化したので、AOp2レベルのDest_Activeフラグがセットされる。その後、AOp2bBがアクティブ化され、AOp2aBが非アクティブ化される。S∩Dがセットされているので、Node_Activeはセットされたままになり、Node_Activeの状態は、AOp2aに関しては変化しない。これ以上の処置は発生しない。合成スタック38は、図20Dに示されたものになる。
【0206】
図20Eからわかるように、Cが次にアクティブ化される場合、このレベルでPush Cがアクティブ化される。Sはアクティブであり、Dは無関係なので、Node_Active818は、このレベルについてセットされる。Node_activeが変化したので、Op1レベルのDest_Activeフラグがセットされる。Op1bがアクティブ化されるので、Op1aは非アクティブ化される。S∩Dのデータがセットされているので、Node_Activeはセットされたままになる。Op1レベルではNode_Activeが変化しないので、これ以上の処置は不要である。合成スタック38は、図20Fに示されたものになる。
【0207】
この手順は、図19のエクスプレッションツリー全体の評価について継続され、したがって、さまざまなアクティブ化条件802およびアクティビティ・インジケータ804による要求に応じて合成スタックにプッシュすることのできるさまざまな演算が確立される形で確立されるアクティビティ・テーブル820をもたらす。この形で、クリッピングまたは実行される他の演算の種類に無関係に、正しいレベルの正しい演算である状態で、評価されるエクスプレッションツリーの複雑さと無関係に、スタックを維持することができる。重要なことに、エクスプレッションツリーの大部分が、表示リストの形成を介して評価されるが、表示リストの生成は、通常は、クリッピングなどのさまざまなオブジェクトの演算の変化を説明することができず、これらの演算は、合成式の評価中に実施することが必要になる。
【0208】
さらなるフラグ、辺の交差によってアクティブ化することのできるsrc_is_leaf_node用のフラグと、dest_is_PAGE(常にアクティブ)用のフラグが、有用になる可能性があることに、さらに留意されたい。dest_is_PAGEの場合、S∩D ̄の場合は絶対に発生しないので、これを無視することが可能である。
【0209】
上では、アクティビティ・テーブル820が、エクスプレッションツリー830の構造に基づいてどのように構築され、その項目が、ツリー830のさまざまなオペランドの変化するアクティブ化を介してどのように完了される(すなわち書き込まれる)かを示した。テーブル820の具体的な例では、異なるアクティブ化と可能な結果を説明するために、72(=2×2×3×3×2)個のスタック構造が生じる可能性がある。この形で、条件802、806、812、814、816および818の論理評価が、特定のレベルの適当なスタック演算として識別される正しいアクティビティ804をもたらす。
【0210】
代替実装では、独立のテーブルとして構成されるのではなく、アクティビティ・テーブル820を、レベル・アクティブ化テーブル530に合併して、組み合わされたテーブル830を与えることができる。これによって、データの複製が行われなくなると同時に、優先順位エンコーダ512および514が正しい辺優先順位だけではなく、アクティブ化演算も選択できるようになり、後者は、モジュール600から導出された塗潰し色を使用する合成モジュール700による評価のために画素合成スタック38に転送(漸進的に)される。このような配置を、図20Gに機能的に図示する。
【0211】
その代わりに、図20Hに機能的に示されているように、アクティビティ・テーブル820が、レベル・アクティブ化テーブル530の前にあってもよい。このような場合には、塗潰しカウントとクリップ・カウントの列を、アクティビティ・テーブル820に含め、レベル・アクティブ化テーブル530から省略することができる。図20Iに機能的に示されているもう1つの代替構成では、アクティビティ・テーブル820が、レベル・アクティブ化テーブル530の後にある。この場合、塗潰しカウントとクリップ・カウントは、レベル・アクティブ化テーブル530に含まれるので、アクティビティ・テーブル820から省略することができる。アクティビティ・テーブル820が図20Aに示されるように構成されるいくつかの応用例では、レベル・アクティブ化テーブル530を省略することができる。
【0212】
アクティビティ・テーブル820およびスタック38に関して上で説明した演算コードは、表示リストから、具体的には命令ストリーム14(図3参照)から導出される。演算コードは、図3に示された処理ステージのパイプラインを介して、他のデータ(たとえば辺交差、塗潰しデータなど)と共に並列に転送され、画素合成モジュール700は、優先順位決定、レベル・アクティブ化および塗潰し決定の結果として決定される順序でopコードをスタックに置く。
【0213】
画素出力モジュール800の動作を、これから説明する。着信メッセージは、画素出力FIFOから読み取られ、これには、画素出力メッセージ、反復メッセージおよびスキャン・ラインの終りメッセージが含まれ、順番に処理される。
【0214】
画素出力メッセージを受け取った時に、画素出力モジュール800は、画素を記憶し、その画素をその出力に転送する。反復メッセージを受け取った時には、最後に記憶した画素が、反復メッセージからのカウントによって指定される回数だけ、出力898に転送される。スキャン・ラインの終りメッセージを受け取った時には、画素出力モジュール800は、そのメッセージをその出力に渡す。
【0215】
出力898は、必要に応じて、画素画像データを使用する装置に接続することができる。このような装置には、ビデオ表示ユニットまたはプリンタなどの出力装置、または、ハード・ディスク、ライン・ストア、バンド・ストアまたはフレーム・ストアを含む半導体RAMなどのメモリ記憶装置、または、コンピュータ・ネットワークが含まれる。
【0216】
ここまでに説明してきたシステムの実施に伴う困難の1つが、多くの場合に、このシステムが、関連する不透明度値を有する画素を含むオブジェクトの合成を適切に処理しないことである。具体的に言うと、いくつかの状況で、スキャン・ラインに沿った、オブジェクトのうちの1つまたは複数がアクティブでない位置において、重なり合うオブジェクトが不正に合成される。この実施形態でのその状況は、ポーター−ダフ合成に伴って生じるので、その特定の合成方式に関して説明する。しかし、下で詳細に説明する本発明の態様は、他の合成方式の下で生じる同様の困難にも適用可能であることを諒解されたい。
【0217】
たとえば、式PAGE←(A in B)over(C out D)over PAGEは、図22に示された2進木構造1000として表すことができる。ここで、A、B、CおよびDは、辺、表示優先順位および不透明度データによって定義される異なるグラフィカル・オブジェクトである。この例のレベル・アクティブ化テーブル1001を図23に示す。図23では、行1002で、図22に示された式のC out D部分が実施されることがわかる。残念ながら、この構成を使用すると、Dがある画素で非アクティブの場合に、out演算が、DではなくPAGEに対して不正に実行される。Cが不透明でない場合には、これが、レンダリング時に視覚的に不正な外見をもたらす。オブジェクトが潜在的に1未満の不透明度を有する場合のこの種の問題を回避するためには、非アクティブ・オブジェクトが、合成式内でover演算の左側以外の位置に現れてはならない。ほとんどのオブジェクトが、それらが現れるすべてのスキャン・ラインの少なくとも一部で非アクティブになるとすると、これは大問題になる可能性がある。
【0218】
この問題を克服する方法の1つが、透明画素を使用してオブジェクトを「パッド・アウト」することである。この形では、各オブジェクトが、効果的に、合成されるオブジェクトが存在するすべての点に存在するので、ポーター−ダフ式が正しく適用される。これを上の例に適用すると、2進木1000の各葉ノード(すなわちA、B、CおよびD)は、図24および図25に示されるように、オブジェクトの対の和集合を囲む境界ボックスのサイズの透明(ガラス)オブジェクトの上に(over)そのオブジェクトを置く式に置換される。
【0219】
図24では、2つの透明なガラス境界ボックスG1およびG2が示されている。G1は、AおよびBの境界ボックスを表し、G2は、CおよびDの境界ボックスを表す。エクスプレッションツリー1000でこれを実施すると、図25に示された変更されたエクスプレッションツリー1004がもたらされる。対応するレベル・アクティブ化テーブル1005を図26に示す。レベル・アクティブ化テーブル1005と変更されたエクスプレッションツリー1004から明白になるとおり、この変更は、各画素に必要なスタック演算の数のかなりの増加をもたらす。これは、スタック演算が、合成される画素の対の一方または両方が透明の場合に実行されるからである。最終的に達成される、実際にレンダリングされる出力に関しては、これらの演算は、スタック資源とプロセッサ時間について比較的浪費的である。
【0220】
演算の数を減らす方法の1つは、ガラス・オブジェクトが合成される葉ノード・オブジェクトを用いてガラス・オブジェクトをクリップ・アウトすることである。その場合、葉ノードと透明オブジェクトの間のover演算は、もはや不要になる。クリッピング動作が、一般に、複数の合成演算よりプロセッサ集中的でないという事実に鑑みて、これは、より効率的なスタックの操作をもたらす。
【0221】
AおよびBによる透明ボックスG1のクリッピングとCおよびDによる透明ボックスG2のクリッピングを使用する、上の例のレベル・アクティブ化テーブル1006を、図27に示す。この実装では、1画素について、複数のover演算を使用してA、B、CおよびDがパディングされる場合の12個のスタック演算と比較して、8つのスタック演算だけが実行されることに留意されたい。これらのレベルのうちの4つは、クリッピング・レベル999である。しかし、それでも透明画素を用いる複数の冗長な合成演算が必要であることを諒解されたい。
【0222】
1つまたは複数の重なり合うオブジェクトが不透明でない場合にポーター−ダフ合成を正しく実施する好ましい方法を、これから説明する。図28に示された例を参照すると、演算C out Dは、領域C∩D ̄、C∩DおよびC ̄∩Dのそれぞれについて1つずつの、3つの形で表現できる。領域C∩D ̄は、Cによって表現できる。というのは、その領域でout演算に関してDからの寄与がなく、Cが必要だからである。領域C∩Dでは、CとDの両方がアクティブであり、したがって、C out D演算を使用する合成が必要である。領域C ̄∩Dでは、CまたはDからの寄与がないので、この領域は、その領域内の画素について合成スタックを構築する時に検討する必要がない。
【0223】
C out D演算を簡略化した表現を、図42および図43に示す。図42には、out演算が実行されるオブジェクトCおよびDが示されている。上で説明したように、スキャン・ラインは、3つの領域C∩D ̄、C∩DおよびC∩D ̄に分割できる。この場合では、Cが不透明でない場合に、領域C∩D ̄内で、out演算がPAGEに対して不正に実行される。
【0224】
図43に、前に説明した解決策を示す。オブジェクトのそれぞれが、それがアクティブになる領域にクリッピングされていることに留意されたい。領域C∩D ̄は、単にレベルC1によって表され、領域C∩Dは、レベルC1およびD1によって表され、領域C ̄∩Dは、どちらのレベルからの入力も必要としない。必要な領域だけへのオブジェクトのクリッピングを制御するために特定の演算に固有の必要条件を使用することによって、透明のパディング画素がもはや不要になるので、かなり少ない数の合成演算がもたらされることを諒解されたい。
【0225】
この例のクリッピングを実施するためのレベル・アクティブ化テーブル1008を、図29に示す。前に説明した方法と比較して、レベル・アクティブ化テーブル1008では、4つの追加レベルが必要であることがわかる。しかし、これら4つの追加レベルのうちの3つは、クリッピング・レベル1015であり、これは、通常は合成演算より集中的でない。また、各画素について作られる実際の合成スタックは、平均して、前に説明した方法の場合より小さい。これは、合成演算が、関連する領域内でのみ行われることを保証するために、クリッピング演算が使用されているという事実に起因する。要するに、プロセッサ時間は、最終的な画像に寄与しない画素の合成に浪費されない。
【0226】
非自明(non-trivial)ポーター−ダフ合成演算子のための合成スタック演算を、図30および図31に示す。図30に示されたテーブル1010では、Dがアクティブの場合にはDがすでにスタックの最上部にあり、合成演算子は、それが適用される領域に従って分割されると仮定する。アルファ・チャネル(不透明度)演算は、Sの辺上でアクティブ化し、Dの辺を用いてクリッピングすることによって、交差領域S∩Dに制限されることに留意されたい。アスタリスクでマークされた事例では、Dに寄与するオブジェクトのすべてが、Sの辺によってクリップ・インされる必要がある。
【0227】
図31のテーブル1016は、S画素値が、それがアクティブになる領域内で、すでにスタック上にある場合の演算を提供する。そのような場合には、D画素値は、Dもアクティブである次の下位レベルにある。アスタリスクでマークされた事例では、スタックは不正な状態になり、その状態が発生しないようにするために「アクティブな枝」のオブジェクトを「非アクティブ」な枝のオブジェクトによってクリッピングするか、最上部の値をスタックからポップするかのいずれかが必要になる。
【0228】
複雑な式の場合、オブジェクトが複数の他のオブジェクトから構築され、その結果、領域SおよびDの形状を、それらの構築に使用された形状から判定する必要が生じる場合がある。このより複雑な事例を実施するのに必要なステップは、ポーター−ダフ合成演算の当業者には明白である。
【0229】
さまざまな合成演算によって作られる結果のアクティブ領域を、図32に示されたテーブル1011に示す。
【0230】
好ましい実施形態を使用してレンダリングのためにエクスプレッションツリーを分析する場合には、アプリケーションは、効果的に木の枝ノードのそれぞれのアクティブ領域を決定し、それを木の次の上位ノードに渡す必要がある。図22に示されたエクスプレッションツリーの詳細な分析を、図33ないし図41に関して、この方針に沿って行う。
【0231】
図33に、各ノードに関連する演算から生じるアクティブ領域に基づく、図22に示されたエクスプレッションツリー1000の予備分析を示す。図34を参照すると、A in B式が、アクティビティにおいてAとBの交差領域に制限されることがわかる。したがって、オブジェクトAの辺が、オブジェクトBのクリッピングに使用され、その結果、不要な場合にスタックに色が残されなくなる。同様に、in演算を実行するレベルは、オブジェクトBによる交差領域に制限される。これを達成するのに必要なスタック演算を、図35に示す。
【0232】
オブジェクトBの辺を使用して両方のレベルをアクティブ化し、オブジェクトAを用いてこの両方のレベルをクリッピングすることによって、クリッピング・レベルを節約しながら、同一の効果を得ることができる。しかし、エクスプレッションツリーのより上位のオブジェクトが、この両方のクリッピング・オブジェクトを必要とする。
【0233】
次の枝は、図36に示されるover演算であり、この図には、2つの枝のアクティブ領域が示されている。検討しなければならない領域を、図37に示す。図37の右側の箱に囲まれたテキスト1012は、左側に示される対応する領域1013のそれぞれのスタックの状態を示す。
【0234】
後者の2つの場合、over演算の結果がすでにスタックにある。したがって、交差領域は、さらに演算が必要な領域だけになる。結果のレベル・アクティブ化テーブル項目を、図38に示す。オブジェクトCがレベルO1をアクティブ化し、AおよびBが、それを領域A∩B∩Cにクリッピングすることがわかる。この演算全体としては、領域(A∩B)∪C内の画素に寄与する。
【0235】
この領域は、エクスプレッションツリーの次のノードに渡されるが、そのノードは、最後のoverであり、これによって、この式がPAGEに合成される。2つの枝のそれぞれについて検討しなければならない関連領域を図40に示す。図40では、やはり、右側の箱に囲まれたテキスト1014に、左側に示される対応するアクティブ領域1015のスタックの状態を示す。
【0236】
和集合演算の画素スタックの正しい動作を得ることは、多少の労力を必要とする。1つの解決策は、区域を相互に排他的な区域に分割し、同一の演算のために2つのレベルを使用することである。これは、前のノードの枝のそれぞれのアクティブ領域を使用して、レベルのうちの1つをアクティブ化することによって行うことができる。レベルのうちの1つのアクティブ領域は、他方のレベルのクリップ・アウトに使用される。たとえば、当業者に諒解されるように、区域Cと区域A∩B∩C ̄を使用して、(A∩B)∪Cを作ることができる。
【0237】
この例の式のレベル・アクティブ化テーブルの結果の項目1020を、図41に示す。レベルO2(オブジェクトCによってアクティブ化される)およびO3(オブジェクトAによってアクティブ化され、Bによってクリップ・インされ、Cによってクリップ・アウトされる)を組み合わせて、領域(A∩B)∪Cに対する最終的なover演算をクリッピングする。
【0238】
クリッピング・レベルは、画素の合成に寄与しないことに留意されたい。寄与するレベルの数、したがって、各画素のスタック演算の数は、平均して、レベルが透明画素によってパッド・アウトされる場合の方法よりかなり少ない。また、所与のスキャン・ライン内で特定のレベルがアクティブになる可能性があると期待される画素の数も減る。
【0239】
多数のレベルにわたるオブジェクトの合成も、本明細書に記載の方法の外挿によって可能であることを、当業者は諒解するであろう。さらに、示されたさまざまな操作を、フレームストア・ベース・システムおよび他のスタック・ベース、ライン・ベースまたはバンド・ベースの合成システムを含む異なる合成パラダイムで使用することができることも諒解されるであろう。
【0240】
前述から、本明細書に記載の方法および装置が、レンダリング処理中の画素画像データの中間記憶を必要とせずに、洗練されたグラフィック記述言語が必要とする機能性のすべてを備えたグラフィック・オブジェクトのレンダリングを提供することは、明白であろう。
【0241】
前述は、本発明の複数の実施形態を記述したのみであり、本発明の趣旨および範囲と、ここまでに付加されたさまざまな態様から逸脱せずに変更を行うことができる。
【図面の簡単な説明】
【図1】好ましい実施形態を組み込まれるコンピュータ・システムの概略ブロック図である。
【図2】好ましい実施形態の機能データ・フローを示すブロック図である。
【図3】好ましい実施形態の画素シーケンシャル・レンダリング装置と、関連する表示リストおよび一時ストアの概略ブロック図である。
【図4】図2の辺処理モジュールの概略機能図である。
【図5】図2の優先順位決定モジュールの概略機能図である。
【図6】図2の塗潰しデータ決定モジュールの概略機能図である。
【図7A】ソースとデスティネーションの間の画素の組合せを示す図である。
【図7B】ソースとデスティネーションの間の画素の組合せを示す図である。
【図7C】ソースとデスティネーションの間の画素の組合せを示す図である。
【図8】好ましい実施形態の演算を説明するための例として使用される、オブジェクトが2つある画像を示す図である。
【図9A】図8のオブジェクトのベクトル辺を示す図である。
【図9B】図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】奇数−偶数塗潰し規則と非ゼロ・ワインディング塗潰し規則を示す図である。
【図13B】奇数−偶数塗潰し規則と非ゼロ・ワインディング塗潰し規則を示す図である。
【図14A】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図14B】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図14C】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図14D】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図14E】X座標の大きな変化がスピル条件にどのように寄与し、それらがどのように処理されるかを示す図である。
【図15A】図5の配置によって実施される優先順位更新ルーチンを示す図である。
【図15B】図5の配置によって実施される優先順位更新ルーチンを示す図である。
【図15C】図5の配置によって実施される優先順位更新ルーチンを示す図である。
【図15D】図5の配置によって実施される優先順位更新ルーチンを示す図である。
【図15E】図5の配置によって実施される優先順位更新ルーチンを示す図である。
【図16A】2つの従来技術の辺記述フォーマットと、好ましい実施形態で使用される辺記述フォーマットを比較するための図である。
【図16B】2つの従来技術の辺記述フォーマットと、好ましい実施形態で使用される辺記述フォーマットを比較するための図である。
【図16C】2つの従来技術の辺記述フォーマットと、好ましい実施形態で使用される辺記述フォーマットを比較するための図である。
【図17A】エクスプレッションツリーとして示される単純な合成式と対応する図を示す図である。
【図17B】エクスプレッションツリーとして示される単純な合成式と対応する図を示す図である。
【図18A】正確なスタック演算を保証するために構成されたテーブルを示す図である。
【図18B】図18Aのテーブルの好ましい形態を示す図である。
【図19】例のエクスプレッションツリーを示す図である。
【図20A】図19の式のアクティビティ・テーブル評価と、そのような評価の間の対応する合成スタックを示す図である。
【図20B】図19の式のアクティビティ・テーブル評価と、そのような評価の間の対応する合成スタックを示す図である。
【図20C】図19の式のアクティビティ・テーブル評価と、そのような評価の間の対応する合成スタックを示す図である。
【図20D】図19の式のアクティビティ・テーブル評価と、そのような評価の間の対応する合成スタックを示す図である。
【図20E】図19の式のアクティビティ・テーブル評価と、そのような評価の間の対応する合成スタックを示す図である。
【図20F】図19の式のアクティビティ・テーブル評価と、そのような評価の間の対応する合成スタックを示す図である。
【図20G】アクティビティ・テーブルと関連モジュールのさまざまな構成を示す図である。
【図20H】アクティビティ・テーブルと関連モジュールのさまざまな構成を示す図である。
【図20I】アクティビティ・テーブルと関連モジュールのさまざまな構成を示す図である。
【図21】複数の合成演算の結果を示す図である。
【図22】オブジェクトA、B、CおよびDに対して一連のポーター−ダフ合成演算を実施するためのエクスプレッションツリーを示す図である。
【図23】図22に示された2進木構造を実施するためのレベル・アクティブ化テーブルを示す図である。
【図24】透明なガラス・オブジェクトの上に置かれた、図22に示された2進木のオブジェクトを示す図である。
【図25】図24に示された配置を実施するための、変更されたエクスプレッションツリーを示す図である。
【図26】図25のエクスプレッションツリーを実施するためのレベル・アクティブ化テーブルを示す図である。
【図27A】透明な箱がA、B、CおよびDによってクリッピングされる、図24および図25に示された例の代替のレベル・アクティブ化テーブルを示す図である。
【図27B】透明な箱がA、B、CおよびDによってクリッピングされる、図24および図25に示された例の代替のレベル・アクティブ化テーブルを示す図である。
【図28】演算C out Dのエクスプレッションツリーを示す図である。
【図29A】図28に示されたクリッピングを実施するためのレベル・アクティブ化テーブルを示す図である。
【図29B】図28に示されたクリッピングを実施するためのレベル・アクティブ化テーブルを示す図である。
【図30】自明でないポーター−ダフ合成演算子のための合成スタック演算を示す図である。
【図31】自明でないポーター−ダフ合成演算子のための合成スタック演算を示す図である。
【図32】さまざまな演算子のアクティブ領域を示す図である。
【図33】式の実施に使用されるステップの予備分析を含む、図22に示されたものに類似のエクスプレッションツリーを示す図である。
【図34】図33に示されたエクスプレッションツリーからのA in B式のアクティブ領域を示す図である。
【図35】図34に示されたin演算を実行するのに必要なスタック演算を示す図である。
【図36】下のin演算およびout演算からのアクティブ領域を示す、図33のover演算の詳細を示す図である。
【図37】図36の式に関連して検討される領域のそれぞれのスタックの状態を示す図である。
【図38】図36および図37に示された演算を実施するためのレベル・アクティブ化テーブル項目を示す図である。
【図39】下のover式およびpage式からのアクティブ領域を示す、図33のエクスプレッションツリーからの最終的なover演算を示す図である。
【図40】図39の式で検討される領域を示す図である。
【図41A】図39に示された式を実施するためのレベル・アクティブ化テーブルの結果の項目を示す図である。
【図41B】図39に示された式を実施するためのレベル・アクティブ化テーブルの結果の項目を示す図である。
【図42】アクティブ領域へのクリッピングの実施の前のC out D演算を示す図である。
【図43】個々のレベルのアクティブ領域へのクリッピングの後のC out D演算を示す図である。
Claims (21)
- ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する方法であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、該処理は前記辺レコードの処理の間に、
限られた数の処理された辺レコードを順序付けされていない第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて、順序付け可能な前記辺レコードを漸進的に順次に第2バッファへ送るステップと、
順序付けできない処理済の辺を、第3バッファにおいて並べるために該第3バッファへ送るステップと、
前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定するステップとを備えることを特徴とする方法。 - 前記第3バッファにおける前記辺レコードの順序付けは、前記第3バッファへ前記辺を追加する際になされることを特徴とする請求項1に記載の方法。
- 前記辺レコードは、前記第3バッファへ挿入され、ソートされることを特徴とする請求項2に記載の方法。
- 前記第3バッファ内の辺は、前記現在のスキャンラインの処理の完了時に順序付けられることを特徴とする請求項3に記載の方法。
- 前記第2及び第3バッファは結合されて、前記選択的処理に用いられる第4バッファのそれぞれの部分を形成し、それにより、前記部分からの順序付けられた辺が漸進的に比較され、前記処理に対する次の辺を決定することを特徴とする請求項2に記載の方法。
- 前記現在のスキャンラインの処理の完了時において、前記第2及び第3バッファの内容と前記第4バッファの内容をスワップすることを特徴とする請求項5に記載の方法。
- 前記第2、第3、第4バッファの各々は、そのスタート位置及びエンド位置のポインタを含み、前記現在のスキャンラインの終了時に、バッファをスワップするために該ポインタをスワップすることを特徴とする請求項6に記載の方法。
- 前記第1バッファは、メモリに形成された辺プールを備え、前記方法は、前記メモリに形成された複数のアクティブ辺レコードから、前記現在のスキャンラインのためのアクティブ辺値を決定し、前記アクティブ辺値の各々に対し、対応する辺レコードを前記辺プールへ送るステップを更に備えることを特徴とする請求項1に記載の方法。
- 前記第2バッファは、前記メモリに形成される現在辺出力リストを備え、前記方法は、前記アクティブ辺値の各々に対して、前記辺プール内のレコードと前記辺レコードの対応する辺レコードを調べ、該辺レコードの順序付けられたものを前記現在辺リストに送るステップを更に備えることを特徴とする請求項8に記載の方法。
- 前記第3バッファは、前記メモリ内に形成された現在スピル出力リストを備え、前記方法は、前記現在のスピルリストへ順次に前記辺プールからの前記現在辺リストに並べることのできない辺レコードを送るステップを更に備えることを特徴とする請求項9に記載の方法。
- 前記方法は、前記スキャンラインの処理の完了時において、前記後続のスキャンラインの処理のために前記出力リストの対応する一つへ順次に前記辺プールからの辺レコードをフラッシュするステップと、ここで、このフラッシュに際しては前記出力リストは現在辺入力リスト及び現在辺入力スピルリストとしてそれぞれ割り当てられるものであり、該後続のスキャンラインに対する前記アクティブ辺値を決定するために前記入力リストから順次に辺レコードを前記アクティブ辺レコードの対応する一つに転送するステップとを備えることを特徴とする請求項10に記載の方法。
- グラフィックオブジェクト描画システムにおいて、ラスター画素イメージを形成するべくグラフィックオブジェクトを処理する方法であって、該処理は、前記グラフィックオブジェクトの辺と前記ラスター画素イメージの現在のスキャンラインとの交差の順序を決定する第1処理を備え、
前記システムが、
現在のスキャンラインと後続のスキャンラインの各々に関する複数の辺レコードと、該辺レコードの各々は少なくとも対応するスキャンライン上の対応する辺の画素位置の値を保持し、前記現在の辺レコード及び後続の辺レコードの各々は、少なくとも主部分とスピル部分に分割され、少なくとも前記現在の辺レコードの主部分はラスター画素順に並べられ、
少なくとも一つの現在のアクティブ辺レコードと、
スピルアクティブ辺レコードと、
制限された所定数の辺レコードを含むプールとを備え、
前記方法が、
(a)前記現在の辺レコードの前記主部分及びスピル部分の各々からの第1の辺レコードを対応するアクティブ辺レコードに送るステップと、
(b)前記ラスタ画素順において最も低い値を有するアクティブ辺レコードを決定し、現在の辺の値及びレコードとしてその値とレコードを出力するために、前記アクティブ辺レコードの値を比較するステップと、
(c)前記現在の辺レコードを、前記後続のスキャンラインのための対応する辺の値で更新するステップと、
(d)更新された辺の値を前記プール内の辺の値と比較するステップと、ここで、更新された辺の値が前記プール内の辺の値より小さい場合に、
(da)前記更新された現在の辺レコードが後続の辺レコードのスピル部分へ送られ、さもなければ、
(db)(dba)最小の辺値を有する辺レコードが前記プールから、前記後続の辺レコードの主部分の次のレコードへ送られ、
(dbb)前記更新された辺レコードは、前記サブステップ(dba)で空になった前記プールのレコードへ送られ、
(dc)更なる辺レコードが、現在の辺レコードの対応する部分から更新された辺レコードによって空にされたアクティブ辺レコードへ送られ、
(e)前記プール内の前記レコードの各々が占領されるまで、ステップ(b)乃至(d)を繰り返すステップと、これによって前記プールの最小の辺値レコードが前記後続の辺レコードの前記主部分へ送られ、
(f)前記現在のレコードの全てのレコードが更新されるまで前記ステップ(b)乃至(e)を繰り返し、次いで、前記プールからのレコードを順次に前記後続のレコードの前記主部分内の次のレコードへフラッシュするステップと、
(g)前記レコードを、前記後続のレコードにおける前記スピル部分において、ラスタ画素順にソートするステップと、
(h)前記後続の辺レコードを前記現在の辺レコードへ送るステップと、
(i)前記ラスタ画素イメージの更なるスキャンラインの各々に関して、前記ステップ(a)乃至(h)を繰り返すステップとを備えることを特徴とする方法。 - ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する装置であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、
未整列の第1バッファ、第2バッファ及び第3バッファを有するメモリと、
限られた数の処理された辺レコードを順序付けされていない前記第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて順序付け可能な前記辺レコードを漸進的に順次に前記第2バッファへ送り、順序付けできない処理済の辺を前記第3バッファにおいて並べるために該第3バッファへ送り、前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定するプロセッサとを備えることを特徴とする装置。 - 前記第1バッファは、メモリに形成された辺プールを備え、前記プロセッサは、前記メモリに形成された複数のアクティブ辺レコードから、前記現在のスキャンラインのためのアクティブ辺値を決定し、前記アクティブ辺値の各々に対し、対応する辺レコードを前記辺プールへ送るように構成されることを特徴とする請求項13に記載の装置。
- 前記第2バッファは、前記メモリに形成される現在辺出力リストを備え、前記プロセッサは、前記アクティブ辺値の各々に対して、前記辺プール内のレコードと前記辺レコードの対応する辺レコードを調べ、該辺レコードの順序付けられたものを前記現在辺リストに送るように構成されることを特徴とする請求項14に記載の装置。
- 前記第3バッファは、前記メモリ内に形成された現在スピル出力リストを備え、前記プロセッサは、前記現在のスピルリストへ順次に前記辺プールからの前記現在辺リストに並べることのできない辺レコードを送るように構成されることを特徴とする請求項15に記載の装置。
- 前記プロセッサは、前記スキャンラインの処理の完了時において、前記後続のスキャンラインの処理のために前記出力リストの対応する一つへ順次に前記辺プールからの辺レコードをフラッシュし、ここで、このフラッシュに際しては前記出力リストは現在辺入力リスト及び現在辺入力スピルリストとしてそれぞれ割り当てられるものであり、該後続のスキャンラインに対する前記アクティブ辺値を決定するために前記入力リストから順次に辺レコードを前記アクティブ辺レコードの対応する一つに転送するように構成されることを特徴とする請求項16に記載の装置。
- ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する装置であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、
限られた数の処理された辺レコードを順序付けされていない第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて、順序付け可能な前記辺レコードを漸進的に順次に第2バッファへ送る手段と、
順序付けできない処理済の辺を、第3バッファにおいて並べるために該第3バッファへ送る手段と、
前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定する手段とを備えることを特徴とする装置。 - ラスター画素イメージを形成するべくグラフィックオブジェクトを処理するグラフィックオブジェクト描画システムの一部を形成する装置であって、該処理は、前記グラフィックオブジェクトの辺と前記ラスター画素イメージの現在のスキャンラインとの交差の順序を決定する第1処理を備え、
前記装置が、
現在のスキャンラインと後続のスキャンラインの各々に関する複数の辺レコードと、該辺レコードの各々は少なくとも対応するスキャンライン上の対応する辺の画素位置の値を保持し、前記現在の辺レコード及び後続の辺レコードの各々は、少なくとも主部分とスピル部分に分割され、少なくとも前記現在の辺レコードの主部分はラスター画素順に並べられ、
少なくとも一つの現在のアクティブ辺レコードと、
スピルアクティブ辺レコードと、
制限された所定数の辺レコードを含むプールと、
辺レコード処理のために、
(a)前記現在の辺レコードの前記主部分及びスピル部分の各々からの第1の辺レコードを対応するアクティブ辺レコードに送り、
(b)前記ラスタ画素順において最も低い値を有するアクティブ辺レコードを決定し、現在の辺の値及びレコードとしてその値とレコードを出力するために、前記アクティブ辺レコードの値を比較し、
(c)前記現在の辺レコードを、前記後続のスキャンラインのための対応する辺の値で更新し、
(d)更新された辺の値を前記プール内の辺の値と比較し、ここで、更新された辺の値が前記プール内の辺の値より小さい場合に、
(da)前記更新された現在の辺レコードが後続の辺レコードのスピル部分へ送られ、さもなければ、
(db)(dba)最小の辺値を有する辺レコードが前記プールから、前記後続の辺レコードの主部分の次のレコードへ送られ、
(dbb)前記更新された辺レコードは、前記サブステップ(dba)で空になった前記プールのレコードへ送られ、
(dc)更なる辺レコードが、現在の辺レコードの対応する部分から更新された辺レコードによって空にされたアクティブ辺レコードへ送られ、
(e)前記プール内の前記レコードの各々が占領されるまで、ステップ(b)乃至(d)を繰り返し、これによって前記プールの最小の辺値レコードが前記後続の辺レコードの前記主部分へ送られ、
(f)前記現在のレコードの全てのレコードが更新されるまで前記ステップ(b)乃至(e)を繰り返し、次いで、前記プールからのレコードを順次に前記後続のレコードの前記主部分内の次のレコードへフラッシュし、
(g)前記レコードを、前記後続のレコードにおける前記スピル部分において、ラスタ画素順にソートし、
(h)前記後続の辺レコードを前記現在の辺レコードへ送り、
(i)前記ラスタ画素イメージの更なるスキャンラインの各々に関して、前記ステップ(a)乃至(h)を繰り返す構成を有することを特徴とする装置。 - ラスター画素イメージを形成するべく、グラフィックオブジェクトを処理する装置のためのプログラムを格納するコンピュータ可読媒体であって、該処理は、ラスタライズされた表示順における現在のスキャンラインのための対応する辺レコードを評価することにより、前記グラフィックオブジェクトの辺間の交差順序を判断し、後続のスキャンラインのための各辺に関する辺交差値を決定するものであって、該プログラムが、
限られた数の処理された辺レコードを順序付けされていない第1バッファに保持し、順序付け可能な処理済の辺レコードが前記第1バッファに加えられたのに応じて、順序付け可能な前記辺レコードを漸進的に順次に第2バッファへ送る保持ステップのコードと、
順序付けできない処理済の辺を、第3バッファにおいて並べるために該第3バッファへ送る転送ステップのコードと、
前記第2及び第3バッファからの辺レコードを選択的に処理し、後続のスキャンラインに対する並べられた交差を決定する処理ステップのコードとを備えることを特徴とするコンピュータ可読媒体。 - グラフィックオブジェクト描画システムにおいて、ラスター画素イメージを形成するべくグラフィックオブジェクトを処理するためのコンピュータプログラム製品を備えたコンピュータ可読媒体であって、該処理は、前記グラフィックオブジェクトの辺と前記ラスター画素イメージの現在のスキャンラインとの交差の順序を決定する第1処理を備え、該コンピュータ製品は、
現在のスキャンラインと後続のスキャンラインの各々に関する複数の辺レコードと、該辺レコードの各々は少なくとも対応するスキャンライン上の対応する辺の画素位置の値を保持し、前記現在の辺レコード及び後続の辺レコードの各々は、少なくとも主部分とスピル部分に分割され、少なくとも前記現在の辺レコードの主部分はラスター画素順に並べられ、
少なくとも一つの現在のアクティブ辺レコードと、
スピルアクティブ辺レコードと、
制限された所定数の辺レコードを含むプールと関連し、
前記第1処理が、
(a)前記現在の辺レコードの前記主部分及びスピル部分の各々からの第1の辺レコードを対応するアクティブ辺レコードに送るステップと、
(b)前記ラスタ画素順において最も低い値を有するアクティブ辺レコードを決定し、現在の辺の値及びレコードとしてその値とレコードを出力するために、前記アクティブ辺レコードの値を比較するステップと、
(c)前記現在の辺レコードを、前記後続のスキャンラインのための対応する辺の値で更新するステップと、
(d)更新された辺の値を前記プール内の辺の値と比較するステップと、ここで、更新された辺の値が前記プール内の辺の値より小さい場合に、
(da)前記更新された現在の辺レコードが後続の辺レコードのスピル部分へ送られ、さもなければ、
(db)(dba)最小の辺値を有する辺レコードが前記プールから、前記後続の辺レコードの主部分の次のレコードへ送られ、
(dbb)前記更新された辺レコードは、前記サブステップ(dba)で空になった前記プールのレコードへ送られ、
(dc)更なる辺レコードが、現在の辺レコードの対応する部分から更新された辺レコードによって空にされたアクティブ辺レコードへ送られ、
(e)前記プール内の前記レコードの各々が占領されるまで、ステップ(b)乃至(d)を繰り返すステップと、これによって前記プールの最小の辺値レコードが前記後続の辺レコードの前記主部分へ送られ、
(f)前記現在のレコードの全てのレコードが更新されるまで前記ステップ(b)乃至 (e)を繰り返し、次いで、前記プールからのレコードを順次に前記後続のレコードの前記主部分内の次のレコードへフラッシュするステップと、
(g)前記レコードを、前記後続のレコードにおける前記スピル部分において、ラスタ画素順にソートするステップと、
(h)前記後続の辺レコードを前記現在の辺レコードへ送るステップと、
(i)前記ラスタ画素イメージの更なるスキャンラインの各々に関して、前記ステップ(a)乃至(h)を繰り返すステップとを実行するように構成されてなることを特徴とするコンピュータ可読媒体。
Applications Claiming Priority (12)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU9234 | 1981-06-10 | ||
AU5858 | 1992-11-16 | ||
AU5854 | 1995-10-09 | ||
AUPP5858A AUPP585898A0 (en) | 1998-09-11 | 1998-09-11 | Pixel image objects in graphic object rasterisation |
AUPP5859A AUPP585998A0 (en) | 1998-09-11 | 1998-09-11 | Unified compositing model for graphic object rendering |
AUPP5854A AUPP585498A0 (en) | 1998-09-11 | 1998-09-11 | Seamless object encoding for rasterised rendering |
AUPP5862A AUPP586298A0 (en) | 1998-09-11 | 1998-09-11 | Sorting arrangements for parallel edge rasterisation |
AUPP9234A AUPP923499A0 (en) | 1999-03-16 | 1999-03-16 | Node activation in binary, tertiary and higher order expression trees |
AUPQ0049A AUPQ004999A0 (en) | 1999-04-29 | 1999-04-29 | Clipping objects in stack-based compositing |
AU5862 | 1999-04-29 | ||
AU0049 | 1999-04-29 | ||
AU5859 | 1999-04-29 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006246138A Division JP4366387B2 (ja) | 1998-09-11 | 2006-09-11 | 画像処理装置及び方法 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2000149035A JP2000149035A (ja) | 2000-05-30 |
JP2000149035A5 JP2000149035A5 (ja) | 2006-11-02 |
JP4365950B2 true JP4365950B2 (ja) | 2009-11-18 |
Family
ID=27542967
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP25512399A Expired - Fee Related JP4365950B2 (ja) | 1998-09-11 | 1999-09-09 | 高速ラスタ形式レンダリングのためのグラフィックオブジェクト処理方法および装置 |
JP2006246138A Expired - Fee Related JP4366387B2 (ja) | 1998-09-11 | 2006-09-11 | 画像処理装置及び方法 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006246138A Expired - Fee Related JP4366387B2 (ja) | 1998-09-11 | 2006-09-11 | 画像処理装置及び方法 |
Country Status (2)
Country | Link |
---|---|
US (2) | US6483519B1 (ja) |
JP (2) | JP4365950B2 (ja) |
Families Citing this family (69)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AUPP771798A0 (en) | 1998-12-14 | 1999-01-14 | Canon Kabushiki Kaisha | Overlapping edge blends and other texture mapped regions |
AUPP923799A0 (en) * | 1999-03-16 | 1999-04-15 | Canon Kabushiki Kaisha | Method for optimising compilation of compositing expressions |
US7126600B1 (en) * | 2000-08-01 | 2006-10-24 | Ati International Srl | Method and apparatus for high speed block mode triangle rendering |
US6756994B1 (en) * | 2000-08-07 | 2004-06-29 | Canon Kabushiki Kaisha | Method and apparatus for handling secondary dependencies |
EP1187066A3 (en) * | 2000-09-01 | 2004-04-21 | Sony Computer Entertainment Inc. | Method and apparatus for image enlargement/reduction |
US7286138B2 (en) * | 2001-05-08 | 2007-10-23 | Microsoft Corporation | Discontinuity edge overdraw |
AUPR860901A0 (en) * | 2001-10-31 | 2001-11-29 | Canon Kabushiki Kaisha | Activating a filling of a graphical object |
AUPS134202A0 (en) * | 2002-03-25 | 2002-05-09 | Canon Kabushiki Kaisha | System and method for optimizing halftoning printer performance |
US7418664B2 (en) * | 2002-04-03 | 2008-08-26 | Microsoft Corporation | Application sharing single document sharing |
US7028266B2 (en) * | 2002-04-05 | 2006-04-11 | Microsoft Corporation | Processing occluded windows during application sharing |
US8756513B1 (en) | 2002-04-23 | 2014-06-17 | Microsoft Corporation | Document viewing mechanism for document sharing environment |
US7293243B1 (en) * | 2002-05-22 | 2007-11-06 | Microsoft Corporation | Application sharing viewer presentation |
JP2003346136A (ja) * | 2002-05-23 | 2003-12-05 | Canon Inc | 画像処理装置およびその方法 |
WO2004001709A2 (en) * | 2002-06-20 | 2003-12-31 | Alberto Baroncelli | Vector graphics circuit accelerator for display systems |
US7423655B1 (en) * | 2002-06-24 | 2008-09-09 | Adobe Systems Incorporated | Revealing clipped portion of image object |
US7355609B1 (en) * | 2002-08-06 | 2008-04-08 | Apple Inc. | Computing visible regions for a hierarchical view |
AU2002951651A0 (en) * | 2002-09-25 | 2002-10-10 | Canon Kabushiki Kaisha | Apparatus for printing using non-overlapping graphic objects |
AU2002952382A0 (en) | 2002-10-30 | 2002-11-14 | Canon Kabushiki Kaisha | Method of Background Colour Removal for Porter and Duff Compositing |
US7466855B2 (en) * | 2003-02-11 | 2008-12-16 | Research In Motion Limited | Display processing system and method |
US7088870B2 (en) * | 2003-02-24 | 2006-08-08 | Microsoft Corporation | Image region filling by example-based tiling |
US6987520B2 (en) * | 2003-02-24 | 2006-01-17 | Microsoft Corporation | Image region filling by exemplar-based inpainting |
AU2003903448A0 (en) * | 2003-06-26 | 2003-07-17 | Canon Kabushiki Kaisha | A method for tracking depths in a scanline based raster image processor |
JP4183082B2 (ja) * | 2003-09-26 | 2008-11-19 | シャープ株式会社 | 3次元画像描画装置および3次元画像描画方法 |
JP2005107780A (ja) * | 2003-09-30 | 2005-04-21 | Sony Corp | 画像混合方法および混合画像データ生成装置 |
US7538770B2 (en) * | 2003-11-28 | 2009-05-26 | Canon Kabushiki Kaisha | Tree-based compositing system |
AU2004233516B2 (en) * | 2003-11-28 | 2008-07-31 | Canon Kabushiki Kaisha | Tree-based compositing system |
US7403661B2 (en) * | 2004-02-12 | 2008-07-22 | Xerox Corporation | Systems and methods for generating high compression image data files having multiple foreground planes |
AU2005200948B2 (en) * | 2004-03-09 | 2008-03-06 | Canon Kabushiki Kaisha | Compositing list caching for a raster image processor |
US7755629B2 (en) * | 2004-06-30 | 2010-07-13 | Canon Kabushiki Kaisha | Method of rendering graphic objects |
US7586500B2 (en) * | 2004-09-24 | 2009-09-08 | Canon Kabushiki Kaisha | Dynamic render algorithm selection |
JP4566772B2 (ja) * | 2005-02-14 | 2010-10-20 | キヤノン株式会社 | 画像処理装置、画像処理方法、及びプログラム |
JP4419876B2 (ja) * | 2005-03-14 | 2010-02-24 | 富士ゼロックス株式会社 | 画像処理装置 |
AU2005201930B2 (en) * | 2005-05-06 | 2009-02-19 | Canon Kabushiki Kaisha | Simplification of alpha compositing in the presence of transfer functions |
US20070085860A1 (en) * | 2005-10-13 | 2007-04-19 | Honeywell International Inc. | Technique for improving the readability of graphics on a display |
US7965299B2 (en) * | 2005-10-31 | 2011-06-21 | Canon Kabushiki Kaisha | Implementing compositing operations on images |
US7969604B2 (en) * | 2005-11-30 | 2011-06-28 | Adobe Systems Incorporated | Systems and methods for printing artwork containing transparency |
US7583410B1 (en) | 2005-12-13 | 2009-09-01 | Adobe Systems Incorporated | System to create image transparency in a file generated utilizing a print stream |
US8085275B1 (en) * | 2005-12-20 | 2011-12-27 | Nvidia Corporation | System and method for low-overhead push buffer jumps |
EP1826723B1 (en) * | 2006-02-28 | 2015-03-25 | Microsoft Corporation | Object-level image editing |
US20070216685A1 (en) * | 2006-03-15 | 2007-09-20 | Microsoft Corporation | Scene write-once vector and triangle rasterization |
US20070216696A1 (en) * | 2006-03-16 | 2007-09-20 | Toshiba (Australia) Pty. Limited | System and method for document rendering employing bit-band instructions |
JP4157569B2 (ja) * | 2006-05-11 | 2008-10-01 | 株式会社東芝 | 描画装置、描画方法及び描画プログラム |
US20080158254A1 (en) * | 2006-12-29 | 2008-07-03 | Hong Jiang | Using supplementary information of bounding boxes in multi-layer video composition |
US7928980B2 (en) * | 2007-07-19 | 2011-04-19 | Analytical Graphics Inc. | Method for visualizing data clouds using color and opacity blending |
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 |
US20090118006A1 (en) | 2007-11-02 | 2009-05-07 | Bally Gaming, Inc. | Game related systems, methods, and articles that combine virtual and physical elements |
JP5199727B2 (ja) | 2008-05-15 | 2013-05-15 | キヤノン株式会社 | 画像処理方法及び画像処理装置とその制御方法 |
AU2008202364B2 (en) * | 2008-05-28 | 2011-04-21 | Canon Kabushiki Kaisha | Scan converting a set of vector edges to a set of pixel aligned edges |
WO2010018622A1 (ja) * | 2008-08-12 | 2010-02-18 | 富士通株式会社 | 電子ペーパ端末装置、画像表示制御プログラム、および画像表示制御方法 |
US8285034B2 (en) | 2009-08-26 | 2012-10-09 | Bally Gaming, Inc. | Apparatus, method and article for evaluating a stack of objects in an image |
DE102009042235A1 (de) * | 2009-09-18 | 2011-04-07 | Diehl Aerospace Gmbh | Verfahren zur Darstellung von mehreren sich mindestens teilweise überlagernden Objekten |
AU2009225336B2 (en) * | 2009-10-13 | 2011-08-04 | Canon Kabushiki Kaisha | Method of compositing variable alpha fills supporting group opacity |
KR101635006B1 (ko) * | 2010-01-22 | 2016-07-01 | 삼성디스플레이 주식회사 | 광원의 휘도 제어 방법 및 이를 수행하기 위한 표시 장치 |
US20110193871A1 (en) * | 2010-02-07 | 2011-08-11 | Microsoft Corporation | Rendering multi-layered image |
CN102376099B (zh) * | 2010-08-19 | 2013-09-11 | 北大方正集团有限公司 | 一种改善矢量图形填充效果的方法及系统 |
AU2013211450A1 (en) | 2013-07-30 | 2015-02-19 | Canon Kabushiki Kaisha | Fixed memory rendering |
US10545657B2 (en) | 2013-09-03 | 2020-01-28 | Apple Inc. | User interface for manipulating user interface objects |
KR102238651B1 (ko) | 2014-04-23 | 2021-04-09 | 삼성전자주식회사 | 경로 렌더링을 수행하는 방법 및 장치. |
AU2015279544B2 (en) | 2014-06-27 | 2018-03-15 | Apple Inc. | Electronic device with rotatable input mechanism for navigating calendar application |
EP2985735B1 (en) | 2014-08-11 | 2019-12-04 | Samsung Electronics Co., Ltd | Method and apparatus for performing tile-based path rendering |
KR102354989B1 (ko) * | 2015-04-14 | 2022-01-24 | 삼성전자주식회사 | 경로 렌더링을 위한 타일 비닝을 수행하는 방법 및 장치. |
KR102426667B1 (ko) | 2015-06-23 | 2022-07-28 | 삼성전자주식회사 | 경로 렌더링에서 에일리어싱을 방지하는 방법 및 장치. |
KR102426669B1 (ko) | 2015-08-03 | 2022-07-28 | 삼성전자주식회사 | 경로 렌더링을 수행하는 방법 및 장치. |
DK201670595A1 (en) | 2016-06-11 | 2018-01-22 | Apple Inc | Configuring context-specific user interfaces |
KR102618560B1 (ko) | 2016-06-15 | 2023-12-27 | 삼성전자주식회사 | 경로 렌더링을 수행하는 방법 및 장치 |
JP6902861B2 (ja) | 2016-12-12 | 2021-07-14 | キヤノン株式会社 | 符号化装置、符号化方法、復号装置、復号方法および生成方法 |
US10431000B2 (en) * | 2017-07-18 | 2019-10-01 | Sony Corporation | Robust mesh tracking and fusion by using part-based key frames and priori model |
CN110705561A (zh) | 2018-07-09 | 2020-01-17 | 菜鸟智能物流控股有限公司 | 一种实现对象分拨分拣的方法及系统 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4815009A (en) * | 1987-04-21 | 1989-03-21 | Xerox Corporation | Algorithm for filling an image outline |
CH685691A5 (de) * | 1991-12-27 | 1995-09-15 | Charles Bosshard | Notausrüstung für Kraftfahrzeuge. |
US5444835A (en) * | 1993-09-02 | 1995-08-22 | Apple Computer, Inc. | Apparatus and method for forming a composite image pixel through pixel blending |
AUPM822394A0 (en) * | 1994-09-16 | 1994-10-13 | Canon Inc. | Object based rendering system |
US5818456A (en) * | 1996-04-30 | 1998-10-06 | Evans & Sutherland Computer Corporation | Computer graphics system with adaptive pixel multisampler |
US5831627A (en) * | 1996-06-27 | 1998-11-03 | R/Greenberg Associates | System and method for providing improved graphics generation performance using memory lookup |
US6008813A (en) * | 1997-08-01 | 1999-12-28 | Mitsubishi Electric Information Technology Center America, Inc. (Ita) | Real-time PC based volume rendering system |
US6300955B1 (en) * | 1997-09-03 | 2001-10-09 | Mgi Software Corporation | Method and system for mask generation |
US6421460B1 (en) | 1999-05-06 | 2002-07-16 | Adobe Systems Incorporated | Blending colors in the presence of transparency |
-
1999
- 1999-09-09 JP JP25512399A patent/JP4365950B2/ja not_active Expired - Fee Related
- 1999-09-10 US US09/394,530 patent/US6483519B1/en not_active Expired - Lifetime
-
2002
- 2002-06-24 US US10/176,644 patent/US7046253B2/en not_active Expired - Lifetime
-
2006
- 2006-09-11 JP JP2006246138A patent/JP4366387B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US6483519B1 (en) | 2002-11-19 |
JP4366387B2 (ja) | 2009-11-18 |
JP2000149035A (ja) | 2000-05-30 |
JP2006338692A (ja) | 2006-12-14 |
US20030016221A1 (en) | 2003-01-23 |
US7046253B2 (en) | 2006-05-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4365950B2 (ja) | 高速ラスタ形式レンダリングのためのグラフィックオブジェクト処理方法および装置 | |
JP4343344B2 (ja) | ラスタ形式のグラフィックオブジェクトを用いたイメージの高速レンダリング方法 | |
JP3919754B2 (ja) | 画素順次描画システムにおいて実行される合成演算回数の削減法 | |
JP4630482B2 (ja) | 表現ツリーを生成する装置及びラスタ画素イメージを描画する装置 | |
JP3797666B2 (ja) | グラフィックオブジェクトの塗りつぶしをアクティブ化する方法および装置 | |
US7538770B2 (en) | Tree-based compositing system | |
US7551173B2 (en) | Pixel accurate edges for scanline rendering system | |
US7714865B2 (en) | Compositing list caching for a raster image processor | |
JP4646436B2 (ja) | デジタル画像の画像処理装置 | |
JP4109740B2 (ja) | 畳み込み走査ラインレンダリング | |
AU744091B2 (en) | Processing graphic objects for fast rasterised rendering | |
JP4143613B2 (ja) | 描画方法、描画装置 | |
AU743218B2 (en) | Fast renering techniques for rasterised graphic object based images | |
AU779154B2 (en) | Compositing objects with opacity for fast rasterised rendering | |
AU2005200948B2 (en) | Compositing list caching for a raster image processor | |
AU2004200655B2 (en) | Reducing the Number of Compositing Operations Performed in a Pixel Sequential Rendering System | |
AU2002301643B2 (en) | Activating a Filling of a Graphical Object | |
AU2004231232B2 (en) | Pixel accurate edges for scanline rendering system | |
AU2005201868A1 (en) | Removing background colour in group compositing | |
AU2005201929A1 (en) | Rendering graphic object images | |
AU2004237873A1 (en) | State table optimization in expression tree based compositing | |
AU2005201931A1 (en) | Rendering graphic object images | |
AU2004233469A1 (en) | Rendering linear colour blends |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060911 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060911 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060911 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080804 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080807 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090424 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090507 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090706 |
|
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: 20090803 |
|
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: 20090824 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120828 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120828 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130828 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |