JP2005267639A - グラフィカルオブジェクトをレンダリングする方法 - Google Patents

Abstract

【課題】グラフィカルオブジェクトをレンダリングする効率の良い方法を提供する。
【解決手段】複数のオブジェクトを組み合わせる方法により行い、１組の連続するグラフィカルオブジェクトを効率よく組み合わせて、連続するグラフィカルオブジェクトの組み合わせを表現するハイレベルコンパイルドオブジェクトを生成し、コンパイルドオブジェクトをディスプレイリストへ出力する。コンパイルドオブジェクトは、関連するメタ塗りつぶしを備え、メタ塗りつぶしは、複合塗りつぶしであり、コンパイルドオブジェクトと関連する塗りつぶしの集合体を記述するために使用される。
【選択図】図８Ｂ

Description

本発明は、一般に、画像処理に関し、特に、複数のグラフィカルオブジェクトをレンダリングする方法に関する。また、本発明は、複数のグラフィカルオブジェクトをレンダリングする方法及び装置、並びに複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムが記録されたコンピュータ可読媒体を含むコンピュータプログラム製品に関する。

ワードプロセッサなどの従来のソフトウェアアプリケーションは、ページ単位の文書を作成する。ページ単位の文書においては、各々のページが１つ以上のグラフィカルオブジェクト（すなわち、テキスト、行、塗りつぶし領域（fill reagions)及び／又は画像データ）を含む。そのような文書を表示装置又は印刷装置において表現する場合、ソフトウェアアプリケーションは、通常、表示装置又は印刷装置へ指令を送信する。それらの指令は、通常、グラフィカルインタフェースサービス(graphics interface services )により定義される。グラフィカルインタフェースサービスは、そのソフトウェアアプリケーションを実行しているネイティブオペレーティングシステムと関連する。そのようなオペレーティングシステムの１つがＷｉｎｄｏｗｓ（登録商標）である。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのグラフィカルインタフェースサービスは、通常、グラフィックスデバイスインタフェース（ＧＤＩ：graphics device interface ）レイヤと呼ばれる。ＧＤＩレイヤは、オペレーティングシステムにより実行されるべきアプリケーションプログラミングインタフェース（ＡＰＩ：application programming interface ）として実現されてもよい。ＡＰＩは、オペレーティングシステムにより実行されるべきソフトウェアアプリケーションに、豊富な図形特徴セットを提供する。

通常、グラフィックスレンダリングシステムは、オペレーティングシステムのＧＤＩレイヤから受信されたグラフィカルオブジェクト（図形オブジェクト）をレンダリングし、画素を生成する。レンダリングは、ＧＤＩレイヤから受信されたグラフィカルオブジェクトをグラフィックスレンダリングシステムにより画素に変換するプロセスである。グラフィックスレンダリングシステムにより生成された画素は、その後、表示及び／又は印刷のために、出力装置へ送信される。

図１は、従来のソフトウェアアプリケーション１１０と、グラフィックスデバイスインタフェースレイヤ１２０と、グラフィックスレンダリングシステム１３０と、ターゲットデバイス１４０との関係を示す。アプリケーション１１０は、１つの文書の各ページを、一連の指令として送信する。レンダリングされるページごとに、一連の指令は、そのページのグラフィカルオブジェクトを記述するグラフィックインタフェースサービスによって定義される。ＧＤＩレイヤ１２０は、アプリケーションプログラム１１０とターゲットデバイス１４０との間を仲介する。ＧＤＩレイヤ１２０の存在によって、グラフィックスレンダリングシステム１３０は、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムが処理できるより、はるかに小さな機能性のセットを支援することが可能である。また、ＧＤＩレイヤ１２０は、グラフィックスレンダリングシステム１３０において最も効率がよいとＧＤＩレイヤ１２０が判定するフォーマット及びターゲットデバイス１４０の分解能で、グラフィカルオブジェクトをグラフィックスレンダリングシステム１３０に提供する。そこで、グラフィックスレンダリングシステム１３０は、ＧＤＩレイヤ１２０から受信されたグラフィカルオブジェクトをレンダリングし、画素を生成する。グラフィックスレンダリングシステム１３０により生成された画素は、その後、ターゲットデバイス１４０へ送信される。

グラフィックスソフトウェアアプリケーションには、多様な種類が存在する。それらのグラフィックスソフトウェアアプリケーションの多くは、複雑なグラフィカルオブジェクトの生成が可能である。通常、これらのオブジェクトは、特定のグラフィックスソフトウェアアプリケーションに特有のものである。例えば、Corel Draw（登録商標）と呼ばれる周知のグラフィックスソフトウェアアプリケーションは、「fountain fill（インクだめ塗りつぶし）」として知られる複雑なオブジェクトを作成できる。「fill（塗りつぶし）」は、グラフィカルオブジェクトがペイントされる（すなわち、塗りつぶされる）ときの画素データを記述するために使用される。例えば、赤色の正方形は、赤色フラット着色塗りつぶしを有する。fountain fillは、オブジェクトの２つ以上の色が互いに滑らかに流れ込むようなオブジェクトの塗りつぶしを記述する「勾配塗りつぶし」の１種である。勾配塗りつぶしには、数多くの型（例えば、線形、円錐形、放射及び非線形）がある。放射勾配塗りつぶしによって塗りつぶされたオブジェクト２１０が、図２Ａに示される。通常、勾配塗りつぶしの遷移は、１つの色が別の色に流れ込むことにより構成される。しかし、より複雑な勾配塗りつぶしは、多数の異なる色の間の多数の遷移を有するであろう。図２Ｂは、多数の遷移を有する勾配塗りつぶしによって塗りつぶされたオブジェクト２２０の一例を示す。

線形勾配塗りつぶしによってオブジェクトを塗りつぶすために、特定のグラフィックスソフトウェアアプリケーションにより，どの方法が使用されるかは、その特定のグラフィックスソフトウェアアプリケーションによって異なる。しかし、線形勾配塗りつぶしによってオブジェクトを塗りつぶす周知の方法の１つは、塗りつぶされるべきグラフィカルオブジェクトの境界規定ボックスの両端部において、開始色及び終了色を指定し、開始色と終了色の間を補間する工程を含む。

オブジェクト２１０及び２２０のような複雑なグラフィカルオブジェクトは、通常、プリンタドライバ又はディスプレイドライバにより直接にレンダリングされることが不可能である。従って、ＧＤＩレイヤは、通常、複数の平行四辺形の形態をとる複数のフラット塗りつぶし隣接オブジェクト（flat filled adjacent objects）として、勾配塗りつぶし（gradient fills ）をグラフィックスレンダリングシステムへ送信する。それらのフラット塗りつぶし隣接平行四辺形（flat filled adjacent parallelograms ）を使用することにより、グラフィックスレンダリングシステムは、アプリケーションに特有のグラフィックス型を支援する必要なく、複雑なグラフィカルオブジェクトをレンダリングすることができる。Painters Algorithmレンダリング方法を使用するレンダラの場合、フラット塗りつぶし平行四辺形は、フレーム記憶装置にレンダリングされてもよい。しかし、通常、ＧＤＩレイヤにより、線形勾配塗りつぶしと非線形勾配塗りつぶし（non-linear gradient fills ）の双方がフラット塗りつぶし平行四辺形として送信されるため、２つの隣接する平行四辺形の幅は、通常、一貫していない。その結果、それらの平行四辺形の連続するセットの間の色の変化は、必ずしも線形にはならない。

グラフィックスレンダリングシステム（図形レンダリングシステム）によっては、レンダリングプロセスは、２段階プロセスになる場合がある。そのようなレンダリングシステムにおいては、レンダリングされるべきページのグラフィカルオブジェクトは、レンダリングプロセスが始まる前に、まず、中間フォーマットに変換される。この中間フォーマットは、「ディスプレイリスト（display list）」として知られている。そのようなグラフィックスレンダリングシステムの１つにおいては、レンダリングプロセスの第１段階は、関連するオペレーティングシステムから受信されたページの各グラフィカルオブジェクトを、中間稜線ベースオブジェクト（intermediate edge-based object）に変換する。例えば、図３は、受信された各グラフィカルオブジェクトを中間稜線ベースオブジェクトに変換する従来のグラフィックスレンダリングシステム３３０を示す。図３の例では、グラフィックスアプリケーション３１０により作成され、且つ、複雑なグラフィカルオブジェクトに対応する線形勾配塗りつぶし（linear gradient fill ）３７０は、多数のフラット着色矩形（flat coloured rectangles ）（例えば、フラット着色矩形３８０）として、グラフィックスデバイスインタフェース３２０から、グラフィックスレンダリングシステム３３０へ送信される。グラフィックスレンダリングシステム３３０のディスプレイリスト作成モジュール３４０は、各々のフラット着色矩形３８０を２つの稜線、レベル及び塗りつぶしデータに変換する。それらの稜線、レベル及び塗りつぶしデータは、データベース（例えば、３８１、３８２及び３８３にそれぞれ）格納される。稜線は、各フラット着色矩形３８０が塗りつぶされるエリアを記述する。塗りつぶしデータは、フラット着色矩形３８０の稜線の内側における画素の色／不透明度を規定する。塗りつぶしデータは、フラット色、ビットマップ、式、又はフラット着色矩形３８０の中の特定の位置における画素データを記述するパターンであってもよい。レベルは、フラット着色矩形３８０のZ-オーダー（Z-order）、塗りつぶしデータに適用されるべきラスタ演算及び関連する稜線がクリッピング稜線であるか、又は塗りつぶし稜線であるかなどの重要なレンダリング情報を含む。

グラフィックスレンダリングシステム３３０がフラット着色矩形３８０のうちの１つをレンダリングする前に、特定の矩形の全ての稜線がｙの昇順で分類され、続いてｘの昇順で分類されるように、各矩形は分類されなければならない。ｙ座標及びｚ座標は、それぞれ、ラスタ化レンダリングシステム（rasterized rendering system）における走査線と、各走査線上の画素位置に対応する。グラフィックスレンダリングシステムは、稜線及びそれらに関連する塗りつぶし優先順位（Z-order）から成るディスプレイリスト３５０と共に、稜線がクリッピング稜線（clipping edge ）であるか、又は塗りつぶし稜線（filling edge）であるかなどの他の情報を生成する。

ディスプレイリスト３５０は、ジョブと呼ばれる場合もある。ジョブは、ページをレンダリングするために、グラフィックスレンダリングシステム３３０のレンダリングモジュール３６０により必要とされる全ての情報を含む。レンダリングモジュール３６０によるページのレンダリングは、レンダリングプロセスの第２段階である。

レンダリングモジュール３６０は、ジョブをパージング（parses）し、ページに沿って走査線ごとに、プリンタなどの下流側デバイスに対して画素を生成する。走査線ごとに、レンダリングモジュール３６０が着色矩形（例えば、矩形３８０）の左側稜線に至たる（encounters）と、レンダリングモジュール３６０は、その矩形と関連するレベルを中間バッファにロードする。矩形と関連するレベルは、この時点で、アクティブ状態になったという。レンダリングモジュール３６０が矩形の右側稜線に至った（encounters）とき、矩形と関連するレベルは非アクティブ状態（deactivated）になる。

レンダリングモジュール３６０は、本明細書において後に説明されるように、稜線に関して様々に異なる種類のアクティべーションルール（activation rules ）を使用できる。走査線上の各稜線セットの間の画素スパンは、それらのルールに従ってレンダリングされる。レンダリングモジュール３６０が１つの稜線に至ると、レンダリングモジュール３６０は、最上位（すなわち、最大Z-オーダー位置（greatest z-order position））の、現在アクティブ状態であるレベルを判定し、最上位の現在アクティブ状態のレベルの塗りつぶしデータに従って、画素をレンダリングする。最上位レベルに対応するオブジェクト（例えば、フラット着色矩形（flat filled rectangle））が透明である場合、下位のｚ-orderのレベルの合成を使用して、結果として得られる画素データが計算される。レンダリングモジュール３６０が稜線に至るたびに、全ての稜線は、次の走査線上の新たな位置に更新されなければならない。更に、稜線は互いに交差する場合もあるので、稜線がｘの昇順のままであることを保証するために、稜線も分類されなければならない。ページ上の全ての画素がレンダリングされるまで、レンダリングプロセスは走査線ごとに継続される。

先に説明したように、複雑なオブジェクトは、通常、グラフィックスデバイスインタフェース３２０により、フラット塗りつぶし矩形のような、より単純なオブジェクトに分解される。それらの単純なオブジェクトの各々は、別個に中間形態（intermediate form ）に変換されなければならないため、その変換には、相当に長い時間を要する。個別のフラット塗りつぶしオブジェクトをレンダリングするとき、オブジェクトの各々の稜線が分類されなければならず、また、走査線ごとに、各稜線が更新されなければならない。これも、レンダリングモジュール３６０には、長い時間を要するプロセスである。そのため、数百個もの単純なオブジェクトの分解された複雑なオブジェクトの場合には、各オブジェクトを中間稜線ベースフォーマット（intermediate edge based format ）に変換し、稜線ベースレンダリングモジュールを使用して、複雑なオブジェクトをレンダリングするプロセスの効率は、きわめて低い。

一例として、図２Ｃに示される水平方向線形勾配塗りつぶし（horizontal linear gradient fill ）２３０は、グラフィックスレンダリングシステム３３０へ送信される前に、グラフィックスデバイスインタフェース３２０により、２５６個のフラット塗りつぶし矩形に分解される。勾配塗りつぶし（gradient fill ）２３０が左から右、又は右から左へ進む最悪のケースでは、１本の走査線の上で、２５６個のフラット塗りつぶし（flat fills）の全てがアクティブ状態になる。これは、走査線ごとに、稜線の数が５１２あることと同等である。従って、稜線ベースレンダリングシステムの場合、走査線ごとに実行されることが必要な稜線の分類及び追跡の量が多くなるため、このようなレンダリング方法の効率は相当に低くなる。加えて、各々のフラット塗りつぶしが中間オブジェクトグラフィックスフォーマットで格納されなければならず、レンダリングを開始できる前に、各走査線の塗りつぶしパスごとに、塗りつぶしがアクセスされ、その後、全ての稜線が分類されなければならない。

上述のレンダリング方法では、処理されるべきフラット塗りつぶしの数が何千にも達した場合、大量のメモリアクセスが要求され、また、大量の塗りつぶし資源が消費される可能性がある。Ａ３より大判のページを高分解能で印刷するときには、そのように大量なフラット塗りつぶしが頻繁に起こる。

勾配塗りつぶし２３０をレンダリングするときに、稜線ベースレンダリングモジュール３６０のレンダリング性能を向上する方法の１つは、稜線更新の回数及び実行される必要がある稜線分類の量を減少することである。稜線更新及び稜線分類を減少する周知の方法の１つは、複数のグラフィカルオブジェクトをより大きな１つのグラフィカルオブジェクトにコンパイルするか、又はレンダリングモジュールが処理可能であるより複雑なオブジェクトにコンパイルすることにより、可能な部分で冗長稜線を除去する。複数のグラフィカルオブジェクトをより大きな１つのグラフィカルオブジェクトとしてコンパイルする多くの方法が、知られている。例えば、別個の２つの隣接するビットマップを互いにつなぎ合わせて、１つの大きなビットマップを形成してもよい。また、同一の色を有する２つの連続するフラット塗りつぶしを組み合わせて、より大きな１つのフラット塗りつぶしを生成してもよいし、線形勾配塗りつぶしを表現する連続するフラット塗りつぶしプリミティブを組み合わせて、グラフィックスレンダリングシステムによりレンダリング可能な型の１つの複雑な線形勾配塗りつぶしを形成してもよい。しかし、これらの周知のレンダリング方法は、全て、欠点や限界を有する。

例えば、連続するオブジェクトを組み合わせることを試みる周知のレンダリング方法は、特定のレンダリングモジュールで利用可能な指定の塗りつぶし型に限定される。従って、組み合わせ可能なオブジェクトは、互いに全く同一の塗りつぶし型を有するオブジェクトのみである。ＧＤＩ３２０のようなＧＤＩレイヤは、そのようなオブジェクトを分解する必要が始めからないので、この種のオブジェクトが頻繁に現れることはない。

ビットマップを組み合わせる方法の場合には、２つの異なるビットマップを１つのビットマップとして組み合わせるために、画像塗りつぶしデータ全体がコピーされなければならない。特に、多くのビットマップが多数のメモリ割り当てとして含まれ、大量の画像データコピーを実行する必要がある場合、画像塗りつぶしデータをコピーするプロセスは、容易に進まない可能性がある。

フラット塗りつぶしプリミティブを複雑な等価の塗りつぶしとして組み合わせるレンダリング方法は、特定のレンダリングモジュールにより支援される塗りつぶしを出力することに限定される。特定のレンダリングモジュールにより支援されると考えられる塗りつぶしの１つは、線形勾配塗りつぶしである。これは、通常、２つ又は３つの点により表現され、それらの点における色値に対応している。

先に説明したように、平行四辺形の幅が一貫せず且つ色の変化が一定ではないような、複数のフラット塗りつぶし平行四辺形として、勾配塗りつぶしをＧＤＩ３２０が送信することは珍しくない。線形ではない勾配塗りつぶし（例えば、図５Ａに示されるような非線形勾配塗りつぶし５１０）の場合、周知のレンダリング方法は、個々のフラット塗りつぶし平行四辺形を等価の線形勾配成分として組み合わせようとする。非線形勾配塗りつぶしオブジェクトを線形勾配塗りつぶしにコンパイルする周知のレンダリング方法は、２つの線形勾配塗りつぶしを生成するのが理想的である。図５Ｂは、図５Ａの非線形勾配塗りつぶし５１０から生成された２つの線形勾配塗りつぶし５２０及び５２５を示す。非線形勾配塗りつぶし５１０を与えられた場合、ＧＤＩ３２０により生成される平行四辺形の色の変化は一定ではなく、平行四辺形の幅も一貫していないため、勾配塗りつぶしをコンパイルする周知の方法は、勾配塗りつぶし５１０中の一貫性の欠如に対応することができず、図５Ｂのような理想的な結果を生成しない。

従来のレンダリング方法は、多くの場合、図５Ｃに示されるような多数の線形勾配塗りつぶし（linear gradient fills）５３０〜５３７を生成する。そのような多数の線形勾配塗りつぶしを生成するプロセスは、元のフラット塗りつぶし表現と比較して効率が悪く、最終的には、レンダリングモジュールの動作を遅くしてしまう。レンダリングモジュールの動作速度が低下するのは、フラット塗りつぶしの画素データと比較して、線形勾配塗りつぶしの画素データを計算するほうが困難であるためと、通常、除去されるのが最小限の稜線にとどまるためである。その結果、最終的には、レンダリング速度（rendering speed）が実際に低下する。ＧＤＩ３２０から受信される勾配塗りつぶしを表現するフラット塗りつぶし（例えば、フラット塗りつぶし矩形３８０）は、必ずしも一貫しておらず、常に正当な線形色変化限界（linear colour change limits）を有しているとは限らない。従って、従来のレンダリング方法は、フラット塗りつぶしを効率よく処理するという点で、非常に大きな制限を有する。更に、従来のレンダリング方法と関連するレンダリングモジュールは、図形プリミティブを完全に最適化するために利用可能な機能性を備えていないため、従来のレンダリング方法には、そのような最適化能力が欠けている。

線形勾配塗りつぶしをレンダリングすることのもう１つの欠点は、ページ上にカラー画像を生成するために、プリンタがシアン、マゼンタ及び黄色（ＣＭＹ）の減法混色の３原色と、黒（Ｋ）とを使用するために起こる。その結果、ＲＧＢ色空間で格納された線形勾配塗りつぶしを、ＣＭＹＫ色空間に変換することが必要である。ＲＧＢ色空間からＣＭＹＫ色空間への線形勾配塗りつぶしの変換は、ホストコンピュータ内で実行されるか、又はターゲットデバイスで実行されることが可能である。しかし、各々がＲＧＢ色空間で対応する色値を有する２つ又は３つの点によって記述される線形勾配塗りつぶしは、単純に各々の点の色を変換するだけでは、色変換不可能である。それは、ＧＤＩにより提供される元の色データが、色変換後の色空間に線形マッピングされないからである。すなわち、ＲＧＢ色空間とＣＭＹＫ色空間との間に、線形関係は存在しない。線形勾配塗りつぶしを色変換する従来の方法は、塗りつぶし中の画素ごとに、画素データのＲＧＢ値を判定する。その後、線形勾配塗りつぶし中の各々の画素は、等価のＣＭＹＫ色値に変換される。色変換後の線形勾配塗りつぶしは、次に、ビットマップとしてディスプレイリストに追加される。従って、線形勾配塗りつぶしをＲＧＢ色空間に格納することは、非常に効率が悪い。

従って、グラフィカルオブジェクトをレンダリングする、更に効率のよい方法が必要であることは明らかである。

本発明の目的は、既存の構成の１つ以上の欠点を実質的に克服すること、又は少なくとも改善することである。

本発明の１つの面によれば、各々が所定のオブジェクトアウトラインと、所定のZ-オーダー（Z-order）と、関連する塗りつぶしとを含み、特定のオブジェクトに関するオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする方法は、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしを含み、前記複合塗りつぶしが、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成する工程と、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングする工程と、
を備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とする。

本発明の別の面によれば、グラフィカルオブジェクトが、所定のオブジェクトアウトラインと、前記複合塗りつぶしと含み、当該所定のオブジェクトアウトラインは、前記グラフィカルオブジェクトが塗りつぶされるエリアを定義する、当該グラフィカルオブジェクトをレンダリングするための複合塗りつぶし方法は、
前記複合塗りつぶしは、レンダリング時に前記グラフィカルオブジェクトが塗りつぶされるべき形式を定義する複数の塗りつぶしを含むデータ構造として構成されることを特徴とする。

本発明の更に別の面によれば、各々が所定のオブジェクトアウトラインと、所定のZ-オーダー（Z-order）と、関連する塗りつぶしと含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする装置は、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしを含み、前記複合塗りつぶしは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成するための組み合わせ手段と、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするレンダリング手段と、
を備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とする。

本発明の更に別の面によれば、各々が所定のオブジェクトアウトラインと、所定のZ-オーダー（Z-order）と、関連する塗りつぶしを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムであって、当該コンピュータプログラムが、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしと含み、前記複合塗りつぶしは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するためのコードと、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするためのコードと、
備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とする。

本発明の更に別の面によれば、各々が所定のオブジェクトアウトラインと、所定のZ-オーダー（Z-order）と、関連する塗りつぶしを含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムを記録したコンピュータで読み取り可能な記録媒体を含むコンピュータプログラム製品であって、当該プログラムが、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしを含み、前記複合塗りつぶしは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するためのコードと、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするためのコードと、
を備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とする。

本発明の他の面も開示される。

添付の図面のうちの１つ以上において、同一の図中符号を有するステップ及び／又は特徴を参照するとき、本明細書の便宜上、それらのステップ及び／又は特徴は、特に指示のない限り、同一の機能又は動作を有するものとする。

「背景技術」の章及び前述の従来技術の構成に関連する部分に含まれる説明は、それぞれ対応する刊行物及び／又は使用を通して公の知識を形成する文書又は装置の説明に関することに注意すべきである。それらは、そのような文書又は装置が何らかの形で当該技術分野における共通の一般知識の一部を形成するという、本発明の発明者又は特許出願人による表明として解釈されるべきではない。

以下、図１から図１６を参照して、複数のオブジェクトを組み合わせる方法９００（図９を参照）を説明する。方法９００は、１組の連続するグラフィカルオブジェクトを効率よく組み合わせて、連続するグラフィカルオブジェクトの組み合わせを表現するハイレベルコンパイルドオブジェクトを生成する。コンパイルドオブジェクトは、「グループ化」オブジェクトと呼ばれてもよい。そのような連続するグラフィカルオブジェクトが異なる塗りつぶし型を有する場合であっても、オブジェクトを組み合わせるために、方法９００が使用されてよい。方法９００は、コンパイルドオブジェクトをディスプレイリストへ出力する。

コンパイルドオブジェクトは、関連するメタ塗りつぶし（meta-fill ）を有する。メタ塗りつぶしは、コンパイルドオブジェクトと関連する塗りつぶしの集合体を記述するために使用される複合塗りつぶし（compound fill）である。以下に詳細に説明されるように、メタ塗りつぶしは、メタ塗りつぶしに関する情報を定義するためのヘッド構造を含む。ヘッド構造の次に、コンパイルドオブジェクトの塗りつぶしを記述する塗りつぶし構造の連係リストが続く。連係リストの大きさを最小限にするために、コンパイルドオブジェクトの複数の塗りつぶしは、１つの単純な複合塗りつぶし又は複雑な塗りつぶしとして組み合わされてもよい。

メタ塗りつぶしは、並列して位置する１組の単純な基本オブジェクト（プリミティブ）を組み合わせて、１つの複雑な基本オブジェクトを形成するために使用されてもよい。従って、この場合、１組のプリミティブを表現するために要求される稜線は、２つだけである。メタ塗りつぶしは、グラフィックスインタフェースが多数のフラット塗りつぶしにより表現していた非線形ブレンド（non-linear blends）のような、複雑な描画オブジェクトを再度合体することにより、レンダリング時間を短縮する。例えば、非線形勾配塗りつぶし５１０に類似するメタ塗りつぶしは、図５Ｃの線形勾配塗りつぶし５３０〜５３７から形成されてもよい。そのようなメタ塗りつぶしは、図５Ｃの線形勾配塗りつぶし５３０〜５３７と比較して大幅に改善されている。

メタ塗りつぶし（meta-fill）は、例えば、ＧＤＩ３２０のようなＧＤＩにより提供される情報を変更しない。しかし、２つのオブジェクトが重複する場合、メタ塗りつぶしは、オブジェクトの閉塞する部分を除去する。塗りつぶしをメタ塗りつぶしに変換する際に、情報は実質的に全く失われない。基本塗りつぶしがメタ塗りつぶしとして組み合わせられるときに、描画出力が一貫したままであり且つ影響を受けないことを保証するために、メタ塗りつぶしを形成するために使用される１つ以上の基本塗りつぶしの全ての情報は保持される。これとは対照的に、従来の方法は、色情報に影響を及ぼすため、出力が入力を反映することが保証されることは全くない。更に、メタ塗りつぶしは、稜線オーバヘッド（edge overhead）を減少する。

ＰＤＬを生成するレンダリングシステムの場合、メタ塗りつぶしは、基本オブジェクトを表現するために要求されるＰＤＬの大きさを縮小する。ＰＤＬの大きさが縮小されると、ＰＤＬの送信が要求される処理は改善される。

メタ塗りつぶしは、フラット塗りつぶし、線形勾配塗りつぶし及びビットマップを使用して形成されてもよい。これに対し、従来のレンダリングシステムは、通常、色混合（color blends）を表現するフラット塗りつぶしを認識するだけである。

コンパイルドオブジェクトは、メタ塗りつぶしをリアルタイムで復号することにより、関連するメタ塗りつぶしを使用して、効率よくレンダリングされる。図１から図１６を参照して、コンパイルドオブジェクトをレンダリングする方法１０００（図１０を参照）も説明される。

ここで説明される方法は、図４に示されるような汎用コンピュータシステム４００を使用して実現されてもよい。その場合、図１から図１６を参照して説明されるプロセスは、コンピュータシステム４００内部で実行されるコードモジュールのようなソフトウェアとして実現されてもよい。特に、説明される方法のステップは、ソフトウェアにおいて、コンピュータにより実行される命令により実行される。それらの命令は、各々が１つ以上の特定のタスクを実行する１つ以上のコードサブモジュールとして形成されてもよい。ソフトウェアは、例えば、以下に説明される記憶装置を含むコンピュータ可読媒体に格納されてもよい。ソフトウェアは、コンピュータ可読媒体からコンピュータにロードされ、その後、コンピュータにより実行される。そのようなソフトウェア又はコンピュータプログラムが記録されたコンピュータ可読媒体は、コンピュータプログラム製品である。コンピュータプログラム製品をコンピュータにおいて使用することにより、説明される方法を実現するための好都合な装置が獲得されるのが好ましい。

コンピュータシステム４００は、コンピュータモジュール４０１、キーボード４０２及びマウス４０３などの入力装置、並びにプリンタ４１５、表示装置４１４及びスピーカ４１７などの出力装置により形成される。変復調器（モデム）トランシーバ装置４１６は、例えば、電話回線４２１又は他の機能媒体を介して接続可能である通信ネットワーク４２０と通信するために、コンピュータモジュール４０１により使用される。モデム４１６は、インターネット、並びにローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）などの他のネットワークシステムへのアクセスを獲得するために使用可能である。また、実現形態によっては、モデム４１６は、コンピュータモジュール４０１に組み込まれてもよい。

コンピュータモジュール４０１は、通常、少なくとも１つのプロセッサユニット４０５と、例えば、半導体ランダムアクセスメモリ（ＲＡＭ）及び読み取り専用メモリ（ＲＯＭ）から構成されるメモリユニット４０６とを含む。コンピュータモジュール４０１は、ビデオディスプレイ４１４及びスピーカ４１７に結合するオーディオビデオインタフェース４０７と、キーボード４０２及びマウス４０３、並びにオプションとして使用されるジョイスティック（図示せず）に対応する入出力（Ｉ／Ｏ）インタフェース４１３と、モデム４１６及びプリンタ４１５に対応するインタフェース４０８とを含む複数のＩ／Ｏインタフェースを更に含む。実現形態によっては、モデム４１６は、コンピュータモジュール４１０の内部、例えば、インタフェース４０８の中に組み込まれてもよい。記憶装置４０９が設けられる。通常、記憶装置４０９は、ハードディスクドライブ４１０及びフロッピー（登録商標）ディスクドライブ４１１を含む。磁気テープドライブ（図示せず）が更に使用されてもよい。ＣＤ‐ＲＯＭドライブ４１２は、通常、不揮発性データ源として設けられる。コンピュータモジュール４０１の構成要素４０５〜４１３は、通常、相互接続バス４０４を介して、コンピュータシステム４００が当業者に知られている従来の動作モードで動作する結果となるように互いに通信する。説明される構成を実施できるコンピュータの例としては、ＩＢＭ‐ＰＣ及びそのコンパチブル、Sun Sparcstation又はそれらから派生した類似のコンピュータシステムがある。

通常、コードモジュールは、ハードディスクドライブ４１０に常駐し、プロセッサ４０５に読み取られ、その実行は、プロセッサ４０５により制御される。モジュール及びネットワーク４２０から取り出されるデータの中間格納は、可能であれば、ハードディスクドライブ４１０と協調して、半導体メモリ４０６を使用して実現されてもよい。場合によっては、コードモジュールは、ＣＤ‐ＲＯＭ又はフロッピー（登録商標）ディスクに符号化された形でユーザに供給され、対応するドライブ４１２又は４１１を介して読み取られてもよい。あるいは、コードモジュールは、ユーザにより、ネットワーク４２０からモデム装置４１６を介して読み取られてもよい。更に、ソフトウェアは、他のコンピュータ可読媒体からコンピュータシステム４００にロードされることも可能である。ここで使用される用語「コンピュータ可読媒体」は、実行及び／又は処理のために、命令及び／又はデータをコンピュータシステム４００に提供することに関与するあらゆる記憶媒体又は送信媒体を表す。記憶媒体の例としては、フロッピー（登録商標）ディスク、磁気テープ、ＣＤ‐ＲＯＭ、ハードディスクドライブ、ＲＯＭ又は集積回路、光磁気ディスク、あるいはＰＣＭＣＩＡカードなどのコンピュータ可読カードがあり、それらの装置は、コンピュータ４０１の内部にあってもよいし、外部にあってもよい。送信媒体の例としては、無線送信チャネル又は赤外線送信チャネル、並びに別のコンピュータ又はネットワーク化装置へのネットワーク接続、更には、Ｅメール送信及びウェブサイトなどに記録された情報を含めたインターネット又はイントラネットがある。

あるいは、説明される方法は、説明される方法の機能又は部分機能を実行する１つ以上の集積回路などの専用ハードウェアで実現されてもよい。そのような専用ハードウェアには、グラフィックプロセッサ、デジタルシグナルプロセッサ、又は１つ以上のマイクロプロセッサ及び関連メモリが含まれる。

方法９００は、連続するグラフィカルオブジェクトを組み合わせるために使用されてもよい。それらのグラフィカルオブジェクトは、元来、１つの複雑なオブジェクトに由来するか、並列して位置する２つのオブジェクトであるか、又は重複する２つのオブジェクトである。図６は、２段階稜線ベースグラフィックスレンダリングシステム６３０の一例を示す。このレンダリングシステム６３０は、方法９００及び方法１０００を実現するために使用されてもよい。グラフィックスレンダリングシステム６３０は、図６に示される線形勾配塗りつぶし６９０のような線形勾配塗りつぶしをレンダリングするために使用されてもよい。グラフィックスレンダリングシステム６３０は、オブジェクトコンパイラ６７０と、メタ塗りつぶしディスパッチャ６８０とを具備する。グラフィックスレンダリングシステム６３０は、ディスプレイリスト作成モジュール６４０と、ディスプレイリスト６５０と、レンダリングモジュール６６０とを更に具備する。図６に示されるように、グラフィックスデバイスインタフェース６２０は、グラフィックスアプリケーション６１０から線形勾配塗りつぶし６９０を受信し、線形勾配塗りつぶし６９０を、複数の隣接するフラット塗りつぶしオブジェクト（例えば、平行四辺形６２１）として、グラフィックスレンダリングシステム６３０へ送信する。

オブジェクトコンパイラ６７０は、隣接するオブジェクト、重複するオブジェクト又は連続するオブジェクトを組み合わせ、関連するメタ塗りつぶしと共にコンパイルドオブジェクトを適宜形成し、それにより、そのようなオブジェクトの間にある稜線を除去するために使用されてもよい。現在のコンパイルドオブジェクトとして組み合わせできるオブジェクトがそれ以上存在しないとオブジェクトコンパイラ６７０が判定したならば、コンパイラ６７０は、コンパイルドオブジェクトを稜線、レベル及び関連するメタ塗りつぶしに変換してもよい。その後、コンパイルドオブジェクトは、現在のディスプレイリスト６５０に挿入されてもよい。

レンダリングモジュール６６０は、ディスパッチャ６８０を具備する。レンダリングモジュール６６０は、メタ塗りつぶしデータを復号し、塗りつぶし情報を生成する。その塗りつぶし情報は、コンパイルドオブジェクト６４１中の１つ以上の画素スパンをレンダリングするために使用されてもよい。

次に、図９を参照して、複数のオブジェクトを組み合わせる方法９００を説明する。方法は、ハードディスクドライブ４１０に常駐し、プロセッサ４０５により実行が制御されるソフトウェアとして実現されてもよい。方法９００は、コンパイラ６７０の１つ以上のソフトウェアモジュールとして実現されてもよい。オブジェクトは、グラフィックスデバイスインタフェース６２０のようなグラフィックスインタフェースから、ｚ-orderの昇順で、コンパイラ６７０により受信されてもよい。

方法９００は、ステップ９１０で始まる。ステップ９１０では、オブジェクトコンパイラ６７０を実行するプロセッサ４０５は、グラフィックスデバイスインタフェース６２０から受信された現在のオブジェクトを検出する。次のステップ９２０で、プロセッサ４０５は、現在のオブジェクトが単純なマージルール（merging rules）に従うか否かを判定する。それらのルールは、
（１）オブジェクトが２つの平行で、一致しない直線の辺を有すること、
（２）オブジェクトが、（１）で識別された２つの平行な辺の不特定の拡張（indefinite extension ）エリアの外に出ないことである。

現在のオブジェクトがそれらのルールに適合する場合、現在のオブジェクトはマージされてもよい。現在のオブジェクトがマージされてもよいならば、方法９００は、ステップ９３０へ進む。そうでない場合には、方法は、ステップ９４０へ進む。

ステップ９３０においては、プロセッサ４０５は、現在のオブジェクトをメモリ４０６に格納する。現在のオブジェクトは、この時点では、中間フォーマットに変換されない。次に、方法９００は、ステップ９５０へ進み、ステップ９１０で受信されたオブジェクトは、「以前に格納された」オブジェクトになる。

ステップ９４０では、プロセッサ４０５は、現在のオブジェクトを稜線ベースフォーマットに変換し、方法９００は、ステップ９５０に続く。次のステップ９５０で、プロセッサ４０５は、グラフィックスデバイスインタフェースから次のオブジェクトを受信する。ステップ９５０で受信されたオブジェクトが「現在」のオブジェクトになる。この時点で、それまでにフローチャートのどの経路をたどったかに応じて、「以前に格納された」オブジェクトは存在する場合もあるが、存在しない場合もある。

方法は、次のステップ９６０に続く。ステップ９６０では、以前に格納されたオブジェクトが存在するとプロセッサ４０５が判定した場合、方法９００は、ステップ９７０へ進む。そうでない場合には、方法９００は、ステップ９８０へ進む。

ステップ９７０で、プロセッサ４０５は、まず、現在のオブジェクトが先にステップ９２０に関連して挙げた単純なマージルールに従うか否かを判定することにより、現在のオブジェクトを先に格納されたオブジェクトと組み合わせてよいか否かを判定する。組み合わせてよいならば、プロセッサ４０５は、現在のオブジェクト及び以前に格納されたオブジェクトが所定の基準を満たすか否かを判定する。ステップ９７０の所定の基準は、次の通りである。

（１）現在のオブジェクトと以前に格納されたオブジェクトの双方の平行な辺が同一の角度であること、及び
（２）現在のオブジェクトと以前に格納されたオブジェクトが、それらのオブジェクトの平行な辺の全長にわたって重複するか、それらの平行な辺で互いに境を接していること。

図１５Ａから図１５Ｅは、上記の所定の基準を満たし、従って、組み合わせ可能なオブジェクトのいくつかの例（例えば、１５１１）を示す。図１５Ａは、上記の基準を満たすオブジェクト１５１１及び１５１０を示す。オブジェクト１５１１及び１５１０は、組み合わせの結果として得られるアウトライン１５１２を記述するために、パス（path）を形成することを要求しない。アウトライン１５１２は、４つの点により表現されてもよい。同様に、図１５Ｂは、上記の基準を満たすオブジェクト１５２０及び１５２２を示す。それらのオブジェクトは、組み合わせの結果として得られるアウトライン１５２１を記述するために、パスを要求しない。この場合も、アウトライン１５２１は、４つの点により表現されてもよい。

図１５Ｃは、上記の所定の基準を満たし、従って、組み合わせ可能なオブジェクト１５３０及び１５３２を示す。オブジェクト１５３０及び１５３２は、組み合わせの結果として得られるコンパイルドオブジェクト（compiled object ）１５３１を記述するために、パスを形成することを要求する。同様に、図１５Ｄは、上記の所定の基準を満たし、組み合わせ可能なオブジェクト１５４０及び１５４２を示す。オブジェクト１５４０及び１５４２は、組み合わせの結果として得られるコンパイルドオブジェクト１５４１を記述するために、パスを形成することを要求する。同様に、図１５Ｅは、上記の所定の基準を満たし、組み合わせ可能な２つのオブジェクト１５５０及び１５５２を示す。オブジェクト１５５０及び１５５２は、組み合わせの結果として得られるコンパイルドオブジェクト１５５１を記述するために、パスを形成することを要求する。

これに対し、図１５Ｆ及び図１５Ｇは、上記の所定の基準を満たさず、組み合わせ不可能なオブジェクトのいくつかの例（例えば、１５７１）を示す。図１５Ｆは、上記の基準を満たさないために、組み合わせ不可能なオブジェクト１５６０及び１５６１の例を示す。特に、オブジェクト１５６０及び１５６１は、オブジェクトの平行な（水平方向の）辺により境界を規定されるエリアの外側に出ていることにより、単純なマージルールのうちの第２のルールに反する。同様に、図１５Ｇは、上記の基準を満たさないために、組み合わせ不可能なオブジェクト１５７０及び１５７１の例を示す。特に、オブジェクト１５７０及び１５７１は、平行である２つの一致しない辺を有していないことにより、単純なマージルールのうちの第１のルールに反する。

現在のオブジェクトと以前に格納されたオブジェクトがステップ９７０の所定の基準を満たすならば、方法９００は、ステップ９７１へ進む。ステップ９７１では、現在のオブジェクトは、以前に格納されたオブジェクトと共に、メモリ４０６に格納される。現在のオブジェクトと、以前に格納されたオブジェクトの塗りつぶしが同一で、フラット色から構成されている場合に、現在のオブジェクトは、以前に格納されたオブジェクトとマージされるのが好ましい。ステップ９７０で、現在のオブジェクトと、以前に格納されたオブジェクトを組み合わせ不可能な場合には、方法９００は、ステップ９９０へ進む。

ステップ９９０では、現在のオブジェクトを以前に格納されたオブジェクトと組み合わせ不可能であるため、以前に格納された全てのオブジェクトが組み合わされて、１つのコンパイルドオブジェクトが形成される。コンパイルドオブジェクトは、中間稜線ベースグラフックスフォーマットに変換され、その後、方法９００は、ステップ９８０へ進む。ステップ９９０で、オブジェクトを中間フォーマットに変換するとき、方法９００は、メモリ４０６内部に構成されたメタ塗りつぶし構造の中に塗りつぶし長さを格納する。塗りつぶし長さは、以前に格納されたオブジェクトの個々の塗りつぶしの水平方向ラン長さに対応する。以前に格納されたオブジェクトが２つ以上存在する場合、コンパイラ６７０は、ステップ９９０において、メタ塗りつぶし中の塗りつぶしを記述する基本塗りつぶしデータ構造（primitive fill data structures ）の連係リスト（linked list ）を作成することにより、メタ塗りつぶしを生成するのが好ましい。

図１１は、メタ塗りつぶし１１１０を詳細に示す。メタ塗りつぶし１１１０は、コンパイルドオブジェクトの中の任意の点における特定の塗りつぶしエントリ（particular fill entry ）を呼び出すために必要なデータの全てを含む。メタ塗りつぶし１１１０は、ヘッダ１１２０を含む。ヘッダ１１２０は、トラッキングポイント（tracking point ）１１２１及びトラッキングポイントＤＸ１１２２を含む。トラッキングポイント１１２１は、指定された走査線に関して、メタ塗りつぶし１１１０の中の第１の塗りつぶし１１２３の開始場所を指示するために使用されてもよい。指定された走査線に関して、メタ塗りつぶし１１１０の中の第１の塗りつぶしの開始場所を指示することにより、以下に更に詳細に説明されるように、メタ塗りつぶし１１１０と関連するコンパイルドオブジェクトをレンダリングすることができる。トラッキングポイント１１２１は、現在の走査線に対して、トラッキングポイントＤＸ１１２２に従って更新される。トラッキングポイントＤＸ１１２２は、メタ塗りつぶし１１１０により表現されるコンパイルドオブジェクトを形成するために、当初、グループ化されたオブジェクトの平行な辺の傾きを表す。トラッキングポイントは、オブジェクトの最も左側の平行な辺と、オブジェクトが存在している最上位置の走査線との交点として設定される。トラッキングポイントＤＸ１１２２は、メタ塗りつぶし１１１０の中の第１の塗りつぶしの場所を追跡するために、ディスパッチャ６８０により使用されてもよい。メタ塗りつぶしの中の第１の塗りつぶしの位置がわかれば、コンパイルドオブジェクトの他の全ての塗りつぶしを判定できる。ヘッダ１１２０は、次の塗りつぶし１１２３を指示するポインタ１１３３を更に含む。

個別の基本塗りつぶし（primitive fills ）１１２３は、連係リストとして、ヘッダ１１２０に付加される。個別の塗りつぶしの各々は、互いに連係され、各基本塗りつぶしは、ヘッダ（例えば、ヘッダ１１２９）を含む。ヘッダ１１２９は、メタ塗りつぶし１１１０の中の特定の塗りつぶしの画素ランの長さを表す少なくとも１つのサイズ変数１１３１を含む。サイズ変数１１３１は、メタ塗りつぶし１１１０を画素にレンダリングするときに、ディスパッチャ６８０により使用される。以下に更に詳細に説明されるように、サイズ変数１１３１は、メタ塗りつぶし１１１０の中の塗りつぶしごとに、正しい大きさの画素ランが出力されることを保証する。コンパイラ６７０は、メタ塗りつぶし１１１０に追加される各オブジェクトの平行な辺の間の水平方向距離を単純に判定することにより、メタ塗りつぶし１１１０の中の個別の塗りつぶしの画素長さを判定する。ヘッダ１１２９は、塗りつぶし型１１３５及び関連パラメータと、次の塗りつぶし１１２５を指示するポインタ１１３７とを更に含む。メタ塗りつぶし１１１０が生成されたならば、メタ塗りつぶし１１１０は、コンパイルドオブジェクトの稜線及びレベルデータと共に、ディスプレイリストに追加される。

他の実施形態においては、メタ塗りつぶしに、テーブル又はアレイなどの他のデータ構造が使用されることも可能であろう。

尚、ステップ９９０で作成されるコンパイルドオブジェクトのレベルは、最も早い時点（最低レベル）で先に格納されたオブジェクトのレベルと等しい。

方法９００は、次のステップ９８０に続く。ステップ９８０では、プロセッサ４０５は、ステップ９２０のときと同様に、現在のオブジェクトが単純なマージルールに従うか否かを判定する。現在のオブジェクトがステップ９７０で以前に評価されており、現在のオブジェクトを別のオブジェクトとマージしてもよいと判定されていた場合、プロセッサ４０５は、その解析結果を使用して、現在のオブジェクトをマージできるか否かを判定してもよい。ステップ９８０で、現在のオブジェクトを別のオブジェクトとマージしてもよいとプロセッサ４０５が判定した場合、方法９００は、ステップ９８１へ進む。そうでない場合には、方法９００は、ステップ９８５へ進む。ステップ９８５では、現在のオブジェクトは、中間フォーマットに変換される。その後、実行は、ステップ９８２へ進む。

ステップ９８１では、現在のオブジェクトは、メモリ４０６に格納される。次のステップ９８２において、グラフィックスレンダリングシステム６３０が処理すべきオブジェクトが他に存在しない場合、方法９００は、ステップ９８３へ進む。処理すべきオブジェクトが存在する場合には、方法９００は、ステップ９５０に戻る。ステップ９８３では、ステップ９９０のときと同様に、以前に格納された全てのオブジェクトが組み合わされて、コンパイルドオブジェクトが形成される。コンパイルドオブジェクトは、関連するメタ塗りつぶしと共に、中間稜線ベースフォーマットに変換される。

ステップ９９０及び／又は９８３において、コンパイルドオブジェクトの稜線及びレベルデータは、個別のオブジェクト（すなわち、以前に格納されたオブジェクト）の特性からではなく、コンパイルドオブジェクトのアウトラインから判定される。コンパイルドオブジェクトの中の塗りつぶしデータを記述するために、標準基本塗りつぶしではなく、メタ塗りつぶしが使用される。図１２は、コンパイルドオブジェクト１２１０の一例及び関連するメタ塗りつぶし１２１５を示す。

図７Ａは、当初の稜線ベースオブジェクト７１０を示す。図７Ｂは、従来の方式により、塗りつぶし７２０、稜線７２２及びレベル７２４として格納されたオブジェクト７１０を示す。これとは対照的に、図７Ｃに示されるように、オブジェクト７１０は、塗りつぶし７３０、稜線７３２及びレベル７３４により表現されるコンパイルドオブジェクトとして格納されてもよい。元のオブジェクト７１０を表現する図７Ｃの稜線７３２及びレベル７３４は、図７Ｂの稜線７２２及びレベル７２４ほどメモリを必要としない。

レンダリングモジュール６６０のディスパッチャ６８０は、特定の画素及び特定の走査線位置に対して、どの塗りつぶしをレンダリングすべきかを判定する。レンダリングされるべき最上位のアクティブレベルが、そのレベルと関連するメタ塗りつぶしを有する場合、ディスパッチャ６８０は、メタ塗りつぶしを復号するために使用されてもよい。

先に説明したように、メタ塗りつぶしは、ディスパッチャ６８０により追跡されるトラッキングポイント１１２１を含む。トラッキングポイント１１２１は、当初組み合わされたオブジェクトの平行な辺と平行に移動する。トラッキングポイント１１２１を使用して、ディスパッチャ６８０は、レンダリングされるべきコンパイルドオブジェクトの中の任意の位置に対して、メタ塗りつぶし１１１０の中でどの塗りつぶしを使用すべきかを判定してもよい。

コンパイルドオブジェクトの全体又は一部がレンダリングされるべき場合、コンパイルドオブジェクトを表現するレンダリング情報は、ディスパッチャ６８０へ送信される。ディスパッチャ８０は、レンダリングモジュール６６０の現在のｘ位置、コンパイルドオブジェクトのトラッキングポイント１１２１及びメタ塗りつぶし１１１０の中の個別の塗りつぶし（例えば、１１２３）の画素幅を使用して、現在の塗りつぶしと、現在の塗りつぶしからレンダリングされるべき画素の数とを判定する。メタ塗りつぶし１１１０の中のｘ位置は、走査線上で、トラッキングポイント１１２１と同一の点に対応するとは限らない。それは、メタ塗りつぶし１１１０を閉塞する他のオブジェクトが存在するか、又はメタ塗りつぶし１１１０がクリップオブジェクトを含む可能性があるためである。例えば、図１２は、クリッピング領域１２２０を伴うコンパイルドオブジェクト１２１０を示す。

図１０は、コンパイルドオブジェクトをレンダリングする方法１０００を示す流れ図である。方法１０００は、ハードディスクドライブ４１０に常駐し、プロセッサ４０５により実行を制御されるソフトウェアとして実現されてもよい。方法１０００は、ディスパッチャ６８０の１つ以上のソフトウェアモジュールとして実現されてもよい。方法１０００は、第１のステップ１０１０で始まる。ステップ１０１０で、ディスパッチャ６８０は、メタ塗りつぶしを受信する。メタ塗りつぶしは、レンダリングモジュール６６０から受信されてもよい。レンダリングモジュール６６０は、レンダリングされるべき画素の数、出力フォーマット及びレンダリングモジュールの現在の走査線位置を指定してもよい。また、レンダリングモジュール６６０は、レンダリングされた画素データを挿入するための、メモリ４０６内部の出力バッファを構成してもよい。

次に、方法１０００は、ステップ１０１５へ進む。ステップ１０１５では、レンダリングされるべき現在の走査線に従って、メタ塗りつぶしのトラッキングポイント（例えば、１１２１）が更新される。ディスパッチャ６８０は、メタ塗りつぶしのトラッキングポイントの現在のｙ位置と、現在の走査線のｙ位置との距離を判定することにより、メタ塗りつぶしのトラッキングポイントを更新する。次に、ディスパッチャ６８０は、判定された距離（０になる場合もある）をトラッキングポイントＤＸ（例えば、１１２２）と乗算する。次に、新たなトラッキングポイントｘ位置を判定するために、その乗算の結果は、現在のトラッキングポイントｘ位置に加算される。メタ塗りつぶしのトラッキングポイントの新たなｙ位置は、現在の走査線の現在のｙ位置と一致するように更新される。次のステップ１０２０で、レンダリングモジュール６６０の現在のレンダリング位置がメタ塗りつぶしのトラッキングポイントから離間している距離の画素数を判定するために、現在のレンダリング位置がトラッキングポイントと比較される。ステップ１０２０における判定は、更新後のトラッキングポイントｘ位置を現在のレンダリングｘ位置から減算することにより実行されてもよい。

方法１０００は、次のステップ１０３０に続く。ステップ１０３０で、プロセッサ４０５は、メタ塗りつぶしの塗りつぶしからアクティブ塗りつぶしを判定する。アクティブ塗りつぶしは、レンダリングされるべき現在の画素データに対応する、メタ塗りつぶしの塗りつぶしである。次のステップ１０４０では、アクティブ塗りつぶしを使用してレンダリングすべき画素の数が判定される。アクティブ塗りつぶしを使用してレンダリングすべき画素の数は、レンダリングモジュール６６０がレンダリングすることを要求する画素の数と、アクティブ塗りつぶしにおいて残留している画素の数のうちで小さいほうの数として判定される。アクティブ塗りつぶしにおいて残留している画素の数は、アクティブ塗りつぶしの最大ｘ位置から現在のレンダラｘ位置を減算した値に基づいて判定される。

レンダリングされるべき画素の数が判定されたならば、方法１０００は、ステップ１０５０へ進む。ステップ１０５０では、要求された画素ランがレンダリングされる。画素データを生成するために、ディスパッチャ６８０は、アクティブ塗りつぶしの塗りつぶし型に従って、アクティブ塗りつぶしをネイティブレンダリング機能へ送信する。また、ステップ１０５０では、現在のレンダリングｘ位置及びレンダリングされるべき画素の数が更新される。方法１０００は、次のステップ１０６０に続く。ステップ１０６０において、レンダリングされるべき画素が他にまだ存在している場合、方法１０００は、ステップ１０７０へ進む。そうでない場合には、方法１０００は終了する。ステップ１０７０で、プロセッサ４０５は、メタ塗りつぶしにおける次の塗りつぶしを検索する。ステップ１０７０で検索された塗りつぶしは、アクティブ塗りつぶしになる。ステップ１０７０に続いて、方法１０００は、ステップ１０４０へ進む。

一例として、図８Ａは、１つの平行四辺形の形態をとるコンパイルドオブジェクト８２０を含むページ８３０を示す。コンパイルドオブジェクト８２０は、コンパイルドオブジェクト８２０の一部を閉塞する円オブジェクト８１０を有する。円オブジェクト８１０は、白色フラット塗りつぶしを含む。コンパイルドオブジェクト８２０は、４つの塗りつぶし８０７、８０９、８１１及び８１３を有する。これらの塗りつぶしは、図８Ｂに示されるように、１つのメタ塗りつぶし８３５の中に含まれていてもよい。

メタ塗りつぶし８３５は、指定された走査線（すなわち、３００）に関して、メタ塗りつぶし８３５の中の第１の塗りつぶし８０７の開始場所（すなわち、画素１００）を指示するトラッキングポイント変数８４４を含むヘッダ８３７を含む。ヘッダ８３７は、トラッキングポイントＤＸ８６５を含む。ヘッダ８３７は、次の塗りつぶし８０９を記述する塗りつぶし構造８３８を指示するポインタを更に含む。

塗りつぶし構造８３８は、ヘッダ８３９を含む。ヘッダ８３９は、塗りつぶし型変数８４６を使用して、塗りつぶし型を説明する。塗りつぶし型変数８４６は、塗りつぶし８０７がパターン塗りつぶしであることを示す。ヘッダ８３９は、塗りつぶし８０７の画素ランの長さを表すサイズ変数８４７を更に含む。塗りつぶし８０７は、２０画素にわたる。塗りつぶし構造８３８は、ストライプパターン塗りつぶしデータ８６１を更に含む。最後に、ヘッダ８３９は、次の塗りつぶし８０９を説明する次の塗りつぶし構造８４１を指示するポインタ８４８を含む。

塗りつぶし構造８４１は、ヘッダ８４３を含む。ヘッダ８４３は、塗りつぶし型変数８４９を使用して、塗りつぶし型を説明する。塗りつぶし型変数８４９は、塗りつぶし８０９がパターン塗りつぶしであることを示す。ヘッダ８４１は、塗りつぶし８０９の画素ランの長さが１００画素であることを示すサイズ変数８５０を更に含む。塗りつぶし構造８４１は、クロスハッチパターン塗りつぶしデータ８６２を更に含む。最後に、ヘッダ８４３は、次の塗りつぶし８１１を説明する次の塗りつぶし構造８４５を指示するポインタ８５１を含む。

塗りつぶし構造８４５は、ヘッダ８５２を含む。ヘッダ８５２は、塗りつぶし型変数８５３を使用して、塗りつぶし型を説明する。塗りつぶし型変数８５３は、塗りつぶし８１１がパターン塗りつぶしであることを示す。ヘッダ８５２は、塗りつぶし８１１の画素ランの長さを表すサイズ変数８５４を更に含む。サイズ変数８５４により示されるように、塗りつぶし８１１は、１５０画素に及ぶ。塗りつぶし構造８４５は、ドットパターン塗りつぶしデータ８６３を更に含む。最後に、ヘッダ８５２は、次の塗りつぶし８１３を説明する次の塗りつぶし構造８５６を指示するポインタ８５５を含む。

塗りつぶし構造８５６は、ヘッダ８５７を含む。ヘッダ８５７は、塗りつぶし型変数８５８を使用して、塗りつぶし型を説明する。塗りつぶし型変数８５８は、塗りつぶし８１３がフラット塗りつぶしであることを示す。ヘッダ８５７は、塗りつぶし８１３の画素ランの長さを表すサイズ変数８５９を更に含む。サイズ変数８５９により示されるように、塗りつぶし８１３は、４０画素にわたる。塗りつぶし構造８５６は、フラット塗りつぶしデータ８６４を更に含む。最後に、ヘッダ８５７は、次の塗りつぶし構造を指示するポインタ８６０を含む。しかし、図８Ａ及び図８Ｂの例においては、他に塗りつぶしは存在しないため、ポインタ８６０の値はヌルである。

円オブジェクト８１０は、メタ塗りつぶし８３５より高いZ-オーダー（Z-order）を有し、従って、コンパイルドオブジェクト８２０の一部を閉塞している。レンダリングモジュール６６０の現在のレンダリング位置が円オブジェクト８１０上の点８０５と交差するのに応答して、点８０６に続く第１の画素と関連する塗りつぶしが判定されなければならない。点８０５において、ｙ位置は３００であり（すなわち、現在の走査線が３００である）、ｘ位置は２６５である。コンパイラ６７０は、コンパイルドオブジェクト８２０の塗りつぶしがメタ塗りつぶし８３５であると判定し、方法１０００のステップ１０１０の通りに、デコンパイリングのために、塗りつぶしをディスパッチャ６８０へ送信する。ディスパッチャ６８０は、方法１０００のステップ１０１５の通りに、メタ塗りつぶし８３５のトラッキングポイントを、現在の走査線（すなわち、走査線３００）におけるコンパイルドオブジェクト８２０のトラッキングポイント８１５と一致するように更新する。

ディスパッチャ６８０は、メタ塗りつぶし８３５のトラッキングポイント変数８４４の現在のｙ位置と、レンダリングされるべき現在の走査線（すなわち、走査線３００）のｙ位置との距離を判定することにより、現在の走査線のトラッキングポイント変数８４４を更新する。次に、ディスパッチャ６８０は、判定された距離（０になる場合も有る）をトラッキングポイントＤＸ８６５と乗算し、メタ塗りつぶし８３５のトラッキングポイント変数８４４の新たなｘ位置を判定する。メタ塗りつぶし８３５のトラッキングポイント変数８４４の新たなｙ位置は、現在の走査線の現在のｙ位置と一致するように更新される。図８Ａ及び図８Ｂの例では、先に説明したように、現在の走査線のトラッキングポイント８１５のトラッキングポイント変数８４４は、（１００，３００）である。

ディスパッチャ６８０は、方法１０００のステップ１０３０の通りに、現在「アクティブ」である塗りつぶしを判定するために、トラッキングポイント８１５を示す判定されたトラッキングポイント変数８４４を使用してもよい。現在アクティブである塗りつぶしは、点８０５に続く第１の画素についてレンダリングされるべき塗りつぶしである。ディスパッチャ６８０は、点８０５におけるｘ位置と、トラッキングポイント８１５のｘ位置との距離を判定する。図８Ａの例では、点８０５において、ｘ位置は、トラッキングポイント８１５から１６５画素（すなわち、２６５−１００）の距離にある。次に、ディスパッチャ６８０は、トラッキングポイント８１５から１６５番目の画素と関連する塗りつぶしを判定するために、メタ塗りつぶし８３５と関連する連係塗りつぶし構造８３８、８４１、８４５及び８５６のリストを検討する。ディスパッチャ６８０は、現在の塗りつぶしが１６５番目の画素に及ぶまで、連係塗りつぶしの個別の画素ランの長さを累積することにより、１６５番目の画素と関連する塗りつぶしを判定する。コンパイルドオブジェクト８２０の場合、先に説明したように、第１の塗りつぶし８０７は、２０画素にわたり、第２の塗りつぶし８０９は、１００画素にわたり、第３の塗りつぶし８１１は、１５０画素にわたり、最後の塗りつぶし８１３は、４０画素にわたる。図８Ａ及び図８Ｂの例においては、第３の塗りつぶし８１１がトラッキングポイント８１５から１６５番目の画素を含む。従って、第３の塗りつぶし８１１が、現在アクティブである塗りつぶしと呼ばれることになる。図８Ａからわかるように、第３の塗りつぶし８１１は、トラッキングポイント８１５から１２０番目の画素で始まる。図８ＡにおいてＡｘとマークされた線は、１２０画素分の長さを有する。ページの境界８３０を参照すると、１２０番目の画素は、現在の走査線（すなわち、走査線３００）上の画素番号２２０に相当する。レンダリングモジュール６６０の現在のレンダリング位置は、画素番号２６５であるので、図８ＡにおいてＬｘにより示されるように、ディスパッチャ６８０は、第３の塗りつぶし８１１のうちの４５画素（すなわち、２６５−２２０）が経過したと判定してもよい。図８Ａからわかるように、Ｆｘは、現在アクティブである塗りつぶし８１１に関して、レンダリングされるべき画素の数を表す。ディスパッチャ６８０は、方法１０００のステップ１０４０の通りに、現在アクティブである塗りつぶし８１１に関して、レンダリングされるべき画素の数は１０５画素（すなわち、１５０−４５）であると判定する。

次に、ディスパッチャ６８０は、方法１０００のステップ１０５０の通りに、ネイティブレンダリング機能を使用して、Ｆｘにより表される第３の塗りつぶし８１１のうちの１０５画素をレンダリングすることを、レンダリングモジュール６６０に要求する。レンダリングモジュール６６０が、現在アクティブである塗りつぶし８１１に従って、１０５画素のレンダリングを終了すると、レンダリングされるべき現在の走査線の画素ランが他に存在するとディスパッチャ６８０が判定した場合、ディスパッチャ６８０は、方法１０００のステップ１０７０の通りに、次のアクティブ塗りつぶしを判定する。

先に説明したように、コンパイルドオブジェクトを形成するために、複数のグラフィカルオブジェクトを組み合わせ、それにより、冗長稜線を除去してもよい。走査線ごとに分類、追跡される必要がある稜線とは異なり、メタ塗りつぶしの属性は、高レベルで、一度判定されるだけでよいので、多数の稜線を分類、追跡しなければならない従来のレンダリング方法と比べて、コンパイルドオブジェクトのレンダリングは、はるかに効率がよい。

ステップ９８３及び／又は９９０で、コンパイラ６７０は、塗りつぶし型の異なるグラフィカルオブジェクトを組み合わせてもよい。コンパイラ６７０は、そのようなオブジェクトの稜線を組み合わせ、オブジェクトと関連する塗りつぶしを、同一のオブジェクトに属する別個のエンティティとして扱う。従って、ビットマップを組み合わせる場合、その他に画像操作又はコピーを実行する必要はない。オブジェクトと関連する塗りつぶしは、別個に処理され、格納されてもよいが、コンパイラ６７０により、一体に連係される。例えば、図１６は、図６のグラフィックスデバイスインタフェース６２０により生成された２つのビットマップ１６３０及び１６４０を連係するメタ塗りつぶし１６６０を示す。図１６の例では、グラフィックスアプリケーション６１０のようなグラフィックスアプリケーションにより作成された元のビットマップ１６２０が、グラフィックスデバイスインタフェース６２０により、２つの別個のビットマップ１６３０及び１６４０として送信される。コンパイラ６７０は、ビットマップ１６３０及び１６４０は互いに並列して位置することを認識し、そこで、２つのビットマップ１６３０及び１６４０からメタ塗りつぶし１６６０を生成する。これとは対照的に、従来のレンダリング方法は、一方のビットマップ（例えば、ビットマップ１６３０）のデータを他方のビットマップ１６４０にコピーすることにより、ビットマップ１６３０及び１６４０を組み合わせるため、効率が悪い。

また、先に説明したように、従来のレンダリング方法は、非線形勾配塗りつぶし５１０のような非線形勾配塗りつぶしから、多数の勾配塗りつぶしを生成する。しかし、先に説明したように、勾配塗りつぶし５１０は、多数の塗りつぶし要素を伴って、単一のコンパイルドオブジェクトとして処理されてもよい。そのようにすることにより、メタ塗りつぶしにおいて関連する線形勾配を保持しつつ、冗長稜線を除去できる。単純なフラット塗りつぶしを組み合わせる場合、コンパイラ６７０が同一の色のオブジェクトの組み合わせのみに限定されることはない。コンパイラ６７０は、色の異なるオブジェクトであっても、更には、塗りつぶし型の異なるオブジェクトであっても、組み合わせることができる。それは、塗りつぶしが再び連係されるからである。従って、オブジェクトの稜線が１つに組み合わせられる一方で、必要な全ての塗りつぶし情報は依然としてレンダリングモジュール６６０に提示される。

図１３は、６つの基本オブジェクト１３１０、１３２０、１３３０、１３４０、１３５０及び１３６０を示す。従来のレンダリングシステム３３０は、オブジェクト１３１０〜１３６０の各々を２つの稜線（例えば、オブジェクト１３１０の場合、稜線１３１１及び１３１２）として処理する。各稜線１３１１は、関連するレベルデータ１３１３及び塗りつぶしデータ１３１４を有する。これに対し、図１４は、オブジェクト１３１０〜１３６０から形成されたコンパイルドオブジェクト１４１０を示す。図１４からわかるように、コンパイルドオブジェクトは、関連するメタ塗りつぶし１４１５を有する。レンダリングモジュール６６０は、コンパイルドオブジェクト１４１０を単一のオブジェクトとして処理し、従って、コンパイルドオブジェクト１４１０のアウトライン１４１３を記述する稜線１４１１及び１４１２の知識を有するのみである。

基本オブジェクト１３１０〜１３６０をレンダリングする時に、モジュール３６０のような従来の稜線ベースレンダリングモジュールは、走査線ごとに、各オブジェクトの各々の稜線（例えば、稜線１３１１）を更新する。個々の走査線ごとに、レンダリングモジュール３６０が稜線１３１１のような左側の稜線に遭遇すると、レベルデータ１３０３がロードされなければならず、また、塗りつぶしデータ１３１４から、画素ランが計算されなければならない。これとは対照的に、メタ塗りつぶし１４１５のようなメタ塗りつぶしを符号化し、復号することにより、レンダリングモジュール６６０は、２つの稜線を処理するだけでよく、単一のレベルをロードするだけでよい。例えば、レンダリングモジュール６６０は、オブジェクト１３１０〜１３６０の各々の稜線を個別に追跡する必要がない。それは、全ての稜線（例えば、稜線１３１１及び１３１２）が平行であるからである。そのため、塗りつぶしデータは、常に、メタ塗りつぶし１４１５の中の第１の塗りつぶし１４１７に関連して判定され、その結果、レンダリングモジュールにより要求される労力の量は大幅に減少する。ディスパッチャ６８０は、画素データを効率よく生成できるであろう。メタ塗りつぶし１４１５のようなメタ塗りつぶしを使用するとき、走査線ごとに要求される唯一の更新は、トラッキングポイント（例えば、１１２１）の更新である。

グラフィックスレンダリングシステム３３０のような従来のグラフィックスレンダリングシステムの場合、ＲＧＢからＣＭＹＫへの色変換を実行する。そこで、ＣＭＹＫ色変換線形勾配塗りつぶしを表現するための多くの方法が知られている。１つの方法は、ＲＧＢ勾配塗りつぶしをＲＧＢ空間におけるビットマップに変換し、次に、各画素色をＣＭＹＫに変換して、色修正ビットマップを生成する。別の方法は、勾配塗りつぶしに沿ってＲＧＢ色空間における多数の点をサンプリングし、それらの点を色変換して、色変換勾配塗りつぶしに近似する多数の小さな線形ＣＭＹＫ勾配塗りつぶしを生成する。更に別の方法は、ＲＧＢ勾配塗りつぶしをサンプリングし、元の勾配塗りつぶしを表現する複数のＣＭＹＫフラット塗りつぶしを生成する。

線形勾配塗りつぶしをＣＭＹＫビットマップとして表現することは、元のＲＧＢ勾配塗りつぶし記述と比較して、非常に不効率である。更に、ＲＧＢ勾配塗りつぶし（RGB gradient fill ）を、多数の小さなＣＭＹＫ勾配塗りつぶし（CMYK gradient fills ）又はＣＭＹＫフラット塗りつぶし（CMYK flat fills ）に分解することは、隣接する勾配塗りつぶしの間に数多くの稜線が生成され、従って、レンダリングモジュール３６０のような従来のレンダリングモジュールの動作速度が劇的に遅くなるという欠点を有する。しかし、多数のＣＭＹＫ勾配塗りつぶし又はフラット塗りつぶしは、先に説明したメタ塗りつぶし１４１５のような単一のメタ塗りつぶしとして表現されてもよい。そのようなメタ塗りつぶし１４１５を使用することで、色空間変換中にオブジェクトに導入された追加稜線は除去される。

オブジェクト１４１３のようなコンパイルドオブジェクトとして組み合わされるオブジェクトの数が多くなるほど、コンパイルドオブジェクトの画素ラン（pixel runs ）は長くなる。特に、先行する走査線から、キャッシュされた画素ランを再利用することが可能である場合、多数のコンパイルドオブジェクトは、より長い画素ランから大きな利益を受ける。例えば、同一の色のフラット塗りつぶしを１つのコンパイルドオブジェクトとして組み合わせると、オブジェクトの画素ランは、より大きくなり、キャッシュの再利用は改善される。更に、レンダリングモジュールの中には、そのレンダリングモジュールがレンダリングできる、１ページ当たりのオブジェクトの量が限られているものもあるため、先に説明したように、１つのコンパイルドオブジェクト及び関連するメタ塗りつぶしを生成することにより、ソフトウェアフォールバックジョブ（すなわち、ターゲットデバイスでレンダリングを実行するには、現在のページが余りにも複雑であるために、完全にソフトウェアのみによりレンダリングされるジョブ）を形成する必要なく、ハードウェアによるページのレンダリングが可能になる。

上述の好ましい方法は、特定の制御フローを含む。本発明の趣旨の範囲から逸脱せずに、異なる制御フローを使用する好ましい方法の他の変形が数多く存在する。更に、好ましい方法のステップのうちの１つ以上は、順次実行されるのではなく、並行して実行されてもよい。

以上、本発明のいくつかの実施形態のみを説明した。本発明の趣旨の範囲内から逸脱せずに、それらの実施形態に対して変形及び／又は変更を実施することは可能である。上述の実施形態は単なる例示であり、限定的な意味を持たない。

従来のソフトウェアアプリケーションと、グラフィックスデバイスインタフェースレイヤと、グラフィックスレンダリングシステムと、ターゲットデバイスとの従来の関係を示す図である。 放射勾配塗りつぶしの一例を示す図である。 非線形勾配塗りつぶしの一例を示す図である。 線形勾配塗りつぶしの一例を示す図である。 従来のグラフィックスレンダリングシステムを示す図である。 説明される構成を実施できる汎用コンピュータの概略ブロック線図である。 非線形勾配塗りつぶしを示す図である。 図５Ａの非線形勾配塗りつぶしから生成される２つの線形勾配塗りつぶしを示す図である。 複数の線形勾配塗りつぶしを示す図である。 ２段階稜線ベースグラフィックスレンダリングシステムを示す図である。 元の稜線ベースオブジェクトを示す図である。 従来の方式により、塗りつぶし、稜線及びレベルとして格納された図７Ａのオブジェクトを示す図である。 塗りつぶし、稜線及びレベルにより表現されるコンパイルドオブジェクトとして格納された図７Ａのオブジェクトを示す図である。 コンパイルドオブジェクトの一部を閉塞する円を有するコンパイルドオブジェクトを示す図である。 図８Ａのコンパイルドオブジェクトの塗りつぶしを説明するメタ塗りつぶしを示す図である。 複数のオブジェクトを組み合わせて、コンパイルドオブジェクトを生成する方法を示す図である。 コンパイルドオブジェクトをレンダリングする方法を示す流れ図である。 メタ塗りつぶしを示す概略図である。 関連するメタ塗りつぶしと共にコンパイルされたオブジェクトの一例を示す図である。 関連する稜線データ及びレベルデータと共に６つの基本オブジェクトを示す図である。 図１３のオブジェクト及び関連するメタ塗りつぶしから形成されたコンパイルドオブジェクトを示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ不可能なオブジェクトのいくつかの例を示す図である。 組み合わせ不可能なオブジェクトのいくつかの例を示す図である。 ２つのビットマップをリンクするメタ塗りつぶしの一例を示す図である。

Claims (24)

1. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする方法であって、
   前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしを含み、前記複合塗りつぶしが、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成する工程と、
   前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングする工程と、
   を備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とする方法。
2. 前記グループ化オブジェクトアウトラインは、前記所定のオブジェクトアウトライン又はその複数の部分のうちの１つ以上に従うことを特徴とする請求項１に記載の方法。
3. 前記オブジェクトは、Z-オーダーにおいて連続し、前記グループ化オブジェクトは、前記オブジェクトの中で最低のZ-オーダーを割り当てられることを特徴とする請求項１に記載の方法。
4. 前記オブジェクトが所定の基準を満たすか否かを判定する工程を更に備えることを特徴とする請求項１に記載の方法。
5. 同一の単色塗りつぶしを有する１つ以上のグラフィカルオブジェクトは、前記複合塗りつぶしにおいて、１つ以上の単色塗りつぶしとして表現されることを特徴とする請求項１に記載の方法。
6. 線形色変化を有する１つ以上のグラフィカルオブジェクトは、前記複合塗りつぶしにおいて、１つ以上の線形混合塗りつぶしとして表現されることを特徴とする請求項１に記載の方法。
7. 前記所定の基準のうちの１つは、前記オブジェクトの各々が２つの平行な辺を有することを特徴とする請求項４に記載の方法。
8. 前記所定の基準のうちの１つは、前記平行な辺の各々が同一の方向角を有することを特徴とする請求項７に記載の方法。
9. 前記所定の基準のうちの１つは、前記オブジェクトの各々が重複するか、または前記平行な辺の全長に沿って境を接することを特徴とする請求項８に記載の方法。
10. 前記複合塗りつぶしにおける画素ランの長さを格納する工程を更に備えることを特徴とする請求項１に記載の方法。
11. 前記塗りつぶしは、前記複合塗りつぶしにおいて、前記塗りつぶしを記述する塗りつぶしデータ構造の連係リストとして表現されることを特徴とする請求項１に記載の方法。
12. 前記データ構造における第１の塗りつぶしを指示するポインタを格納する工程を更に備えることを特徴とする請求項１１に記載の方法。
13. 前記塗りつぶしの各々は、フラット塗りつぶしであることを特徴とする請求項１に記載の方法。
14. 前記グラフィカルオブジェクトの各々のオブジェクトアウトラインは、１つ以上の稜線を含むことを特徴とする請求項１に記載の方法。
15. オブジェクトアウトラインはパスであることを特徴とする請求項１に記載の方法。
16. オブジェクトアウトラインは、複数の点により定義される多角形であることを特徴とする請求項１に記載の方法。
17. グラフィカルオブジェクトが、所定のオブジェクトアウトラインと、前記複合塗りつぶしと含み、当該所定のオブジェクトアウトラインは、前記グラフィカルオブジェクトが塗りつぶされるエリアを定義する、当該グラフィカルオブジェクトをレンダリングするための複合塗りつぶし方法であって、
    前記複合塗りつぶしは、レンダリング時に前記グラフィカルオブジェクトが塗りつぶされるべき形式を定義する複数の塗りつぶしを含むデータ構造として構成されることを特徴とする複合塗りつぶし方法。
18. 前記グラフィカルオブジェクトは、複数のグラフィカルオブジェクトから形成されることを特徴とする請求項１７に記載の複合塗りつぶし方法。
19. 前記データ構造は、連係リストであることを特徴とする請求項１７に記載の複合塗りつぶし方法。
20. 前記複合塗りつぶしにおけるトラッキングポイントを格納する工程を更に備えることを特徴とする請求項１記載の方法。
21. 前記トラッキングポイントは、前記グループ化オブジェクトをレンダリングするために、前記複合塗りつぶし中における現在の塗りつぶしを判定するために使用されることを特徴とする請求項２０に記載の方法。
22. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしと含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする装置であって、
    前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしを含み、前記複合塗りつぶしは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成するための組み合わせ手段と、
    前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするレンダリング手段と、
    を備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とする装置。
23. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムであって、当該プログラムが、
    前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしと含み、前記複合塗りつぶしは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するためのコードと、
    前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするためのコードと、
    備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とするコンピュータプログラム。
24. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしを含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムを記録したコンピュータで読み取り可能な記録媒体を含むコンピュータプログラム製品であって、当該プログラムが、
    前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしを含み、前記複合塗りつぶしは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する１つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するためのコードと、
    前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするためのコードと、
    を備え、前記グループ化オブジェクトをレンダリングするために使用される１つ以上の塗りつぶしは、前記複合塗りつぶしに従って判定されることを特徴とするコンピュータプログラム製品。

Images