JP2010535371A - 二次元ベクター画像のマルチサンプルレンダリング - Google Patents

Abstract

グラフィックプロセッサの必要メモリ帯域幅の少ない、改良されたレンダリングのための方法およびデバイス。レンダリングプロセスにおいて、ピクセルを分類するために、ビット長の短い分類バッファが使用される。ピクセルの部分のためにマルチサンプルバッファにアクセスすることなく、この分類に基づいて、ピクセル色を決定できる。これにより、必要なメモリ帯域幅が低減される。

Description

本発明はベクターグラフィックに関し、より詳細には、二次元ベクター画像をレンダリングするための効率的な方法およびデバイスに関する。

近年、ハンドヘルドデバイスがマルチメディア機能に対応している。最初のマルチメディア対応ハンドヘルドデバイスが登場して以来、このようなデバイスの機能が飛躍的に向上している。このため、携帯電話やその他のハンドヘルドマルチメディアコンピュータなどの最近のハンドヘルドデバイスは、高度なカラーグラフィック処理、カメラ、ミュージックプレーヤ、高速通信などの機能を備えている。しかし、新しい機能が未だに登場しており、ユーザの体感を向上させるために、既存の機能も引き続き改善されている。

一般に、グラフィック機能はアンチエイリアシングを使用することで改善される。二次元ベクターグラフィックで使用するアンチエイリアシングには、基本的に、エッジアンチエイリアシングとフルシーンアンチエイリアシングの２つの手法（variant）が存在する。

エッジアンチエイリアシングでは、ラスタライゼーション中にポリゴンエッジでアンチエイリアシングが実行され、ポリゴンカバレッジが透明度に変換され、この透明度の値を使用して、ターゲットキャンバスでポリゴンのペイント色がブレンドされる。仕様には明記されないが、エッジアンチエイリアシングは、ＯｐｅｎＶＧ １．０ ＡＰＩで使用されているとされるレンダリングモデルである。

フルシーンアンチエイリアシングでは、ピクセルごとに多数のサンプルが記憶され、画像が完成すると、最終的なピクセル色が別のパスでリゾルブされる。この手法は、三次元グラフィックのアンチエイリアスレンダリングの代表的な方法である。また、Ａｄｏｂｅ Ｆｌａｓｈは、二次元ベクターグラフィックのレンダリングにフルシーン手法を使用している。

エッジアンチエイリアシングの問題としては、例えば、隣接するポリゴンエッジにレンダリングアーチファクトが生成されてしまう点が挙げられる。例えば、Ａｄｏｂｅ Ｆｌａｓｈのコンテンツは、エッジアンチエイリアシングを使用すると正しくレンダリングすることができない。一方で、典型的なフルシーンアンチエイリアシング法は、多量のメモリを必要とし、帯域幅が過剰に消費されてしまう。

完全なアンチエイリアシングを行うには、ピクセル内のすべての寄与するジオメトリのカバレッジを計算し、この情報から最終的なピクセル色をリゾルブしなければならない。実際には、これを解析的に解決するには、ポリゴンフラグメントをピクセルレベルでクリッピングしなければならない。しかし、このようなアルゴリズムは実用的でないため、性能への悪影響を考慮して、代表的な二次元レンダリングＡＰＩは、ポリゴンを１つずつレンダリングし、性能と品質のバランスに鑑みて生成されたアーチファクトを容認する。

このようなアーチファクトを防ぐために、一部のアーキテクチャでは、複合シェイプ（compound shape）などの回避法が使用される。複合シェイプとは、隣接するポリゴンの組を定義するポリゴンエッジの集まりである。次に、複合シェイプラスタライザは、比較的直接的なソフトウェア実装により、ピクセルごとにすべてのポリゴンの合計カバレッジと色とを評価することができる。しかし、複合シェイプの制限により、この方法はさほど一般的でなく、所期または所望の結果を得るために重複が削除されている、特別に作成したデータを必要とする。

このようなアーチファクトを防ぐための比較的直接的な手法として、単に、スーパーサンプリングまたはマルチサンプリング技術を使用する手法もある。この手法は、ブレンディング操作と透明度に関して従来のレンダリングモデルの利益を得る、すなわち、データが後ろから前の順に処理されるが、多くの場合、メモリと帯域幅の消費が問題となりうる。

スーパーサンプリングは、その最も基本的な形態では、高い解像度を有するレンダリングバッファを使用し、ピクセル領域内のすべてのサンプルのピクセル値の平均値を算出して、リゾルブパス中にこれを縮小する。一方、マルチサンプリングは、これより若干高度な方法である。マルチサンプリングでは、ピクセルに割り当てられたデータが、１つの色値と、その色がピクセル内でどのサンプルに割り当てられているかを示すマスクとから構成される。

このため、適切なアンチエイリアシング機能を有する、改良され、より費用効率の高いレンダリングメカニズムが求められている。

本発明の実施形態は、グラフィックプロセッサの必要メモリ帯域幅の少ない、改良されたレンダリングのための方法およびデバイスを開示する。レンダリング中に、ピクセルに対して分類プロセスが実行される。ピクセルの部分のためにマルチサンプルバッファにアクセスすることなく、分類に基づいて、ピクセル色の決定を計算できる。これにより、必要なメモリ帯域幅が低減される。

本発明の一実施形態では、ベクターグラフィック画像をレンダリングするための方法は、分類バッファをクリアするステップと、マルチサンプルバッファと分類バッファとを使用してポリゴンをレンダリングするステップと、ピクセル値をリゾルブするステップと、ターゲット画像バッファ内に画像を生成するステップと、を有する。ピクセル分類は各ピクセルのカバレッジ値に基づいて行われる。ピクセル分類には、一般に、２ビットで表すことができる４つの異なるクラスが含まれる。代表的には、これらのクラスは、「背景」、「非伸張」、「圧縮」および「伸張」である。圧縮クラスにおいて、ピクセルのカバレッジマスクがロスレス圧縮法を使用して圧縮される。

本発明の一実施形態では、分類バッファ内の全ピクセルを背景にセットすることによって、ピクセル分類情報バッファのクリアが行われる。分類バッファをクリアする利点は、クリアする段階でピクセル色に書き込む必要がないため、画像のクリアを高速化できる点にある。ピクセル値は、分類バッファとマルチサンプルバッファとを使用してリゾルブされる。レンダリングのどの段階でも中間リゾルブを実行することが可能である。

更に別の実施形態では、ベクターグラフィック画像のレンダリングがタイルで実行される。この実施形態では、マルチサンプルバッファのサイズを削減できる。

一実施形態では、本発明がグラフィックプロセッサに実装され、このグラフィックプロセッサは、分類バッファ、マルチサンプルバッファおよびターゲット画像バッファを有する。プロセッサは、ベクター画像を表す入力コマンドを実行することができる処理手段を更に有する。また、本発明の代替の実施形態では、グラフィックプロセッサが追加のメモリを備えてもよい。本発明に加えて、グラフィックプロセッサは、高品質のグラフィックを生成するために必要な機能に要求される複数のグラフィック生成ユニットを有する。

本発明は、メモリ帯域幅の低いデバイスのための効率的なベクターグラフィックのレンダリング方法を提供する。これにより、先行技術のシステムより低い演算パワーコストで、高品質のグラフィックの生成が可能となる。このため、本方法は、コンピュータグラフィックを使用するどのようなデバイスにも適している。このようなデバイスには、例えば携帯電話、ハンドヘルドコンピュータ、通常のコンピュータなどがある。

本発明の例示の一実施形態を示すブロック図。 本発明に係る例示の方法のフローチャート。 本発明に係る例示の方法のフローチャート。 本発明に係る例示の方法のフローチャート。 本発明に係る例示の方法のフローチャート。 本発明に係る例示の方法のフローチャート。 本発明に係る例示の方法のフローチャート。

本発明を更に詳しく理解できるように提供する添付の図面は、本明細書の一部を構成しており、本発明の実施形態を示し、本明細書と共に本発明の原理を説明する一助となる。

以下、本発明の実施形態を詳細に記載し、その例が添付の図面に図示されている。

図１は、本発明の例示の一実施形態のブロック図である。本発明はグラフィックプロセッサに完全に実装されるように設計されており、このため、例はこのような環境に関連している。しかし、本発明の一部分がソフトウェアコンポーネントとして実装されても、またはグラフィックプロセッサ以外のハードウェアコンポーネントに実装されてもよいことを、当業者は認めるであろう。

図１は、ブロックの例１０を開示している。ブロック１０は、プロセッサ１４、分類バッファ１１、ターゲット画像バッファ１２、およびマルチサンプルバッファ１３を有する。プロセッサ１４は、通常、ブロック１０に含まれるグラフィック処理ユニットの他の機能と共有される。バッファ１１〜１３はそれぞれ、ブロック１０を含むグラフィック処理ユニットに実装されているメモリに、予約された部分を有しうる。このため、メモリは、グラフィック処理ユニットの他の機能と共有される。しかし、通常は、バッファ１１〜１３に割り当てられる部分は、バッファ１１〜１３の専用に割り当てされる。このため、メモリは、本明細書に記載の関連する機能のために排他的に予約されうる。また図１は、別の用途（needs）と、アプリケーションプロセッサ１４で実行中のアプリケーションとに予約されている追加のメモリ１５も開示している。このメモリは、ブロック１０の内部に設けられても、ブロック１０の外部であるが、グラフィックプロセッサの内部に設けられても、メモリ１５が外部メモリであってもよい。入力と出力のデータフォーマットは、当業者が理解するように、本明細書に開示の要件に従って選択されうる。

本発明をよりよく理解できるように、本実施形態は、ポリゴンのエッジが、ピクセルの一部のみを覆う場合に、ピクセルのカバレッジ値を計算するために、ピクセルが、サブピクセルに更に分割されるという点に留意すべきである。例えば、ピクセルが１６×１６のサブピクセルの組に分割されうる。次に、サブピクセルの組から代表サンプル（例えば１６のサンプル）が選択される。サンプルは、ピクセルのカバレッジを適切に示すように選択される。例えば、この選択は、ピクセルの組から、それぞれ一意のｘとｙの値とを有する１６のサンプルを無作為に選択することによって行うことができる。しかし、本明細書では１６のサンプルと１６×１６サブピクセルの組を説明するが、本発明はこれに限定されない。サンプルの数と、サブピクセルの組の数が変わってもよいことを当業者は認めるであろう。例えば、８サンプル、３２サンプルなどが挙げられる。一般に、１６のサンプルが１６×１６のサブピクセルの組と使用され、これに対応して、３２のサンプルが３２×３２のサブピクセルと使用されるなどである。しかし、これは必須ではなく、例えば、３２のサンプルを１６×１６のサブピクセルの組と使用することも可能である。

本発明のこの例示の実施形態は分類バッファ１１を備え、例示的な実施形態では、分類バッファ１１は、２ビットの分類値またはコードを記憶する。ターゲット画像バッファ１２の各ピクセルに対して、分類バッファ１１内に対応する分類ビットが存在するように、分類バッファ１１の大きさはターゲット画像バッファ１２のサイズに対応している。また、圧縮されているピクセルデータと伸張されているピクセルデータの両方を記憶するために、マルチサンプル画像バッファ１３が使用される。１６サンプルの場合、マルチサンプル画像バッファ１３は、ターゲット画像バッファ１２のサイズの１６倍となる。オペレーティング環境が動的メモリ割り当てに対応している場合、マルチサンプルバッファ１３の必要メモリ量が少なくてもよい点に留意されたい。ハードウェア実装などのスタティックな実装では、圧縮が一切行われない最悪の場合に鑑みて、マルチサンプルバッファ１３にメモリを割り当てる必要がある。

本実施形態に係る圧縮法について更に詳細に説明する。本実施形態の圧縮法は、画像のピクセルを、背景色のピクセルである変更されない（unaffected）ピクセルと、レンダリングされるポリゴンの完全に内部に存在するピクセルと、ポリゴンエッジのピクセル、の３つの異なるカテゴリに分類できるということを利用している。ポリゴンエッジのピクセルの大多数は、変更されないピクセルの背景色と、レンダリングされるポリゴンの完全に内部に存在するピクセルのポリゴンのペイント色の２つの色のうち、１つのみに関わる。このため、このようなピクセルを、１つの１６ビットマスクと、２つの色値とで表現することができる。本圧縮法は、上記の概念を利用して、ピクセルを以下の４つのカテゴリに分けている。
−背景ピクセル：色値が記憶されない
−非伸張ピクセル：色値がターゲット画像バッファに記憶されている
−圧縮ピクセル：色値が一時マルチサンプルバッファに圧縮データとして記憶される
−伸張ピクセル：色値が一時マルチサンプルバッファに個々のサンプルとして記憶される

これらの４つのカテゴリのそれぞれに、分類バッファに対応する２ビット値が割り当てられる。本例示の実施形態の圧縮はロスレスであり、ピクセルのカバレッジマスクのみに基づき、色値の分析が行われない点は触れる価値があろう。これにより、本圧縮法の実装が極めて効率的となる。しかし、他のロッシーまたはロスレスの圧縮法を使用することも可能である。

図２は、例示の一実施形態に係るレンダリング法のフローチャートを開示している。レンダリングプロセスは、クリア２０、ポリゴン処理２１およびリゾルブ２７の３つの段階から構成される。これらの３つのステップは独立しており、本明細書に記載の例示的な実施形態では、完成フレームを生成するためにこの順に繰り返される。ポリゴン処理は、ステップ２２〜２６を更に有する。一般に、全ポリゴンが処理されてからリゾルブステップ２７に移る。下に説明するように、これらのステップがほかの順序で実行されてもよい。しかし、リゾルブステップは、ターゲット画像バッファ内の未使用のピクセルしか変更しないため、レンダリング中の任意の時点で画像を提供するための中間リゾルブを実行することも可能である。複数のフレームを同時に計算するために、これらのステップが同時に処理されてもよいことを当業者は認めよう。しかし、本発明をよりよく理解できるように、以下では、１つのフレームの逐次的な処理を開示する。

まず、クリア操作が発行される（ステップ２０）。このとき、分類バッファ内の全ピクセルが背景ピクセルとしてマークされ、背景色の値が記憶されるのみである。ターゲット画像バッファまたはマルチサンプルバッファにあるピクセル色が変更されることはない。分類バッファのクリアにより画像のクリアが高速されるため、これは通常有利である。この処理は、一般に、クリア段階でピクセル色を書き込むよりも高速である。しかし、代替の実装では、画像に定数の色値を書き込むことによって、背景の分類を行わずにクリアが実装されてもよい。この代替の実装では、ピクセルが非伸張ピクセルに分類され、色値がターゲット画像バッファに書き込まれる。

この後、ポリゴンが、一度に１ポリゴンずつ処理される（ステップ２１）。各ポリゴンはペイント色を有する。多くの場合、ペイント色はポリゴンで一定であるが、特に、勾配またはテクスチャが使用される場合には、ピクセルごとに変更されてもよい。また、ペイント色は、アルファ値として定義される半透明度も有しうる。ポリゴンは、何らかのブレンディングを行ってレンダリングされてもよいが、簡潔を期するために、まずは、ペイントが不透明で、ブレンディングなしの場合について説明する。

ポリゴンのピクセルごとに、１６ビットのカバレッジマスクが生成される（ステップ２２）。カバレッジマスクには、ポリゴンのシェイプと、「内部かどうか（insideness）」の決定に使用する塗りつぶしルールとに応じた、ポリゴン内部にあるピクセル内のサンプルが含まれる。内部がどうかは、走査線の順序、またはタイリングラスタライザ（例えばピクセルの６４×６４ブロックにこれを行うラスタライザなど）を使用して決定することができる。カバレッジマスクのサイズは、アプリケーションに応じて選択することができる。例えば、１ピクセルにつき８サンプルが好ましい場合、８ビットのみが必要となる。

ピクセルのカバレッジマスクが完全である、すなわち、１６ビットすべてがセットされている場合（ステップ２３）、ターゲット画像バッファに直接レンダリングされ、ピクセルに対応する分類バッファ内の値が「非伸張」にセットされる（ステップ２４）。また、新しい不透明な色値により、そのピクセル用に既に記憶されている値がすべて破棄されるため、この操作により、マルチサンプリングされているピクセルが非伸張フォーマットに逆変換されうる。

カバレッジが部分的な場合、ターゲットピクセルの分類を考慮する必要があり（ステップ２５）、その後にレンダリングが行われる（ステップ２６）。背景ピクセルと非伸張ピクセルに対して、マルチサンプルバッファ内に圧縮されたエントリが作成される。その際、マスクは、生成されたカバレッジマスクであり、第１の色のエントリが、背景色として、あるいはターゲット画像バッファ内の色としてセットされ、第２のエントリが、現在のペイント色としてセットされる。また、ピクセルの分類値が「圧縮」にセットされる。

圧縮ピクセルでは、ピクセルが圧縮状態に保持され、この場合、色のエントリのうちの１つが現在のペイント色に変更され、マスクが更新される可能性がある。マスクの変更（This）は、新しいカバレッジマスクが、記憶されているカバレッジマスクのいずれの一部を完全にカバーしているかどうかを確認することによって検出することができる。カバーしていない場合、すなわち、新しいマスクが適用されたときに、記憶されている色の両方が可視状態に保持されている場合、データが完全な１６のサンプルに伸張され、ピクセルの分類値が「伸張」にセットされる。記憶されているピクセルが既に伸張形式の場合、ピクセル値が、単にマルチサンプルバッファの適切なサンプル位置に記憶される。

ブレンドされた値の場合、ペイント色のアルファ成分と使用するブレンドモードとに応じて、ターゲットピクセルを常に考慮しなければならない。ブレンドされたピクセルが完全なカバレッジを有する場合、ターゲット画像バッファ内の関連するすべての色値とブレンドされる。カバレッジが部分的な場合、ピクセル分類に応じて、ターゲットピクセルの適切な成分とのブレンディングを実行する必要がある。一般に、ポリゴンが同じ位置にラスタライズされる場合、ピクセルの分類が別の分類に変換される。各種の変換を表１に示す。

画像生成の最終ステップは、リゾルブパスである（ステップ２７）。このステップでは、分類バッファから値が読み出され、分類に従ってターゲット画像バッファに適切な色が書き込まれる。「背景」の分類は、背景色と共にターゲット画像バッファに書き込まれる。「非伸張」の分類は、ターゲット色が既に存在するため、無視される。「圧縮」の分類では、カバレッジマスクがカバレッジ割合に変換され、記憶されている２つの色がブレンドされ、これがターゲット画像バッファに書き込まれる。「伸張」の分類では、すべての記憶されているサンプル値の平均値が計算され、これがターゲット画像バッファに書き込まれる。この段階で、ターゲット画像バッファ内で画像が完成する。

上で説明した方法は１つのマルチサンプルバッファを想定している。しかし、画面解像度が大きな場合、このバッファは何十メガバイトものメモリを消費しかねない。このため、ハンドヘルドデバイス用の代替的な手法が必要となる。

一般に、画像内のピクセルのごく一部のみが、完全に伸張されたマルチサンプルバッファを必要とする。しかし、最悪の場合、画像内のすべてのピクセルによって完全に伸張されたマルチサンプルバッファが使用されることも考えられる。画像がレンダリングされるまでマルチサンプルバッファの使用（the usage）が判明しないため、レンダリングに必要なメモリ量を正確に割り当てる実装では、ラスタライゼーション中に動的メモリ割り当てを実行する必要がある。これはハードウェア実装では実行不可能である。

本発明の例示の一実施形態では、ラスタライゼーションが、６４×６４のタイルで、左から右、上から下などの所望の順に実行される。このタイルは、実際の画面タイルでなく、ラスタライザによって使用される一時タイルである。これは、かなり効率的なメカニズムであり、ポリゴンエッジのリスト構造を使用せずに、一定のメモリ空間においてラスタライゼーションを実行可能となる。しかし、このメカニズムでは、６４×６４ピクセルを超えるポリゴンは、複数回（１ラスタライゼーションタイルにつき１回）処理する必要がある。

このメカニズムによりポリゴンがタイルに分割されるため、このタイリングを、マルチサンプリングプロセスを含むように拡張することができる。１度に１つのポリゴンをタイルの順にレンダリングする代わりに、１つのタイルに属するすべてのポリゴンが、タイルサイズと等しいマルチサンプルバッファを使用してレンダリングされ、タイルの最終的な出力がターゲット画像バッファにおいてリゾルブされる。この手法では、同じ入力データを複数回処理する必要があるため、入力データ全体を完全にキャプチャする必要がある。つまり、入力においてパスデータが別のバッファとして既に記憶されているため、実際には、コマンドのストリームの記録のみを実行し、これは、（メモリ消費の観点からいえば）比較的負荷が低い。

最終的には全ポリゴンのタイルをリゾルブする必要があるため、タイリングに関連する追加の処理オーバーヘッドが発生することがない。

更に、ラスタライゼーションタイルのサイズはマルチサンプルバッファのサイズに大きく依存しておらず、マルチサンプルバッファは、１度に少なくとも１つのラスタライゼーションタイルを保持できるだけの大きさであればよい。例えば、ターゲット画像バッファの幅をタイル幅として使用するなど、マルチサンプルバッファのサイズを大型化することにより、性能を向上できる。このようにすれば、タイルエッジごとのクランピング操作が必要なくなり、ラスタライゼーションプロセスは、タイルラスタライザのタイプライタスキャン順序を使用して、右に移動しながら、左のタイルから情報を引き継ぐことができる（inherit information from the tile on the left while proceeding forward to the right）。データサイズが更に比較的大きい場合も考えられ、例えば６４０×６４のマルチサンプリングバッファは、２．５メガバイトのメモリを消費する。メモリの量は、ラスタライゼーションタイルの高さと、ターゲット画像バッファの幅とによって決まるため、ラスタライゼーションタイルのアスペクト比を、例えば３２×１２８に変更することにより、マルチサンプルバッファのサイズをかなり小型化することができる。一般に、マルチサンプリングバッファのメモリの消費量が、ターゲットビットマップの消費量の１〜２倍であれば、実施可能であると考えられる。ＶＧＡ画面（６４０×４８０）において３２×１２８のラスタライゼーションタイルのサイズの場合、バッファの大きさが６４０×３２となり、画面自体の数パーセントしか消費しない。

マルチサンプルバッファのサイズをこのように小型化することにより、分類バッファも小型化される。帯域幅の利用率とレーテンシを更に低減させるために、マルチサンプルバッファをオンチップメモリに記憶させることも可能である。

分類バッファのクリアを高速化するために、階層レベルの一番上に別の階層レベルを作成し、ピクセルのグループ（例えば３２ピクセル）に対して、そのグループのすべてのピクセルが「背景」に分類されることを示す１ビットを記憶することも可能である。これにより、分類バッファへのリードアクセス回数を減らし、初期のクリア操作のサイズを低減することができる。

図３は、本発明に係る更に別の実施形態のフローチャートを開示している。本実施形態では、処理が、レンダリングされるポリゴンの組から開始される（ステップ３０）。まず、クリア手順が実行される（ステップ３１）。このとき、分類バッファ内の全ピクセルが背景ピクセルとしてマークされ、背景色の値が記憶されるのみである。ターゲット画像バッファまたはマルチサンプルバッファにあるピクセル色が変更されることはない。次に、ポリゴンが１つずつ処理される（ステップ３２）。残りのポリゴンが存在する場合、処理する次のポリゴンのデータが取得される（ステップ３３）。ポリゴンデータには、例えば、ポリゴンのシェイプ、ペイントおよびブレンドが含まれる。次に、ポリゴンの各ピクセルが処理される（ステップ３４）。追加のピクセルが存在する場合、ステップ３５において１ピクセル用のカバレッジマスクであるフラグメントが生成される。次に、フラグメントが図５に示すように処理される（ステップ３６）。すべてのピクセルが処理されている場合、ループがステップ３２に戻る。すべてのポリゴンが処理されている場合、本実施形態は、図４に示すリゾルブ（ステップ３７）に進む。リゾルブ後に、画像が完成し、次の画像の処理が開始されうる。

図４は、本発明による例示的なリゾルブプロセスのフローチャートを開示している。本発明に係るリゾルブは、ピクセルごとに行われる（ステップ４０）。しかし、本発明に係る機能が、一度に複数のピクセルを処理可能なデバイスで実装されてもよいことを当業者は認めるであろう。この場合、例えば、一度に４または８ピクセルを処理して、次のピクセルの組を処理することが可能である。最初のステップでは、残りのピクセルが存在するかどうかが判定される（ステップ４１）。リゾルブする残りのピクセルが存在する場合、ピクセル分類情報を取得し（ステップ４２）、次にピクセルの分類を確認する（ステップ４３）。ピクセルが「背景」に分類されている場合、ターゲット画像バッファに背景色を書き込む（ステップ４４）。ピクセルが「非伸張」に分類されている場合、データが既に存在するため、処理を行わない（ステップ４５）。ピクセルが「圧縮」に分類されている場合、マルチサンプルバッファからマスクと２つの色とを取得し（ステップ４６）、マスクをアルファに変換して、色値とブレンドする（ステップ４７）。次に、結果がターゲット画像バッファに書き込まれる（ステップ４８）。ピクセルが「伸張」に分類されている場合、マルチサンプルバッファから１６色値のすべてを取得し（ステップ４９）、全１６色値の平均値を計算する（ステップ４１０）。次に、結果の色がターゲット画像バッファに書き込まれる。この段階で、ピクセルの処理が完了し（ready）、このプロセスが次のピクセルが続行される。残りのピクセルが存在しない場合、画像がリゾルブされる（ステップ４１１）。

図５ａ〜５ｃは、本発明によるフラグメントを処理するための実施形態のフローチャートを開示している。処理は図５ａから開始し、現在のピクセルにブレンディングまたはアルファが存在するかどうかが確認される（ステップ５０）。「はい」の場合、次に、マスクが完全であるかどうかが確認される（ステップ５１）。マスクが完全な場合、処理は図５ｃに進む。マスクが完全ではない場合、処理は図５ｂに進む。これらの図面については、後で詳細に説明する。

現在のピクセルにブレンディングまたはアルファが存在しない場合でも、マスクが完全であるかどうかが確認される（ステップ５２）。マスクが完全な場合、ピクセルが「非伸張」に分類される（ステップ５３）。次に、ペイント色がターゲット画像バッファに記憶される（ステップ５４）。現在のフラグメントが処理可能となる（ready）（ステップ５５）。

ステップ５２においてマスクが完全でない場合、最初にピクセル分類を取得し（ステップ５６）、次にクラス（class）を決定する（ステップ５７）。ピクセルが「背景」に分類されている場合、ピクセルが「圧縮」に分類される（ステップ５８）。次に、マスク、背景およびペイント色が、マルチサンプルバッファに記憶される（ステップ５９）。ピクセルが「非伸張」に分類されている場合、ピクセルが「圧縮」に分類される（ステップ５１０）。次に、マスク、ターゲット画像バッファからの色およびペイント色が、マルチサンプルバッファに記憶される（ステップ５１１）。ピクセルが「圧縮」に分類されている場合、ピクセルが「伸張」に分類される（ステップ５１２）。次に、マルチサンプルバッファ内の圧縮データが伸張され、マスクにおいてペイント色でマークされているサンプルが上書きされる（ステップ５１３）。ピクセルが「伸張」に分類されている場合、分類は変更されない（ステップ５１４）。次に、マスクにおいてペイント色でマークされているサンプルが、マルチサンプルバッファにおいて上書きされる（ステップ５１５）。この段階でフラグメントの処理が完了している（ready）（ステップ５５）。

図５ｂは、マスクが完全でない場合に、図５ａのステップ５１から続いて実行される処理の例を開示している。最初に、ピクセル分類を取得し（ステップ５１６）、次にクラスを決定する（ステップ５１７）。ピクセルが「背景」に分類されている場合、ピクセルが「圧縮」に分類される（ステップ５１８）。次に、マスク、背景色、およびペイント色とブレンドされた背景が、マルチサンプルバッファに記憶される（ステップ５１９）。ピクセルが「非伸張」に分類されている場合、ピクセルが「圧縮」に分類される（ステップ５２０）。次に、マスク、ターゲット画像バッファからの色、およびペイント色とブレンドしたターゲット画像バッファからの色が、マルチサンプルバッファに記憶される（ステップ５２１）。ピクセルが「圧縮」に分類されている場合、ピクセルが「伸張」に分類される（ステップ５２２）。次に、マルチサンプルバッファ内の圧縮データが伸張され、ペイント色が、マスク内のマークされているサンプルとブレンドされる（ステップ５２３）ピクセルが「伸張」に分類されている場合、ピクセルの分類が保持され（ステップ５２４）、ペイント色が、マルチサンプルバッファ内で、マスク内のマークされているサンプルとブレンドされる。この段階でフラグメントの処理が完了している（ready）（ステップ５５）。

図５ｃは、マスクが完全な場合に、図５ａのステップ５１から続いて実行される処理の例を開示している。最初に、ピクセル分類を取得し（ステップ５２６）、次にクラスを決定する（ステップ５２７）。ピクセルが「背景」に分類されている場合、ピクセルが「未圧縮」に分類され（ステップ５２８）、ペイント色が背景とブレンドされ、ターゲット画像バッファに記憶される（ステップ５２９）。ピクセルが「非伸張」に分類されている場合、分類が変更されず（ステップ５３０）、ペイント色がターゲット画像バッファとブレンドされる（ステップ５３１）。ピクセルが「圧縮」に分類されている場合、分類が変更されず（ステップ５３２）、ペイント色がマルチサンプルバッファ内の、圧縮されている２つの色値とブレンドされる（ステップ５３３）。ピクセルが「伸張」に分類されている場合、分類が変更されず（ステップ５３４）、ペイント色がマルチサンプルバッファ内の全サンプルとブレンドされる（ステップ５３５）。この段階でフラグメントの処理が完了している（ready）（ステップ５５）。

当業者が理解するように、本明細書に記載の実施形態は、ベクターグラフィック処理（process vector graphics）を使用しうる、適したコンピューティングデバイスおよびシステムであればどのようなものにも適用可能であり、これには、ワイヤレスハンドヘルドデバイス、ラップトップコンピュータ、デスクトップコンピュータ、プリンタ、サーバ、セットトップボックス、デジタルテレビなどがあるが、これらに限定されない。本明細書に記載の本発明の真の趣旨および範囲を逸脱しない範囲で、上記の方法および装置を更に変更してもよい。このため、上記の開示の主題を例示と解釈すべきであり、限定的に解釈すべきではないことが意図されよう。

技術の発達に伴い、本発明の基礎的な概念をさまざまな方法で実施できることは、当業者にとって明白であろう。このため、本発明およびその実施形態は上記の例に限られず、特許請求の範囲内で変わりうる。

Claims (19)

1. 各ピクセルに関連するピクセル分類およびカバレッジ値に基づいてピクセル値をリゾルブするステップと、
   前記リゾルブしたピクセル値を使用してバッファ内に画像を生成するステップとを含む、ベクターグラフィック画像をレンダリングするための方法。
2. ピクセルごとにピクセル分類とカバレッジ値とを決定するステップを更に含む、請求項１に記載の方法。
3. 前記ピクセル分類は背景のクラスを含む、請求項２に記載の方法。
4. 前記ピクセル分類は、非伸張、圧縮および伸張の各クラスを含む、請求項３に記載の方法。
5. 前記圧縮クラスにおいて、前記ピクセルの前記カバレッジマスクがロスレス圧縮法を使用して圧縮される、請求項４に記載の方法。
6. 前記ピクセル分類情報バッファを含む前記メモリの部分内の全ピクセルを背景にセットすることによって、前記部分をクリアするステップを更に含む、請求項３に記載の方法。
7. 前記ベクターグラフィック画像がタイルでレンダリングされる、請求項２に記載の方法。
8. 前記レンダリングはレンダリング中の中間リゾルブを更に有する、請求項２に記載の方法。
9. 前記分類を変換するステップを含む、請求項２に記載の方法。
10. 少なくとも分類バッファ、マルチサンプルバッファおよびターゲット画像バッファを記憶するように構成されたメモリと、
    プロセッサとを備え、
    前記プロセッサは、前記ピクセル分類のための前記分類バッファと前記マルチサンプルバッファと使用して前記ターゲット画像バッファ内に画像を生成するように構成され、前記画像は、各ピクセルのカバレッジ値と分類とに基づいて生成されるグラフィックデバイス。
11. 前記プロセッサは、背景のクラスを含むクラスにピクセルを分類するように構成されている、請求項１０に記載のグラフィックデバイス。
12. 前記プロセッサは、非伸張、圧縮および伸張の各クラスを含むクラスにピクセルを分類するように更に構成されている、請求項１１に記載のグラフィックデバイス。
13. 前記プロセッサは、前記圧縮クラスにおいて、ロスレス圧縮法を使用して前記ピクセルの前記カバレッジマスクを圧縮するように更に構成されている、請求項１２に記載のグラフィックデバイス。
14. 前記プロセッサは、前記ピクセル分類バッファ内の全ピクセルを背景にセットすることによって、前記分類情報バッファをクリアするように構成されている、請求項１１に記載のグラフィックデバイス。
15. 前記プロセッサは、前記分類バッファと前記マルチサンプルバッファとを使用してピクセル値をリゾルブするように構成されている、請求項１０に記載のグラフィックデバイス。
16. 前記プロセッサは、ベクターグラフィック画像をタイルでレンダリングするように更に構成されている、請求項１０に記載のグラフィックデバイス。
17. 前記プロセッサはレンダリング中に中間リゾルブを実行するように構成されている、請求項１０に記載のグラフィックデバイス。
18. レンダリングブロックが追加メモリに結合されている、請求項１０に記載のグラフィックデバイス。
19. 少なくとも分類バッファ、マルチサンプルバッファおよびターゲット画像バッファを記憶するように構成されたメモリと、
    処理手段とを備え、
    前記処理手段は、前記ピクセル分類のための前記分類バッファと前記マルチサンプルバッファとを使用して前記ターゲット画像バッファ内に画像を生成するように構成され、前記画像は、各ピクセルのカバレッジ値と分類とに基づいて生成される、ベクターグラフィックを処理するためのグラフィックプロセッサ。

Images