JPH08508353A

JPH08508353A - 多態グラフィック・デバイス

Info

Publication number: JPH08508353A
Application number: JP6517161A
Authority: JP
Inventors: ハリス，ジェリー，グレン
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-01-22
Filing date: 1994-01-06
Publication date: 1996-09-03
Anticipated expiration: 2018-11-05
Also published as: DE69404440D1; JP3462211B2; EP0673524A1; WO1994017495A1; CA2135521A1; EP0673524B1; US5394523A; AU6090794A

Abstract

(57)【要約】多態グラフィック・デバイスに関するもので、多態ピクセル・バッファを提供する方法および装置が開示されている。オブジェクト指向システム設計によれば、新しいメソッドと、データ型と、オペレーションをディジタル・ピクセル表現と処理システムに追加することを可能にする頑強で、拡張可能なピクセル仕様が得られる。

Description

【発明の詳細な説明】多態グラフィック・デバイス著作権所有表記本明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標局の特許ファイルまたは記録に記載されている特許文書または特許開示事項を第三者がファクシミリ複製することを妨げるものではないが、その他の場合は、一切の著作権を所有する権利を留保する。関連特許出願の相互参照本特許出願は、特許出願（発明者： Debra L．Orton，David B．Goldsmith， Christopher P．Moeller and Andrew G．Heninger、発明の名称：Object Oriented Fra mework System、 1992年12月23日出願、被譲渡人：Taligent）の関連出願であり、その開示事項を引用して本明細書の一部とする。技術分野本発明は、コンピュータ・グラフィックスに関し、特に、ピクセル・メモリの多態操作に関する。背景の技術コンピュータ・スクリーン上に描かれるコンピュータ・ピクチャやイメージは、コンピュータ・グラフィックスと呼ばれている。コンピュータ・グラフィック・システムは、グラフィックスをディジタルで内部にストアしている。ピクチャは、小さな画素、すなわち、ピクセルに分割されている。従って、コンピュータ・ピクチャまたはイメージは、実際には、個々の画素、すなわち、ピクセルの集合体である。内部、すなわち、コンピュータのディジタル世界では、各ピクセルには、ピクセルの属性を表すディジタル値の集合が割り当てられている。ピクセルの属性は、例えば、ピクセルのカラーと、明度と、ロケーションを記述することができる。従って、ピクセルのカラーか、明度か、あるいは、ロケーションを変更するには、その特定の属性のディジタル値を変更するだけでよい。慣用のコンピュータ・グラフィック・システムは、イメージか、ビットマップか、あるいはピクセル・マップとして知られているプリミティブを利用して、コンピュータ・イメージをピクセルの集合体として表す。これらのプリミティブはピクセル属性と、個々のディジタル値の２次元配列を表す。典型的には、このようなプリミティブは、ピクセル・データを指すポインタと、ピクセルサイズと、スキャンライン・サイズと、境界と、場合によっては、カラー・テーブルへの参照を含む「構造体」（データ構造）として表される。よく行われる仮定であるが、ピクセルは、RGB（red ，green，blue）カラーか、ルミナンスか、あるいは、カラーテーブルを指すインデックスを表すものとする。従って、プリミティブは２重の役割、すなわち、フレームバッファとしての役割と、フレーム記憶としての役割をサーブする。急成長のコンピュータ・グラフィック産業は、ピクセル表現に関する事実上の標準の上に成り立っている。この標準に当てはまらないイメージ形体は、全て、いやが応でも２流の市民権を得ることになる。しかし、慣用のグラフィックス・システムは拡張不可能である。これらのシステムは、通常、特定のクラスのイメージに対してオペレートする特定のアプリケーションの専用になっている。これは、急速に変化しているディジタル技術環境では認容できない。日々、新しいアプリケーションが出現し、この新しいアプリケーションを用いて、新しいイメージ型を新しい方法で処理し操作する必要がある。従って、拡張不可能なグラフィック仕様をもつグラフィックス・システムを使用するのは、先見の明がなく、早い話、時代後れなのである。グラフィカル・アプリケーションと、属性と、ピクセル・メモリに対する編成上の条件は、多様化しており拡大している。従って、専用化された単一目的のグラフィックス・システムは、現在のユーザ要求を満たすことができない。動的環境を提供する頑固なグラフィックシステムに対する要求があり、新しいアプリケーション、新しいイメージ・タイプを取り入れるため拡張することができ、しかも、新しいピクセル操作を備えた拡張可能なグラフィック仕様に対する要求がある。例えば、２つのアプリケーションが、同じセットのピクセル属性を必要とすることはまれである。３次元アプリケーションはｚ値（奥行き配列）をストアし、他方、アニメーションおよびペイント・アプリケーションはアルファ値をストアする。対話式マテリアル・エディタおよび３次元ペイント・システムは、３次元の陰影情報をストアするのに対し、ビデオ作成システムはYUV 4:2:2ピクセル配列を必要とすることができる。ハードウェアのクリッパはレイヤ（layer）タグをストアし、高度のシステムはヒット検出のためにオブジェクトIDをストアすることができる。さらに、カラー空間のようなグラフィカル属性は、PhotoYCC（商標）のような一定条件を蓄積している。等色（color matching）技法は依然として発展段階にあり、どの量子化カラー空間が可視スペクトルをピクセルとして記録するのに最良であるかはまだ明らかではない。従って、グラフィック世界では、データ・タイプは様々である。記憶編成技術も様々である。問題をさらに悪化させているのは、虞らく、アプリケーションが新しくなるたびに、異なるピクセル・メモリ編成が必要になることである。例えば、コンポーネント・インターリーブか、あるいは、”Chunky”スキャンライン配向は、Mach intosh（登録商標）ビデオ・カードで主流の編成になっている。しかし、コンポーネント・インターリーブ・バンク付きスイッチ・メモリが、小規模アドレス空間を有するホストを目標としたビデオ・カードではトレンドになっている。コンポーネント・プレーナ・タイルと、コンポーネント・インターリーブ・タイルは、プリプレス（prepress）およびエレクトロニック・ペイント・プログラムのトレンドになっている。しかし、複数のパスでプリントまたはスキャンする入出力デバイスでは、コンポーネント・プレーナ形式の方が好まれている。多重解像度またはピラミッド形式はリアルタイムの再サンプリングを必要とする静的イメージでは普通になっている。さらに、メモリを大量に消費するイメージは、種々の方法でコード化できる圧縮ピクセル・データとして表現することができる。グラフィック・アプリケーションと、データ・タイプと、ピクセル・メモリ操作は、多様になり、著しく成長している。周知の全てのアプリケーションを処理することができる多目的システムであって、まだ未知のアプリケーションを処理するために拡張可能な多目的システムに対する要求がある。単一プログラムで解決することは実用的でない。周知の要件をことごとく処理することはできるが、処理は莫大で、扱いが困難になるであろう。しかし、このようなプログラムがダウンサイズされている場合は、最早、全てのアプリケーションを扱うことができい。あるいはまた、機能を幾つかの小さなプログラムに分割することも可能である。望まなくても、この技法に従ったプログラムの数が多くなる。また、どの機能を所定のプログラムに置くかをどのように決めるのか。一人のユーザの要件をどのプログラムに収めておくのか。ユーザが二人のときはどうするのか。従って、多数のユーザの要求を満たす汎用プログラムに対する要求がある。しかも、個々のユーザがカスタマイズし、特定の要求を満たすように、汎用プログラムに付加することができる汎用プログラムに対する要求がある。発明の概要オブジェクト指向システムは、従来システムが遭遇する問題を解決するのに適している。オブジェクト指向設計によると、多数のユーザの要求は満たすが、個々のユーザが独自の要求に合うように汎用プログラムをカスタマイズし、強化できるようにした汎用プログラムが得られる。一般的に、オブジェクトは、複数のオペレーションにより特徴付けるとともに、これらのオペレーションの効果を覚えている状態により特徴付けることができる。オブジェクト指向オペレーティング・システムは、システムの明確に区別された部分か、あるいは、関数である複数のオブジェクトから構成されている。各オブジェクトは、そのオブジェクトに関する情報およびオブジェクトがその情報または自身に渡された情報について実行できる１組のオペレーションを含む。例えば、オブジェクトをMANと名づけることが可能である。オブジェクトMANに収められている情報、すなわち、その属性としては、年齢、アドレス、職業などがある。これらの属性はオブジェクトMANを記述している。また、オブジェクトは、そこに収められている情報について実行できる１組のオペレーションも含む。従って、MANは、あるオペレーションを実行して、その職業を医者から弁護士に変更することができる。オブジェクトは、互にメッセージを送信して対話する。これらのメッセージは、受信オブジェクトを刺激して、なんらかのアクション、すなわち、そのオブジェクトに含まれるオペレーションの１つ以上を実行する。本発明では、通信オブジェクトは多数存在する。オブジェクトの中には、共通の特性をもち、あるクラスにグループ化される。クラスとはテンプレートであり、同一クラスの他のメンバーと同じ情報とオペレーションを含む新しいオブジェクトを作成することができる。あるクラスから作成されたオブジェクトは、そのクラスのインスタンスと呼ばれる。クラスは、あるインスタンスに最初から入っているオペレーションと情報を定義している。これに対して、インスタンスの現在状態はそのインスタンスに対してパフォームされるオペレーションによって定義される。従って、所定のクラスの全てのインスタンスは、同等に作成される。これに対して、その後のオペレーションは、同じ親クラスから派生したその兄弟および姉妹と異なり、各インスタンスを一意のオブジェクトにすることができる。多態とは、刺激またはメッセージの送信側が、受信インスタンスのクラスを知っている必要がないことを意味する。どのオブジェクトがそのオペレーションをパフォームするか、そのオブジェクトがどのクラスに属しているかは関係なく、送信側は、受信側があるオペレーションをパフォームすることができることだけを知る必要がある。インスタンスはそのクラスの属性を継承する。従って、親クラスの属性を変更すると、種々インスタンスの属性も変更される。その変更はサブクラスにより継承される。新しいクラスは、既存クラスに対する変更を記述することにより作成することができる。新しいクラスはそのクラスの属性を継承するので、ユーザは新しいクラスに一意の何かを追加することができる。従って、新しいクラスまたはオブジェクトがその親クラスまたはオブジェクトとどのように異なるかを記述するだけで、クラスを定義することができる。継承階層において、別のクラスの下位にあるクラスは、親クラスの子孫または子供と呼ばれる。子孫または子供は親クラスの下位にあり、親クラスから継承する多態環境では、受信オブジェクトは、刺激メッセージを受信したとき、どのオペレーションをパフォームするかを判断する責任がある。オペレーションとは、あるクラス内のオブジェクトに適用できるか、あるいはオブジェクトにより適用できる関数または変換のことである。従って、刺激オブジェクトは受信オブジェクトについてほとんどなにも知っている必要がないので、オペレーションのパフォームが単純化される。各オブジェクトは、自身のオペレーションをどのようにパフォームするか、自身がパフォームできないオペレーションをパフォームするために誰をコールすべきかを知っているだけでよい。同一オペレーションが多数の異なるクラスに適用されるとき、それは多態オペレーションである。同一オペレーションはクラスが異なるごとに、異なる形体になっている。メソッドとは、所定のクラスの特定のオペレーションを実装したものである。例えば、Documentというクラスには、Readと呼ばれるオペレーションを含むことができる。Documentのデータ型によって、例えば、ASCIIであるか、B INARYであるかによって、Readオペレーションをパフォームするために異なるメソッドが使用できる。従って、どちらのメソッドも、論理的には同一タスクRead をパフォームするので、同一名前で呼ばれている。しかし、実際には、これらはパフォーム可能コードの異なる部分で実装された異なるメソッドである。オペレーションReadは幾つかのクラスに属するメソッドをもつことができるが、これは、同数で同一型の引数をもっている。つまり、そのシグニチャは同一のままになっている。従って、本発明の目的は、オブジェクト指向設計として、ジェネリックな汎用グラフィックス・ユーティリティを提供することにあり、各ユーザが独自の、可能ならば、要件の一意の組み合わせを満たすように、この汎用ユーティリティの特定バージョンまたはインスタンス化したものをカスタマイズすることにより多くのユーザの要求を満たすことにある。ユーザ全員が使用することができるジェネリックなツールをユーザは要求している。しかし、そのツールは、そのツールにより、ユーザが汎用プログラムをカスタマイズして、ユーザ独自の特定の要求を満たすようにできるものである。本発明によれば、抽象基本クラスTPixelBufferが用意されている。これは、メモリにピクセルとしてストアされるピクセル属性を矩形配列で表したものである。上に挙げたアプリケーションは、いずれも、特定のアプリケーションがユーザまたはクライアントとして必要とする特定の属性によりインスタンス化されたTPixel Bufferサブクラスにより、その要求が満たされる。サブクラスにより、ユーザは、独自の要求を満たすように汎用プログラムを調整（tailor）することができる。また、量子化トレードオフと、ピクセル属性のセットと、ピクセル・メモリ編成を、それぞれ、異なったものにすることができる。各サブクラスは独自のピクセル・データ・クラスをどのように割り振り、管理し、ストリーム化し、変換し、修正するかの知識をカプセル化することができる。本発明によれば、全てのサブシステムは、多態アクセス機構を使用するので、ユーザは、レンダリングまたはコピーすることができるPixelBuffer型を拡張することができる。幸いなことに、種々の型のPixelBufferには共通点が幾つかある。明らかに、多くのクライアントの要求を満たすために必要な基本関数またはカテゴリは８つある。クライアントは、大多数が、多態管理を必要とし、離散空間と連続空間との関係を指定する能力を望んでいる。クライアントは正確なカラー再現により使用するために、カラー機能を特徴づけようとしている。クライアントはピクセル・メモリ変更のための望んでいる機構は、GetとSetPixel、スキャン変換を行うクライアント用に調整されたSpecialized”blitloop”と、BitBltと、CopyImage の形式のものである。クライアントは、クライアントが与えた属性の組合せから作られたキーに一致する4bの変種をユーザに与える機構を望んでいる。クライアントは、特徴またはストアされた属性に関して多態照会を行うことができることを望んでいる。クライアントはクライアントがPixelBufferキャッシュを、多態に作成し、維持し、照会できるような機構を望んでいる。最後に、クライアントは、クライアントが相互に関連をもつバックバッファを多態に作成し、維持できるような機構を望んでいる。従って、本発明の目的は、多態ピクセル管理を可能にする方法と装置を提供することにある。本発明の別の目的は、ユーザが離散空間と連続空間との関係を指定できるようにする方法と装置を提供することにある。本発明の他の目的は、ユーザが正確なカラー再現で使用するためにカラー機能を特徴づけることができる方法と装置を提供することにある。本発明の別の目的は、ピクセル・メモリ変更の機構をGetおよびSetPixelと、スキャン変換を行うクライアント用に調整されたSpecialized”blitloops”と、BitBltと、CopyIm ageの形で提供する方法と装置を提供することである。本発明の他の目的は、クライアントが与えた属性の組合せから作られたキーに一致する4bの変種をクライアントに与える機構を提供する方法と装置を提供することである。本発明の別の目的は、特徴またはストアされた属性に関して多態照会を行うことを可能にする方法と装置を提供することである。本発明の他の目的は、クライアントがPixelBufferキャッシュを多態に作成し、維持し、照会することを可能にする機構を提供する方法と装置を提供することである。本発明の他の目的は、特徴またはストアされた属性に関して多態照会を行うことを可能にする方法と装置を提供することである。本発明の別の目的は、クライアントが相互に関連をもつバックバッファを多態に作成し、維持することを可能にする機構を提供する方法と装置を提供することである。本発明の他の目的は、ピクセル・メモリを多態にアクセスし、操作することを可能にする方法と装置を提供することにある。本発明の別の目的は、新しいイメージ型をサポートする拡張可能なディジタル・グラフィックス環境を提供する方法と装置を提供することにある。本発明の別の目的は新しい転送モードか、新しいTPaintか、あるいは新しいディザリング手法に対するレンダリング・サポートを追加するように拡張可能である、任意のイメージ型をサポートするディジタル・グラフィックス環境を提供する方法と装置を提供することにある。本発明の別の目的は、イメージ・エディタと、時間的／空間的イメージ圧縮手法と、イメージ収集デバイス・ドライバと、イメージ出力デバイス・ドライバのピクセル操作要求を満たすために汎用的に解決することができる拡張可能ディジタル・グラフィックス環境を提供する方法と装置を提供することにある。本発明の他の目的は、幾何学的イメージ変換アクションを変更することができる拡張可能ディジタル・グラフィックス環境を提供する方法と装置を提供することにある。本発明の別の目的は、高速化イメージ変換または”blitloops”を実装することができる拡張可能なディジタル・グラフィックス環境を提供する方法と装置を提供することにある。図面の簡単な説明第１図は本発明による好ましいハードウェア環境の例を示す図である。第２図は本発明のためにMCollectibleクラスから派生した好ましいサブクラス TPixelBufferの例を示す図である。第３図は本発明による好ましい座標系の例を示す図である。第４図は本発明による好ましいアクティブ境界の例を示す図である。第５図は本発明による好ましい参照解像度の例を示す図である。第６図は本発明による好ましい参照配向の例を示す図である。第７図は本発明による連続座標平面と離散座標平面との間の好ましい変換の例を示す図である。第８図は本発明による好ましい比色特徴づけの例を示す図である。第９図は本発明による好ましいTColorProfileの例を示す図である。第10図は本発明による好ましい32ビットARGBの例を示す図である。第11図は本発明によるPaintBlockの好ましい使用例を示す図である。第12図は本発明によるPaintBufferedSpanと、FlushBufferedSpansと、PaintSp ansの好ましい使用例を示す図である。第13図は本発明によるPaintBufferedSpanと、不透明スパン上のFlushBuffered Spansと、CompositeSpan好ましい使用例を示す図である。第14図は本発明による不透明ピクセル上のPaintBlockおよび既存ピクセルとブレンドされたピクセル上のCompositeSpanの好ましい使用例を示す図である。第15図は本発明による不透明ピクセルに対するPaintBufferedSpan、FlushBuff eredSpansの好ましい使用例を示す図である。第16図は本発明による好ましいTHairLinePainterの例を示す図である。第17図は本発明による好ましいTAntialiasedHairLinePainterの例を示す図である。第18図は本発明の好ましいアウトライングリフおよびビットマップグリフの例を示す図である。第19図は本発明の好ましいTGlyphPainterの例を示す図である。第20図は本発明の好ましいTAntialisedGlyphPainterの例を示す図である。第21図は本発明による好ましいBitBlt（ビット・ブロック−転送）の例を示す図である。第22図は本発明によるPixelStreamReaderおよび／またはPixelStreamWriterを使用した好ましい変換の例を示す図である。第23図は本発明によるStreamPixelBlockの好ましい使用例を示す図である。第24図は本発明によるStreamRectilinearRotatedPixelBlockの好ましい使用例を示す図である。第25図は本発明によるStreamScaledPixelBlockの好ましい使用例を示す図である。第26図は本発明によるStreamAndFilterScaledPixelBlockの好ましい使用例を示す図である。第27図は本発明によるStreamPixelIntoConvexPolygonの好ましい使用例を示す図である。第28図は本発明によるStreamAndFilterPixelIntoConvexPolygonの好ましい使用例を示す図である。第29図は本発明による好ましい多態照会の例を示す図である。第30図は本発明によるPixelBufferクラス階層の例を示す図である。第31図は本発明によるPixe1Bufferコンポーネントの例とその使用例を示す図である。第32図は本発明による好ましいTComponentInterleavedPixelBufferの例を示す図である。第33図本発明による好ましいTA8R8G8BPixelBufferの例を示す図である。第34図は本発明による好ましいTAlpha8GrayPixelBufferの例を示す図である。第35図は本発明による好ましいTIndexdPixelBufferの例を示す図である。第36図は本発明による好ましいTClut2PixelBufferの例を示す図である。第37図は本発明による好ましいTClut4PixelBufferの例を示す図である。第38図は本発明による好ましいTClut8PixelBufferの例を示す図である。第39図は本発明による好ましいTGlay4PixelBufferの例を示す図である。第40図は本発明による好ましいTGlay8PixelBufferの例を示す図である。第41図は本発明による好ましいTAlpha8PixelBufferの例を示す図である。第42図は本発明による好ましい TBitmappedPixelBufferの例を示す図である。第43図は本発明による好ましい THalftonedBitmappedPixelBufferの例を示す図である。第44図は本発明による好ましいTAlphalPixelBufferの例を示す図である。第45図は本発明による好ましいTB8R8G8B8PixelBufferの例を示す図である。第46図は本発明による好ましいTZ32PixelBufferの例を示す図である。第47図は本発明による好ましいTA8R8G8B8Z32PixelBufferの例を示す図である。第48図は本発明による好ましいTA1R5TR5G5B5PixelBufferの例を示す図である。第49図は本発明による好ましいTB1R5G5BPixelBufferの例を示す図である。第50図は本発明による好ましいTR8G8B8PixelBufferの例を示す図である。第51図は本発明による好ましいTGImageの例を示す図である。以下、図面を参照して以下の詳細説明と例を考慮にいれて、本発明について詳しく説明するが、これらは本発明の方法と装置を例示したにすぎないものである。本発明の好ましい実施例の詳細説明本発明は、オペレーティング・システムよりなるオブジェクト指向ソフトウェア・プラツトフォームと開発環境の下で作成されたオブジェクト群から構成されている。好ましいハードウェア環境第１図に示すように、本発明は、IBM社のPS/2またはApple社のMacintoshコンピュータのようなパーソナル・コンピュータ上に置かれたオペレーティング・システムの下で実施されることが好ましい。代表的なハードウェア環境を第１図に示す。第１図は従来のマイクロプロセツサのようなCPU(central processingunit )110と、システム・バス112を介して相互に接続された複数の他のユニットとを有する、本発明によるワークステーションの代表的なハードウェア構成を示す。第１図のワークステーションは、RAM(randomaccess memory)114、ROM(read only memory)116、およびディスク・ユニット120のような周辺デバイスをバスに接続するためのI/0アダプタ118と、キーボード124、マウス126、スピーカ128、マイクロホン132、および／またはタッチ・スクリーン・デバイス（図示せず）のような他のユーザ・インタフェースをバスに接続するためのユーザ・インタフェース・アダプタ122と、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ134と、バスをディスプレイデバイス138に接続するためのディスプレイアダプタ136とを備えている。ワークステーションには、IBM 0S/2オペレーティング・システムやApple 社のSystem/7オペレーティング・システムなどのオペレーティング・システムが置かれている。多態管理（polymorphic management）第２図を説明する。好ましい実施例では、多態管理されるオブジェクトは、共通の特性をもち、これらの特性は、好ましくは、親クラスであるMCollectibleから派生したサブクラスに入っている。サブクラスは、派生した親クラスの属性を継承する。好ましい実施例では、サブクラスはMCollectible 140から派生する。これらの派生サブクラスにおいて作成されたオブジェクトは、属性をMCollectib le 140から継承する。好ましい実施例では、派生サブクラスTPixe1Buffer 142は、ユーザによって追加されたMCollectible 140 の属性を、ユーザが追加できる属性とともに継承する。従って、ユーザはMCollectibleから派生したサブクラスにおいて作成されたオブジェクトをカスタマイズして、そのオブジェクトをユーザ独自の要求に合わせることができる。オブジェクトは要求が変化したとき、変更または作成することができる。 MCollectible 140をサブクラス化することにより、セーブと、リストアと、クローニングと、収集、比較、割当てのような機能は、多態オペレートすることができる。好ましい実施例では、MCollectibleから生成されたサブクラスであるサブクラスTPixelBuffer 142は、オブジェクトがTPixel Bufferから派生したサブクラスにおいて作成されるように、この概念を拡張したものである。従って、好ましい実施例では、PixelBufferの内容のセーブは、MCo llectibleメソッドFlattenPtrにより行われ、リストアはMCollectibleメソッドR esurrectPtrにより行われ、クローニングはMCollectibleのCloneメソッドにより行われる。=operatorと==operatorは、割当ておよび比較オペレーションを行うためのものである。座標規則次に、第３図に示すように、好ましい実施例では、PixelBufferは各座標系の同じ仕様およびその座標系と連続座標系との関係を共用している。好ましい実施例では、PixelBufferは整数サイズ化（integral-sized）されたピクセル配列になっているので、ピクセルは整数ロケーションに存在すると共に、PixelBuffer のエリアは整数矩形によって記述される。第３図に示すように、PixelBuffer 14 6の起点144はイメージの左上隅であり、正の座標148は右方向および／または下方向に伸びている。好ましくは、座標は無限に薄く、ピクセル140間に位置している。好ましくは、ピクセルのロケーションはその左上隅の座標によって指定される。直線方向のエリアはTLongRectクラスとして記述される。ピクセルが座標平面上の点と点の間にあるとすると、TLongRect内に含まれる両端ピクセルのロケーションは、第３図に示すように、（fleft,fTop）152および（fRight-1,fBottom- 1）である。アクテイブ境界（active boundary）第４図を説明する。好ましい実施例では、Pixe1Buffersは、それぞれのピクセル・メモリ配列のどの部分がアクティブであるかを指定する。この境界矩形156 はTLongRectとして定義され、DeviceBoundsと呼ばれるのが好ましい。クライアントはこの境界矩形156内に存在するピクセルに対してリードライトを行うのが好ましい。PixelBuffersは、見かけ上、ピクセル記憶のために、大きさが正確になっているが、種々のサブクラスは、実際に、空間的および時間的にコード化されるピクセル・メモリを実装することができる。GetDeviceBoundsは、DeviceBou ndsのゲッタである。すなわち、GetDeviceBoundsからは、 PixelBufferの左上隅158と右下隅160の値が返される。参照解像度（reference resolution）第５図を説明する。好ましい実施例では、PixelBufferピクセルは、単位当たりのピクセル数の関係として指定できるある種の測定可能エリアを表している。デフォルトの測定単位は点で指定されるので、一貫性が維持されている。多くのハードウェア・デバイスは、非正方形ピクセルになっているので、好ましくは、垂直方向164と水平方向166の両方の仕様が用意されている。好ましい実施例では、これらの数は単位インチ当たりの垂直方向と水平方向のピクセル数であり、これは小数点以下の精度をもつ数と値として指定される。GetVerticalDPIとGetHor izontalDPIはゲッタである。SetVerticalDPIとSetHorizontalDPIはセッタである。この値はクライアントのための参照情報であり、好ましくは、PixelBufferによって保存される。参照配向（reference orientation）第６図を説明する。本発明の好ましい実施例では、ピクセル配列は直線的配向を持つことができ、これは、好ましくは、それが表示または編集されるとき考慮される。第６図に示すように、それぞれ、中心を軸にした回転および／または垂直軸を中心とした鏡像（ミラー）の回転の結果であるピクセル配列の配向は、好ましくは、８つまで可能である。好ましくは、ピクセル配列の配向は８つの選択の中から指定され、配向（Orientation）と名づけられている。Get0rientationはゲッタであり、SetOrie ntationはセッタである。これはクライアントのための参照情報であり、好ましくは、PixelBufferによって保存されている。第６図に示すように、正しく表示される166配向を表す可能な８つの値は、無回転168と、鏡像170と、90度回転172と、鏡像90度回転174と、180度回転176と、鏡像180度回転178と、270度回転180と、鏡像270度回転182である。連続Ｇ座標から離散ピクセルへ第７図を説明する。好ましい実施例では、PixelBufferの連続座標平面と離散座標平面との間の正しい変換を作成するために使用されるPixelBufferの属性は、好ましくは４つある。好ましくは、CreateDeviceTransformは、正しい変換マツピングと共にTGrafMatrixを作成するメソッドである。好ましくは、CreateDev iceTranformの唯一の引数は、連続空間における起点であるTGPointである。好ましい実施例では、座標をこのマトリックスを通して連続空間へマッピングし、連続空間からピクセル空間へマッピングするのはクライアントの責任になっている。比色特徴づけ（colorimetric characterization）好ましい実施例では、PixelBuffersは、PixelBuffersが作成できるカラーとある種の絶対測定基準との間の関係を指定できるのが好ましい。第８図を説明する。TColorProfileオブジェクト184は、この関係を指定する設計になっている。好ましくは、このオブジェクトは８つのTxyYColorsを含み、それぞれ、PixelBuffe rにより表されるハードウェア・デバイスの出力または入力から測定したデータ・ポイントを記録する。これらのカラーは、PixelBufferを再現できる全てのカラーを包み込むCIEカラー立体の頂点を形成する。測定のうちの２つは、PixelBufferの白点と黒点で行われる。残りの６つのカラーは、このPixelBufferで再現できる最大飽和シアンと、緑と、黄と、赤と、マゼンタと、青を含む。好ましくは、PixelBufferの非線形応答特性も記録される。好ましい実施例では、この情報は７つの色調再現曲線（Tonal Reproduction Curve）またはTRC 186で獲得される。好ましくは、このTRCグループは、白と、シアンと、緑と、黄と、赤と、マゼンタと、青から黒点までの256個の一様な入力ステップからの応答を測定する。好ましくは、全てのPixelBufferは第９図に示すように、TColorProfile 184への参照を含む。好ましい実施例では、CIE空間にピクセルをストアするPixelBuff erは、TColorProfile 184を有する。例えば、次に、CIE空間に基づくPixelBuffe rの場合の等色シナリオについて検討する。純粋な比色はポイント・プロセスであるので、プロフィールを必要としないのが好ましい。ソース・プロフィールで定義された３次元カラーからデスティネーションのカラー立体へのマッピングまたは態（morph）を作成する知覚的等色は、プロフィールをもっているのが好ましい。好ましい実施例では、PixelBufferのカラー・プロフィール184は、SetColorPr ofileメソッドによりセットされ、GetColorProfileメソッドにより取り出される。記憶と効率性を考慮して、これらのTColorProfile 184は参照カウントをとることにより共用される。実際の等色プロセスの詳細については、次のセクションで説明する。ピクセル・メモリの変更エンドユーザは、グラフィック・システムに対してハイレベルのパフォーマンスを期待している。この期待に応えるためには、レンダリングまたはスキャン変換プロセスが、ピクセルメモリを非常に特殊な方法で変更できることが要求される。好ましい実施例では、これらのプロセスは共用になっている。PixelBuffer では、複数のタスクが同時に描画してそこに入れたり、そこから読み出したりすることがあるので、これらの機構はマルチタスクセーフ（safe）であるのが好ましい。すなわち、ピクセル・プロセスが秩序正しく共用される。 GetPixelとSetPixel 好ましい実施例では、SetPixelとGetPixelルーチンを使用してレンダリングするのが特に効率的でない場合であっても、これらが有用であることが実証されている。好ましい使い方の１つは、他のアクセス機構のデフォルト・バージョンをサポートすることである。TPixelBuffer 142には、好ましくは、これらのルーチンを頼りとする基本アクセス機構のデフォルトバージョンが用意されている。これらは多態オペレーションであり、第10図に示すように、32ビットARGB値186を受け取り、あるいは返す。サブクラスは、好ましくは、GetPixelとSetPixelメソッドをオーバライドする。しかし、eyedropperのようなツールでは、パフォーマンスは充分である。好ましくは、GetCIElabPixelとSetCIElabPixelメソッドはロスのないカラーのセットとゲットを行うために用意されている。オブジェクト・ベースの”Blitloops” 現在、市販されているグラフィックス・システムには、レンダリングされたプリミティブの可視的表示を、ユーザが指定するときに使用するボキャブラリが用意されているのが普通である。本発明の方法および装置とは異なり、これらのボキャブラリは拡張不可能であるのが典型的である。これらには、特性、例えば、カラーと、パターンと、転送モードと、等色と、ディザリングの指定に対するサポートが含まれる。これらの特性は３つの目的に使用される。すなわち、あるピクセルでの所望カラーの指定と、そのピクセルと現在のデスティネーション・ピクセルとの間のやりとりの指定と、時間および／または品質とのトレードオフとが与えられているとき、優先するものを述べたヒントの指定である。これらのプロパティを一緒に使用すると、ある程度の自由度が得られる。好ましい実施例では、あるPixelBufferでは、これらの属性で指定された状態にピクセルをセットするサブルーチンが存在する。これらのサブルーチンは一般に”bl itloops”と呼ばれている。各自由度ごとに一定の選択項目がセットで用意されているので、従来のグラフィック・システムでは、ネストされたテストによるか、あるいは、blitloopsを指すポインタ配列にインデックスすることによって、該当のblitloopを選択する。好ましい実施例では、クライアントも、TGrafBundleとTPortBundleの設定可能な属性により、これらの自由度にアクセスすることができる。これらのblitloop sは２つの特性を有するのが好ましい。異なるセマンチックを有するblitloopsを利用する異なるレンダリング・パイプラインと、異なるアピアランス属性を得るために異なるアルゴリズムを使用するblitloopである。レンダリング・パイプラインの詳しい説明は、GrafDeviceと、３次元レンダリング・パイプラインを参照されたい。これらは、引用によって本明細書の一部とする。クライアントには、必要とするアクセス機構ごとに個々のPixelBufferメソッドを用意することも可能であるが、この解決手法にはいくつかの問題がある。第１は、異なるアルゴリズムを得るために、異種のメソッドを作成する必要があることである。本発明の方法と装置によれば、各属性および自由度が個々のメソッドを際限なく規律することができる。もう１つの設計上の考慮事項は機構をマルチタスクから安全にし、効率化することである。このことは、あるメソッド・コールから次のメソッド・コールまでの間にキャッシュできる情報がタスクセーフでキャッシュされることを意味する。従って、好ましい実施例では、PixelBuffer内の個々のメソッドは”blitloop ”オブジェクトを作成することができる。これらのオブジェクトは、ペインタ（ painter）と総称される。好ましい実施例では、クライアントがピクセル・メモリを変更するときの特殊な方法ごとに、抽象基本・ペインタ・クラスがPixelBuf fer内の対応するCreateメソッドを使用して作成される。好ましくは、特定のCre ateメソッドから戻された全てのペインタは、特定のペインタ基本クラスのサブクラスである。どのペインタ・サブクラスを返すかの選択は、クライアントの希望のアルゴリズムによって駆動されるのが好ましい。ペインタ・サブクラス選択プロセスは、別のセクションで詳しく説明する予定である。好ましくは、複数のレンダリング・オペレーションで記憶割振りを行う必要があるために起こるスピード／パフォーマンス・コストを分散化するために、キャッシング・ストラテジが採用されている。好ましい実施例では、クライアントの特殊な要求を満たすために５つの基本クラスが用意されている。すなわち、TSpanPainterと、THairLinePainterと、TAnt iAliasedHairLinePainterと、TGlyphPainterと、BitBltである。 TSpanPainter スキャン変換プリミティブを塗りつぶし、フレーム化することは、グラフィックス・システムの基本オペレーションである。好ましい実施例では、この種のクライアントをサポートするため、４種類の機構が用意されている。これらのオペレーションはピクセル・メモリ変更と併用できるので、好ましくは、これらは同じペインタ基本クラスのメソッドになっている。好ましい実施例では、これらのメソッドとは、1）「スパン」の塗りつぶし、2）矩形ブロックの塗りつぶし、3 ）ブレンド・スパンの塗りつぶし、4）隣接エッジからのカラーとブレンドされた個々のピクセルの塗りつぶしである。TSpanPainterオブジェクトはTPixelBuffersCreateSpanPainterメソッドにより取得されるのが好ましい。ラスタ化の期間、多くの２次元プリミティブはエッジ・リストに挿入されるのが好ましい。好ましい実施例では、このカテゴリに属するクライアントはTSimpl eFillEdgeEngineと、 TSimpleFillAndFrameEdgeEngineパイプライン・オブジェクトである。スキャン変換は、エッジ・リストを初めから終わりまで調べ、塗りつぶすべき「スパン」を生成することにより行われるのが好ましい。好ましい実施例では、スパンとは、ある行の列（カラム）のハーフオープン・インタバル（half-open interval）のことである。オーバヘッド・コストを軽減するために、スパンはグループでクライアントのスタック上に蓄積されるのが好ましい。これは抽象クラスから継承した複数のインライン・メソッドにより行われるのが好ましい。好ましい実施例では、クライアントは、PaintBufferedSpanをコールすることにより、スパンを各自のローカル・スタックに追加する。好ましい実施例では、このメソッドは、ローカル・スパン・スタックが大きくなり過ぎると、ローカル・スパン・スタックをフラッシュする。クライアントはレンダリングを終えたとき、FlushBufferedSpansをコールしてスタックに残っているスパンをクリアするのが好ましい。クライアントがスパンをバッファに置くことを望まない場合は、PaintSpansメソッドを使用することができる。PaintSpansメソッドは、この反復を制御するカウントとともに、スパン引数に入れて渡されたスキャンライン・スパンの配列を反復する。矩形ピクセル・エリアを効率よく塗りつぶすことは好ましい実施例で用意されているもう１つの機構である。好ましくは、この機構を利用するクライアントは TRectilinearFillEdgeEngine 188と、TRectilinearFillAndFrameEdgeEngineと、 TRectilinearAntialiasedFillEngineと、TRectilinearAntialiasedFillAndFrame EdgeEngineである。好ましい実施例では、このメソッドはPaintBlockと呼ばれ、エリアは列と、開始行と、行カウントのハーフオープン範囲として指定される。スキャン変換がアンチエリアスされている場合、本発明によれば、クライアントは、最終ピクセルの透明性を変更すると、サブピクセルが位置付けまたはカバレッジされたとの印象を得ることができるのが好ましい。好ましい実施例では、このカテゴリに属するクライアントはTAntialiasedFillEdgeEngineと、TAntiali asedFillAndFrameEdgeEngineと、TRectilinearAntialiasedFillEdgeEngineと、T RectininearAntialiasedFillAndFrameEdgeEngineパイプライン・オブジェクトである。この種のピクセル・メモリ変更はCompositeSpanメソッドにより行われる。その引数はスパンおよび加重値の配列を指すポインタである。全体がカバーされたピクセルはPaintSpansまたはPaintBlockメソッドにより塗りつぶされるのが好ましい。好ましい実施例では、最後のピクセル変更メソッドは、異なるペインタを使用するアンチエリアスされた隣接エッジをペイントするときの通路となる。このようなことは、塗りつぶされフレーム化されたプリミティブをレンダリングするとき起こる。このような状況に置かれるクラアイントは、TAntialiasedFillAndFra meEdgeEngineと、TRectilinearAntialiasedFillAndFrameEdgeEngineパイプライン・オブジェクトである。好ましい実施例では、メソッドPaintAbuttingEdgePai ntの引数は、TLongPointとブレンド重み（blending weight）である。ブレンド重みは、用意されているTColorと、このTSpanPainterがそのロケーションで必要とするカラーとの間でブレンドを行うために使用される。隣接エッジのカラーは、SetAbuttingEdgeColorメソッドによりセットされるのが好ましい。ブレンドを容易にするために、２つの追加メソッドが用意されているのが好ましい。クライアントは、ペインタが、あるロケーションでどのカラーを必要としているのかを照会する。このメソッドはGetDesiredColorAtであり、これはTColorとTLongPtを引数として使用する。GetDesiredColorは、ペインタがTLongPtロケーションで必要としているカラーを、TColorに入れて返す。好ましい実施例では、クライアントは隣接エッジを見つけると、一方のペインタGetDesiredColorを使用し、必要とするカラーを他方のペインタGetAbuttingEdgeColorメソッドに渡してから、Pa intAbuttingEdgepixelを使用する。最後のメソッドにより、ペインタが１つのべた（solid）カラーとIsShadingCo nstantで塗りつぶしている隣接エッジに対して、この対話を効率よく行なうことができる。IsShadingConstantがTRUEのとき、GetDesiredColorAt/SetAbuttingEd geColorコンボを一度だけ実行するだけでよい。これらのメソッドがないと、現れた内部シーム（internal seam）を、塗りつぶされフレーム化されたプリミティブで正しくアンチエリアスすることは不可能である。好ましい実施例では、クライアントの要求を満たすために、メソッドはペインタとして１つにパッケージ化されている。パッケージ化すると、複数のユーザの要求を満たすことができる。メソッドは次のような種々のクライアント要求に応じるように１つにパッケージ化されているのが好ましい。すなわち、1）TRectil inearFillEdgeengineのように、エリアスされたピクセル・ブロックを塗りつぶすクライアントと、2）TSimpleFillEdgeEngi neのように、スキャン変換プリミティブからのエリアスされたスパンを塗りつぶすクライアントと、3）アンチエリアスされたスキャン変換プリミティブを塗りつぶすクライアントと、4）TRectilinearAntialiasedFillEdgeEngineのように、アンチエリアスされた位置付けブロックを塗りつぶすクライアントと、5）TAnti aliasedFillAndFrameEdgeEngineのように、２つのペインタからのアンチエリアスされた隣接エッジを含んでいるピクセルを塗りつぶすクライアントである。次に、第12図を説明する。最初のクライアントはPaintBlock 190を排他的に使用することができるのが好ましい。２番目のクライアントはPaintBufferedSpan 200と、第12図に示すように、内部的にPaintSpans 204メソッドをコールするFlu shBufferedSpans 202を使用する。第13図に示すように、３番目のクライアントは、不透明スパンではPaintBufferedSpan 206とFlushBufferedSpans 208を使用し、既存のピクセルとブレンドされたピクセルではCompositeSpan 210を使用することができる。第14図を説明する。４番目のクライアントは不透明ピクセルではPaintBlock 2 10を使用し、既存のピクセルとブレンドする必要のあるピクセルでは、 CompositeSpan 212を使用することができる。第15図を説明する。５番目のクライアントのケースはもっと複雑である。５番目のクライアントは不透明ピクセルに対して該当のスパン・ペインタのPaintBuf feredSpan 214とFlushBufferedSpans 216メソッドを使用することができる。フレームの外側エッジは、フレームスパンペインタのCompositeSpan 218を通してレンダリングされるのが好ましい。フレームと、塗りつぶされたエッジとの間の内部シームは、SetAbuttingEdgeColorAt 222が、フレーム化スパンペインタのGe tDesiredColor 224メソッドから返されたカラーと共にコールされた後だけ、塗りつぶしスパンペインタのPaintAbuttingEdgePixel 220メソッドによりレンダリングされるのが好ましい。 THairlinePainter 第16図を説明する。好ましい実施例では、THairlineFrameVertexEngineのようなクライアントは、細線または微細線（hairline）を描くために特殊な機構を利用する。微細線はピクセルバッファの最精細解像度で描かれる線と定義されている。ラスタ・デバイスでは、これは単一ピクセル幅の線である。微細線が、ラインと、ポリライン（polyline）と、枠付き多角形と、曲線と、３次元ワイヤフレームの結果としてレンダリングされ、Hairline属性をTGrafBundleでオンにしてドローイングされる。微細線の終端点226,228は、小数点以下の精度で指定されるのが好ましい。TGr afBundleはTPixelBuffersCreateHairlinePainterメソッドにより取得される。サブクラスはPaintHairlineをオーバライドするのが好ましい。好ましい実施例では、PaintHairlineは、例えば、DVIイメージやフラットスクリーン技術に見られる非正方形アスペクト比を考慮する。LongRectに対してクリップする、オーバロードされたPaintHairlineメソッドが用意されているのが好ましい。 TAntialiasedHairlinePainter 第17図を説明する。好ましい実施例では、 TAntialiasedHairlineFrameVertexEngineのようなクライアントは、アンチエリアスされた微細線をドローイングするには特殊な機構を必要とする。アンチエリアスされた微細線とは、サブピクセルの位置付けとカバレッジを変換している間にレンダリングできる最も細い線である。これらは、普通、３ピクセル幅である。微細線の終端点は小数点以下の精度で指定されるのが好ましい。好ましい実施例では、このオブジェクトは TPixelBuffersCreateAntialiasedHairlinePainterメソッドにより取得される。サブクラスはPaintAntiAliasedHairlineとSetFilterPixelをオーバライドするのが好ましい。PaintAntiAliasedHairlineと、SetFilterPixelは、例えば、DVIイメージやフラットスクリーン技術に見られる非正方形アスペクト比を考慮するのが好ましい。好ましい実施例では、TLongRectに対してクリップする、オーバロードされたPaintAntiAliasedHairlineメソッドが用意されている。 TGlyphPainter 第18図を説明する。好ましい実施例では、グリフ（glyph）は高速化されている。グリフはハイレベル輪郭記述からなっている。好ましい実施例では、TFrame buffer::RenderGlyphRunのようなクライアントは、任意のTFontのビットマップまたはグレースケール・ピクセルマップをTFontServerに要求する。TFontServer は、グリフのハイレベル輪郭描写を取り出し、ビットマップまたはグレースケール・ピクセルマップを作るように該当のTFontHandlerに要求するのが好ましい。好ましい実施例では、TFramebufferが結果を得た後、ビットマップまたはピクセルマップを合成してTPixelBufferに置くための効率のよいメソッドが用意されている。ビットマップの場合は、好ましいオブジェクトはTGlyphPain terである。第19図を説明する。好ましい実施例では、TGlyphPainterはビットマップ形体のグリフをレンダリングするために必要なメソッドを含む。これらのビットマップは不透明マットの働きをし、ユーザが与えたペイントがこれを通して合成されるのが好ましい。これらのメソッドの最初のものは、デスティネーション起点を dstx引数とdsty引数に入れて受け取るPaintSmallGlyphであり、これはTGlyphPix mapと同じである。このメソッドはクリップされていないグリフに対するものである。次のメソッドはオーバロードされたPaintSmallGlyphである。好ましい実施例では、PaintSmallGlyphは、デスティネーションの矩形クリップ・エリアである別の引数を受け取る。このオブジェクトはTPixelBuffersCreateBitmapGlyph Painterメソッドにより取得される。サブクラスは両方のPaintSmallGlyph メソッドをオーバライドするのが好ましい。代替実施例では、グリフはバッチにされて、PaintSmallGlyphではなく、PaintSmallGlyp hs メソッドへ送られる。 TAntialiasedGlyphPainter 第20図を説明する。好ましい実施例のグリフには、２つの低レベル表現がある。一方はビットマップであり、他方はグレースケール・ピクセルマップである。グレースケール・ピクセルマップはグリフのサブピクセル位置付けとカバレッジを伝達するために必要な透明情報を含んでいる。これらのピクセルマップは半透明マットの働きをし、ユーザが与えたペイントはこれを通して合成される。好ましい実施例では、TAntialiasedGlyphPainterはグレースケール・ピクセルマップをレンダリングするためのメソッドを含む。これらのメソッドは、グレースケール・ピクセルマップを扱う点を除けば、TG lyphPainterに入っているものと同じであるのが好ましい。好ましい実施例では、このオブジェクトはTPixelBuffersCreateGrayscaleGlyphPainterメソッドにより取得される。サブクラスは両方のCompositeSmallGlyph メソッドをオーバライドするのが好ましい。好ましい実施例では、グリフのサブピクセル位置付けのタスクは、フォント・サーバーの責任である。代替実施例では、グリフはバッチにして、CompositeSmallGlyphではなく、CompositesmallGlyphsメソッドへ送ることができる。さらに別の代替実施例では、交差するグリフは、デスティネーションに合成する前に、そのマットを一緒に加えることにより、アセンブルしてストライク（strike）にすることが可能である。好ましくは、CompositeSmallGlyphsにより、隣接グリフからのグレースケール・マットの総和をとって、より高品質の結果を得ることができる。 BitBlt（ビットブロック転送）好ましい実施例では、機構は、例えば、エンド・ユーザがウィンドゥの内容をスクロールしたり、同じモニタ上でウィンドゥを再位置付けするときのように、素早い対話のグラフィック基盤を形成する。スクロールまたは再位置付けされたウィンドゥの内容を消去し、再ドローイングする代わりに、ウィンドゥの内容を構成するピクセルは、ブロックで移動されるのが好ましい。このオペレーションはメモリ移動オペレーションであり、より汎用的な働きをするCopyImage メソッドと混同してはならない。このオペレーションは、まだ読み取られていないで残っているピクセルに書くのを避けるように、ピクセル・メモリをコピーするのが好ましい。好ましい実施例では、TPixelBufferのMovePixelBlockメソッドはTLongRectをソースとして、T LongPtをデスティネーション起点として受け取る。オペレーションをある領域にクリップするこのメソッドには、若干の捩じれがあるのが好ましい。領域を受け取るオーバロードされたMovePixelBlockはクリッピングを行うのが好ましい。グラフィックス・アクセラレータ・カードは、頻繁にこの機能を実行する。変更可能であれば、サブクラスはこのメソッドのアンクリップ版をオーバライドするのがこのましい。あるピクセルバッファから同じタイプの別のピクセルバッファヘピクセルをブロック移動するとき、非常に似た機構が使用されるのが好ましい。好ましい実施例では、このメソッドはMovePixelBlockと名づけられている。このメソッドはソース矩形のTLongRectと、デスティネーション起点のTLongptと、ソース・ピクセルを含むTPixelBufferへの定数参照を受け取る。実行時のタイプキャストの結果、PixelBuffersが同じクラス系統でないことが分かったとき、例外が発生するのが好ましい。（このタイプの機能のための低レベル入口点がないのは、Macintos h開発者がオフスクリーンでするときQuickdrawをバイパスしている主な理由の１つである。）好ましい実施例では、追加のオーバロードされたMovePixelBlockメソッドは領域を受け取り、これを通して結果がクリップされる。（これは、グラフィック・アクセラレータ・カードにより、頻繁に実行されるオペレーションである。）変更可能ならば、サブクラスはこのメソッドのアンクリップ版をオーバライドするのが好ましい。MovePixelBlockのクリップ版のデフォルト版はアンクリップ版を使用する好ましい。サブクラスはビットマップを基本クラスとするもののように、別の方法でクリッピングした方が好ましければ、これらをオーバライドすることができるのが好ましい。上記方法を多態使用するためには、ピクセルバッファが同じタイプのものであるかを確かめるだけでは充分でない場合がある。カラー・テーブルが同等かどうかを検査するといった、追加のテストを行うことができるのが好ましい。好ましい実施例では、これは、デスティネーションのPixelBufferで実行できるテストになっている。好ましい実施例では、このメソッドはCanBlockMovePixelsと名づけられ、別のPixelBufferへの定数参照を受け取り、ブール計算結果を返却する。サブクラスは、これらが変更可能であればこのメソッドを用意し、クラス名の比較よりも高い精度を使用するのが好ましい。 CopyImage オブジェクト好ましい実施例では、グラフィック・システムがレンダリングするプリミティブの１つは、イメージである。Pixe1BufferのCopyImage メソッドはソースPixel BufferをデスティネーションPixelBuffer上にレンダリングするが、これはそれ自身であるのが好ましい。ソースピクセルは、アフィン変換または射影変換（projective transform ation）を受けて、デスティネーションにされるのが好ましい。ソース・イメージのピクセルに収められた属性は、転送モードのようなハイレベルの変換か、あるいは、別のピクセル形式への変換のような低レベルの変換を受ける場合がある。好ましい実施例では、CopyImage はソース・ピクセルバッファと、ソース幾何形状仕様と、デスティネーション幾何形状仕様と、グラフ状態（grafstate）を受け取る。これらの幾何形状仕様は、変換タイプと、最大境界と、変換された幾何形状に関する情報と、クリッピング情報とを含んでいるのが好ましく。これらの仕様はCopyImage またはCopyImageTo メソッドで２つの異なるフレームバッファによって計算されるのが好ましい。TPixelBufferのCopyImage はこれらの仕様を一緒に評価する最初のメソッドであるのが好ましい。これは、ピクセルを変換する正しいメソッドを判断し、必要なセットアップを行い、CopyImageパイプラインの次のステージに入る。拡張可能なCopyImageエンジンとPixelStreamers 好ましい実施例では、追加のpixelbufferサブクラスがシステムに追加されるので、CopyImageはオペレーションを多態実行するように作られているのが好ましい。好ましい実施例では、拡張可能なピクセル変換エンジンを備えた最初のグラフィックス・システムを提供している。好ましい実施例では、この制約により、TPixelBufferレベルで存在するCopyImageを実装することも可能であるが、この場合、ピクセル・メモリの編成に関してはなにも仮定していない。好ましい実施例では、”blitloop”機構により、CopyImage エンジンは、ピクセルを一方のPixelBuffer から他方のPixelBuffer へ多態移動することが可能である。PixelBufferサブクラスが現在多様化していることを考えると、PixelBuff erは。それぞれ、他のピクセル・メモリ編成の全てについては”blitloop”を含んでいないのが好ましい。その代わり、好ましい実施例では、各PixelBufferは、少数の標準ピクセル・バッファ・タイプについて知っているものと期待されている。そのタイプとは、TAlpha8Gray8PixelBufferと、TA 8R8G8B8PixelBufferと、TL12A12B12PixelBufferである。このデフォルトでのふるまいにより、CopyImage エンジンは、未知の編成のピクセルバッファからのピクセルをストリーム化し、３つの標準形式にすることができる。デスティネーションPixelBufferには、ピクセルをこの中間PixelBuffer からデスティネーションに移動し、TTransferModeとTDitherHintを反映した結果が得られる別の”blitloop”機構が用意されているのが好ましい。好ましい実施例では、TPix elStreamReaderとTPixelStreamWriterオブジェクトがこれらの要求を達成する。この２つのオブジェクトはピクセル・ストリーマと総称されている。これらのピクセル・ストリーマは、目標と設計上考慮する点が、多くの面で、ペインタと共通している。好ましい実施例では、３つの共通PixelBuffer形式は共通項的解決手法を提供している。しかし、これらの３つの中間形式だけでは、ピクセルまたは属性ストリーミング・エンジンはルースになり低速になってしまう。この問題を解決するために、好ましい実施例では、各PixelBufferには、実効セット（working set）を構成するピクセルストリーマがセットで用意されている。この問題は、新しいペイントと、新しいペインタと、旧PixelBufferの問題と本質的に類似している。この問題の解決の仕方も類似している。CreatePixelStreamWriterメソッドがどのように実現されているかについては、あとで詳しく検討する予定である。各ピクセルバッファは、その一意のキーであるトークンを生成することができるのが好ましい。このキーはIsA関係を指定するのが好ましい。好ましい実施例では、GetNativeKeyメソッドからこのトークンが返される。GetNativeKeyにより、サブクラスは、GetClassNameAsTokenではできない形で、インスタンス化が可能なサブクラスに影響力を及ぼすことができる。これらのキーにより、CopyImage エンジンはソース・ピクセルバッファとデスティネーション・ピクセルバッファとの間で共通の基盤で型をネゴシエートすることができるのが好ましい。好ましい実施例では、このキーの有効性に依存するメソッドは、実行時の型識別を使用して保証を得ることができる。 CopyImage エンジンは、ピクセルバッファのCreatePixelStreamReader メソッドにより、ソースピクセルバッファ・ピクセルを、所定のキーを有するピクセルバッファに移動することができるPixelStreamReaderを獲得するのが好ましい。好ましい実施例では、ソース・ピクセルバッファがその所定のキーと一致しな場合は、nilを返す。PixelBuffersは、適正な型を返す、CreateA8R8G8BPixelStrea mReaderと、CreateAlpha8Gray8PixelStreamReaderと、CreateL12A12B12PixelStr eamReaderとを有するのが好ましい。好ましい実施例では、ペインタ・サーチ機構のように、新たに特殊化されたPixelStreamReadersが動的にピクセスバッファに追加されている場合は、これらを返すことができる。好ましい実施例では、CopyImageエンジンはデスティネーションPixelBufferからのPixelStreamWriterを使用して、ピクセルを所定のキーを有するPixelBufferから自身に移動すると共に、供給されたTTranster ModeとTDitherHintsを反映することができる。CopyImageはPixelStreamWriterを、デスティネーションCreatePixelStreamReader メソッドにより取得することができるのが好ましい。好ましい実施例では、デスティネーションPixelBufferに所定のキーと、TTransferModeと、TDitherHintに一致しない場合は、nilが返される。PixelBuffersには、キーと、単純転送モードと、単純ディーザ・ヒントに一致するPixelStreamWriterを返すCreateA8R8G8BPixelStreamWriterと、CreateA lpha8Gray8PixelStreamWriterと、CreateL12A12B12PixelStreamWriterメソッドとがあるのが好ましい。ペインタ・サーチ機構のように、新たに特殊化されたPi xelStreamWritersが動的にPixelBuffersに追加されている場合は、これらを返すことができるのが好ましい。好ましい実施例では、PixelStreamReadersは、PixelBufferサブクラス・ピクセルのストリームを効率よく読み取るために必要なプロトコルを有する。ピクセル移動メソッドとしては、GetRowと、GetColum nAsRowと、GetPixelAlongAffine DDAと、GetPixelAlongPerspectiveDDAとを有するのが好ましい。好ましい実施例では、PixelStreamReaderサブクラスは、ピクセルの行か、列か、あるいは補間された座標スパンのフェッチを高度に最適化することができる。好ましくは、PixelStreamReadersは、一方のピクセル形式から直接に別の形式に移る効率的なパスを作るためにサブクラス化されている。好ましい実施例では、AdviseWillReadは補足的メソッドであり、これはピクセル移動メソッドのコール前にコールされるのが好ましい。このメソッドにより、 PixelStreamReaderは、圧縮や他の目的のために必要なバッファを効率よく割り振ることができる。 PixelStreamWritersは、所定のPixelBufferサブクラス・ピクセルの１行または複数行を、デスティネーション形式に効率よく書くために必要なプロトコルを有するのが好ましい。ピクセル移動メソッドはPutRowとPutRowsを備えている。結果はTIransferModeとTDitherHint属性を反映しているのが好ましい。所定のPi xelStreamWriterサブクラスは、形式変換と、転送モードと、ディザリング手法の対象となるピクセル行（１行または複数行）を書くことを最適化することができるのが好ましい。２つの補足的メソッドがPixelStreamWriterを補助するのが好ましい。好ましい実施例では、これらは、AdviseWillModifyとRequiresScanli neOrderedSetsである。AdviseWillModifyはSetsメソッドをコールする前にコールされるのが好ましい。これにより、PixelStreamWriterサブクラスはバッファ割振りなどを最適化することができるのが好ましい。ReaquiresScanlineOrd eredSetsメソッドは、エラー拡散の場合のように、行が順次に書かれる場合は、 TRUEを返す。 TPixelBufferのサブクラスは、そのネイティブの型である、TA8R8G8B8PixelBu fferと、TAlpha8Gray8PixelBufferと、TL12A12B12PixelBufferに対してPixelStr eamersを実装するのが好ましい。そうでない場合は、デフォルトのgetとSetPixe lベースのPixelStreamersが返されることになる。中間フォーマットがどれであるかの型ネゴシエーションがTPixelBufferのCreateMatchingPixelStreamersメソッドによって実装されるのが好ましい。サブクラスはこのメソッドをオーバライドして、最も効率的な中間基盤を最初に探索するのが好ましい。デフォルト版はソースまたはデスティネーションのピクセルバッファ形式を読み書きできるペアのPixelStreamersを最初に探索するのが好ましい。最初の探索が失敗した場合、CreateMatchingPixelStreamersは必要とする型の１つに戻るのが好ましい。より高度のサーチ方式では、GetTypesFromPixelStrea mersメソッドを使用することができる。GetTypesFromPixelStreamersメソッドは可能な限りの型を全てTDequeに挿入するためにコールされるのが好ましい。その後、デスティネーション・ピクセルバッファは、そのリストから、それがサポートしている中間基盤型を選択する。ピクセルバッファのピクセルストリーマは実行時に変更できる辞書に保存されているので、これらのメソッドは、周知のデフォルト値だけをそこに入れる代わりに、このTDequeに入れるために、この辞書に照会するのが好ましい、 CreateMatchingPixelStreamersは、CopyImageの２つのケースを除き、全ての場合にコールされるのが好ましい。CopyImage オペレーションが幾何学的変換だけである場合であって、CanBlockMovePixelsメソッドにより、ブロック移動が可能であると判断された場合、デスティネーションのMovePixelBlockメソッドがコールされる。２番目のケースは、CopyImageオペレーションが変換だけのときにも生起される。デスティネーション・ピクセルバッファが、ソースPixelBuffer を理解するPixelStreamWriterを生成できる場合は、PixelStreamReaderは必要とされない。好ましい実施例では、他の変換は型デスティネーションされたPixelStreamer に依存して、読み書きを行い、異種の型のPixelBuf fers間の変換を行う。次に述べるCopyImage メソッドは、そのプライベイト・セクションに置かれているのが好ましい。これらのメソッドの実装は特定のサブクラスから独立している。サポートされるアフィン変換と射影変換は次の手法の１つに送ることができるのが好ましい。好ましい実施例では、各手法は独自の固有セットアップとメソッドをもっており、これはTPixelBufferオブジェクトのプロテクト・メソッドとして現れる。これらのメソッドはPixelStreamReadersとPixelStreamWritersを採用しているので、これらは該当のサブクラス化されたPixelBuffersと協働するのが好ましい。 MovePixelBlockはソース・ピクセルからデスティネーションへの変換をメモリ移動により行う。StreamPixelBlockは、ソース・ピクセルからデスティネーションへの変換をPixelStreamWriterを使用して行う。StreamRectilinearPixelBlock は、ソース・ピクセルのスケール不変線的回転をPixelStreamReaderとPixelStre amWriterにより行う。StreamScaledPixelBlockは、ソース・ピクセルの直線的回転を伴うか、あるいは伴わないポイント・サンプル・スケールを、PixelStreamR eaderとPixelStreamWriterを使用して行う。StreamAndFilterScaledPixelBlock は、ソース・ピクセルからの直線的回転を伴うか、あるいは伴わないフィルタ・スケールを、Pixe lStreamReaderとPixelStreamWriterにより行う。StreamPixelConvexPolygonは、ソースからのソース・ピクセルのポイント・サンプル変換を、PixelStreamReade rにより行い、その結果をPixelStreamWriterによりデスティネーションの凸面多角形に書き入れる。StreamAndFilterPixelsintoCovexPolygonは、ソースからのソース・ピクセルのフィルタ変換をPixelStreamReaderにより行い、その結果をP ixelStreamWriterによりデスティネーションの凸面多角形に書き入れる。 StreamPixelBlock 第23図を説明する。好ましい実施例では、StreamPixelBlockメソッドは、デスティネーションのPixelStreamWriterのPutRows メソッドをコールすることによりそのタスクをパフォームする。従って、ピクセル形式変換と、転送モードと、ディザリングが高速化される。第23図に示すように、好ましい実施例では、TPix elBuffer::CopyImage 310はTFrameBuffer 312によってコールされる。その後、T PixelBuffer::CopyImage 310は自身の CreatePixelStreamWriter 314メソッドを呼び出す。CreatePixelStreamWriter 3 14メソッドは、ソースPixelBuffer 300を読み取ることができるかどうかを、ソースPixelBufferのGetNativeType 316によりその型をソースPixelBuffer 300 に要求することにより判断するのが好ましい。その後、CreatePixelStreamWriter 314は、その型および該当のバンドル属性に一致するPixelStreamWriterを返すのが好ましい。好ましい実施例では、TPixelBuffer::CopyImageは、次に、ソース・ピクセルバッファを使用してPixelStreamWriterのPutRows 320メソッドを呼び出し、自身のStreamPixelBlock 318メソッドを呼び出す。 StreamRectilinearRotatedPixelBlock 好ましい実施例では、StreamRectilinearRotatedPixelBlockメソッドは、ソースPixelStreamReaderのGetRowまたはGetColumnAsRowメソッドを多態的にコールし、ピクセルを一時ピクセルバッファに入れている。デスティネーションPixelS treamWriterのPutRowメソッドを用いて、ピクセルを書き出すのが好ましい。従って、ピクセルメモリを同一の型との間で、高速度スケール不変直線的転送か、あるいは形式変換と、転送モードと、ディザリングを行う同転送を行うことができる。第24図を説明する。好ましい実施例では、TPixelBuffer::CopyImage 322はTFr ameBufferメソッドによってコールされる。TPixelBuffer::CopyImage 322は、その後、自身のCreateMatchingStreamers 324 メソッドを呼び出すのが好ましい。 PixelBufferフォーマットを型デスティネートすることができるかどうかを、Cre ateMatchingStreamers メソッド32が判断するのが好ましい。PixelBufferフォーマットに対して、ソース・ピクセルバッファがPixelStreamerReaderを作成でき、しかも、デスティネーション自身がPixelStreamWriterを作成できるこの場合も、ソースPixelBufferはソースPixelBufferのGetNativeType メソッドによりその型が要求される。好ましい実施例では、CreateMatchingStreamers 324は、次に、この形式で、デスティネーションPixelBuffer のCreatePixelStre amWriter 326を呼び出す。CreatePixelStreamWriter 326は、この型および該当のバンドル属性に一致するPixelStreamWriterを返すのが好ましい。好ましい実施例では、CreateMatchingStreamers 324は、その後、ソースのCreatePixelStre amReader 328メソッドにより PixelStreamerReaderを作成するようにソースPix elBufferに要求する。このペアのPixelStreamReadersとCreateStreamWritersが、その後、TPixelBuf fer::CopyImageに返されるのが好ましい。次に、TPixelBuffer::CopyImageは自身のStreamRectilinearRotatedPixelBlock 330メソッドを呼び出す。好ましい実施例では、TPixelBuffer::StreamRectilinearRotatedPixelBlock 330は、その後、PixelStreamReaderのGetRow 332またはGetColumnAsRowのどちらかのメソッドを繰り返しコールし、中間 PixelBufferを一杯にし、その後、PixelStreamWrit erのPutRow 334メソッドをコールする。 StreamSclePixelBlock 第25図を説明する。好ましい実施例では、StreamScaledPixelBlock 340メソッドは、ソースPixelStreamReaderのGetPixelsAlongAffineDDA メソッドをコールして、ピクセルを一時ピクセルバッファに入れる。デスティネーションPixelStr eamWriter 342のPutRow 344メソッドは、ピクセルを書き出すために使用されるのが好ましい。よって、ピクセル・メモリを同一型との間で、高速ポイント・サンプル直線スケール転送するか、あるいは、フォーマット変換と、転送モードと、ディザリングを行う同転送を行うことができる。好ましい実施例では、StreamScaledPixelB lock 340は、ソースPixelBufferがMipMapまたは多重解像度ピラミッドである場合には、フィルタ変換を行うことができる。第25図に示すように、好ましい実施例では、TPixelBuffer::CopyImage 346はT FrameBuffer 348メソッドによって呼び出される。そして、TPixelBuffer::Copy Image 346は自身のCreateMatchingStreamers 352メソッドを呼び出し、ついで、上記のStreamRectilinearRotatedPixelBlockの例で説明したように、アクションを行うのが好ましい。一度、CreateMatchingStreamers 352がペアのPixelStream Readers 354およびPixelStreamWriters 342をTPixelBuffer::CopyImage 346に返すと、TPixelBuffer::Copyimage 346は自身のStreamScaledPixelBlock 340を呼び出すのが好ましい。そして、好ましい実施例では、TPixelBuffer::StreamScal edPixelBlock 340は、PixelStreamReaderのGetPixelsAlongAffineDDAメソッドを繰り返しコールして、中間PixelBufferを一杯にし、ついで、PixelStreamWriter のPutRow 344メソッドをコールする。 StreamAndFilterScaledPixelBlock 第26図を説明する。好ましい実施例では、StreamAndFilterScaledPixelBlock 356メソッドは、ソースPixelStreamReaderのGetRow 360またはGetColumnAsRow 3 62メソッドを多態的にコールしてピクセルをA8R8G8B8またはAlpha8Gray8フォーマットにロードする。このピクセル・データはそのあとフィルタに通され、総和されて出力ピクセルが得られるのが好ましい。フィルタリングが完了して出力スキャンラインが得られると、デスティネーションPixelStreamWriterのPutRow 36 4メソッドがコールされてピクセルを書き出すのが好ましい。 PixelStreamWriterのPutRow 364メソッドは、畳み込みオペレーションの回数を大幅に減少させる効率的な２パス・アルゴリズムを採用しているのが好ましい。好ましい実施例では、使用されるフィルタ・カーネルはTGrafBundleからのTIm ageSamplingControl属性に指定されているものである。よって、同一の型との間のピクセル・メモリの直線スケール転送か、あるいは、フォーマット変換と、転送モードと、ディザリング行う同転送が効率よくフィルタリングされる。第26図に示すように、好ましい実施例では、TPixelBuffer::CopyImage 366はT FrameBuffer 368メソッドによってコールされる。そして、 TPixelBuffer::CopyImage 366は自身のCreateFilteringStreamers 370メソッドを呼び出し、ついで、StreamRectilinearRotatedPixelBlockで記載したように、同一のアクションをパフォームする。ただし、グレースケールまたはRGB間ピクセル・バッファだけが使用されることになる。一度、CreateFilteringStreamers 370がペアのPixelStreamReadersとPixelStreamWritersをTPixelBuffer::CopyIm age 366に返すと、TPixelBuffer::CopyImage 366が自身のStreamAndFilterScale dPixelBlock 356メソッドを呼び出すのが好ましい。そして、好ましい実施例では、TPixelBuffer::StreamAndFilterScaledPixelBlockは、PixelStreamReader 3 72のGetRow 374またはGetColumnAsRow 362メソッドをコールして、中間ピクセルバッファを一杯にし、ついで、フィルタリングされたスキャンラインが準備されると、PixelStreamWriter 376のPutRow 364メソッドをコールする。 StreamPixelsIntoConvexPolygon 第27図を説明する。好ましい実施例では、StreamPixelsIntoConvexPolygon 38 0スキャンは、エッジに添ってx,y,u,v,wを内挿して、凸面多角形を変換し、塗りつぶすスパンごとに、ソースPixelStreamReader 386のGetPixe lsAongAffineDDA 382またはGetPixelsAlongPerspectiveDDA 384メソッドをコールしてピクセルを一時ピクセルバッファに入れる。デスティネーションPixelStr eamWriter 388のPutRow 390メソッドは、ピクセルを書き出すために使用されるのが好ましい。よって、同一型との間のピクセル・メモリのポイント・サンプル回転、スキュー、スケール、または射影転送またはフォーマット変換、転送モード、およびディザリングを受ける転送の効率が向上する。好ましい実施例では、 StreamPixelsIntoConvexPolygon 380は、ソース・ピクセルバッファがMipMapまたは多重解像度ピラミッドである場合にはフィルタ変換を行うことができる。第27図に示すように、好ましい実施例では、TPixelBuffer::CopyImage 390はT FrameBuffer 392メソッドによってコールされる。そして、TPixelBuffer::CopyI mage 390は自身のCreateMatchingStreamers 394メソッドを呼び出し、ついで、上記のStreamRectilinearRotatedPixelBlockで記載したように、同じアクションをパフォームするのが好ましい。一度、CreateMatchingStreamers 394がペアのP ixelStreamReadersとPixelStreamWritersをPixelBuffer::CopyImage 390に返すと、 PixelBuffer::CopyImage 390は自身のStreamPixelsIntoConvexPolygon 380メソッドを呼び出すのが好ましい。そして、 TPixelBuffer::StreamPixelsIntoConvexPolygon 380は、PixelStreamReader 386 のGetPixelsAlongAffineDDA 382またはGetPixelsAlongPerspectiveDDA 384メソッドを繰り返しコールして、中間ピクセルバッファを一杯にし、その後、PixelS treamWriter 388のPutRow 390メソッドをコールする。 StreamAndFilterPixelsIntoConvexPolygon 第28図を説明する。好ましい実施例では、StreamAndFilterPixelsIntoConvexP olygon 400メソッドは、ソース・ピクセルバッファを、デスティネーションの凸面多角形に区分ごとに２パスでフィルタ変換する。ソースPixelStreamReader 41 0のGetRow 412またはGetColumnAsRow 414メソッドがコールされ、ピクセルをA8R 8G8B8またはAlpha8Gray8 フォーマットにロードするのが好ましい。そして、このピクセル・データは２パスでフィルタにかけられ、総和がとられて出力ピクセルが得られるのが好ましい。フィルタリングが完了して出力ピクセル・ブロックが得られると、デスティネーションPixelStreamWriter 416のPutRows 418メソッドがコールされ、ピクセルを書き出すのが好ましい。好ましい実施例では、このPutRows 41 8メソッドは、畳み込みオペレーション回数を大幅に減少させるる効率的な区分ごとの２パス・アルゴリズムを採用している。これは、２次元変換を２つの１次元スケールとスキュー変換に縮減することによって行われるのが好ましい。好ましい実施例では、使用されるフィルタ・カーネルはTGrafBundleからのTImageSam plingControl属性オブジェクトから取り出される。よって、同一型との間の効率的なフィルタ回転か、スキューか、スケーリングか、あるいは、射影転送を行うことができるか、あるいは、フォーマット変換と、転送モードと、ディザリング行う同転送を行うことができる。第28図に示すように、好ましい実施例では、TPixelBuffer::CopyImage 420はT FrameBuffer 422メソッドによってコールされる。そして、TPixelBuffer::CopyI mage 420は自身のCreateFilterStreamers 422メソッドを呼び出し、その後、これは、上記StreamRectilinearRotatedPixelBlockで記載したように、同じアクションをパフォームする。ただし、グレースケールまたはRGB中間ピクセルバッファだけが使用されることになる。一度、 CopyFilteringStreamers 422がペアのPixelStreamReadersとPixelStreamWriters をTPixelBuffer::CopyImage 420に返すと、TPixelBuffer::CopyImage 420は自身のStreamAndFilterPixelsIntoConvexPolygon 400メソッドを呼び出すのが好ましい。そして、好ましい実施例では、TPixelBuffer::StreamAndFilterPixelsIntoC onvexPolygon 400は、PixelStreamReader 410のGetRow 412またはGetColomnAsRo w414メソッドをコールして、中間ピクセルバッファを一杯にし、その後、フィルタ・ブロックが２パスで変換されると、PixelStreamWriter 416のPutRows 418をコールする。多態照会（Polymorphic Query） TPixelBufferサブクラスの数はシステムの使用と共に増加していくのが好ましい。好ましい実施例では、各サブクラスはクライアントにとって不定数の属性のコンテナに過ぎない。好ましい実施例において、クライアントがTPixelBufferへの多態参照をもっている場合を検討する。この場合、このクライアントは、カラーか、不透明か、あるいはＺ奥行き値などの特定の属性がストアされているかどうかを知ることが必要である。イメージ編集データ・エンカプスレータ（image editing data encapsulator）は、カラー属性を含んでいないイメージをスクリーン・アウトすることを望む場合がある。Ｚバッファ・レンダリング・パイプラインは、Ｚ平面が存在しない場合、別個のＺ平面を作るのが好ましい。好ましい実施例では、TGimageでのポイント・コンテインメント・テスト（point containment test）は、不透明がストアされているかどうかを判定し、肯定判定された場合は、問題のピクセルが完全に透明であるかどうかを判定する必要がある。上記要求を全て解決するには、どのような手法をとるべきか。コンテナの名前はMCollectibleメソッドのGetClassNameAsTokenにより得ることができるが、これは好ましい方法ではない。属性の型は拡張しているので、ピクセルバッファに課されるだけの問題の包括的なリストを作成するのは好ましくない。これに対し、型ネゴシエーションに類似したメカニズムは、はるかにクリーンで拡張可能であり、オブジェクト指向であることが実証されている。第29図を説明する。好ましい実施例では、属性のハイレベル記述子はTPixelAt tributes 452を通して指定される。TPixelAttributes 452は、記憶の明細を記述することを目的としていないのが好ましい。好ましい実施例では、メソッドCont ainsPixelAttributeにより、ピクセルバッファは、これらに特定の属性が含まれているかどうかについて答えることができる。ContainsPixelFieldはTPixelAt tributeを受け取り、Booleanのtrueかfalse結果を返すのが好ましい。別の実施例では、GetPixelAttributesメソッドは、特定のピクセルバッファ内に含まれる属性を全て列挙する。 GetPixelAttributesはTDequeへの参照を受け取り、この参照は、返されたとき、ピクセルバッファにストアされている全てのピクセル属性を含んでいるのが好ましい。好ましい実施例では、多数の事前に定義されたTPixelAttributesが用意されているので、共通属性の標準ボキャブラリを作成することができる。サブクラスはこれらのメソッドを提供するのが好ましい。好ましい実施例では、PixelBuffersの主なユーザは、TFramebufferと、TGImag eと、TImageSequenceである。PixelBuffersは２つの機能を持っているのが好ましい。一方はリードオンリピクセルをコレクションすることであり、他方は変更可能なピクセルをコレクションすることである。好ましい実施例では、メソッド ArePixelsReadOnlyはピクセルバッファが変更可能かどうかを質問するために使用され、BooleanのTRUEまたはFALSEを返す。ピクセルバッファは修正可能であるのが好ましい。好ましい実施例では、システムには、ピクセルメモリを変更するための機構が用意されている。多態ピクセルバッファ・キャッシュ好ましい実施例では、システムには、クライアントがピクセルバッファ・キャッシュを作成し、保守し、照会することができるメソッドが用意されている。これらのキャッシュはスプライト（sprite）およびキャッシュ・グラフィック・クライアントによって使用されるのが好ましい。これらのキャッシュは、同種の実行時属性をもつ同じサブクラスのインスタンスに高速にブリット（blit）するために使用することもできる。多態バック・バッファリング／相関ピクセルバッファ追加のメソッドにより、クライアントは相関ピクセルバッファまたは「バックバッファ」（BackBuffers）を作成し、保守することができるのが好ましい。上述したキャッシュと異なり、好ましい実施例では、これらのバックバッファと、サブクラスのこのインスタンスとは緊密に結合されている。 TPixleBufferサブクラス上述したように、ピクセル・メモリの編成方法は数多くある。その幾つかを挙げると、コンポーネント・インタリーブと、コンポーネント・プレーナと、ビット・プレーナと、タイルと、これらの階層バージョンがある。可能なものは、絶えず拡張されている。好ましい実施例では、クラス階層はサブクラスがメモリ編成を見せているかどうか、ピクセス・データへのアクセスがプライベートか、パブリックかを考慮に入れている。ピクセルメモリ編成と記憶サブクラスはピクセル編成を見せることは自由であるが、そうする必要はない。好ましい実施例では、パワーは実装を隠蔽するのではなく、クライアントのピクセル記憶に多態アクセスすることにより導出される。さらに、サブクラスのクライアントは、ピクセル・メモリの特定の実装に依存することができる。例えば、８ビット・ポインタを利用するようにプログラムされたハードウェア・ルックアップ・テーブルをもつカードの場合は、Clut8PixelBuffersメモリ編成を再定義することは歓迎されない。この８ビット・ポインタは使用されるなくなる虞がある。サブクラスがそのピクセル・メモリ編成を他へエクスポートしない場合は、外部クライアントがペインタとピクセルストリーマのサブクラスのアーセナルを拡張することは、不可能ではないにしても困難である。これはサブクラスに依存する。あるサブクラスは、そのパワーを、実装を隠蔽することにより得ている。他のサブクラスは、メモリ・レイアウトをパブリックにし、クライアントがピクセル値を不正確な状態にセットするのを防止するために、アクセスをプライベートにしている。好ましいサブクラス好ましい実施例では、多数のイメージ形式がサポートのために選択されている。この選択プロセスは、現在のビデオ・カード標準と、交換形式と、非インテリジェント・バイレベル・プリンタと、３次元レンダリングと、等色と、２次元イメージ合成をサポートする必要から行われたものである。好ましい実施例では、全てのサブクラスは、初期状態では、コンポーネント・インタリーブ・メモリ編成になっている。好ましい実施例では、TComponentInterleavedPixelBufferはTP ixelBufferのサブクラスである。全てのPixelBufferはTPixelBufferから派生されるのが好ましい。第30図はクラス階層図であり、TPixelBufferクラス系統を示す。 TComponentInterleavedPixelBuffer 第32図を説明する。好ましい実施例では、TComponentInterleavedPixelBuffer 500は、コンポーネント・インタリーブまたはチャンキ（chunky）ピクセルバッファの指定を基本クラスレベルでサポートするTPixelBufferのサブクラスである。これが追加する新しい成分は、ピクセル・メモリを指す単一のポインタと、４バイトの倍数で指定されるスキャンライン・サイズであるのが好ましい。好ましい実施例では、サブクラスはGetPixelSizeを純粋な仮想メソッドとして追加し、これには、MovePixelBlockメソッドのデフォルト版が用意されている。従って、好ましい実施例では、GetBestScanlineSize メソッドは、クライアントが自身のピクセル・メモリを割り振るときに利用できる。好ましくは、返されるサイズは、プラットフォームに合わせて最適化されているが、結果は４の倍数になっていることが必要である。メモリがPixelBuffer により割り振られており、しかも、コンストラクタに渡されていない場合、ピクセルバッファは、削除時に、そのピクセル・メモリを処分するのが好ましい。よって、フレームバッファのマッピング・インが可能になる。好ましい実施例では、ピクセル・メモリの先頭を指すポインタは、 GetBaseAddressメソッドにより取得することができ、スキャンライン・サイズは GetScanlineSize メソッドにより取得することができる。 TA8R8G8B8PixelBuffer 第33図を説明する。好ましい実施例では、TA8R8G8B8PixelBufferは４つの８ビット・コンポーネントを備えた32ビット・ピクセルのためのコンテナである。これらのコンポーネントとは、第33図に示すように、アルファと、赤と、緑と、青であるのが好ましい。赤と、緑と、青のコンポーネントは、RGB空間に座標を形成する。PixelBufferのTColorProfileメソッドは、このRGBの３つのコンポーネントからXYZカラーを得るのが好ましい。好ましい実施例では、アルファ・コンポーネントは不透明を指定する。カラー・コンポーネントはアルファ値よりも前に重み付けされないのが好ましい。好ましい実施例では、これは、kRGBPixelFie ldと、kAlphaPixelFieldと、kColorPixelFieldピクセル・フィールドを含むことが考慮されている。（ピクセル・メモリ編成のここでの説明と以下の説明は、好ましい実施例においてピクセル・レイアウトが高レベル言語からどのように見えるかを中心に述べる。） TL12A12B12PixelBuffer CIElabは可視スペクトルの全てではないとしも、その大部分をストアするための離散化カラー空間であるのが好ましい。CIElabコンポーネントは８または12ビット値に非線形的にマッピングされるのが好ましい。 TAlpha8Gray8PixelBuffer 第34図を説明する。好ましい実施例では、TAlpha8Gray8PixelBufferは、２つの８ビット・コンポーネントを含む16ビット・ピクセルのためのコンテナである。これらのコンポーネントはアルファとグレーを備えているのが好ましい。好ましい実施例では、グレー・コンポーネントはルミナンス空間に座標を作成する。 PixelBufferのTColorProfileはこのグレー値からXYZ カラーを得るのが好ましい。アルファ・コンポーネントは不透明を指定するのが好ましい。好ましい実施例では、グレー・コンポーネントはアルファ値よりも前に重み付けされない。好ましい実施例では、kGrayscalePixelFieldと、kAlphaPixelFieldと、kColorPixelF ieldピクセル・フィールドを含むことが考慮される。 TIndexedPixelBuffer 第35図に示すように、好ましい実施例では、TIndexedPixelBuffer 510は、１つのコンポーネントを含むピクセルのための抽象基本クラスコンテナである。このコンポーネントはPixelBufferのTColorlist512へのインデックスであるのが好ましい。このインデックスからXYZカラーを導出するため、これは、インデックスとTXYZC カラーの参照で、TColorList 512のGetColorメソッドをコールするのが好ましい。好ましい実施例では、TColorList 512のTColorProfileは、PixelBu fferによって参照されるものと同じである。TColorを該当のインデックスにマッピングするには、colorlistを引数としてTColorsFindIndexがコールされるのが好ましい。 TIndexPixelBuffer 510は、TColorListの参照をストアしているのが好ましい。好ましい実施例では、カラーリストはGetColorListメソッドによりアクセスできる。２〜256個のカラーを有するTColorListsは、サブクラスにより処理されるのが好ましい。 TClut2PixelBuffer 第36図に示すように、好ましい実施例では、TClut2PixelBuffer は１つの２ビット・コンポーネントを含むピクセルのためのコンテナである。このコンポーネントは、PixelBuffe rのTColorListへのインデックスである。TColorListは４つのカラー・エントリを含んでいるのが好ましい。これは、kRGBPixelFieldlとkColorPixelFieldピクセル・フィールドを含んでいるのが好ましい。 TClut4PixelBuffer 第37図に示すように、好ましい実施例では、TClut4PixelBufferは１つの４ビット・コンポーネントを含むピクセルのためのコンテナである。このコンポーネントは、PixelBufferのTColorListへのインデックスである。TColorListは16個のカラー・エントリを含んでいるのが好ましい。これは、kRGBPixelFieldlとkCo lorPixelFieldピクセル・フィールドを含んでいるのが好ましい。 TClut8PixelBuffer 第38図に示すように、好ましい実施例では、TClut8PixelBufferは１つの８ビット・コンポーネントを含むピクセルのためのコンテナである。このコンポーネントは、PixelBufferのTColorListへのインデックスである。TColorListは256個のカラー・エントリを含んでいるのが好ましい。好ましい実施例では、kRGBPixelFieldlとkColo rPixelFieldピクセル・フィールドを含むことが考慮される。 TSystemClut8PixelBuffer 好ましい実施例では、TSystemClut8PixelBufferはTClut8PixelBufferのサブクラスである。ピクセルはまだカラー・リストへの８ビット・インデックスを表しているが、カラー・リストは、好ましい実施例では、一定のデフォルト・カラー・リストである。よって、TColorを正しいインデックスに変換するとき、仮定することができる。TSystemClut8PixelBufferのペインタとピクセルストリーマは、これらの仮定を用いて、パフォーマンスを向上させることができる。 TGray4PixelBuffer 第39図に示すように、好ましい実施例では、TGray4PixelBuffer は１つの４ビット・コンポーネントを含むピクセルのためのコンテナである。このコンポーネントはピクセルバッファのTGrayColorListへのインデックスである。TGrayColor Listは、白から黒までの16個のグレー・カラーの固定ランプである。kGrayscale PixelFieldとkColorPixelFieldピクセル・フィールドを含むことが考慮される。 TGray8PixelBuffer 第40図に示すように、好ましい実施例では、TGray8PixelBufferは１つの８ビット・コンポーネントを含んでいるピクセルのためのコンテナである。このコンポーネントはPixelBufferのTGrayColorListへのインデックスである。TGrayColo rListは白から黒までの256個のグレーカラーの固定ランプであるのが好ましい。好ましい実施例では、kGrayscalePixelFieldlとkColorPixelFieldピクセル・フィールドを含んでいる。 TAlpha8PixelBuffer 第41図を説明する。好ましい実施例では、TAlpha8PixelBufferはTGray8PixelB ufferのサブクラスであるが、唯一の違いは、グレー値がルミナンスではなく、不透明を指定していることである。これはkAlphaPixelFieldピクセル・フィールドを含んでいるのが好ましい。 TBitMappedPixelBuffer 第42図に示すように、好ましい実施例では、TBitmappedPxelBufferは、１ビット・コンポーネントを含むピクセルのためのコンテナである。このコンポーネントはピクセルバッファのTGrayColorListへのインデックスである。TGrayColorLi stは２つのグレー値だけを含んでおり、それは黒と白である。これはkGrayscale PixelFieldとkColorPixelFieldピクセル・フィールドを含んでいるのが好ましい。 THalftoneBitmappedPixelBuffer 第43図を説明する。好ましい実施例では、THalftoneBitmappedPixelBufferはT BitmappedPixelBufferのサブクラスである。唯一の違いは、到来するTColorから導出されたグレー値が周期的パターンに対する閾値であるのが好ましい。このTH alftoneオブジェクトはGetHalftoneメソッドにより取り出すことができる。これはSetHalftoneメソッドによりセットできる。周期的閾値パターンはfThresholdA rrayフィールドの中で参照されたハーフトーン・マトリックスにストアされる。これはアンインテリジェント・バイレベル・プリンタで使用されるサブクラスであるのが好ましい。 TAlphalPixelBuffer 第44図を説明する。好ましい実施例では、TAlpalPixelBufferはTBitmappedPix elBufferのサブクラスである。唯一の違いは、グレー値がルミナンスではなく不透明を指定していることである。これはkAlphaPixelFieldピクセル・フィールドを含んでいるのが好ましい。 Tb8R8G8B8PixelBuffer 第45図を説明する。好ましい実施例では、Tb8R8G8BPixelBufferは、４つの８ビット・コンポーネントを含む32ビット・ピクセルのためのコンテナである。最上位コンポーネントは未定義であり、残りのコンポーネントは赤、緑、および青であるのが好ましい。赤、緑および青コンポーネントはRGB空間に座標を形成する。ピクセルバッファのTColorProfileはこのRGB３成分からXYZカラーを導出するために使用されるのが好ましい。このピクセルバッファは、見かけ上32ビット・ピクセルをサポートしていても、最上位バイトをサポートする物理メモリがないビデオ・カードを表すために使用される。これはkRGBPixelFieldとkColorPixe lFieldピクセル・フィールドを含んでいるのが好ましい。 TZ32PixelBuffer 第46図に示すように、好ましい実施例では、TZ32PixelBufferは、Ｚ奥行きを表す１つの32ビット・コンポーネントを含む32ビット・ピクセルのためのコンテナである。Ｚ奥行き値はピクセルの３次元奥行きまたは層を指定している。しばしば、個々の３次元オブジェクトはレンダリングされて個々のTPixelBufferに入れられる。好ましい実施例では、ｚ奥行き値により、個々のピクセルバッファは、個々のオブジェクトの前方から後方への配列を正確に反映した最終的シーンにアセンブルすることができる。これはkZDepthPixelFieldピクセルフィールドを含んでいるのが好ましい。 TA8R8G8B8Z32PixelBuffer 第47図に示すように、好ましい実施例では、TA8MG8B8232PixelBufferは、32ビット・コンポーネントと４つの８ビット・コンポーネントを含む64ビット・ピクセルのためのコンテナである。これらのコンポーネントはＺ奥行きと、アルファと、赤と、緑と、青である。赤と、緑と、青はRGB 空間に座標を形成する。好ましくは、ピクセルバッファのTColorProfileはこのRGB ３成分からXYZカラーを導出する。好ましい実施例では、アルファ・コンポーネントは不透明を指定している。カラー・コンポーネントはアルファ値よりも前に重み付けされないのが好ましい。好ましい実施例では、Ｚ奥行き値はピクセルの３次元奥行きまたは層を指定している。３次元オブジェクトはレンダリングされて別々のTA8R8G8Z32PixelBuffe rに入れられるのが好ましい。ｚ奥行き値により、個々のピクセルバッファは、個々のオブジェクトの前方から後方への配列を正確に反映した最終的シーンにアセンブルすることができる。これはkRGBPixelField、kAlphaPixelFieldと、kZDe pthPixelFieldと、kColorPixelFieldピクセルフィールドを含んでいるのが好ましい。 TAlR5G5B5PixelBuffer 第48図に示すように、好ましい実施例では、TAlR5G5B5PixelBufferは、１つの１ビット・コンポーネントと、３つの５ビット・コンポーネントを含む16ビット・ピクセルのためのコンテナである。これらのコンポーネントはアルファと、赤と、緑と、青である。赤、緑および青コンポーネントはRGB空間に座標を形成する。RGB ３成分からXYZカラーを導生するには、ピクセルバッファのTColorProfi leを使用する必要がある。アルファ・コンポーネントは不透明を指定する。カラー・コンポーネントはアルファ値よりも前に重み付けされない。これはkRGBPixelFieldと、kAlphaPixelFieldと、kColorPixelFieldピクセルフィールドを含んでいる。 TblR5G5B5PixelBuffer 第49図に示すように、好ましい実施例では、TblR5G5B5PixelBufferは、１つの１ビット・コンポーネントと、３つの５ビット・コンポーネントを含む16ビット・ピクセルのためのコンテナである。最上位コンポーネントは未定義である。残りのコンポーネントは赤、緑および青である。赤、緑および青コンポーネントは RGB空間に座標を形成する。RGB ３成分からXYZカラーを導出するには、ピクセルバッファのTColorProfileを使用する必要がある。これはkRGBPixelFieldおよびk ColorPixelFieldピクセルフィールドを含んでいるのが好ましい。 TR8G8B8PixelBuffer 好ましい実施例では、第50図に示すように、TR8G8B8PixelBufferは、３つの８ビット・コンポーネントを含む24ビット・ピクセルのためのコンテナである。最上位コンポーネントは未定義である。残りのコンポーネントは赤、緑および青である。赤、緑および青コンポーネントはRGB 空間に座標を形成する。このRGB ３成分からXYZカラーを導出するには、ピクセルバッファのTColorProfileを使用する必要がある。このピクセルバッファは、不透明RGBイメージを表すための記憶の点でより効率的である。これはkRGBPixel FieldとkColorPixelFieldピクセルフィールドを含むのが好ましい。 TPixelBufferのサブクラス化好ましい実施例では、CMYKのように新しいサブクラスを必要とするデバイス固有のカラー・モデルをサポートするためか、あるいはイメージ・エディタのために、追加のPixelBufferクラスを追加して、コンポーネント・インタリーブ・タイラか、あるいはコンポーネント・プレーナ・ピクセルバッファ・サブクラスを追加し、参照の局所性をレバリッジすることができる。さらに、ハードウェア・プラットフォーム・ベンダーは、真正のカラー・イメージをピクセル当たり12-1 6ビットで再現できるTYUVPixelBufferを書くことにより、品質を犠牲にしないで、ビデオRAM所用量を低減することができる。ビデオイフェクトカード・ベンダーは、そのカードをグラフィックス・システムとデスクトップに統合化することができる。ネットワークからのビデオフィードは、TPixelBufferおよびTGImageサブクラスによりデスクトップに迅速に統合することができるのが好ましい。再編成されたピクセル・メモリのサポートの不必要に複雑なのは、慣用のシステムでは、抑制することができる。例えば、Apple社のQuickDraw32では、約１年かかって、16ビットと32ビット・ピクセル・マップのサポートを追加した。最初の塗りつぶされた矩形をこのようなデバイス上に表示するには、無駄な努力であった。好ましい実施例では、TPixelBufferのサブクラスは、デフォルト・レンダリングのふるまいをget するSetおよびGetPixelメソッドをオーバライドするだけでよい。TPixelBufferのCreatePainterとCreatePixelStreamerメソッドは、仮想GetおよびSetPixelメソッドに依存する幾つかのジェネリック・ペインタとピクセルストリーマを有する。TPixelBufferのMovePixelBlockメソッドはSetおよびGetPixelに基づいて実装もされる。このデフォルトのふるまいは出荷プロダクトに必要なパフォーマンスが最適化されない場合もあるが、これは、開発目的のためのインリクメンタルモデルを作成する。一度、新しいPixelBufferサブクラスに独自のペインタとピクセルストリーマのアーセナルがあると、他の共通のピクセルバッファに対して、サブクラスのピクセル・メモリを理解するPixelStreamWriterを書くことは、価値があるかもしれない。この機構により、サード・パーティは、TMPE GPixelBufferのような新しいPixelBufferサブクラスを開発することができるのが好ましい。新しいPixelBufferサブクラスは、ピクセルをスクリーン・デバスに転送する前にピクセルをある種の共通のフォーマットに変換する必要がない。 TPixelBuffer/TGImage 第51図を説明する。好ましい実施例では、ピクセル・メモリのエンカプスレータとして、TPixelBufferは２つの目的をサーブする。TPixelBufferはレンダリング・デスティネーション・オブジェクトであると同時に、イメージと呼ばれるレンダリング・プリミティブとして使用されるオブジェクトでもある。好ましい実施例では、TPixelBufferは、好ましい成分を全て含んでいなくても、イメージ・プリミティブを完全に記述することができる。 TGImageは、TPixelBufferを、TGrafPortレベルでエクスポーズする必要のないクラスであるのが好ましい。TGImage はレンダリングを行うときに必要になる追加成分も含んでいる。TGImageはTPixelBufferと、TGRect境界矩形と、デバイス変換を含んでいる。これは、好ましい実施例では、イメージ・プリミティブを幾何形状で表したものと同じである。

【手続補正書】特許法第１８４条の８【提出日】１９９４年１２月１４日【補正内容】（原文第１頁ないし第３頁の翻訳文）明細書多態グラフィック・デバイス著作権所有表記本特許出願は、著作権保護の対象となる内容を含んでいる。この著作権保護の対象となる内容を、情報を得る目的で、本特許出願の一部として複製してもそれを妨げるものではないが、他の権利、特に、本内容を商業的に利用する権利を全て留保する。技術分野本発明は、コンピュータ・グラフィックスに関し、特に、ピクセル・メモリの多態操作に関する。背景の技術コンピュータ・スクリーン上に描かれるコンピュータ・ピクチャやイメージは、コンピュータ・グラフィックスと呼ばれている。コンピュータ・グラフィック・システムは、グラフィックスをディジタルで内部にストアしている。ピクチャは、小さな画素、すなわち、ピクセルに分割されている。従って、コンピュータ・ピクチャつまりグラフィックは、実際には、個々の画素、すなわち、ピクセルの集合体である。内部、すなわち、コンピュータのディジタル世界では、各ピクセルには、ピクセルの属性を表すディジタル値の集合が割り当てられている。ピクセルの属性は、例えば、ピクセルのカラーと、明度と、ロケーションを記述することができる。従って、ピクセルのカラーか、明度か、あるいは、ロケーションを変更するには、その特定の属性のディジタル値を変更するだけでよい。慣用のコンピュータ・グラフィック・システムは、イメージか、ビットマップか、あるいはピクセル・マップとして知られているプリミティブを利用して、コンピュータ・イメージをピクセルの集合体として表す。これらのプリミティブはピクセル属性と、個々のディジタル値の２次元配列を表す。典型的には、このようなプリミティブは、ピクセル・データを指すポインタと、ピクセルサイズと、スキャンライン・サイズと、境界と、場合によっては、カラー・テーブルへの参照を含む「構造体」（データ構造）として表される。よく行われる仮定であるが、ピクセルは、RGB（red，green，blue）カラーか、ルミナンスか、あるいは、カラーテーブルを指すインデックスを表すものとする。従って、プリミティブは２重の役割、すなわち、フレームバッファとしての役割と、フレーム記憶指定（ frame storage specification）としての役割をサーブする。急成長のコンピュータ・グラフィック産業は、ピクセル表現に関する事実上の標準の上に成り立っている。この標準に当てはまらないイメージ形体は、全て、いやが応でも２流の市民権を得ることになる。しかし、慣用のグラフィックス・システムは拡張不可能である。これらのシステムは、通常、特定のクラスのイメージに対してオペレートする特定のアプリケーションの専用になっている。これは、急速に変化しているディジタル技術環境では認容できない。日々、新しいアプリケーションが出現し、この新しいアプリケーションを用いて、新しいイメージ型を新しい方法で処理し操作する必要がある。従って、拡張不可能なグラフィック仕様をもつグラフィックス・システムを使用するのは、先見の明がなく、早い話、時代後れなのである。グラフィカル・アプリケーションと、属性と、ピクセル・メモリに対する編成上の条件は、多様化しており拡大している。従って、専用化された単一目的のグラフィックス・システムは、現在のユーザ要求を満たすことができない。動的環境を提供する頑強なグラフィックシステムに対する要求があり、新しいアプリケーション、新しいイメージ・タイプを取り入れるため拡張することができ、しかも、新しいピクセル操作を備えた拡張可能なグラフィック仕様に対する要求がある。例えば、２つのアプリケーションが、同じセットのピクセル属性を必要とすることはまれである。３次元アプリケーションはｚ値（奥行き配列）をストアし、他方、アニメーションおよびペイント・アプリケーションはアルファ値をストアする。対話式マテリアル・エディタおよび３次元ペイント・プログラムは、３次元の陰影情報をストアするのに対し、ビデオ作成システムはYUV 4:2:2 ピクセル配列を必要とする。ハードウェアのクリッパはレイヤ（layer）タグをストアし、高度のシステムはヒット検出のためにオブジェクトIDをストアすることができる。さらに、カラー空間のようなグラフィカル属性は、PhotoYCC（商標）のような一定の付加物を蓄積している。等色（color matching）技法は依然として発展段階にあり、どの量子化カラー空間が可視スペクトルをピクセルとして記録するのに最良であるかはまだ明らかではない。従って、グラフィック世界では、データ・タイプは様々である。記憶編成技術も様々である。問題をさらに悪化させているのは、虞らく、アプリケーションが新しくなるたびに、異なるピクセル・メモリ編成が必要になることである。例えば、コンポーネント・インターリーブか、あるいは、”Chunky”スキャンライン配向は、Mach intosh（登録商標）ビデオ・カードで主流の編成になっている。しかし、コンポーネント・インターリーブ・バンク付きスイッチ・メモリが、小規模アドレス空間を有するホストを目標としたビデオ・カードではトレンドになっている。コンポーネント・プレーナ・タイルと、コンポーネント・インターリーブ・タイルは、プリプレス（prepress）と、エレクトロニック・ペイント・プログラムのトレンドになっている。しかし、複数のパスでプリントまたはスキャンする入出力デバイスでは、コンポーネント・プレーナ形式の方が好まれている。多重解像度またはピラミッド形式はリアルタイムの再サンプリングを必要とする静的イメージでは普通になっている。さらに、メモリを大量に消費するイメージは、種々の方法でコード化できる圧縮ピクセル・データとして表現することができる。グラフィック・アプリケーションと、データ・タイプと、ピクセル・メモリ操作は、多様になり、著しく成長している。周知の全てのアプリケーションを処理することができる多目的システムであって、まだ未知のアプリケーションを処理するために拡張可能な多目的システムに対する要求がある。単一プログラムで解決することは実用的でない。周知の要件をことごとく処理することはできるが、処理は莫大で、扱いが困難になるであろう。しかし、このようなプログラムがダウンサイズされている場合は、最早、全てのアプリケーションを扱うことができい。あるいはまた、機能を幾つかの小さなプログラムに分割することも可能である。望まなくても、この技法に従ったプログラムの数が多くなる。また、どの機能を所定のプログラムに置くかをどのように決めるのか。一人のユーザの要件をどのプログラムに収めておくのか。ユーザが二人のときはどうするのか。従って、多数のユーザの要求を満たす汎用プログラムに対する要求がある。しかも、個々のユーザがカスタマイズし、特定の要求を満たすように、汎用プログラムに付加することができる汎用プログラムに対する要求がある。 NOVATICA，Vol.17，No.90，1991，Spain，pp.83-89，Navarro‘Que Son La He rienca Y El Polimofismo’には、ラスタディスプレイ上にピクセルから構成される幾何学形状を描くグラフィック・エディタが開示されている。幾何学形状は、矩形、正方形そしてその他の基本幾何学形状を含む。エディタは、C++プログラミング言語を使いクラスとしての図形を表示することを含む。発明の概要オブジェクト指向システムは、従来システムが遭遇する問題を解決するのに適している。オブジェクト指向設計によると、多数のユーザの要求を満たす汎用プログラムは得られるものの、個々のユーザが独自の要求に合うように汎用プログラムをカスタマイズし、強化できるようにした汎用プログラムは得られない。一般的に、オブジェクトは、多くのオペレーションにより特徴付けられるとともに、これらのオペレーションの効果を覚えている状態により特徴付けられる。オブジェクト指向オペレーティング・システムは、システムの明確に範囲が定められたパーツか、あるいは、関数である多くのオブジェクトを備えている。各オブジェクトは、そのオブジェクトに関する情報と、オブジェクトがその情報または自身に渡された情報に対して実行できる１組のオペレーションを含む。例えば、オブジェクトをMANと名づけることが可能である。オブジェクトMANに収められている情報、すなわち、その属性としては、年齢、アドレス、職業などがある。これらの属性はオブジェクトMANを記述している。また、オブジェクトは、そこに収められている情報に対して実行できる１組のオペレーションも含む。従って、MANは、あるオペレーションを実行して、その職業を医者から弁護士に変更することができる。オブジェクトは、互にメッセージを送信して対話する。これらのメッセージは、受信オブジェクトを刺激して、なんらかのアクション、すなわち、そのオブジェクトに含まれるオペレーションの１つ以上を実行する。本発明では、通信オブジェクトは多数存在する。オブジェクトの中には、共通の特性をもち、あるクラスにグループ化される。クラスとはテンプレートであり、同一クラスの他のメンバーと同じ情報とオペレーションを含む新しいオブジェクトを作成することができる。あるクラスから作成されたオブジェクトは、そのクラスのインスタンスと呼ばれる。クラスは、あるインスタンスに最初から入っているオペレーションと情報を定義している。これに対して、インスタンスの現在状態はそのインスタンスに対して実行されるオペレーションによって定義される。従って、所定のクラスの全てのインスタンスは、同等に作成される。これに対して、その後のオペレーションは、同じ親クラスから派生したその兄弟および姉妹と異なり、各インスタンスを一意のオブジェクトにすることができる。多態とは、刺激またはメッセージの送信側が、受信インスタンスのクラスを知っている必要がないことを意味する。どのオブジェクトがそのオペレーションをパフォームするか、そのオブジェクトがどのクラスに属しているかは関係なく、送信側は、受信側があるオペレーションをパフォームすることができることだけを知る必要がある。【手続補正書】特許法第１８４条の８【提出日】１９９５年４月６日【補正内容】請求の範囲 1．コンピュータ（10）のメモリ（14）にストアされたピクセル・データ（38, 38）を、幾何形状（158）を表現するクラス（140,142）として管理し表示する装置であり、ユーザとインタフェースするオブジェクト指向オペレーティング・システム（140）と、該オペレーティング・システムに制御されるデータ・プロセッサ手段（10）と、該データ・プロセッサ手段により制御されるデバイスであって、グラフィック・イメージ（158）を作成するため複数のピクセル（154）を表示するカラー・ディスプレイ・デバイス（38）と、ピクセル・データをストアする複数のロケーション（190）をもつ記憶手段を有する装置であり、前記クラスから導出されたグラフィック・オブジェクトを多態に管理する手段をさらに含む装置（10,12,14,18,20）であって、複数のカラー属性を有する抽象基本クラスであり、前記複数のカラー属性が前記カラー・ディスプレイ・デバイス（38）に表示するためのカラー符号化フォーマットを指定し、前記配列（164）により表現される前記ピクセルにそれぞれ適用可能である抽象基本クラスであり、予め定めた方法で前記複数のピクセルのアピアランスを変更するため、前記複数のロケーションのうち選択したロケーションにあるピクセル・データを修正する複数のメソッド（184,188,200）を有する抽象基本クラスであり、前記複数のメソッドがカラー属性（452）に対応する抽象基本クラスと、前記複数のピクセルは、前記カラー・ディスプレイ・デバイス（38）では、それぞれ、前記オブジェクト指向オペレーティング・システムで、グラフィック・オブジェクトを前記抽象基本クラスの子孫として表現する前記複数のピクセルに対するアピアランスを表示するため、前記カラー・ディスプレイ・デバイスを制御するピクセル・データ（186）を有し、前記ピクセス・データを多態に管理するピクセル・バッファ・オブジェクトであって、前記メモリと前記ピクセル・バッファにストアされた前記ピクセルの実際のデータ・フォーマットとは独立して、前記ピクセル・データを表現する抽象配列（164）を有するピクセル・バッファ・オブジェクト（142）と、前記複数の記憶ロケーション（190）のうちの選択された記憶ロケーションを参照する手段であって、前記選択された記憶ロケーションは前記配列（164）により表現されたピクセルに対応する手段と、前記ピクセル・バッファ・オブジェクトがその抽象基本クラスから作成される時点で、前記ストアされたピクセル・データ・フォーマットに適するメソッドを、抽象基本クラスから選択する手段と、前記カラー属性に応答して、前記カラー属性（452）に対応する前記選択されたメソッドを含む多態ペインタ・オブジェクト（450）を作成し、しかも、前記ピクセル・データ・フォーマットに基づき前記ピクセル・データを多態に操作する手段とを備えたことを特徴とする装置。 2．ユーザとインタフェースするオブジェクト指向オペレーティング・システム（140）と、該オペレーティング・システムにより制御されるデータ・プロセッサ手段（10）と、該データ・プロセッサ手段により制御される装置であって、グラフィック・イメージ（158）を形成するために複数のピクセル（154）を表示するカラー・ディスプレイ・デバイス（38）と、複数のロケーション（190）を有し、ピクセル・データをストアする記憶装置を用いて、コンピュータ（10）のメモリ（14）にストアされた前記ピクセル・データ（36,38）を、幾何形状（158 ）を表わすクラス（140,142）として管理および表示する方法であり、クラスから導出されたグラフィック・オブジェクトを多態に管理する方法であって、前記カラー・ディスプレイ・デバイス（38）上に表示するために、カラー符号化フォーマットを指定する複数のカラー属性であって、前記配列（164）により表現された各ピクセルに適用可能な複数のカラー属性（452）を有する抽象基本クラスを作成するステップであり、前記抽象基本クラスが、予め定めた方法で前記複数のピクセルのアピアランスを変更するため、前記の複数のロケーションのうちの選択されたロケーションのピクセルデータを修正する複数のメソッド（184,188,200）を有し、前記複数のメソッドがそれぞれカラー属性（452）に対応するステップであり、前記複数のピクセルは、前記カラー・ディスプレイ・デバイス（38）では、それぞれ、前記オブジェクト指向オペレーティング・システムで、グラフィック・オブジェクトを前記抽象基本クラスの子孫として表現する前記複数のピクセルに対するアピアランスを表示するため、前記カラー・ディスプレイ・デバイスを制御するピクセル・データ（186）を有するステップと、前記ピクセル・データを多態に管理するためのピクセル・バッファ・オブジェクトを作成するステップであり、前記ピクセル・バッファ・オブジェクト（142）が、前記メモリと前記ピクセル・バッファにストアされた前記ピクセルの実際のデータ・フォーマットとは独立して、前記ピクセル・データを表現する抽象配列（164）を有するステップと、前記複数の記憶ロケーション（190）のうちの選択された記憶ロケーションに対する参照を作成するステップであって、前記選択された記憶ロケーションが前記配列（164）により表現されたピクセルに対応するステップと、前記ピクセル・バッファ・オブジェクトがその抽象基本クラスから作成された時点で、前記ストアされたピクセル・データ・フォーマットに適するメソッドを、抽象基本クラスから選択するステップと、前記カラー属性（452）に対応する前記選択されたメソッドを含む多態ペインタ・オブジェクト（450）を前記カラー属性に応答して作成し、しかも、前記ピクセル・データ・フォーマットに基づき前記ピクセル・データを多態に操作するステップとを備えたことを特徴とする方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．ピクセルデータを多態管理する装置であって、（a）データ処理手段と、（b）ピクセル記憶手段と、（c）ユーザ・インタフェース手段と、（d）データ・プロセッサ上で稼働するオブジェクト指向オペレーティング・システムと、（e）複数のピクセルを表し、複数の属性を有する抽象基本クラスと、（f）抽象基本クラスの属性をもつ新しいオブジェクトを、ユーザが作成することができるオブジェクト作成手段であって、新しいオブジェクトが抽象基本クラスの子孫としてオブジェクト指向オペレーティング・システムに存在するオブジェクト作成手段とを具備したことを特徴とする装置。２．請求の範囲第１項において、オブジェクトに照会して、ストアされた属性を判断するプロセッサ手段を含むことを特徴とする装置。３．請求の範囲第１項において、追加の属性を、新しく作成されたオブジェクトにカプセル化するオブジェクト編集手段を含むことを特徴とする装置。４．請求の範囲第３項において、新しく作成されたオブジェクトは、レンダリングまたはコピーすることができるピクセルバッファを備えたことを特徴とする装置。５．請求の範囲第３項において、新しく作成されたオブジェクトは、blitloopを備えたことを特徴とする装置。６．請求の範囲第３項において、新しく作成されたオブジェクトは、Getピクセル・メモリ変更機構を備えたことを特徴とする装置。７．請求の範囲第３項において、新しく作成されたオブジェクトは、SetPixelピクセル・メモリ変更機構を備えたことを特徴とする装置。８．請求の範囲第３項において、新しく作成されたオブジェクトは、BitBltピクセル・メモリ変更機構を備えたことを特徴とする装置。９．請求の範囲第３項において、新しく作成されたオブジェクトは、CopyImage ピクセル・メモリ変更機構を備えたことを特徴とする装置。 10．請求の範囲第３項において、新しく作成されたオブジェクトは、相関バック・バッファを備えたことを特徴とする装置。 11．請求の範囲第３項において、新しく作成されたオブジェクトは、ピクセル転送モード備えたことを特徴とする装置。 12．請求の範囲第３項において、新しく作成されたオブジェクトは、新しいイメージ型を備えたことを特徴とする装置。 13．請求の範囲第１項において、基本クラスは、MCollectibleから導出されたTP ixelBufferであることを特徴とする装置。 14．請求の範囲第３項において、新しく作成されたオブジェクト属性は、アクティブ境界オブジェクトを含むことを特徴とする装置。 15．請求の範囲第13項において、新しく作成されたオブジェクト属性は、参照解像度を含むことを特徴とする装置。 16．請求の範囲第13項において、新しく作成されたオブジェクト属性は、参照配向を含むことを特徴とする装置。 17．請求の範囲第３項において、新しく作成されたオブジェクトは、連続座標と離散ピクセル・オブジェクトとの間の変換を含むことを特徴とする装置。 18．請求の範囲第３項において、新しく作成されたオブジェクトは、比色特徴付けオブジェクトを含むことを特徴とする装置。 19．請求の範囲第３項において、新しく作成されたオブジェクトは、TSpanPaint erオブジェクトを含むことを特徴とする装置。 20．請求の範囲第３項において、新しく作成されたオブジェクトは、THairLineP ainterオブジェクトを含むことを特徴とする装置。 21．請求の範囲第３項において、新しく作成されたオブジェクトは、TAntialias HairLinePainterオブジェクトを含むことを特徴とする装置。 22．請求の範囲第３項において、新しく作成されたオブジェクトは、TGlyphPain terオブジェクトを含むことを特徴とする装置。 23．請求の範囲第３項において、新しく作成されたオブジェクトは、TAntialias edGlyphPainterオブジェクトを含むことを特徴とする装置。 24．請求の範囲第３項において、新しく作成されたオブジェクトは、BitBltオブジェクトを含むことを特徴とする装置。 25．請求の範囲第３項において、新しく作成されたオブジェクトは、CopyImage オブジェクトを含むことを特徴とする装置。 26．請求の範囲第３項において、新しく作成されたオブジェクトは、CopyImage オブジェクトを含むことを特徴とする装置。 27．請求の範囲第３項において、新しく作成されたオブジェクトは、StreamPixe lBlockオブジェクトを含むことを特徴とする装置。 28．請求の範囲第３項において、新しく作成されたオブジェクトは、StreamRect ilinearRotatedPixelBlockオブジェクトを含むことを特徴とする装置。 29．請求の範囲第３項において、新しく作成されたオブジェクトは、StreamScal edPixelBlockオブジェクトを含むことを特徴とする装置。 30．請求の範囲第３項において、新しく作成されたオブジェクトは、StreamAndF ilterScaledPixelBlockオブジェクトを含むことを特徴とする装置。 31．請求の範囲第３項において、新しく作成されたオブジェクトは、StreamPixe lsIntoConvexPolygonオブジェクトを含むことを特徴とする装置。 32．請求の範囲第３項において、新しく作成されたオブジェクトは、 StreamAndFilterPixelsIntoConvexPolygonオブジェクトを含むことを特徴とする装置。 33．請求の範囲第３項において、新しく作成されたオブジェクトは、TComponent InterleavedPixelBufferオブジェクトを含むことを特徴とする装置。 34．ピクセル・データを多態管理する方法であって、（a）データ処理手段を供給するステップと、（b）ピクセル記憶手段を供給するステップと、（c）ユーザ・インタフェース手段を供給するステップと、（d）データ・プロセッサ上で稼働するオブジェクト指向オペレーティング・システムを供給するステップと、（e）複数のピクセルを表し、複数の属性をもつ抽象基本クラスを供給するステップと、（f）オブジェクト作成手段を供給し、抽象基本クラスの属性をもつ新しいオブジェクトを作成し、新しいオブジェクトは抽象基本クラスの子孫としてオブジェクト指向オペレーティング・システムに存在するステップとを備えたことを特徴とする方法。 35．請求の範囲第34項において、オブジェクトに照会してオブジェクト属性を判断するステップを含むことを特徴とする方法。 36．請求の範囲第34項において、新しく作成したオブジェクトを編集して追加の属性を、新しく作成されたオブジェクトにカプセル化し、多態ピクセル・データ管理を行うステップを含むことを特徴とする方法。 37．データを多態管理する装置であって、（a）処理手段と、（b）記憶手段と、（c）インタフェース手段と、（d）プロセッサ上で稼働するオペレーティング・システムと、（e）複数のデータを表し、複数の属性をもつ抽象基本クラスと、（f）抽象基本クラスの属性を有する新しいオブジェクトをユーザが作成するのを可能にするオブジェクト作成手段であって、新しいオブジェクトは抽象基本クラスの子孫としてオペレーティング・システムに存在するオブジェクト作成手段とを具備したことを特徴とする装置。