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

グラフィカルオブジェクトをレンダリングする方法 Download PDF

Info

Publication number
JP4174484B2
JP4174484B2 JP2005075523A JP2005075523A JP4174484B2 JP 4174484 B2 JP4174484 B2 JP 4174484B2 JP 2005075523 A JP2005075523 A JP 2005075523A JP 2005075523 A JP2005075523 A JP 2005075523A JP 4174484 B2 JP4174484 B2 JP 4174484B2
Authority
JP
Japan
Prior art keywords
fill
rendering
objects
data
fill data
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
Application number
JP2005075523A
Other languages
English (en)
Other versions
JP2005267639A (ja
JP2005267639A5 (ja
Inventor
イアン  リチャード  ボーモンド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from AU2004901386A external-priority patent/AU2004901386A0/en
Application filed by Canon Inc filed Critical Canon Inc
Publication of JP2005267639A publication Critical patent/JP2005267639A/ja
Publication of JP2005267639A5 publication Critical patent/JP2005267639A5/ja
Application granted granted Critical
Publication of JP4174484B2 publication Critical patent/JP4174484B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T11/002D [Two Dimensional] image generation
    • G06T11/40Filling a planar surface by adding surface attributes, e.g. colour or texture

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Image Generation (AREA)

Description

本発明は、一般に、画像処理に関し、特に、複数のグラフィカルオブジェクトをレンダリングする方法に関する。また、本発明は、複数のグラフィカルオブジェクトをレンダリングする方法及び装置、並びに複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムが記録されたコンピュータ可読媒体を含むコンピュータプログラム製品に関する。
ワードプロセッサなどの従来のソフトウェアアプリケーションは、ページ単位の文書を作成する。ページ単位の文書においては、各々のページが1つ以上のグラフィカルオブジェクト(すなわち、テキスト、行、塗りつぶし領域(fill reagions)及び/又は画像データ)を含む。そのような文書を表示装置又は印刷装置において表現する場合、ソフトウェアアプリケーションは、通常、表示装置又は印刷装置へ指令を送信する。それらの指令は、通常、グラフィカルインタフェースサービス(graphics interface services )により定義される。グラフィカルインタフェースサービスは、そのソフトウェアアプリケーションを実行しているネイティブオペレーティングシステムと関連する。そのようなオペレーティングシステムの1つがWindows(登録商標)である。Windows(登録商標)オペレーティングシステムのグラフィカルインタフェースサービスは、通常、グラフィックスデバイスインタフェース(GDI:graphics device interface )レイヤと呼ばれる。GDIレイヤは、オペレーティングシステムにより実行されるべきアプリケーションプログラミングインタフェース(API:application programming interface )として実現されてもよい。APIは、オペレーティングシステムにより実行されるべきソフトウェアアプリケーションに、豊富な図形特徴セットを提供する。
通常、グラフィックスレンダリングシステムは、オペレーティングシステムのGDIレイヤから受信されたグラフィカルオブジェクト(図形オブジェクト)をレンダリングし、画素を生成する。レンダリングは、GDIレイヤから受信されたグラフィカルオブジェクトをグラフィックスレンダリングシステムにより画素に変換するプロセスである。グラフィックスレンダリングシステムにより生成された画素は、その後、表示及び/又は印刷のために、出力装置へ送信される。
図1は、従来のソフトウェアアプリケーション110と、グラフィックスデバイスインタフェースレイヤ120と、グラフィックスレンダリングシステム130と、ターゲットデバイス140との関係を示す。アプリケーション110は、1つの文書の各ページを、一連の指令として送信する。レンダリングされるページごとに、一連の指令は、そのページのグラフィカルオブジェクトを記述するグラフィックインタフェースサービスによって定義される。GDIレイヤ120は、アプリケーションプログラム110とターゲットデバイス140との間を仲介する。GDIレイヤ120の存在によって、グラフィックスレンダリングシステム130は、Windows(登録商標)オペレーティングシステムが処理できるより、はるかに小さな機能性のセットを支援することが可能である。また、GDIレイヤ120は、グラフィックスレンダリングシステム130において最も効率がよいとGDIレイヤ120が判定するフォーマット及びターゲットデバイス140の分解能で、グラフィカルオブジェクトをグラフィックスレンダリングシステム130に提供する。そこで、グラフィックスレンダリングシステム130は、GDIレイヤ120から受信されたグラフィカルオブジェクトをレンダリングし、画素を生成する。グラフィックスレンダリングシステム130により生成された画素は、その後、ターゲットデバイス140へ送信される。
グラフィックスソフトウェアアプリケーションには、多様な種類が存在する。それらのグラフィックスソフトウェアアプリケーションの多くは、複雑なグラフィカルオブジェクトの生成が可能である。通常、これらのオブジェクトは、特定のグラフィックスソフトウェアアプリケーションに特有のものである。例えば、Corel Draw(登録商標)と呼ばれる周知のグラフィックスソフトウェアアプリケーションは、「fountain fill(インクだめ塗りつぶし)」として知られる複雑なオブジェクトを作成できる。「fill(塗りつぶし)」は、グラフィカルオブジェクトがペイントされる(すなわち、塗りつぶされる)ときの画素データを記述するために使用される。例えば、赤色の正方形は、赤色フラット着色塗りつぶしを有する。fountain fillは、オブジェクトの2つ以上の色が互いに滑らかに流れ込むようなオブジェクトの塗りつぶしを記述する「勾配塗りつぶし」の1種である。勾配塗りつぶしには、数多くの型(例えば、線形、円錐形、放射及び非線形)がある。放射勾配塗りつぶしによって塗りつぶされたオブジェクト210が、図2Aに示される。通常、勾配塗りつぶしの遷移は、1つの色が別の色に流れ込むことにより構成される。しかし、より複雑な勾配塗りつぶしは、多数の異なる色の間の多数の遷移を有するであろう。図2Bは、多数の遷移を有する勾配塗りつぶしによって塗りつぶされたオブジェクト220の一例を示す。
線形勾配塗りつぶしによってオブジェクトを塗りつぶすために、特定のグラフィックスソフトウェアアプリケーションにより,どの方法が使用されるかは、その特定のグラフィックスソフトウェアアプリケーションによって異なる。しかし、線形勾配塗りつぶしによってオブジェクトを塗りつぶす周知の方法の1つは、塗りつぶされるべきグラフィカルオブジェクトの境界規定ボックスの両端部において、開始色及び終了色を指定し、開始色と終了色の間を補間する工程を含む。
オブジェクト210及び220のような複雑なグラフィカルオブジェクトは、通常、プリンタドライバ又はディスプレイドライバにより直接にレンダリングされることが不可能である。従って、GDIレイヤは、通常、複数の平行四辺形の形態をとる複数のフラット塗りつぶし隣接オブジェクト(flat filled adjacent objects)として、勾配塗りつぶし(gradient fills )をグラフィックスレンダリングシステムへ送信する。それらのフラット塗りつぶし隣接平行四辺形(flat filled adjacent parallelograms )を使用することにより、グラフィックスレンダリングシステムは、アプリケーションに特有のグラフィックス型を支援する必要なく、複雑なグラフィカルオブジェクトをレンダリングすることができる。Painters Algorithmレンダリング方法を使用するレンダラの場合、フラット塗りつぶし平行四辺形は、フレーム記憶装置にレンダリングされてもよい。しかし、通常、GDIレイヤにより、線形勾配塗りつぶしと非線形勾配塗りつぶし(non-linear gradient fills )の双方がフラット塗りつぶし平行四辺形として送信されるため、2つの隣接する平行四辺形の幅は、通常、一貫していない。その結果、それらの平行四辺形の連続するセットの間の色の変化は、必ずしも線形にはならない。
グラフィックスレンダリングシステム(図形レンダリングシステム)によっては、レンダリングプロセスは、2段階プロセスになる場合がある。そのようなレンダリングシステムにおいては、レンダリングされるべきページのグラフィカルオブジェクトは、レンダリングプロセスが始まる前に、まず、中間フォーマットに変換される。この中間フォーマットは、「ディスプレイリスト(display list)」として知られている。そのようなグラフィックスレンダリングシステムの1つにおいては、レンダリングプロセスの第1段階は、関連するオペレーティングシステムから受信されたページの各グラフィカルオブジェクトを、中間稜線ベースオブジェクト(intermediate edge-based object)に変換する。例えば、図3は、受信された各グラフィカルオブジェクトを中間稜線ベースオブジェクトに変換する従来のグラフィックスレンダリングシステム330を示す。図3の例では、グラフィックスアプリケーション310により作成され、且つ、複雑なグラフィカルオブジェクトに対応する線形勾配塗りつぶし(linear gradient fill )370は、多数のフラット着色矩形(flat coloured rectangles )(例えば、フラット着色矩形380)として、グラフィックスデバイスインタフェース320から、グラフィックスレンダリングシステム330へ送信される。グラフィックスレンダリングシステム330のディスプレイリスト作成モジュール340は、各々のフラット着色矩形380を2つの稜線、レベル及び塗りつぶしデータに変換する。それらの稜線、レベル及び塗りつぶしデータは、データベース(例えば、381、382及び383にそれぞれ)格納される。稜線は、各フラット着色矩形380が塗りつぶされるエリアを記述する。塗りつぶしデータは、フラット着色矩形380の稜線の内側における画素の色/不透明度を規定する。塗りつぶしデータは、フラット色、ビットマップ、式、又はフラット着色矩形380の中の特定の位置における画素データを記述するパターンであってもよい。レベルは、フラット着色矩形380のZ-オーダー(Z-order)、塗りつぶしデータに適用されるべきラスタ演算及び関連する稜線がクリッピング稜線であるか、又は塗りつぶし稜線であるかなどの重要なレンダリング情報を含む。
グラフィックスレンダリングシステム330がフラット着色矩形380のうちの1つをレンダリングする前に、特定の矩形の全ての稜線がyの昇順で分類され、続いてxの昇順で分類されるように、各矩形は分類されなければならない。y座標及びz座標は、それぞれ、ラスタ化レンダリングシステム(rasterized rendering system)における走査線と、各走査線上の画素位置に対応する。グラフィックスレンダリングシステムは、稜線及びそれらに関連する塗りつぶし優先順位(Z-order)から成るディスプレイリスト350と共に、稜線がクリッピング稜線(clipping edge )であるか、又は塗りつぶし稜線(filling edge)であるかなどの他の情報を生成する。
ディスプレイリスト350は、ジョブと呼ばれる場合もある。ジョブは、ページをレンダリングするために、グラフィックスレンダリングシステム330のレンダリングモジュール360により必要とされる全ての情報を含む。レンダリングモジュール360によるページのレンダリングは、レンダリングプロセスの第2段階である。
レンダリングモジュール360は、ジョブをパージング(parses)し、ページに沿って走査線ごとに、プリンタなどの下流側デバイスに対して画素を生成する。走査線ごとに、レンダリングモジュール360が着色矩形(例えば、矩形380)の左側稜線に至たる(encounters)と、レンダリングモジュール360は、その矩形と関連するレベルを中間バッファにロードする。矩形と関連するレベルは、この時点で、アクティブ状態になったという。レンダリングモジュール360が矩形の右側稜線に至った(encounters)とき、矩形と関連するレベルは非アクティブ状態(deactivated)になる。
レンダリングモジュール360は、本明細書において後に説明されるように、稜線に関して様々に異なる種類のアクティべーションルール(activation rules )を使用できる。走査線上の各稜線セットの間の画素スパンは、それらのルールに従ってレンダリングされる。レンダリングモジュール360が1つの稜線に至ると、レンダリングモジュール360は、最上位(すなわち、最大Z-オーダー位置(greatest z-order position))の、現在アクティブ状態であるレベルを判定し、最上位の現在アクティブ状態のレベルの塗りつぶしデータに従って、画素をレンダリングする。最上位レベルに対応するオブジェクト(例えば、フラット着色矩形(flat filled rectangle))が透明である場合、下位のz-orderのレベルの合成を使用して、結果として得られる画素データが計算される。レンダリングモジュール360が稜線に至るたびに、全ての稜線は、次の走査線上の新たな位置に更新されなければならない。更に、稜線は互いに交差する場合もあるので、稜線がxの昇順のままであることを保証するために、稜線も分類されなければならない。ページ上の全ての画素がレンダリングされるまで、レンダリングプロセスは走査線ごとに継続される。
先に説明したように、複雑なオブジェクトは、通常、グラフィックスデバイスインタフェース320により、フラット塗りつぶし矩形のような、より単純なオブジェクトに分解される。それらの単純なオブジェクトの各々は、別個に中間形態(intermediate form )に変換されなければならないため、その変換には、相当に長い時間を要する。個別のフラット塗りつぶしオブジェクトをレンダリングするとき、オブジェクトの各々の稜線が分類されなければならず、また、走査線ごとに、各稜線が更新されなければならない。これも、レンダリングモジュール360には、長い時間を要するプロセスである。そのため、数百個もの単純なオブジェクトの分解された複雑なオブジェクトの場合には、各オブジェクトを中間稜線ベースフォーマット(intermediate edge based format )に変換し、稜線ベースレンダリングモジュールを使用して、複雑なオブジェクトをレンダリングするプロセスの効率は、きわめて低い。
一例として、図2Cに示される水平方向線形勾配塗りつぶし(horizontal linear gradient fill )230は、グラフィックスレンダリングシステム330へ送信される前に、グラフィックスデバイスインタフェース320により、256個のフラット塗りつぶし矩形に分解される。勾配塗りつぶし(gradient fill )230が左から右、又は右から左へ進む最悪のケースでは、1本の走査線の上で、256個のフラット塗りつぶし(flat fills)の全てがアクティブ状態になる。これは、走査線ごとに、稜線の数が512あることと同等である。従って、稜線ベースレンダリングシステムの場合、走査線ごとに実行されることが必要な稜線の分類及び追跡の量が多くなるため、このようなレンダリング方法の効率は相当に低くなる。加えて、各々のフラット塗りつぶしが中間オブジェクトグラフィックスフォーマットで格納されなければならず、レンダリングを開始できる前に、各走査線の塗りつぶしパスごとに、塗りつぶしがアクセスされ、その後、全ての稜線が分類されなければならない。
上述のレンダリング方法では、処理されるべきフラット塗りつぶしの数が何千にも達した場合、大量のメモリアクセスが要求され、また、大量の塗りつぶし資源が消費される可能性がある。A3より大判のページを高分解能で印刷するときには、そのように大量なフラット塗りつぶしが頻繁に起こる。
勾配塗りつぶし230をレンダリングするときに、稜線ベースレンダリングモジュール360のレンダリング性能を向上する方法の1つは、稜線更新の回数及び実行される必要がある稜線分類の量を減少することである。稜線更新及び稜線分類を減少する周知の方法の1つは、複数のグラフィカルオブジェクトをより大きな1つのグラフィカルオブジェクトにコンパイルするか、又はレンダリングモジュールが処理可能であるより複雑なオブジェクトにコンパイルすることにより、可能な部分で冗長稜線を除去する。複数のグラフィカルオブジェクトをより大きな1つのグラフィカルオブジェクトとしてコンパイルする多くの方法が、知られている。例えば、別個の2つの隣接するビットマップを互いにつなぎ合わせて、1つの大きなビットマップを形成してもよい。また、同一の色を有する2つの連続するフラット塗りつぶしを組み合わせて、より大きな1つのフラット塗りつぶしを生成してもよいし、線形勾配塗りつぶしを表現する連続するフラット塗りつぶしプリミティブを組み合わせて、グラフィックスレンダリングシステムによりレンダリング可能な型の1つの複雑な線形勾配塗りつぶしを形成してもよい。しかし、これらの周知のレンダリング方法は、全て、欠点や限界を有する。
例えば、連続するオブジェクトを組み合わせることを試みる周知のレンダリング方法は、特定のレンダリングモジュールで利用可能な指定の塗りつぶし型に限定される。従って、組み合わせ可能なオブジェクトは、互いに全く同一の塗りつぶし型を有するオブジェクトのみである。GDI320のようなGDIレイヤは、そのようなオブジェクトを分解する必要が始めからないので、この種のオブジェクトが頻繁に現れることはない。
ビットマップを組み合わせる方法の場合には、2つの異なるビットマップを1つのビットマップとして組み合わせるために、画像塗りつぶしデータ全体がコピーされなければならない。特に、多くのビットマップが多数のメモリ割り当てとして含まれ、大量の画像データコピーを実行する必要がある場合、画像塗りつぶしデータをコピーするプロセスは、容易に進まない可能性がある。
フラット塗りつぶしプリミティブを複雑な等価の塗りつぶしとして組み合わせるレンダリング方法は、特定のレンダリングモジュールにより支援される塗りつぶしを出力することに限定される。特定のレンダリングモジュールにより支援されると考えられる塗りつぶしの1つは、線形勾配塗りつぶしである。これは、通常、2つ又は3つの点により表現され、それらの点における色値に対応している。
先に説明したように、平行四辺形の幅が一貫せず且つ色の変化が一定ではないような、複数のフラット塗りつぶし平行四辺形として、勾配塗りつぶしをGDI320が送信することは珍しくない。線形ではない勾配塗りつぶし(例えば、図5Aに示されるような非線形勾配塗りつぶし510)の場合、周知のレンダリング方法は、個々のフラット塗りつぶし平行四辺形を等価の線形勾配成分として組み合わせようとする。非線形勾配塗りつぶしオブジェクトを線形勾配塗りつぶしにコンパイルする周知のレンダリング方法は、2つの線形勾配塗りつぶしを生成するのが理想的である。図5Bは、図5Aの非線形勾配塗りつぶし510から生成された2つの線形勾配塗りつぶし520及び525を示す。非線形勾配塗りつぶし510を与えられた場合、GDI320により生成される平行四辺形の色の変化は一定ではなく、平行四辺形の幅も一貫していないため、勾配塗りつぶしをコンパイルする周知の方法は、勾配塗りつぶし510中の一貫性の欠如に対応することができず、図5Bのような理想的な結果を生成しない。
従来のレンダリング方法は、多くの場合、図5Cに示されるような多数の線形勾配塗りつぶし(linear gradient fills)530〜537を生成する。そのような多数の線形勾配塗りつぶしを生成するプロセスは、元のフラット塗りつぶし表現と比較して効率が悪く、最終的には、レンダリングモジュールの動作を遅くしてしまう。レンダリングモジュールの動作速度が低下するのは、フラット塗りつぶしの画素データと比較して、線形勾配塗りつぶしの画素データを計算するほうが困難であるためと、通常、除去されるのが最小限の稜線にとどまるためである。その結果、最終的には、レンダリング速度(rendering speed)が実際に低下する。GDI320から受信される勾配塗りつぶしを表現するフラット塗りつぶし(例えば、フラット塗りつぶし矩形380)は、必ずしも一貫しておらず、常に正当な線形色変化限界(linear colour change limits)を有しているとは限らない。従って、従来のレンダリング方法は、フラット塗りつぶしを効率よく処理するという点で、非常に大きな制限を有する。更に、従来のレンダリング方法と関連するレンダリングモジュールは、図形プリミティブを完全に最適化するために利用可能な機能性を備えていないため、従来のレンダリング方法には、そのような最適化能力が欠けている。
線形勾配塗りつぶしをレンダリングすることのもう1つの欠点は、ページ上にカラー画像を生成するために、プリンタがシアン、マゼンタ及び黄色(CMY)の減法混色の3原色と、黒(K)とを使用するために起こる。その結果、RGB色空間で格納された線形勾配塗りつぶしを、CMYK色空間に変換することが必要である。RGB色空間からCMYK色空間への線形勾配塗りつぶしの変換は、ホストコンピュータ内で実行されるか、又はターゲットデバイスで実行されることが可能である。しかし、各々がRGB色空間で対応する色値を有する2つ又は3つの点によって記述される線形勾配塗りつぶしは、単純に各々の点の色を変換するだけでは、色変換不可能である。それは、GDIにより提供される元の色データが、色変換後の色空間に線形マッピングされないからである。すなわち、RGB色空間とCMYK色空間との間に、線形関係は存在しない。線形勾配塗りつぶしを色変換する従来の方法は、塗りつぶし中の画素ごとに、画素データのRGB値を判定する。その後、線形勾配塗りつぶし中の各々の画素は、等価のCMYK色値に変換される。色変換後の線形勾配塗りつぶしは、次に、ビットマップとしてディスプレイリストに追加される。従って、線形勾配塗りつぶしをRGB色空間に格納することは、非常に効率が悪い。
従って、グラフィカルオブジェクトをレンダリングする、更に効率のよい方法が必要であることは明らかである。
本発明の目的は、既存の構成の1つ以上の欠点を実質的に克服すること、又は少なくとも改善することである。
各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする方法は、
グループ化オブジェクトを形成するための組み合わせ手段が、前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、を含み、前記複合塗りつぶしデータが、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成する工程と、
レンダリング手段が、前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングする工程と、
を備え、前記レンダリングする工程では、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリングする工程は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする。
各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする装置は、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、を含み、前記複合塗りつぶしデータは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成するための組み合わせ手段と、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするレンダリング手段と、
を備え、前記レンダリング手段は、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリング手段は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする。
各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムであって、当該コンピュータプログラムが、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、と含み、前記複合塗りつぶしデータと、は、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するための工程と、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするための工程と、をコンピュータに実行させ、
前記レンダリングするための工程では、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリングするための工程は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする。
各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムを記録したコンピュータで読み取り可能な記録媒体であって、当該コンピュータプログラムが、
前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、を含み、前記複合塗りつぶしデータは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するための工程と、
前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするための工程と、をコンピュータに実行させ、
前記レンダリングするための工程では、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリングするための工程は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする。
本発明の他の面も開示される。
添付の図面のうちの1つ以上において、同一の図中符号を有するステップ及び/又は特徴を参照するとき、本明細書の便宜上、それらのステップ及び/又は特徴は、特に指示のない限り、同一の機能又は動作を有するものとする。
「背景技術」の章及び前述の従来技術の構成に関連する部分に含まれる説明は、それぞれ対応する刊行物及び/又は使用を通して公の知識を形成する文書又は装置の説明に関することに注意すべきである。それらは、そのような文書又は装置が何らかの形で当該技術分野における共通の一般知識の一部を形成するという、本発明の発明者又は特許出願人による表明として解釈されるべきではない。
以下、図1から図16を参照して、複数のオブジェクトを組み合わせる方法900(図9を参照)を説明する。方法900は、1組の連続するグラフィカルオブジェクトを効率よく組み合わせて、連続するグラフィカルオブジェクトの組み合わせを表現するハイレベルコンパイルドオブジェクトを生成する。コンパイルドオブジェクトは、「グループ化」オブジェクトと呼ばれてもよい。そのような連続するグラフィカルオブジェクトが異なる塗りつぶし型を有する場合であっても、オブジェクトを組み合わせるために、方法900が使用されてよい。方法900は、コンパイルドオブジェクトをディスプレイリストへ出力する。
コンパイルドオブジェクトは、関連するメタ塗りつぶし(meta-fill )を有する。メタ塗りつぶしは、コンパイルドオブジェクトと関連する塗りつぶしの集合体を記述するために使用される複合塗りつぶし(compound fill)である。以下に詳細に説明されるように、メタ塗りつぶしは、メタ塗りつぶしに関する情報を定義するためのヘッド構造を含む。ヘッド構造の次に、コンパイルドオブジェクトの塗りつぶしを記述する塗りつぶし構造の連係リストが続く。連係リストの大きさを最小限にするために、コンパイルドオブジェクトの複数の塗りつぶしは、1つの単純な複合塗りつぶし又は複雑な塗りつぶしとして組み合わされてもよい。
メタ塗りつぶしは、並列して位置する1組の単純な基本オブジェクト(プリミティブ)を組み合わせて、1つの複雑な基本オブジェクトを形成するために使用されてもよい。従って、この場合、1組のプリミティブを表現するために要求される稜線は、2つだけである。メタ塗りつぶしは、グラフィックスインタフェースが多数のフラット塗りつぶしにより表現していた非線形ブレンド(non-linear blends)のような、複雑な描画オブジェクトを再度合体することにより、レンダリング時間を短縮する。例えば、非線形勾配塗りつぶし510に類似するメタ塗りつぶしは、図5Cの線形勾配塗りつぶし530〜537から形成されてもよい。そのようなメタ塗りつぶしは、図5Cの線形勾配塗りつぶし530〜537と比較して大幅に改善されている。
メタ塗りつぶし(meta-fill)は、例えば、GDI320のようなGDIにより提供される情報を変更しない。しかし、2つのオブジェクトが重複する場合、メタ塗りつぶしは、オブジェクトの閉塞する部分を除去する。塗りつぶしをメタ塗りつぶしに変換する際に、情報は実質的に全く失われない。基本塗りつぶしがメタ塗りつぶしとして組み合わせられるときに、描画出力が一貫したままであり且つ影響を受けないことを保証するために、メタ塗りつぶしを形成するために使用される1つ以上の基本塗りつぶしの全ての情報は保持される。これとは対照的に、従来の方法は、色情報に影響を及ぼすため、出力が入力を反映することが保証されることは全くない。更に、メタ塗りつぶしは、稜線オーバヘッド(edge overhead)を減少する。
PDLを生成するレンダリングシステムの場合、メタ塗りつぶしは、基本オブジェクトを表現するために要求されるPDLの大きさを縮小する。PDLの大きさが縮小されると、PDLの送信が要求される処理は改善される。
メタ塗りつぶしは、フラット塗りつぶし、線形勾配塗りつぶし及びビットマップを使用して形成されてもよい。これに対し、従来のレンダリングシステムは、通常、色混合(color blends)を表現するフラット塗りつぶしを認識するだけである。
コンパイルドオブジェクトは、メタ塗りつぶしをリアルタイムで復号することにより、関連するメタ塗りつぶしを使用して、効率よくレンダリングされる。図1から図16を参照して、コンパイルドオブジェクトをレンダリングする方法1000(図10を参照)も説明される。
ここで説明される方法は、図4に示されるような汎用コンピュータシステム400を使用して実現されてもよい。その場合、図1から図16を参照して説明されるプロセスは、コンピュータシステム400内部で実行されるコードモジュールのようなソフトウェアとして実現されてもよい。特に、説明される方法のステップは、ソフトウェアにおいて、コンピュータにより実行される命令により実行される。それらの命令は、各々が1つ以上の特定のタスクを実行する1つ以上のコードサブモジュールとして形成されてもよい。ソフトウェアは、例えば、以下に説明される記憶装置を含むコンピュータ可読媒体に格納されてもよい。ソフトウェアは、コンピュータ可読媒体からコンピュータにロードされ、その後、コンピュータにより実行される。そのようなソフトウェア又はコンピュータプログラムが記録されたコンピュータ可読媒体は、コンピュータプログラム製品である。コンピュータプログラム製品をコンピュータにおいて使用することにより、説明される方法を実現するための好都合な装置が獲得されるのが好ましい。
コンピュータシステム400は、コンピュータモジュール401、キーボード402及びマウス403などの入力装置、並びにプリンタ415、表示装置414及びスピーカ417などの出力装置により形成される。変復調器(モデム)トランシーバ装置416は、例えば、電話回線421又は他の機能媒体を介して接続可能である通信ネットワーク420と通信するために、コンピュータモジュール401により使用される。モデム416は、インターネット、並びにローカルエリアネットワーク(LAN)又はワイドエリアネットワーク(WAN)などの他のネットワークシステムへのアクセスを獲得するために使用可能である。また、実現形態によっては、モデム416は、コンピュータモジュール401に組み込まれてもよい。
コンピュータモジュール401は、通常、少なくとも1つのプロセッサユニット405と、例えば、半導体ランダムアクセスメモリ(RAM)及び読み取り専用メモリ(ROM)から構成されるメモリユニット406とを含む。コンピュータモジュール401は、ビデオディスプレイ414及びスピーカ417に結合するオーディオビデオインタフェース407と、キーボード402及びマウス403、並びにオプションとして使用されるジョイスティック(図示せず)に対応する入出力(I/O)インタフェース413と、モデム416及びプリンタ415に対応するインタフェース408とを含む複数のI/Oインタフェースを更に含む。実現形態によっては、モデム416は、コンピュータモジュール410の内部、例えば、インタフェース408の中に組み込まれてもよい。記憶装置409が設けられる。通常、記憶装置409は、ハードディスクドライブ410及びフロッピー(登録商標)ディスクドライブ411を含む。磁気テープドライブ(図示せず)が更に使用されてもよい。CD‐ROMドライブ412は、通常、不揮発性データ源として設けられる。コンピュータモジュール401の構成要素405〜413は、通常、相互接続バス404を介して、コンピュータシステム400が当業者に知られている従来の動作モードで動作する結果となるように互いに通信する。説明される構成を実施できるコンピュータの例としては、IBM‐PC及びそのコンパチブル、Sun Sparcstation又はそれらから派生した類似のコンピュータシステムがある。
通常、コードモジュールは、ハードディスクドライブ410に常駐し、プロセッサ405に読み取られ、その実行は、プロセッサ405により制御される。モジュール及びネットワーク420から取り出されるデータの中間格納は、可能であれば、ハードディスクドライブ410と協調して、半導体メモリ406を使用して実現されてもよい。場合によっては、コードモジュールは、CD‐ROM又はフロッピー(登録商標)ディスクに符号化された形でユーザに供給され、対応するドライブ412又は411を介して読み取られてもよい。あるいは、コードモジュールは、ユーザにより、ネットワーク420からモデム装置416を介して読み取られてもよい。更に、ソフトウェアは、他のコンピュータ可読媒体からコンピュータシステム400にロードされることも可能である。ここで使用される用語「コンピュータ可読媒体」は、実行及び/又は処理のために、命令及び/又はデータをコンピュータシステム400に提供することに関与するあらゆる記憶媒体又は送信媒体を表す。記憶媒体の例としては、フロッピー(登録商標)ディスク、磁気テープ、CD‐ROM、ハードディスクドライブ、ROM又は集積回路、光磁気ディスク、あるいはPCMCIAカードなどのコンピュータ可読カードがあり、それらの装置は、コンピュータ401の内部にあってもよいし、外部にあってもよい。送信媒体の例としては、無線送信チャネル又は赤外線送信チャネル、並びに別のコンピュータ又はネットワーク化装置へのネットワーク接続、更には、Eメール送信及びウェブサイトなどに記録された情報を含めたインターネット又はイントラネットがある。
あるいは、説明される方法は、説明される方法の機能又は部分機能を実行する1つ以上の集積回路などの専用ハードウェアで実現されてもよい。そのような専用ハードウェアには、グラフィックプロセッサ、デジタルシグナルプロセッサ、又は1つ以上のマイクロプロセッサ及び関連メモリが含まれる。
方法900は、連続するグラフィカルオブジェクトを組み合わせるために使用されてもよい。それらのグラフィカルオブジェクトは、元来、1つの複雑なオブジェクトに由来するか、並列して位置する2つのオブジェクトであるか、又は重複する2つのオブジェクトである。図6は、2段階稜線ベースグラフィックスレンダリングシステム630の一例を示す。このレンダリングシステム630は、方法900及び方法1000を実現するために使用されてもよい。グラフィックスレンダリングシステム630は、図6に示される線形勾配塗りつぶし690のような線形勾配塗りつぶしをレンダリングするために使用されてもよい。グラフィックスレンダリングシステム630は、オブジェクトコンパイラ670と、メタ塗りつぶしディスパッチャ680とを具備する。グラフィックスレンダリングシステム630は、ディスプレイリスト作成モジュール640と、ディスプレイリスト650と、レンダリングモジュール660とを更に具備する。図6に示されるように、グラフィックスデバイスインタフェース620は、グラフィックスアプリケーション610から線形勾配塗りつぶし690を受信し、線形勾配塗りつぶし690を、複数の隣接するフラット塗りつぶしオブジェクト(例えば、平行四辺形621)として、グラフィックスレンダリングシステム630へ送信する。
オブジェクトコンパイラ670は、隣接するオブジェクト、重複するオブジェクト又は連続するオブジェクトを組み合わせ、関連するメタ塗りつぶしと共にコンパイルドオブジェクトを適宜形成し、それにより、そのようなオブジェクトの間にある稜線を除去するために使用されてもよい。現在のコンパイルドオブジェクトとして組み合わせできるオブジェクトがそれ以上存在しないとオブジェクトコンパイラ670が判定したならば、コンパイラ670は、コンパイルドオブジェクトを稜線、レベル及び関連するメタ塗りつぶしに変換してもよい。その後、コンパイルドオブジェクトは、現在のディスプレイリスト650に挿入されてもよい。
レンダリングモジュール660は、ディスパッチャ680を具備する。レンダリングモジュール660は、メタ塗りつぶしデータを復号し、塗りつぶし情報を生成する。その塗りつぶし情報は、コンパイルドオブジェクト641中の1つ以上の画素スパンをレンダリングするために使用されてもよい。
次に、図9を参照して、複数のオブジェクトを組み合わせる方法900を説明する。方法は、ハードディスクドライブ410に常駐し、プロセッサ405により実行が制御されるソフトウェアとして実現されてもよい。方法900は、コンパイラ670の1つ以上のソフトウェアモジュールとして実現されてもよい。オブジェクトは、グラフィックスデバイスインタフェース620のようなグラフィックスインタフェースから、z-orderの昇順で、コンパイラ670により受信されてもよい。
方法900は、ステップ910で始まる。ステップ910では、オブジェクトコンパイラ670を実行するプロセッサ405は、グラフィックスデバイスインタフェース620から受信された現在のオブジェクトを検出する。次のステップ920で、プロセッサ405は、現在のオブジェクトが単純なマージルール(merging rules)に従うか否かを判定する。それらのルールは、
(1)オブジェクトが2つの平行で、一致しない直線の辺を有すること、
(2)オブジェクトが、(1)で識別された2つの平行な辺の不特定の拡張(indefinite extension )エリアの外に出ないことである。
現在のオブジェクトがそれらのルールに適合する場合、現在のオブジェクトはマージされてもよい。現在のオブジェクトがマージされてもよいならば、方法900は、ステップ930へ進む。そうでない場合には、方法は、ステップ940へ進む。
ステップ930においては、プロセッサ405は、現在のオブジェクトをメモリ406に格納する。現在のオブジェクトは、この時点では、中間フォーマットに変換されない。次に、方法900は、ステップ950へ進み、ステップ910で受信されたオブジェクトは、「以前に格納された」オブジェクトになる。
ステップ940では、プロセッサ405は、現在のオブジェクトを稜線ベースフォーマットに変換し、方法900は、ステップ950に続く。次のステップ950で、プロセッサ405は、グラフィックスデバイスインタフェースから次のオブジェクトを受信する。ステップ950で受信されたオブジェクトが「現在」のオブジェクトになる。この時点で、それまでにフローチャートのどの経路をたどったかに応じて、「以前に格納された」オブジェクトは存在する場合もあるが、存在しない場合もある。
方法は、次のステップ960に続く。ステップ960では、以前に格納されたオブジェクトが存在するとプロセッサ405が判定した場合、方法900は、ステップ970へ進む。そうでない場合には、方法900は、ステップ980へ進む。
ステップ970で、プロセッサ405は、まず、現在のオブジェクトが先にステップ920に関連して挙げた単純なマージルールに従うか否かを判定することにより、現在のオブジェクトを先に格納されたオブジェクトと組み合わせてよいか否かを判定する。組み合わせてよいならば、プロセッサ405は、現在のオブジェクト及び以前に格納されたオブジェクトが所定の基準を満たすか否かを判定する。ステップ970の所定の基準は、次の通りである。
(1)現在のオブジェクトと以前に格納されたオブジェクトの双方の平行な辺が同一の角度であること、及び
(2)現在のオブジェクトと以前に格納されたオブジェクトが、それらのオブジェクトの平行な辺の全長にわたって重複するか、それらの平行な辺で互いに境を接していること。
図15Aから図15Eは、上記の所定の基準を満たし、従って、組み合わせ可能なオブジェクトのいくつかの例(例えば、1511)を示す。図15Aは、上記の基準を満たすオブジェクト1511及び1510を示す。オブジェクト1511及び1510は、組み合わせの結果として得られるアウトライン1512を記述するために、パス(path)を形成することを要求しない。アウトライン1512は、4つの点により表現されてもよい。同様に、図15Bは、上記の基準を満たすオブジェクト1520及び1522を示す。それらのオブジェクトは、組み合わせの結果として得られるアウトライン1521を記述するために、パスを要求しない。この場合も、アウトライン1521は、4つの点により表現されてもよい。
図15Cは、上記の所定の基準を満たし、従って、組み合わせ可能なオブジェクト1530及び1532を示す。オブジェクト1530及び1532は、組み合わせの結果として得られるコンパイルドオブジェクト(compiled object )1531を記述するために、パスを形成することを要求する。同様に、図15Dは、上記の所定の基準を満たし、組み合わせ可能なオブジェクト1540及び1542を示す。オブジェクト1540及び1542は、組み合わせの結果として得られるコンパイルドオブジェクト1541を記述するために、パスを形成することを要求する。同様に、図15Eは、上記の所定の基準を満たし、組み合わせ可能な2つのオブジェクト1550及び1552を示す。オブジェクト1550及び1552は、組み合わせの結果として得られるコンパイルドオブジェクト1551を記述するために、パスを形成することを要求する。
これに対し、図15F及び図15Gは、上記の所定の基準を満たさず、組み合わせ不可能なオブジェクトのいくつかの例(例えば、1571)を示す。図15Fは、上記の基準を満たさないために、組み合わせ不可能なオブジェクト1560及び1561の例を示す。特に、オブジェクト1560及び1561は、オブジェクトの平行な(水平方向の)辺により境界を規定されるエリアの外側に出ていることにより、単純なマージルールのうちの第2のルールに反する。同様に、図15Gは、上記の基準を満たさないために、組み合わせ不可能なオブジェクト1570及び1571の例を示す。特に、オブジェクト1570及び1571は、平行である2つの一致しない辺を有していないことにより、単純なマージルールのうちの第1のルールに反する。
現在のオブジェクトと以前に格納されたオブジェクトがステップ970の所定の基準を満たすならば、方法900は、ステップ971へ進む。ステップ971では、現在のオブジェクトは、以前に格納されたオブジェクトと共に、メモリ406に格納される。現在のオブジェクトと、以前に格納されたオブジェクトの塗りつぶしが同一で、フラット色から構成されている場合に、現在のオブジェクトは、以前に格納されたオブジェクトとマージされるのが好ましい。ステップ970で、現在のオブジェクトと、以前に格納されたオブジェクトを組み合わせ不可能な場合には、方法900は、ステップ990へ進む。
ステップ990では、現在のオブジェクトを以前に格納されたオブジェクトと組み合わせ不可能であるため、以前に格納された全てのオブジェクトが組み合わされて、1つのコンパイルドオブジェクトが形成される。コンパイルドオブジェクトは、中間稜線ベースグラフックスフォーマットに変換され、その後、方法900は、ステップ980へ進む。ステップ990で、オブジェクトを中間フォーマットに変換するとき、方法900は、メモリ406内部に構成されたメタ塗りつぶし構造の中に塗りつぶし長さを格納する。塗りつぶし長さは、以前に格納されたオブジェクトの個々の塗りつぶしの水平方向ラン長さに対応する。以前に格納されたオブジェクトが2つ以上存在する場合、コンパイラ670は、ステップ990において、メタ塗りつぶし中の塗りつぶしを記述する基本塗りつぶしデータ構造(primitive fill data structures )の連係リスト(linked list )を作成することにより、メタ塗りつぶしを生成するのが好ましい。
図11は、メタ塗りつぶし1110を詳細に示す。メタ塗りつぶし1110は、コンパイルドオブジェクトの中の任意の点における特定の塗りつぶしエントリ(particular fill entry )を呼び出すために必要なデータの全てを含む。メタ塗りつぶし1110は、ヘッダ1120を含む。ヘッダ1120は、トラッキングポイント(tracking point )1121及びトラッキングポイントDX1122を含む。トラッキングポイント1121は、指定された走査線に関して、メタ塗りつぶし1110の中の第1の塗りつぶし1123の開始場所を指示するために使用されてもよい。指定された走査線に関して、メタ塗りつぶし1110の中の第1の塗りつぶしの開始場所を指示することにより、以下に更に詳細に説明されるように、メタ塗りつぶし1110と関連するコンパイルドオブジェクトをレンダリングすることができる。トラッキングポイント1121は、現在の走査線に対して、トラッキングポイントDX1122に従って更新される。トラッキングポイントDX1122は、メタ塗りつぶし1110により表現されるコンパイルドオブジェクトを形成するために、当初、グループ化されたオブジェクトの平行な辺の傾きを表す。トラッキングポイントは、オブジェクトの最も左側の平行な辺と、オブジェクトが存在している最上位置の走査線との交点として設定される。トラッキングポイントDX1122は、メタ塗りつぶし1110の中の第1の塗りつぶしの場所を追跡するために、ディスパッチャ680により使用されてもよい。メタ塗りつぶしの中の第1の塗りつぶしの位置がわかれば、コンパイルドオブジェクトの他の全ての塗りつぶしを判定できる。ヘッダ1120は、次の塗りつぶし1123を指示するポインタ1133を更に含む。
個別の基本塗りつぶし(primitive fills )1123は、連係リストとして、ヘッダ1120に付加される。個別の塗りつぶしの各々は、互いに連係され、各基本塗りつぶしは、ヘッダ(例えば、ヘッダ1129)を含む。ヘッダ1129は、メタ塗りつぶし1110の中の特定の塗りつぶしの画素ランの長さを表す少なくとも1つのサイズ変数1131を含む。サイズ変数1131は、メタ塗りつぶし1110を画素にレンダリングするときに、ディスパッチャ680により使用される。以下に更に詳細に説明されるように、サイズ変数1131は、メタ塗りつぶし1110の中の塗りつぶしごとに、正しい大きさの画素ランが出力されることを保証する。コンパイラ670は、メタ塗りつぶし1110に追加される各オブジェクトの平行な辺の間の水平方向距離を単純に判定することにより、メタ塗りつぶし1110の中の個別の塗りつぶしの画素長さを判定する。ヘッダ1129は、塗りつぶし型1135及び関連パラメータと、次の塗りつぶし1125を指示するポインタ1137とを更に含む。メタ塗りつぶし1110が生成されたならば、メタ塗りつぶし1110は、コンパイルドオブジェクトの稜線及びレベルデータと共に、ディスプレイリストに追加される。
他の実施形態においては、メタ塗りつぶしに、テーブル又はアレイなどの他のデータ構造が使用されることも可能であろう。
尚、ステップ990で作成されるコンパイルドオブジェクトのレベルは、最も早い時点(最低レベル)で先に格納されたオブジェクトのレベルと等しい。
方法900は、次のステップ980に続く。ステップ980では、プロセッサ405は、ステップ920のときと同様に、現在のオブジェクトが単純なマージルールに従うか否かを判定する。現在のオブジェクトがステップ970で以前に評価されており、現在のオブジェクトを別のオブジェクトとマージしてもよいと判定されていた場合、プロセッサ405は、その解析結果を使用して、現在のオブジェクトをマージできるか否かを判定してもよい。ステップ980で、現在のオブジェクトを別のオブジェクトとマージしてもよいとプロセッサ405が判定した場合、方法900は、ステップ981へ進む。そうでない場合には、方法900は、ステップ985へ進む。ステップ985では、現在のオブジェクトは、中間フォーマットに変換される。その後、実行は、ステップ982へ進む。
ステップ981では、現在のオブジェクトは、メモリ406に格納される。次のステップ982において、グラフィックスレンダリングシステム630が処理すべきオブジェクトが他に存在しない場合、方法900は、ステップ983へ進む。処理すべきオブジェクトが存在する場合には、方法900は、ステップ950に戻る。ステップ983では、ステップ990のときと同様に、以前に格納された全てのオブジェクトが組み合わされて、コンパイルドオブジェクトが形成される。コンパイルドオブジェクトは、関連するメタ塗りつぶしと共に、中間稜線ベースフォーマットに変換される。
ステップ990及び/又は983において、コンパイルドオブジェクトの稜線及びレベルデータは、個別のオブジェクト(すなわち、以前に格納されたオブジェクト)の特性からではなく、コンパイルドオブジェクトのアウトラインから判定される。コンパイルドオブジェクトの中の塗りつぶしデータを記述するために、標準基本塗りつぶしではなく、メタ塗りつぶしが使用される。図12は、コンパイルドオブジェクト1210の一例及び関連するメタ塗りつぶし1215を示す。
図7Aは、当初の稜線ベースオブジェクト710を示す。図7Bは、従来の方式により、塗りつぶし720、稜線722及びレベル724として格納されたオブジェクト710を示す。これとは対照的に、図7Cに示されるように、オブジェクト710は、塗りつぶし730、稜線732及びレベル734により表現されるコンパイルドオブジェクトとして格納されてもよい。元のオブジェクト710を表現する図7Cの稜線732及びレベル734は、図7Bの稜線722及びレベル724ほどメモリを必要としない。
レンダリングモジュール660のディスパッチャ680は、特定の画素及び特定の走査線位置に対して、どの塗りつぶしをレンダリングすべきかを判定する。レンダリングされるべき最上位のアクティブレベルが、そのレベルと関連するメタ塗りつぶしを有する場合、ディスパッチャ680は、メタ塗りつぶしを復号するために使用されてもよい。
先に説明したように、メタ塗りつぶしは、ディスパッチャ680により追跡されるトラッキングポイント1121を含む。トラッキングポイント1121は、当初組み合わされたオブジェクトの平行な辺と平行に移動する。トラッキングポイント1121を使用して、ディスパッチャ680は、レンダリングされるべきコンパイルドオブジェクトの中の任意の位置に対して、メタ塗りつぶし1110の中でどの塗りつぶしを使用すべきかを判定してもよい。
コンパイルドオブジェクトの全体又は一部がレンダリングされるべき場合、コンパイルドオブジェクトを表現するレンダリング情報は、ディスパッチャ680へ送信される。ディスパッチャ80は、レンダリングモジュール660の現在のx位置、コンパイルドオブジェクトのトラッキングポイント1121及びメタ塗りつぶし1110の中の個別の塗りつぶし(例えば、1123)の画素幅を使用して、現在の塗りつぶしと、現在の塗りつぶしからレンダリングされるべき画素の数とを判定する。メタ塗りつぶし1110の中のx位置は、走査線上で、トラッキングポイント1121と同一の点に対応するとは限らない。それは、メタ塗りつぶし1110を閉塞する他のオブジェクトが存在するか、又はメタ塗りつぶし1110がクリップオブジェクトを含む可能性があるためである。例えば、図12は、クリッピング領域1220を伴うコンパイルドオブジェクト1210を示す。
図10は、コンパイルドオブジェクトをレンダリングする方法1000を示す流れ図である。方法1000は、ハードディスクドライブ410に常駐し、プロセッサ405により実行を制御されるソフトウェアとして実現されてもよい。方法1000は、ディスパッチャ680の1つ以上のソフトウェアモジュールとして実現されてもよい。方法1000は、第1のステップ1010で始まる。ステップ1010で、ディスパッチャ680は、メタ塗りつぶしを受信する。メタ塗りつぶしは、レンダリングモジュール660から受信されてもよい。レンダリングモジュール660は、レンダリングされるべき画素の数、出力フォーマット及びレンダリングモジュールの現在の走査線位置を指定してもよい。また、レンダリングモジュール660は、レンダリングされた画素データを挿入するための、メモリ406内部の出力バッファを構成してもよい。
次に、方法1000は、ステップ1015へ進む。ステップ1015では、レンダリングされるべき現在の走査線に従って、メタ塗りつぶしのトラッキングポイント(例えば、1121)が更新される。ディスパッチャ680は、メタ塗りつぶしのトラッキングポイントの現在のy位置と、現在の走査線のy位置との距離を判定することにより、メタ塗りつぶしのトラッキングポイントを更新する。次に、ディスパッチャ680は、判定された距離(0になる場合もある)をトラッキングポイントDX(例えば、1122)と乗算する。次に、新たなトラッキングポイントx位置を判定するために、その乗算の結果は、現在のトラッキングポイントx位置に加算される。メタ塗りつぶしのトラッキングポイントの新たなy位置は、現在の走査線の現在のy位置と一致するように更新される。次のステップ1020で、レンダリングモジュール660の現在のレンダリング位置がメタ塗りつぶしのトラッキングポイントから離間している距離の画素数を判定するために、現在のレンダリング位置がトラッキングポイントと比較される。ステップ1020における判定は、更新後のトラッキングポイントx位置を現在のレンダリングx位置から減算することにより実行されてもよい。
方法1000は、次のステップ1030に続く。ステップ1030で、プロセッサ405は、メタ塗りつぶしの塗りつぶしからアクティブ塗りつぶしを判定する。アクティブ塗りつぶしは、レンダリングされるべき現在の画素データに対応する、メタ塗りつぶしの塗りつぶしである。次のステップ1040では、アクティブ塗りつぶしを使用してレンダリングすべき画素の数が判定される。アクティブ塗りつぶしを使用してレンダリングすべき画素の数は、レンダリングモジュール660がレンダリングすることを要求する画素の数と、アクティブ塗りつぶしにおいて残留している画素の数のうちで小さいほうの数として判定される。アクティブ塗りつぶしにおいて残留している画素の数は、アクティブ塗りつぶしの最大x位置から現在のレンダラx位置を減算した値に基づいて判定される。
レンダリングされるべき画素の数が判定されたならば、方法1000は、ステップ1050へ進む。ステップ1050では、要求された画素ランがレンダリングされる。画素データを生成するために、ディスパッチャ680は、アクティブ塗りつぶしの塗りつぶし型に従って、アクティブ塗りつぶしをネイティブレンダリング機能へ送信する。また、ステップ1050では、現在のレンダリングx位置及びレンダリングされるべき画素の数が更新される。方法1000は、次のステップ1060に続く。ステップ1060において、レンダリングされるべき画素が他にまだ存在している場合、方法1000は、ステップ1070へ進む。そうでない場合には、方法1000は終了する。ステップ1070で、プロセッサ405は、メタ塗りつぶしにおける次の塗りつぶしを検索する。ステップ1070で検索された塗りつぶしは、アクティブ塗りつぶしになる。ステップ1070に続いて、方法1000は、ステップ1040へ進む。
一例として、図8Aは、1つの平行四辺形の形態をとるコンパイルドオブジェクト820を含むページ830を示す。コンパイルドオブジェクト820は、コンパイルドオブジェクト820の一部を閉塞する円オブジェクト810を有する。円オブジェクト810は、白色フラット塗りつぶしを含む。コンパイルドオブジェクト820は、4つの塗りつぶし807、809、811及び813を有する。これらの塗りつぶしは、図8Bに示されるように、1つのメタ塗りつぶし835の中に含まれていてもよい。
メタ塗りつぶし835は、指定された走査線(すなわち、300)に関して、メタ塗りつぶし835の中の第1の塗りつぶし807の開始場所(すなわち、画素100)を指示するトラッキングポイント変数844を含むヘッダ837を含む。ヘッダ837は、トラッキングポイントDX865を含む。ヘッダ837は、次の塗りつぶし809を記述する塗りつぶし構造838を指示するポインタを更に含む。
塗りつぶし構造838は、ヘッダ839を含む。ヘッダ839は、塗りつぶし型変数846を使用して、塗りつぶし型を説明する。塗りつぶし型変数846は、塗りつぶし807がパターン塗りつぶしであることを示す。ヘッダ839は、塗りつぶし807の画素ランの長さを表すサイズ変数847を更に含む。塗りつぶし807は、20画素にわたる。塗りつぶし構造838は、ストライプパターン塗りつぶしデータ861を更に含む。最後に、ヘッダ839は、次の塗りつぶし809を説明する次の塗りつぶし構造841を指示するポインタ848を含む。
塗りつぶし構造841は、ヘッダ843を含む。ヘッダ843は、塗りつぶし型変数849を使用して、塗りつぶし型を説明する。塗りつぶし型変数849は、塗りつぶし809がパターン塗りつぶしであることを示す。ヘッダ841は、塗りつぶし809の画素ランの長さが100画素であることを示すサイズ変数850を更に含む。塗りつぶし構造841は、クロスハッチパターン塗りつぶしデータ862を更に含む。最後に、ヘッダ843は、次の塗りつぶし811を説明する次の塗りつぶし構造845を指示するポインタ851を含む。
塗りつぶし構造845は、ヘッダ852を含む。ヘッダ852は、塗りつぶし型変数853を使用して、塗りつぶし型を説明する。塗りつぶし型変数853は、塗りつぶし811がパターン塗りつぶしであることを示す。ヘッダ852は、塗りつぶし811の画素ランの長さを表すサイズ変数854を更に含む。サイズ変数854により示されるように、塗りつぶし811は、150画素に及ぶ。塗りつぶし構造845は、ドットパターン塗りつぶしデータ863を更に含む。最後に、ヘッダ852は、次の塗りつぶし813を説明する次の塗りつぶし構造856を指示するポインタ855を含む。
塗りつぶし構造856は、ヘッダ857を含む。ヘッダ857は、塗りつぶし型変数858を使用して、塗りつぶし型を説明する。塗りつぶし型変数858は、塗りつぶし813がフラット塗りつぶしであることを示す。ヘッダ857は、塗りつぶし813の画素ランの長さを表すサイズ変数859を更に含む。サイズ変数859により示されるように、塗りつぶし813は、40画素にわたる。塗りつぶし構造856は、フラット塗りつぶしデータ864を更に含む。最後に、ヘッダ857は、次の塗りつぶし構造を指示するポインタ860を含む。しかし、図8A及び図8Bの例においては、他に塗りつぶしは存在しないため、ポインタ860の値はヌルである。
円オブジェクト810は、メタ塗りつぶし835より高いZ-オーダー(Z-order)を有し、従って、コンパイルドオブジェクト820の一部を閉塞している。レンダリングモジュール660の現在のレンダリング位置が円オブジェクト810上の点805と交差するのに応答して、点806に続く第1の画素と関連する塗りつぶしが判定されなければならない。点805において、y位置は300であり(すなわち、現在の走査線が300である)、x位置は265である。コンパイラ670は、コンパイルドオブジェクト820の塗りつぶしがメタ塗りつぶし835であると判定し、方法1000のステップ1010の通りに、デコンパイリングのために、塗りつぶしをディスパッチャ680へ送信する。ディスパッチャ680は、方法1000のステップ1015の通りに、メタ塗りつぶし835のトラッキングポイントを、現在の走査線(すなわち、走査線300)におけるコンパイルドオブジェクト820のトラッキングポイント815と一致するように更新する。
ディスパッチャ680は、メタ塗りつぶし835のトラッキングポイント変数844の現在のy位置と、レンダリングされるべき現在の走査線(すなわち、走査線300)のy位置との距離を判定することにより、現在の走査線のトラッキングポイント変数844を更新する。次に、ディスパッチャ680は、判定された距離(0になる場合も有る)をトラッキングポイントDX865と乗算し、メタ塗りつぶし835のトラッキングポイント変数844の新たなx位置を判定する。メタ塗りつぶし835のトラッキングポイント変数844の新たなy位置は、現在の走査線の現在のy位置と一致するように更新される。図8A及び図8Bの例では、先に説明したように、現在の走査線のトラッキングポイント815のトラッキングポイント変数844は、(100,300)である。
ディスパッチャ680は、方法1000のステップ1030の通りに、現在「アクティブ」である塗りつぶしを判定するために、トラッキングポイント815を示す判定されたトラッキングポイント変数844を使用してもよい。現在アクティブである塗りつぶしは、点805に続く第1の画素についてレンダリングされるべき塗りつぶしである。ディスパッチャ680は、点805におけるx位置と、トラッキングポイント815のx位置との距離を判定する。図8Aの例では、点805において、x位置は、トラッキングポイント815から165画素(すなわち、265−100)の距離にある。次に、ディスパッチャ680は、トラッキングポイント815から165番目の画素と関連する塗りつぶしを判定するために、メタ塗りつぶし835と関連する連係塗りつぶし構造838、841、845及び856のリストを検討する。ディスパッチャ680は、現在の塗りつぶしが165番目の画素に及ぶまで、連係塗りつぶしの個別の画素ランの長さを累積することにより、165番目の画素と関連する塗りつぶしを判定する。コンパイルドオブジェクト820の場合、先に説明したように、第1の塗りつぶし807は、20画素にわたり、第2の塗りつぶし809は、100画素にわたり、第3の塗りつぶし811は、150画素にわたり、最後の塗りつぶし813は、40画素にわたる。図8A及び図8Bの例においては、第3の塗りつぶし811がトラッキングポイント815から165番目の画素を含む。従って、第3の塗りつぶし811が、現在アクティブである塗りつぶしと呼ばれることになる。図8Aからわかるように、第3の塗りつぶし811は、トラッキングポイント815から120番目の画素で始まる。図8AにおいてAxとマークされた線は、120画素分の長さを有する。ページの境界830を参照すると、120番目の画素は、現在の走査線(すなわち、走査線300)上の画素番号220に相当する。レンダリングモジュール660の現在のレンダリング位置は、画素番号265であるので、図8AにおいてLxにより示されるように、ディスパッチャ680は、第3の塗りつぶし811のうちの45画素(すなわち、265−220)が経過したと判定してもよい。図8Aからわかるように、Fxは、現在アクティブである塗りつぶし811に関して、レンダリングされるべき画素の数を表す。ディスパッチャ680は、方法1000のステップ1040の通りに、現在アクティブである塗りつぶし811に関して、レンダリングされるべき画素の数は105画素(すなわち、150−45)であると判定する。
次に、ディスパッチャ680は、方法1000のステップ1050の通りに、ネイティブレンダリング機能を使用して、Fxにより表される第3の塗りつぶし811のうちの105画素をレンダリングすることを、レンダリングモジュール660に要求する。レンダリングモジュール660が、現在アクティブである塗りつぶし811に従って、105画素のレンダリングを終了すると、レンダリングされるべき現在の走査線の画素ランが他に存在するとディスパッチャ680が判定した場合、ディスパッチャ680は、方法1000のステップ1070の通りに、次のアクティブ塗りつぶしを判定する。
先に説明したように、コンパイルドオブジェクトを形成するために、複数のグラフィカルオブジェクトを組み合わせ、それにより、冗長稜線を除去してもよい。走査線ごとに分類、追跡される必要がある稜線とは異なり、メタ塗りつぶしの属性は、高レベルで、一度判定されるだけでよいので、多数の稜線を分類、追跡しなければならない従来のレンダリング方法と比べて、コンパイルドオブジェクトのレンダリングは、はるかに効率がよい。
ステップ983及び/又は990で、コンパイラ670は、塗りつぶし型の異なるグラフィカルオブジェクトを組み合わせてもよい。コンパイラ670は、そのようなオブジェクトの稜線を組み合わせ、オブジェクトと関連する塗りつぶしを、同一のオブジェクトに属する別個のエンティティとして扱う。従って、ビットマップを組み合わせる場合、その他に画像操作又はコピーを実行する必要はない。オブジェクトと関連する塗りつぶしは、別個に処理され、格納されてもよいが、コンパイラ670により、一体に連係される。例えば、図16は、図6のグラフィックスデバイスインタフェース620により生成された2つのビットマップ1630及び1640を連係するメタ塗りつぶし1660を示す。図16の例では、グラフィックスアプリケーション610のようなグラフィックスアプリケーションにより作成された元のビットマップ1620が、グラフィックスデバイスインタフェース620により、2つの別個のビットマップ1630及び1640として送信される。コンパイラ670は、ビットマップ1630及び1640は互いに並列して位置することを認識し、そこで、2つのビットマップ1630及び1640からメタ塗りつぶし1660を生成する。これとは対照的に、従来のレンダリング方法は、一方のビットマップ(例えば、ビットマップ1630)のデータを他方のビットマップ1640にコピーすることにより、ビットマップ1630及び1640を組み合わせるため、効率が悪い。
また、先に説明したように、従来のレンダリング方法は、非線形勾配塗りつぶし510のような非線形勾配塗りつぶしから、多数の勾配塗りつぶしを生成する。しかし、先に説明したように、勾配塗りつぶし510は、多数の塗りつぶし要素を伴って、単一のコンパイルドオブジェクトとして処理されてもよい。そのようにすることにより、メタ塗りつぶしにおいて関連する線形勾配を保持しつつ、冗長稜線を除去できる。単純なフラット塗りつぶしを組み合わせる場合、コンパイラ670が同一の色のオブジェクトの組み合わせのみに限定されることはない。コンパイラ670は、色の異なるオブジェクトであっても、更には、塗りつぶし型の異なるオブジェクトであっても、組み合わせることができる。それは、塗りつぶしが再び連係されるからである。従って、オブジェクトの稜線が1つに組み合わせられる一方で、必要な全ての塗りつぶし情報は依然としてレンダリングモジュール660に提示される。
図13は、6つの基本オブジェクト1310、1320、1330、1340、1350及び1360を示す。従来のレンダリングシステム330は、オブジェクト1310〜1360の各々を2つの稜線(例えば、オブジェクト1310の場合、稜線1311及び1312)として処理する。各稜線1311は、関連するレベルデータ1313及び塗りつぶしデータ1314を有する。これに対し、図14は、オブジェクト1310〜1360から形成されたコンパイルドオブジェクト1410を示す。図14からわかるように、コンパイルドオブジェクトは、関連するメタ塗りつぶし1415を有する。レンダリングモジュール660は、コンパイルドオブジェクト1410を単一のオブジェクトとして処理し、従って、コンパイルドオブジェクト1410のアウトライン1413を記述する稜線1411及び1412の知識を有するのみである。
基本オブジェクト1310〜1360をレンダリングする時に、モジュール360のような従来の稜線ベースレンダリングモジュールは、走査線ごとに、各オブジェクトの各々の稜線(例えば、稜線1311)を更新する。個々の走査線ごとに、レンダリングモジュール360が稜線1311のような左側の稜線に遭遇すると、レベルデータ1303がロードされなければならず、また、塗りつぶしデータ1314から、画素ランが計算されなければならない。これとは対照的に、メタ塗りつぶし1415のようなメタ塗りつぶしを符号化し、復号することにより、レンダリングモジュール660は、2つの稜線を処理するだけでよく、単一のレベルをロードするだけでよい。例えば、レンダリングモジュール660は、オブジェクト1310〜1360の各々の稜線を個別に追跡する必要がない。それは、全ての稜線(例えば、稜線1311及び1312)が平行であるからである。そのため、塗りつぶしデータは、常に、メタ塗りつぶし1415の中の第1の塗りつぶし1417に関連して判定され、その結果、レンダリングモジュールにより要求される労力の量は大幅に減少する。ディスパッチャ680は、画素データを効率よく生成できるであろう。メタ塗りつぶし1415のようなメタ塗りつぶしを使用するとき、走査線ごとに要求される唯一の更新は、トラッキングポイント(例えば、1121)の更新である。
グラフィックスレンダリングシステム330のような従来のグラフィックスレンダリングシステムの場合、RGBからCMYKへの色変換を実行する。そこで、CMYK色変換線形勾配塗りつぶしを表現するための多くの方法が知られている。1つの方法は、RGB勾配塗りつぶしをRGB空間におけるビットマップに変換し、次に、各画素色をCMYKに変換して、色修正ビットマップを生成する。別の方法は、勾配塗りつぶしに沿ってRGB色空間における多数の点をサンプリングし、それらの点を色変換して、色変換勾配塗りつぶしに近似する多数の小さな線形CMYK勾配塗りつぶしを生成する。更に別の方法は、RGB勾配塗りつぶしをサンプリングし、元の勾配塗りつぶしを表現する複数のCMYKフラット塗りつぶしを生成する。
線形勾配塗りつぶしをCMYKビットマップとして表現することは、元のRGB勾配塗りつぶし記述と比較して、非常に不効率である。更に、RGB勾配塗りつぶし(RGB gradient fill )を、多数の小さなCMYK勾配塗りつぶし(CMYK gradient fills )又はCMYKフラット塗りつぶし(CMYK flat fills )に分解することは、隣接する勾配塗りつぶしの間に数多くの稜線が生成され、従って、レンダリングモジュール360のような従来のレンダリングモジュールの動作速度が劇的に遅くなるという欠点を有する。しかし、多数のCMYK勾配塗りつぶし又はフラット塗りつぶしは、先に説明したメタ塗りつぶし1415のような単一のメタ塗りつぶしとして表現されてもよい。そのようなメタ塗りつぶし1415を使用することで、色空間変換中にオブジェクトに導入された追加稜線は除去される。
オブジェクト1413のようなコンパイルドオブジェクトとして組み合わされるオブジェクトの数が多くなるほど、コンパイルドオブジェクトの画素ラン(pixel runs )は長くなる。特に、先行する走査線から、キャッシュされた画素ランを再利用することが可能である場合、多数のコンパイルドオブジェクトは、より長い画素ランから大きな利益を受ける。例えば、同一の色のフラット塗りつぶしを1つのコンパイルドオブジェクトとして組み合わせると、オブジェクトの画素ランは、より大きくなり、キャッシュの再利用は改善される。更に、レンダリングモジュールの中には、そのレンダリングモジュールがレンダリングできる、1ページ当たりのオブジェクトの量が限られているものもあるため、先に説明したように、1つのコンパイルドオブジェクト及び関連するメタ塗りつぶしを生成することにより、ソフトウェアフォールバックジョブ(すなわち、ターゲットデバイスでレンダリングを実行するには、現在のページが余りにも複雑であるために、完全にソフトウェアのみによりレンダリングされるジョブ)を形成する必要なく、ハードウェアによるページのレンダリングが可能になる。
上述の好ましい方法は、特定の制御フローを含む。本発明の趣旨の範囲から逸脱せずに、異なる制御フローを使用する好ましい方法の他の変形が数多く存在する。更に、好ましい方法のステップのうちの1つ以上は、順次実行されるのではなく、並行して実行されてもよい。
以上、本発明のいくつかの実施形態のみを説明した。本発明の趣旨の範囲内から逸脱せずに、それらの実施形態に対して変形及び/又は変更を実施することは可能である。上述の実施形態は単なる例示であり、限定的な意味を持たない。
従来のソフトウェアアプリケーションと、グラフィックスデバイスインタフェースレイヤと、グラフィックスレンダリングシステムと、ターゲットデバイスとの従来の関係を示す図である。 放射勾配塗りつぶしの一例を示す図である。 非線形勾配塗りつぶしの一例を示す図である。 線形勾配塗りつぶしの一例を示す図である。 従来のグラフィックスレンダリングシステムを示す図である。 説明される構成を実施できる汎用コンピュータの概略ブロック線図である。 非線形勾配塗りつぶしを示す図である。 図5Aの非線形勾配塗りつぶしから生成される2つの線形勾配塗りつぶしを示す図である。 複数の線形勾配塗りつぶしを示す図である。 2段階稜線ベースグラフィックスレンダリングシステムを示す図である。 元の稜線ベースオブジェクトを示す図である。 従来の方式により、塗りつぶし、稜線及びレベルとして格納された図7Aのオブジェクトを示す図である。 塗りつぶし、稜線及びレベルにより表現されるコンパイルドオブジェクトとして格納された図7Aのオブジェクトを示す図である。 コンパイルドオブジェクトの一部を閉塞する円を有するコンパイルドオブジェクトを示す図である。 図8Aのコンパイルドオブジェクトの塗りつぶしを説明するメタ塗りつぶしを示す図である。 複数のオブジェクトを組み合わせて、コンパイルドオブジェクトを生成する方法を示す図である。 コンパイルドオブジェクトをレンダリングする方法を示す流れ図である。 メタ塗りつぶしを示す概略図である。 関連するメタ塗りつぶしと共にコンパイルされたオブジェクトの一例を示す図である。 関連する稜線データ及びレベルデータと共に6つの基本オブジェクトを示す図である。 図13のオブジェクト及び関連するメタ塗りつぶしから形成されたコンパイルドオブジェクトを示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ可能なオブジェクトのいくつかの例を示す図である。 組み合わせ不可能なオブジェクトのいくつかの例を示す図である。 組み合わせ不可能なオブジェクトのいくつかの例を示す図である。 2つのビットマップをリンクするメタ塗りつぶしの一例を示す図である。

Claims (15)

  1. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする方法であって、
    グループ化オブジェクトを形成するための組み合わせ手段が、前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、を含み、前記複合塗りつぶしデータが、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成する工程と、
    レンダリング手段が、前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングする工程と、
    を備え、前記レンダリングする工程では、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリングする工程は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする方法。
  2. 前記グループ化オブジェクトアウトラインは、前記所定のオブジェクトアウトライン又はその複数の部分のうちの1つ以上の組合わせの結果として得られることを特徴とする請求項1に記載の方法。
  3. 前記オブジェクトは、Z-オーダーにおいて連続し、前記グループ化オブジェクトは、前記オブジェクトの中で最低のZ-オーダーを割り当てられることを特徴とする請求項1に記載の方法。
  4. 判定する手段が、前記オブジェクトが所定の基準を満たすか否かを判定する工程を更に備え、前記判定する工程により所定の基準を満たすと判定された場合、グループ化オブジェクトアウトラインを形成することを特徴とする請求項1に記載の方法。
  5. 同一の単色塗りつぶしを有する1つ以上のグラフィカルオブジェクトは、前記複合塗りつぶしにおいて、1つ以上の単色塗りつぶしとして表現されることを特徴とする請求項1に記載の方法。
  6. 線形色変化を有する1つ以上のグラフィカルオブジェクトは、前記複合塗りつぶしにおいて、1つ以上の線形混合塗りつぶしとして表現されることを特徴とする請求項1に記載の方法。
  7. 前記所定の基準のうちの1つは、前記オブジェクトの各々が2つの平行な辺を有することを特徴とする請求項4に記載の方法。
  8. 前記塗りつぶしは、前記複合塗りつぶしデータにおいて、前記塗りつぶしデータを記述する塗りつぶしデータ構造の連係リストとして表現されることを特徴とする請求項1に記載の方法。
  9. 前記データ構造における第1の塗りつぶしを指示するポインタを格納手段に格納する工程を更に備えることを特徴とする請求項に記載の方法。
  10. 前記塗りつぶしの各々は、フラット塗りつぶしであることを特徴とする請求項1に記載の方法。
  11. 前記グラフィカルオブジェクトの各々のオブジェクトアウトラインは、1つ以上の稜線を含むことを特徴とする請求項1に記載の方法。
  12. オブジェクトアウトラインは、複数の点により定義される多角形であることを特徴とする請求項1に記載の方法。
  13. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングする装置であって、
    前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、を含み、前記複合塗りつぶしデータは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含む、グループ化オブジェクトを形成するための組み合わせ手段と、
    前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするレンダリング手段と、
    を備え、前記レンダリング手段は、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリング手段は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする装置。
  14. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトに関する当該オブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムであって、当該コンピュータプログラムが、
    前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、と含み、前記複合塗りつぶしデータと、は、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するための工程と、
    前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするための工程と、をコンピュータに実行させ、
    前記レンダリングするための工程では、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリングするための工程は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とするコンピュータプログラム。
  15. 各々が所定のオブジェクトアウトラインと、所定のZ-オーダーと、関連する塗りつぶしデータを含み、特定のオブジェクトのオブジェクトアウトラインは、前記特定のオブジェクトが塗りつぶされるエリアを定義する、複数のグラフィカルオブジェクトをレンダリングするためのコンピュータプログラムを記録したコンピュータで読み取り可能な記録媒体であって、当該コンピュータプログラムが、
    前記オブジェクトの各々を組み合わせて、グループ化オブジェクトアウトラインと、関連する複合塗りつぶしデータと、を含み、前記複合塗りつぶしデータは、前記グラフィカルオブジェクトと関連する塗りつぶしを表現する1つ以上の塗りつぶしデータ構造を含むグループ化オブジェクトを形成するための工程と、
    前記グループ化オブジェクトアウトラインに従って、前記グループ化オブジェクトをレンダリングするための工程と、をコンピュータに実行させ、
    前記レンダリングするための工程では、前記グループ化オブジェクトをレンダリングするために使用すべき1つ以上の塗りつぶしデータ現在のレンダリング位置と前記複合塗りつぶしデータの塗り潰し開始位置を示す走査線ごとに更新されるトラッキングポイントとの距離及び各塗り潰しデータの画素ランの長さの累計に基づいて判定、前記レンダリングするための工程は、前記現在のレンダリング位置と前記トラッキングポイントとの距離、及び前記各塗り潰しデータの画素ランの長さの累計に基づいて判定された使用すべき塗り潰しデータを用いてレンダリングすることを特徴とする記録媒体。
JP2005075523A 2004-03-16 2005-03-16 グラフィカルオブジェクトをレンダリングする方法 Expired - Fee Related JP4174484B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU2004901386A AU2004901386A0 (en) 2004-03-16 A Method of Rendering Graphical Objects

Publications (3)

Publication Number Publication Date
JP2005267639A JP2005267639A (ja) 2005-09-29
JP2005267639A5 JP2005267639A5 (ja) 2008-01-31
JP4174484B2 true JP4174484B2 (ja) 2008-10-29

Family

ID=34831700

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005075523A Expired - Fee Related JP4174484B2 (ja) 2004-03-16 2005-03-16 グラフィカルオブジェクトをレンダリングする方法

Country Status (4)

Country Link
US (1) US7277095B2 (ja)
EP (1) EP1577838B1 (ja)
JP (1) JP4174484B2 (ja)
AU (1) AU2005201019B2 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3922568B2 (ja) * 2002-03-18 2007-05-30 株式会社リコー 画像処理装置、描画処理方法及び該方法を実行するためのプログラム
JP4621617B2 (ja) * 2006-03-28 2011-01-26 株式会社東芝 図形描画装置、図形描画方法、及びプログラム
US8332751B2 (en) 2006-11-14 2012-12-11 Microsoft Corporation Removal of redundant information from electronic documents
CN101192307B (zh) * 2006-11-17 2012-05-23 鸿富锦精密工业(深圳)有限公司 点云三角网格面构建方法
US7907151B2 (en) * 2007-05-14 2011-03-15 Business Objects Software Ltd. Apparatus and method for associating non-overlapping visual objects with z-ordered panes
JP5067881B2 (ja) * 2008-07-11 2012-11-07 キヤノン株式会社 画像処理装置および画像処理方法
US8339672B2 (en) * 2009-03-30 2012-12-25 Sharp Laboratories Of America, Inc. Methods and systems for rendering data using graphic-list partitions and associated rendering processors
US8411319B2 (en) * 2009-03-30 2013-04-02 Sharp Laboratories Of America, Inc. Methods and systems for concurrent rendering of graphic-list elements
US20100245889A1 (en) * 2009-03-30 2010-09-30 Nguyen Uoc H Methods and Systems for Rendering Data
US8339653B2 (en) * 2009-03-30 2012-12-25 Sharp Laboratories Of America, Inc. Methods and systems for rendering data based on overlap characteristics
US8339670B2 (en) * 2009-03-30 2012-12-25 Sharp Laboratories Of America, Inc. Methods and systems for rendering data based on graphic-list partitioning
US20100245918A1 (en) * 2009-03-30 2010-09-30 Nguyen Uoc H Methods and Systems for Rendering Data
US8339671B2 (en) * 2009-03-30 2012-12-25 Sharp Laboratories Of America, Inc. Methods and systems for rendering data by partitioning a graphics list
AU2009202377A1 (en) * 2009-06-15 2011-01-06 Canon Kabushiki Kaisha Combining overlapping objects
JP5523002B2 (ja) 2009-07-29 2014-06-18 キヤノン株式会社 画像処理装置及び画像処理方法
AU2010241218B2 (en) * 2010-11-03 2013-10-31 Canon Kabushiki Kaisha Method, apparatus and system for associating an intermediate fill with a plurality of objects
WO2012164959A1 (ja) * 2011-06-02 2012-12-06 グリー株式会社 ベクターデータ変換出力装置、ベクターデータ変換出力方法、及びベクターデータ変換出力プログラム
TWI486947B (zh) * 2013-05-14 2015-06-01 Mstar Semiconductor Inc 圖層擷取方法、資料擷取裝置與圖層擷取安排方法
US9443331B2 (en) 2013-06-06 2016-09-13 Microsoft Technology Licensing, Llc Input object for routing input for visual elements
AU2014202321A1 (en) 2014-04-29 2015-11-12 Canon Kabushiki Kaisha Print-ready document editing using intermediate format
JP6445899B2 (ja) * 2015-02-26 2018-12-26 キヤノン株式会社 画像形成装置及びその制御方法
US10157485B2 (en) * 2016-02-17 2018-12-18 Texas Instruments Incorporated Method and system for merging of polygons in adjacent tiles

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3634447B2 (ja) * 1995-07-14 2005-03-30 キヤノン株式会社 画像処理装置及び方法
US6141462A (en) * 1995-10-11 2000-10-31 Dainippon Screen Mfg. Co., Ltd. Image processing using adjoining relationships between image parts
US5859959A (en) * 1996-04-29 1999-01-12 Hewlett-Packard Company Computer network with devices/paths having redundant links
US5926185A (en) * 1996-05-03 1999-07-20 Barco Graphics N.V. Method for processing a set of page description language commands to reduce complexity
US6115049A (en) * 1996-09-30 2000-09-05 Apple Computer, Inc. Method and apparatus for high performance antialiasing which minimizes per pixel storage and object data bandwidth
US6278457B1 (en) * 1998-01-15 2001-08-21 International Business Machines Corporation Methods and apparatus for performing sampling based synthesis of three-dimensional geometric models
JP3646969B2 (ja) * 1998-05-25 2005-05-11 富士通株式会社 3次元画像表示装置
US6515763B1 (en) * 1998-07-31 2003-02-04 Adobe Systems Incorporated Vignette recognition and compression
US6781600B2 (en) * 2000-04-14 2004-08-24 Picsel Technologies Limited Shape processor
AUPS300502A0 (en) * 2002-06-17 2002-07-11 Canon Kabushiki Kaisha Generating one or more linear blends

Also Published As

Publication number Publication date
AU2005201019A1 (en) 2005-10-06
EP1577838A2 (en) 2005-09-21
US20050206653A1 (en) 2005-09-22
JP2005267639A (ja) 2005-09-29
AU2005201019B2 (en) 2007-04-05
EP1577838A3 (en) 2006-09-06
EP1577838B1 (en) 2013-01-23
US7277095B2 (en) 2007-10-02

Similar Documents

Publication Publication Date Title
JP4174484B2 (ja) グラフィカルオブジェクトをレンダリングする方法
US20100315431A1 (en) Combining overlapping objects
US5542052A (en) Applying traps to a printed page specified in a page description language format
US7561303B2 (en) Caching and optimisation of compositing
US6490055B1 (en) Printing apparatus with execution of software rendering and hardware rendering
US9013718B2 (en) Print control apparatus, control method thereof, and device driver for converting commands from one format to another
US5852679A (en) Image processing apparatus and method
US8723884B2 (en) Scan converting a set of vector edges to a set of pixel aligned edges
JP2006309671A (ja) 画像処理装置及びその制御方法、プログラム
US6975416B2 (en) Print control apparatus and method
JP5644214B2 (ja) 印刷制御プログラム、情報処理装置、記憶媒体、印刷装置、印刷システム
US8705118B2 (en) Threshold-based load balancing printing system
JP2007245723A (ja) ドキュメント・レンダリング・システム、方法およびプログラム
JP4461361B2 (ja) 描画処理方法およびプログラム並びに描画命令出力装置および画像形成装置
US20050195220A1 (en) Compositing with clip-to-self functionality without using a shape channel
JP5424546B2 (ja) 画像処理装置及び画像形成システム
JP2004021886A (ja) 画像処理装置及び画像処理方法
JP4467715B2 (ja) 画像出力制御装置及び方法
AU2005203541A1 (en) Multiple image consolidation in a printing system
JP2000215010A (ja) 画像処理装置、画像形成装置、画像処理形成システム、画像処理方法、画像形成方法および画像処理形成方法
JP2019192087A (ja) 情報処理装置、プログラム、情報処理方法
AU2004240230A1 (en) Caching and optimisation of compositing
AU2004237908A1 (en) Apparatus for printing overlapping objects

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071206

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20071221

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080219

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080411

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080609

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20080619

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: 20080808

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: 20080818

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: 20110822

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120822

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120822

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130822

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees