JPH08512156A

JPH08512156A - 図形エッジ・システム

Info

Publication number: JPH08512156A
Application number: JP7503456A
Authority: JP
Inventors: ウェッブ，リチャード，ディー．; カブラル，オーサー，ダブリュ．
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-06-30
Filing date: 1994-01-03
Publication date: 1996-12-17
Anticipated expiration: 2018-03-31
Also published as: EP0691012A1; CA2144870A1; EP0691012B1; JP3392870B2; CN1113666A; US5471568A; WO1995001615A1; AU6081794A; DE69410458D1

Abstract

(57)【要約】図形オブジェクトをメモリにロードし、この図形オブジェクトを複数のエッジ・オブジェクトに変換し、このエッジ・オブジェクトを複数の走査線ピクセルに変換し、かつディスプレイ上にこの走査線ピクセルおよび図形オブジェクトを表示することによって、メモリおよび付属ディスプレイを有するコンピュータ上で、図形オブジェクトを処理する方法およびシステム。

Description

【発明の詳細な説明】図形エッジ・システム著作権通知書本特許出願は、一部に、著作権保護の対象となる内容を含んでいる。何人が特許書類または特許開示事項を、米国特許商標局の特許ファイルまたは記録の通り、ファクシミリ複製しても、著作権者はそれを妨げるものではないが、そうでない場合は一切の著作権を留保する。技術分野本発明は、コンピュータ・システムの改良に関し、特に、グラフィック・ディスプレイ上のエッジ情報を処理するシステムおよび方法に関する。背景技術美学的、人間工学的方法で情報を表示するために、エッジ情報をグラフィック処理することは非常に厄介なことである。したがって、最新のグラフィック・システムは、テキストおよび図形情報を含む広範囲の情報を処理する情報ハンドリング・システムを利用しているが、このシステムはこのような情報をより人間工学的な方法で処理するため、ますます精巧になっている。例えば、選択された方法で、図形エッジ情報をプログラミングするか、あるいは処理するコンピュータ・プログラマまたはコンピュータ・ユーザの能力には限界がある。従来のソフトウェアOS(operationg system)アーキテクチャは、エッジ処理能力に限界があった。その限界の１つには、OSアーキテクチャが所定の周辺デバイス用に設計されていないか、所定の周辺デバイスをサポートできるようにOSアーキテクチャを修正することができない場合、OSアーキテクチャはその周辺デバイスをサポートすることができないということが挙げられる。また、従来のアーキテクチャは図形エッジ情報を予め定義された単一の方法で処理できるだけである。発明の開示従って、本発明の主な目的は、メモリおよび付属のディスプレイを有するコンピュータによって、図形オブジェクトと、これらの図形オブジェクトに関係付けをしたエッジを柔軟に処理することにある。本発明の目的は、図形オブジェクトをメモリにロードし、この図形オブジェクトを複数のエッジ・オブジェクトに変換し、このエッジ・オブジェクトを複数の走査線ピクセルに変換し、この走査線ピクセルをディスプレイ上に表示することによって達成される。図面の簡単な説明第１図は好ましい実施態様に係るパーソナル・コンピュータ・システムのブロック図である。第２図は好ましい実施態様に係る図形エッジ対を示す図である。第３図は好ましい実施態様に係るソート順を示す図である。第４図は好ましい実施態様に係る星型多角形、奇偶規則を示す図である。第５図は好ましい実施態様に係るワインディング数(winding number)規則を採用する星型多角形を示す図である。第６図は好ましい実施態様に係る有心奇偶規則に従う星型多角形の有心フレームを示す図である。第７図は好ましい実施態様に係る有心ワインディング数規則に従う星型多角形の有心フレームを示す。第８図は好ましい実施態様によるインセット奇偶規則に従う星型多角形のインセット・フレームを示す図である。第９図はワインディング数規則に従う星型多角形のインセット・フレームを示す図である。第10図は好ましい実施態様に係るアウトセット奇偶規則に従う星型多角形のアウトセット・フレームを示す図である。第11図は好ましい実施態様に係るアウトセットワインディング数規則に従う星型多角形のアウトセット・フレームを示す図である。第12図は好ましい実施態様に係る個別装置によって使用されるエッジ・エンジンを示す図である。第13図は好ましい実施態様に係る図示された構造を有する領域プリミティブである。第14図は好ましい実施態様に係る現在位置の状態を決定する方法を示す図である。第15図は好ましい実施態様に係る種々のエッジを示す図である。第16図は好ましい実施態様に係る＋ｙ方向の走査変換を示す図である。第17図は好ましい実施態様に係る直線エッジの例を示す図である。第18図は好ましい実施態様に係る論理のフローチャートである。第19図は本発明に係るエッジ遷移処理の実施態様を示すフローチャートである。第20図は本発明に係るエッジ遷移処理の実施態様を示すフローチャートである。第21図は本発明に係るエッジ遷移処理の実施態様を示すブロック図である。発明の実施するための最良の形態本発明は、パーソナル・コンピュータ、例えば、IBM（登録商標）のPS/2（登録商標）またはApp1e（登録商標）のマッキントッシュ（登録商標）のようなパーソナルコンピュータに駐在する0Sのコンテキストで実施されるのが好ましい。代表的なハードウェア環境を第１図に示す。この代表的なハードウェア環境は、本発明に係るコンピュータの典型的なハードウェア構成を示しており、このコンピュータはCPU(central processing unit)10、例えば、慣用のマイクロプロセッサを有し、不揮発性メモリ11が内蔵されており、システムバス12を介して多数の他の装置が相互接続されている。第１図に示すワークステーションは、RAM(rand om access memory)14と、ROM(read only memory)16と、I/Oアダプタ18と、ユーザ・インタフェース・アダプタ22と、通信アダプタ34と、ディスプレイ・アダプタ36を含む。I/Oアダプタ18は周辺装置、例えば、ディスク・ユニット20およびディスケット・ユニット21のような周辺装置をシステムバスに接続するためのものである。ユーザ・インタフェース・アダプタ22はキーボード24、マウス26、スピーカ28、マイクロホン32および／またはユーザ・インタフェース装置、例えば、タッチ・スクリーン装置（図示せず）のようなユーザ・インタフェース装置をシステムバスに接続するためのものである。通信アダプタ34はワークステーションをデータ処理ネットワーク23に接続するためのものである。ディスプレイ・アダプタ36はシステムバスをディスプレイ装置38に接続するためのものである。このコンピュータには、OS、例えば、App1e System/7（登録商標）のようなOSが駐在している。好ましい実施態様では、本発明は、OOP(object-oriented programming)技術を用いて、C++プログラミング言語で実装される。当業者にとって当然のことであるが、0OPオブジェクトは、データ構造と、データに対するオペレーションとを備えたソフトウェア・エンティティである。同時に、これらの要素により、オブジェクトはデータ要素により表される特性と、データ操作機能によって表されるその振る舞いの観点から、任意のリアル・ワールド・エンティティをバーチャルにモデル化することができる。このように、オブジェクトは人間およびコンピュータのような具体的な事物をモデル化することができ、しかも、オブジェクトは数または幾何学的概念のような抽象的な概念をモデル化することができる。オブジェクト技術の利点は、３つの基本原理、すなわち、カプセル化と、ポリモフィズム（多形）と、継承から生じる。オブジェクトは、そのデータの内部構造と、オブジェクトが機能するアルゴリズムを隠蔽、すなわちカプセル化する。これらの実装の細部を露出する代わりに、オブジェクトは、外部からの情報を一切有しない抽象化を完全に表すインタフェースを表示する。その多形はさらに１ステップだけカプセル化する。そのアイディアとは多くの形態、１つのインタフェースである。ソフトウェア・コンポーネントは、そのコンポーネントが何であるかを正確に知らないので、他のコンポーネントを要求することができる。この要求を受けるコンポーネントは、その要求を解釈し、その変数およびデータに従って、その要求をどのように実行するかを理解する。第３の原理は継承である。この継承により、デベロパーは前から存在する設計およびコードを再使用することができる。よって、デベロパーは初めからソフトウェアを作成しなくて済むことになる。それどころか、継承によって、デベロパーは振る舞いを継承するサブクラスを導出しており、デベロパーはサブクラスをデベロパーの特定の要求を満足させるためにカスタマイズしている。従来のアプローチでは、手続き環境で、オブジェクトを階層化し、ライブラリをクラス化している。市販のアプリケーション・フレームワークは、この設計アプローチを採っているものが多い。この設計では、モノリシックOSの頂上に１つ以上のオブジェクト層が存在する。このアプローチでは、オブジェクト層で、カプセル化と、多形と、継承という全ての原理を利用しており、しかも、このアプローチは手続きプログラミング技術を実質的に改良したものであるが、この方法には限界がある。この方法の限界は次のようなことから生じる。すなわち、デベロパーが手続きプログラミング技術のオブジェクトを再使用することは容易であるが、他のシステムからオブジェクトを使用することは困難であり、しかも、デベロパーは、依然、手続きOSコールにより、下位の非オブジェクト層に到達する必要があることから生じる。 OOPの他の態様は、フレームワークのアプリケーション開発へのアプローチである。フレームワークの定義として、the University of IllinoisのRalph E.Jo nsonと、PurdueのVincent F.Russoから最も合理的な定義が得られた。1991年の論文、すなわち、Reusing Object−Oriented Designs,University of Illinois tech report UIUCDCS91−1696で、Ralph E.JonsonとVincent F.Russoは次のように定義している。すなわち、「抽象クラスとは、責任のセットを遂行するために協働するオブジェクトのセットの設計である。従って、フレームワークとは、コンピューティング責任の定義されたセットを実行するため協働するオブジェクト・クラスのセットである。」と定義している。プログラミングの観点からいうと、フレームワークは、本質的には、ワーキング・アプリケーションの前もって作成された構造を提供するオブジェクト・クラスであって、相互接続されたオブジェクト・クラスのグループである。例えば、ユーザ・インタフェース・フレームワークであれば、ウィンドウと、スクロールバーと、メニュー等のドローイングをサポートし、それらの「デフォルト」な振る舞いを提供することができる。フレームワークがオブジェクト技術に基づいているので、デベロパーはこの振る舞いを継承、かつ、オーバライドして、フレームワークを拡張し、カスタマイズされた解決法を、専門的知識の特定の領域で生み出すことができる。この点は伝統的なプログラミングに勝る主な利点である。というのは、プログラマはオリジナルなコードを変更しないが、ソフトウェアを拡張するからである。さらに、デベロパーはコードの層を無闇に行き来していない。というのは、フレームワークはアーキテクチャを導き、アーキテクチャをモデル化し、同時に、コードの層を解放して、問題ドメインに特有の特定のアクションを供給するからである。ビジネスの観点から言うと、フレームワークは、専門的知識を特定の知識領域でカプセル化するかあるいは具体化する１つの方法として見ることができる。企業の開発組織と、独立のソフトウェア・ベンダー(ISV)と、システム・インテグレータは、既に例を挙げたが、特定の領域、例えば、製造、金融、または為替のような特定の領域で、専門的な知識を獲得してきた。この専門的な知識は自らのコードで具体化される。企業は、その企業のコードで、その専門的知識をフレームワークにより具体化して、その専門的知識の共通の特性を獲得し、パッケージ化することができる。最初に、このようにして、デベロパーは専門的な知識を利用するアプリケーションを作成するか拡張することができ、従って、この問題が一度解決され、ビジネス規則および設計が絶えず強化され使用される。また、フレームワークと、これらフレームワークの背後にある専門的知識は、戦略資産として、垂直市場(vertical market)、例えば、製造、金融のような垂直市場で、専門的な知識を獲得してきた企業に影響を与えている。さもないと、バイオ技術なんかが、これらの専門的知識をパッケージ化し、リセリング(reselling)し、展開し、さらに技術の進歩および普及を促進するための販売機構を持つことになるのである。歴史的に言えば、フレームワークは、つい最近、パーソナル・コンピューティング・プラットホームに関する主流の概念として出現した。このマイグレーションが支えられているのは、C++のようなオブジェクト指向言語が利用可能になったからである。伝統的には、C++は、商業的背景のパーソナル・コンピュータよりも、UNIXシステムや、研究者のワークステーション上で使用されるのがほとんどである。多くの大学および研究プロジェクトにより、今日の商用フレームワークおよびクラス・ライブラリの先駆者を作らせたのが、C++のような言語と、Sma lltalkのようなオブジェクト指向言語、等々である。例えば、Stanford Univers ityのInterViewsと、Carnegie-Mellon UniversityのAndrew toolkitと、Univers ity of ZurichのET++フレームワークがある。種々のタイプのフレームワークはシステムのレベルと問題の性質に依存している。フレームワークのタイプは、ユーザ・インタフェース開発を支援するアプリケーション・フレームワークから、基本的なシステム・ソフトウェア・サービス、例えば、通信と、印刷と、ファイル・システム・サポートと、グラフィックス等のようなサービスを提供する低レベルフレームワークに及んでいる。市販のアプリケーション・フレームワークとしては、MacAPP(Apple)と、Bedrock(Symante c)と、OWL(Borland)と、NeXTStep App Kit(NeXT)と、Smalltalk-80 MVC(ParcPla ce)がある。フレームワークを用いたプログラミングは、他の種類のシステムに慣れたデベロパーに新しい思考法を要求するものだ。実際、フレームワークを用いたプログラミングは、伝統的な意味では、「プログラミング」に似つかわしくないのである。DOSまたはUNIXのような旧いタイプのOSでは、デベロパー自身のプログラムが全ての構造を提供するのであり、OSはシステム・コールによってサービスを提供する。すなわち、デベロパーのプログラムがサービスを必要とするとき、そのプログラムがコールを行い、サービスが提供されたとき、制御を戻すのである。プログラム構造は、デベロパーにより書かれたコードで具体化された制御のフローに基づいている。このことはフレームワークが使用されたときは撤回される。デベロパーはもはや制御の流れに責任を負わないのである。デベロパーは実行のフローによってプログラミング作業を理解するという風潮より先んじていなければいけない。この考え方は、いつタスクが実行されるかを決定するために、フレームワークを信頼しなければならず、オブジェクトの責任によらなければならない。デベロパーが書いたルーチンは、デベロパーが書いてもいないし、見てもいないコードによって活動化される。このように制御フローが突然転換することは、手続きプログラミングのみの経験を積んだデベロパーの大きな心理的な障げになり得るのである。しかしながら、このことが一旦理解されると、フレームワーク・プログラミングは他のタイプのプログラミングよりも作業量が非常に少なくなる。アプリケーション・フレームワークがデベロパーにプレハブ機能を提供するのと同様の方法で、システム・フレームワーク、例えば、好ましい実施態様で含まれるようなシステム・フレームワークは、システム・レベル・サービスを提供して同一の概念をレバレッジする。この同一の概念を用いて、システム・プログラマのようなデベロパーはサブクラス化／オーバライドし、カスタマイズされた解決法を作成する。例えば、マルチメディア・フレームワークを考えてみよう。マルチメディア・フレームワークは新して多様な装置、例えば、オーディオと、ビデオと、MIDIと、アニメーションと、等々のような装置をサポートするための基盤を提供する。新しい種類の装置をサポートするのに必要なデベロパーは、デバイス・ドライバを書かなければならなくなる。フレームワークを用いてデバイス・ドライバを書くには、デベロパーは新しい装置の特性と、その新しい装置に特有の振る舞いを供給するだけでよい。この場合、デベロパーはマルチメディア・フレームワークによってコールされるあるメンバー関数にインプリメンテーションを供給する。デベロパーが直接得る利益は、装置の各カテゴリに対して必要なジェネリックなコードが、マルチメディア・フレームワークによって既に提供されていることである。これは、デバイス・ドライバ・デベロパーが書き、試験し、デバッグするコードが少ないことを意味する。システム・フレームワークを使用する他の例を挙げると、SCSI装置と、NuBusカードと、グラフィックス・ドライバに対する別々のI/Oフレームワークを有することにある。継承された機能が存在するため、各フレームワークはそのデバイス・カテゴリーにある共通の機能をサポートする。従って、他のデベロパーは、全ての種類のデバイスに対するインタフェースに一貫して依存することができる。好ましい実施態様では、フレームワークの概念を採用しており、その概念をシステム全体に適用している。企業のデベロパーか、システム・インテグレータか、あるいはOEMにとって、このことは次のようなことを意味する。すなわち、Mac Appのようなフレームワークのために説明してきた利点を、テキストおよびユーザ・インタフェースのような事物に対しては、アプリケーション・レベルでレバレッジできるだけでなく、サービス、例えば、グラフィックスと、マルチメディアと、ファイル・システムと、I/Oと、試験と、等々のようなサービスにとっては、システム・レベルでレバレッジすることができる。好ましい実施態様のアーキテクチャでアプリケーションを作成することは、本質的には、フレームワーク・プロトコルに付着するドメイン特有のパズルのピースを書くのに似ている。このように、プログラミングの全概念は変化する。多重 API階層をコールするコードの行ごとに書く代わりに、この環境内に前から存在していたフレームワークからクラスを導出し、ついで、新しい振る舞いを付加し、かつ／あるいは、継承された振る舞いをオーバライドして、ソフトウェアが開発されることになる。従って、デベロパーのアプリケーションは、書かれたコードのコレクションであって、他の全フレームワーク・アプリケーションと共有されるコードのコレクションになる。デベロパーは互いの作品の上に築きあげることができるので、これは強力な概念である。この概念も必要なだけカスタマイズする柔軟性をデベロパーに与える。フレームワークの中には、そのまま用いられものもある。カスタマイズの程度は最少なので、デベロパーが加担するパズルのピースは小さくなることがある。デベロパーが非常に細な修正をして、何か全く新しいものを作成する場合もある。好ましい実施態様では、第１図で示すように、RAM 14に常駐し、しかも、CPU10により制御されるプログラムは、オブジェクト指向のグラフィック・フレームワークを使用して、種々のタスクを管理することを担当する。好ましい実施態様では、TGrafEdgeのリストを操作するためにレンダリング・パイプラインのエッジ・エンジンを採用している。エッジ・エンジンは個別のデバイスだけで使用されている。例えば、TFrameBufferデバイスでは、エッジ・エンジンは、プリミティブのうちの塗り潰されかつフレーム化(framed)された部分を表すエッジから走査線のスパンを生成する。この処理は走査変換として公知である。 TGrafEdgeは多形の走査変換プリミティブである。一対の図形エッジを第２図に示す。図形エッジ230,240は、それぞれ、最小Ｙ値が210、開始Ｘ値が200、高さが220であり、virtualStepメソッドを有する。virtualStepメソッドは次の走査線（次の整数Ｙ値）に対してＸ値を更新する。従って、TGrafEdgeはＹが単調な任意の曲線を記述することができる。すなわち、TGrafEdgeはスパンされる走査線ごとに単一のＸ値を有する。TGrafEdgeも単一のCAGノード・オブジェクトに対してリファレンスを有する。このレファレンスを用いて、ある点が全幾何学形状の内部にあるか外部にあるかを判定するのに用いられる。簡単なプリミティブはレンダリングするのが容易である。簡単なプリミティブは、ある点が幾何学形状の内部にあるか外部にあるかを判定するための単一のラップ・カウントを有する。一方、TGAreaプリミティブは、任意に複雑にすることができる。サブ・プリミティブはそれぞれ独立のラップ・カウントを有する。サブ・プリミティブのラップ・カウント値は全て全プリミティブの状態を計算するのに用いることができる。内部／外部の計算を行うための構造はTGAreaによってセットアップされ、エッジ・エンジンに渡される。しかし、TGAreaプリミティブに対してのみ、より複雑な内部／外部計算に関連するオーバヘッドがある。エッジ・エンジンのサブクラスはアンチ・エイリアシング走査変換を行うことになり、加速されたエッジ、例えば、直線エッジのようなエッジに対して、エッジ・エンジンのサブクラスをmakeすることができる。ピクセル・パーフェクション(pixel perfection)はエッジ・エンジンにとって重要である。というのは、エッジ・エンジンが個別のデバイス・ユニットへの走査変換を行うからである。ピクセル・パーフェクションは、どのピクセルが変更され、どのピクセルに、デバイス空間の領域を規定するエッジのセットが付与されるかを規定する。たとえ「ピクセル」という用語を用いるとしても、ピクセル・パーフェクションは他の個別のデバイスに対しても有用である。というのは、個別のユニットがデバイス座標系のどこにあるのかが、ピクセル・パーフェクションにより規定されるからである。走査変換は、個別のグラフィック・デバイス上にドローイングすることができる幾何学形状を、水平走査ライン・スパンに変換する処理である。幾何学形状を、塗り潰すか、フレーム化するか、あるいは塗り潰しかつフレーム化することができる。塗り潰しおよび／またはフレーム化された幾何学形状をドローイングするためのアルゴリズムは、どの領域も２度ドローイングされないし、変換(trans fer)モードが正確に機能し、正確に透過することができることを保証する。エッジ・エンジンにより、輪郭を表すTGrafEdgeのリストにより規定される幾何学形状が塗り潰される。ユーザは、幾何学形状の周辺を任意の方向にトレースすることにより、幾何学形状の輪郭を指定することができる。こうすることにより、リスト中の各エッジの符号が決定される。エッジが＋ｙ方向を指す場合は、エッジの符号は＋である。出力に影響を与えないエッジは廃棄される。第３図は好ましい実施態様に係るソート順を示す。エッジは、最初に、降順にｙ値によりソートされ、ついで、特定のｙ値内のｘ値によりソートされる。エッジを交差する各走査線に対して、ｘ方向に１つ以上のスパンが生成される。これは、エッジの「アクティブ」リスト、すなわち、現走査線を交差するエッジを常に保持することにより達成される。各走査線に対して、アクティブ・エッジ・リストが作成される。そして、エッジが交差されると、次の規則、すなわち、奇偶規則(Even-odd rule)またはワインディング数規則(Winding number rule)のいずれかにより、走査線に対して適正なスパンが生成される。奇偶規則：エッジに出会う度に、スパンの開始または終了のいずれかが行われる。第４図は好ましい実施態様に係る各エッジ対に対して生成された星型スパンの例である。ワインディング数規則：エッジが交差されると、そのエッジの符号がワインディング数に付加される。ワインディング数はゼロに初期設定されている。ワインディング数が非ゼロであると、スパンが開始される。このワインディング数がゼロになると、スパンが終了される。その結果、多角形の外部境界内の全ての領域が塗り潰される。第５図は好ましい実施態様に係るワインディング数規則を用いる星型多角形の例を示す。適用される規則は、レンダリングされているプリミティブに依存する。例えば、多角形の図形オブジェクトを定義するTGPolygonプリミティブは、どの規則を使用するかを指定するパラメータを含む。他方、TGEllipseプリミティブはいずれかの規則を用いることができる。というのは、内部に交点を持たない(nonself −intersecting)幾何学形状に両方の規則が適用されたとき、それらの規則により、同一の結果を生じるからである。２種類のフレームを、フレーム（ヘヤライン・フレームおよび太いフレーム）の意図された目的に従って、オブジェクトの周囲にドローイングすることができる。これらのフレームは次に説明する。太いフレームは、任意の太さを有することができる。エンド・キャップ(end c ap)と、ジョイント・スタイル(joint style)と、ダッシング(dashing)を、希望どおり適用することができる。エッジ・エンジン走査により、太いフレームおよび塗り潰しが同時に変換される。フレームの両側（右側および左側）を表すTGra fEdgeが生成され、かつ塗り潰しエッジを有するリストに挿入される。フレーム・エッジの方向、従って、フレーム・エッジの符号は、フレーム・エッジから作成された塗り潰しエッジの方向と同一である。プリミティブが走査変換されると、２つのワインディング数、すなわち、左フレーム・エッジに対するワインディング数と、右フレーム・エッジに対するワインディング数が保持される。フレームに対して生成されたスパンは、どの塗り潰し規則が用いられたかに依存する。奇偶規則：フレーム・エッジが出合うと、フレーム・エッジの符号が適正なワインディング数（左側または右側）に付加される。２つのワインディング数が等しくなくなると、スパンが開始される。２つのワインディング数が再び等しくなると、スパンが終了される。ワインディング数規則：フレーム・エッジが出合うと、フレーム・エッジの符号が適正なワインディング数（左側または右側）に付加される。２つのワインディング数の符号が等しくなくなると、スパンが開始される。符号が再び等しくなると、スパンが終了される。どのペン・バランスが使用されるかによって、塗り潰された領域にフレームを重ね合わすことができる。しかしながら、塗り潰された領域とフレームが一緒にドローイングされるので、その領域はどの部分も２度はドローイングされない。有心ペンの場合、フレームの太さは塗り潰された領域の輪郭に集中する。これは、フレームのために生成されたスパンが、塗り潰すために生成されたスパンに取って代わることができる場合に達成される。第６図は好ましい実施態様に係る有心奇偶規則に従う星型多角形の有心フレームを示し、第７図は好ましい実施態様に係る有心ワインディング数規則に従う星型多角形の有心フレームを示す。インセット・ペン(inset pen)の場合、フレームの太さは、塗り潰された領域の輪郭の完全に内側にある。フレームのために生成されたスパンは、塗り潰すために生成されたスパンにとって代わるが、これらは、充填スパンが生成されたときだけドローイングされる。言い換えると、そのフレームはクリップされ塗り潰し幾何学形状に付加される。これはアウトセット・フレーム(outset frame)の逆になる。第８図は好ましい実施態様に係るインセット奇偶規則に従う星型多角形のインセット・フレーム(inset frame)を示す。第９図はワインディング数規則に従う星型多角形のインセット・フレームを示す。アウトセット・ペンの場合、フレームの太さは塗り潰し領域の輪郭の完全に外側にある。フレームのために生成されたスパンは、塗り潰しスパンがドローイングされないときだけドローイングされる。言い換えると、フレームは塗り潰し幾何学形状の内側には決してドローイングされることはない。第10図は好ましい実施態様に係るアウトセット奇偶規則に従う星型多角形のアウトセット・フレームを示す。第11図は好ましい実施態様に係るアウトセット・ワインディング数規則に従う星型多角形のアウトセット・フレームを示す。エッジ・エンジン・エイリアシング・サブクラス第12図は個別の装置によって使用されるエッジ・エンジンを示す。アンチ・エイリアシングされたエッジ・エンジンは図示されていない。TEdgeEngineは抽象クラスであり、その抽象クラスから全てのエッジ・エンジンが導出される。TEdg eEngineはTGrafEdgeを受取るpureな仮想関数を含む。TGrafEdgeはpureな仮想Ren der関数を含む。 TFillEdgeEngineは、TGrafEdgeのリストで記載された幾何学形状に対して、エイリアシングされた塗り潰しを行う。エッジは任意のタイプが可能である。 TRectilinearFillEdgeEngineは、直線のTGrafEdgeのリストで記載された幾何学形状のエイリアシングされた塗り潰しを行う。それは、TFillEdgeEngineの最適化である。各TGrafEdgeが垂直線であるものと仮定する。 TFillAndFrameEdgeEngineは、TGrafEdgeのリストで記載された幾何学形状のエイリアシングされた塗り潰しを行い、エイリアシングされたフレーム化を行う。エッジは任意のタイプが可能である。 TRectilinearFillAndFrameEdgeEngineは、直線のTGrafEdgeのリストで記載された幾何学形状に対してエイリアシングされた塗り潰しを行い、エイリアシングされたフレーム化を行う。それはTFillEdgeEngineの最適化である。各TGrafEdge が垂直線であるものと仮定する。エッジ・エンジン・アンチ・エイリアシング・サブクラスエッジ・エンジンをサブクラス化するための他の理由は、アンチ・エイリアシングに適応させることにある。有効な実装により、フィルタ・カーネル(kernel) によりエッジの周りの領域のみを巻き込む共通の最適化が行なわれる。この最適化により、その形の内部で行われる多量のフィルタリング演算が回避され、同様に、用いられる簡単なnon compositing TSpanPainterメソッド、例えば、PaintS panのようなメソッドを使用することもできる。アンチ・エイリス・エッジ・エンジンの場合は、エッジを巻き込む２つのアプローチを行うことができる。スーパ・サンプリング・アプローチ走査は、より高解像度で、レンダリングを、サブピクセル・レベルで詳細に表現するサブピクセル・ビットマップに変換する。あるいはまた、サブピクセル走査変換を予め計算して、次のようなテーブルにする。このテーブルは、幾つかの有意ビットにより、エッジの入口および出口座標の小部分(fractional)コンポーネントからインデックスされるものである。これらのビットマップは典型的には４×８ピクセルである。ボックス・フィルタが使用されている場合は、必要とされるものは全てビットマップ母集団のタリーである。0.5を超える大きさの支持体サイズ(support size)を有するより高品質のフィルタが使用された場合は、出力されたピクセルの透過は、それぞれ、それ自身のビットマップと、隣接のビットマップの重み付け平均値から決定される。より高品質のフィルタにより、１つの付加的な問題が課せられる。その寄与しているサブピクセル・ビットマスクが、全て、フィルタ・カーネルで巻き込まれ、かつ加算されるまで、走査線を出力することはできない。これは、エッジ・エンジンがその走査変換より１，２走査線遅れてスパンを出力することになることを意味する。これらのアプローチは、頂点が整数であるか、あるいは隠れた面を解明する必要があるときに採られるのが典型的である。予めフィルタリングするアプローチは、エッジを含む各ピクセルで、正確な領域計算を採用している。これは高価であるようであるが、そのことには、実際には、有効なインクリメンタル解法がある。走査線上の所定のエッジ対の場合は、注目する高々３つの領域、すなわち、左エッジと、中間かあるいは完全にカバーされたピクセルと、右エッジが存在することができる。エッジが交差した全てのピクセルは、その領域が計算されていなければならない。幾つかの隣接したピクセルが共通エッジによって交差された場合は、引き続き交差するピクセルに対する領域を、インクリメントに計算することができる。所定の傾斜を有するエッジの場合は、ピクセルからピクセルまでの領域の差は一定である。この仮定に基づいたアプローチはより魅力的である。どちらのアルゴリズムが採用されても、２つのエッジのケースがかち合うかもしれない。分離されたエッジの第１のケースは最も普通である。全てのエンジンはこのケースに遭遇する。フレーム化のみエッジ・エンジンか、塗り潰しのみエッジ・エンジンからのエッジは、全ては、このカテゴリに属する。塗り潰しおよびフレーム化エッジ・エンジンは、フレームの外部エッジ上でこのケースに遭遇する。エッジの不透明性(edge opacity)が判定された後、不透明でないピクセルは、TSpanPainterのCompositeSpanメソッドによってデスティネーション・ピクセルと合成されなければならない。第18図は好ましい実施態様に係るロジックのフローチャートである。処理は機能ブロック1800で開始され、所定の幾何学形状、例えば、矩形か、楕円か、あるいは多角形のような幾何学形状からエッジを生成する。そして、機能ブロック18 10にて、エッジのｙ値を、１次ソート・フィールドとして、昇順でソートし、エッジのｘ値を、２次ソート・フィールドとして、昇順でソートする。ついで、機能ブロック1820にて、現在の走査線を第１のエッジのｙ値に初期設定し、機能ブロック1830にて、新しいエッジをコレクトしてアクティブ・エッジ・リストに入れる。（アクティブ・エッジ・リストとは、現在の走査線を交差するエッジのリストである）。機能ブロック1840にて、エッジが現在の走査ラインを最早交差しない場合は、エッジはアクティブ・エッジ・リストから除去される。機能ブロック1850にて、ステップ関数が全アクティブ・エッジに対してコールされ、エッジの順序が狂っているかどうかを検出する。（エッジのステップ関数は現在の走査線に対応する次のｘ値を計算する）、そして、判定ブロック1860にて、試験を行って、エッジをｘ値でソートする必要があるかどうかを判定する。新しいエッジが付加される場合か、古いエッジが除去される場合か、あるいは、エッジが交差した場合は、ｘ値でソートする必要がある。ソートが必要な場合には、機能ブロック1870にて、アクティブ・リストをｘ値で昇順でソートし、制御を機能ブロック1880に渡す。ソートする必要がない場合は、制御を機能ブロック1880に直接渡す。機能ブロック1880にて、各アクティブ・リストに対して、試験を行って、エッジを交差した結果、幾何学形状の外部に遷移し、しかも、現在の走査線上にピクセルをドローイングすることになるかどうかを判定する。エッジ遷移関数を用いて、内部／外部検出を行う機構を一般化することができる。その論理の検討は第 19図、第20図および第21図を参照して行う。第19図、第20図および第21図はこの処理の種々の実施態様を示す。ついで、判定ブロック1890にて、試験を行って全てのエッジが処理されたかどうかを判定する。処理された場合は、終了端子1891 にて、その処理が完了する。処理されない場合は、機能ブロック1892にて、現在の走査ラインをインクリメントし、上述した論理と一致する処理をさらに行うため、制御を機能ブロック1830に渡す。ワインディング数規則第19図は第18図の機能ブロック1880で示されたような本発明に係るエッジ遷移処理の実施態様を示すフローチャートである。処理が機能ブロック1900にて開始され、機能ブロック1900にて、エッジの符号が現在のラップ・カウントに付加される。判定ブロック1910にて、試験を行い、ラップ・カウントがゼロになったかどうかを判定する。ゼロになった場合は、セーブされたｘ値から機能ブロック19 40で示されるようなエッジのｘ値まで、ピクセルが現在の走査ライン上にドローイングされる。ゼロでない場合には、試験を行って、ラップ・カウントが非ゼロになったか否かを判定する。ラップ・カウントが非ゼロである場合は、機能ブロック1930にてエッジのｘ値をセーブする。奇偶規則第20図は第18図の機能ブロックで示されたような本発明に係るエッジ遷移処理の実施態様を示すフローチャートである。処理が機能ブロック2000で開始され、機能ブロック2000にて、エッジの符号が現在のラップ・カウントに付加される。判定ブロック2010にて、試験を行って、ラップ・カウントが偶数であるかどうかを判定する。エッジ・カウントが偶数である場合は、機能ブロック2030にて、セーブされたｘ値からそのエッジのｘ値まで、ピクセルを現在の走査ライン上にドローイングする。エッジ・カウントが偶数でない場合には、機能ブロック2020 にて、エッジのｘ値をセーブする。第21図は本発明に係るエッジ遷移の実施態様を示すブロック図である。このブロック図は矩形と楕円のブール和を用いて、遷移処理を明確にしている。結果ブロック2100にて、結果値を記憶する。ブール和オブジェクト2110は、２つの奇偶値を取り、２つの値の論理和を計算する。奇偶オブジェクト2120は、奇偶論理を用いて、各幾何学形状の内部または外部をトレースする。エッジが交差されると、ブロック2130を介して、その遷移関数をコールする。矩形および楕円のエッジはブロック2140に示す。

【手続補正書】特許法第１８４条の８【提出日】１９９５年７月５日【補正内容】（原文明細書第１頁）明細書図形エッジ・システム著作権通知書本特許出願は、一部に、著作権保護の対象となる内容を含んでいる。特許書類または特許開示事項を、米国特許商標庁の特許ファイルまたは記録の通り、何人がファクシミリ複製しても、著作権者はそれを妨げるものではないが、そうでない場合は、一切の著作権を留保する。技術分野本発明は、コンピュータ・システムの改良に関し、特に、グラフィック・ディスプレイ上のエッジ情報を処理するシステムおよび方法に関する。背景技術美学的、人間工学的方法で情報を表示するために、エッジ情報をグラフィック処理することは非常に厄介なことである。したがって、最新のグラフィック・システムは、テキストおよび図形情報を含む広範囲な情報を処理する情報ハンドリング・システムを利用しているが、このシステムはこのような情報をより人間工学的な方法で処理するため、ますます精巧になっている。例えば、選択された方法で、図形エッジ情報をプログラミングするか、あるいは処理するコンピュータ・プログラマまたはコンピュータ・ユーザの能力には限界がある。従来のOS(operating system)はエッジ処理能力に限界があった。その限界の１つには、OSアーキテクチャが所定の周辺デバイス用に設計されていないが、所定の周辺デバイスをサポートできるようにOSアーキテクチャを修正することができない場合、OSアーキテクチャはその周辺デバイスをサポートすることができないということが挙げられる。また、従来のアーキテクチャは図形エッジ情報を予め定義された単一の方法で処理できるだけである。 Ackland et al，"The Edge Flag Algorithm−A Fill Method for Raster Scan Displays"，IEEE Transactions on Computer，vol.C-30，no.1，January 1981 ，pages 41-47には、ラスタ・スキャン・ディスプレイのための多数の周知の輪郭塗り潰しアルゴリズムが記載され、評価されている。ordered edge listアルゴリズムは、ordered edge listのセットからスパンを生成して、輪郭を塗り潰している。このアルゴリズムはスキャン・ライン順で適用され、現在のスキャンラインと交差するエッジのテーブルであるアクティブなエッジ・リストにエントリを付加するか、あるいは、そのアクティブなエッジ・リストからエントリを削除する。前ラインの結果に基づき、差分方程式を用いて、アクティブな各エッジの交差点を現在のスキャンラインを用いて評価している。そして、ｘ値を増加させて、これらの交差点が並べられ、内部(interior)スパンのセットが生成される。あるいはまた、このアルゴリズムは、まず、各ポリゴンを、エッジ・ソートの量を減少させる台形または三角形のセットに分解している。OELアルゴリズムが必要とする処理は、大部分、フレーム・ストアをワーキング・メモリとして用いることにより除去することができる。これはシード塗り潰しアルゴリズムにより行われ、このアルゴリズムに従って、塗り潰される図形の接続された輪郭が、まず、フレーム・ストアのワーキング・プレーン上にドローイングされる。ついで、この図形の内部にあるシード点が選択され、このアルゴリズムにより、当該図形の境界を与える周知の内部の点の近傍の点を連続的に検査することにより、その図形のextentが交差していないことが判定される。記載されている別のアルゴリズムは、ワーキング・プレーン上にドローイングされた輪郭の内部を判定するパリティ・チェックである。そのピクセルから境界まで引かれたラインが輪郭と奇数回交差する場合、あるピクセルがその図形の内部に割り当てられる。記載された別のアルゴリズムはエッジ塗り潰し技法であり、一連のピクセルにより表されるアウトライン・ドローイングにより塗り潰される輪郭を定義することを避けて、その代わり、輪郭を数学的に記述する技法である。パリティ・チェック形アルゴリズムを用いて、実際の塗り潰しが行われている。スキャン・ライン当たりのエッジ・チェックの回数を減少させることによりエッジ塗り潰し技法を改善するために、Ackland et alの文献では、エッジ・フラグ・アルゴリズムを提案している。このアルゴリズムよれば、１つのピクセルのみがエッジ／スキャン交差ごとにマークされ、その後、実際の塗り潰しがコピー・ルーチンにより行われる。交点でピクセルを補完することによりマークする。このアルゴリズムは訂正塗り潰しを行なうため、パリティ・チェックを簡単にしている。説明されているアルゴリズムの中には、手続き型プログラミングか、マイクロコードか、あるいは、ハードウェアによるインプリメンテーションが示されているものがある。これら記載されているアルゴリズムのどれも、オブジェクト指向環境で用いられるものではないが、あるオペレーティング・システム・アーキテクチャには依存していない。これらのアルゴリズムは輪郭塗り潰しに限定されている。さらに、輪郭線をシャープニングするか、細線化してスケルトン表現を修正する種々の方法が良く知られている。Chin et al，"A One-Pass Thinning Algorit hm and its Parallel Implementation"と、COMPUTER VISION，GRAPHICS AND IMA GE PROCESSING，vol.40，no.1，October 1987，pages 30-34，Academic Press， Inc.，Duluth，MN，USAと、Naccache et al，"An Investigation into the Skel etonizaton Approach of Hilditch"，PATTERN RECOGNITION，vol.17，no.3，198 4，pages 279-284，Pergamon Press，Ltd.，Oxford，GBを参照されたい。これらの方法は、上述した周知のエッジ処理の欠点を解消するのにもまた適さない。発明の開示従って、本発明の目的は、メモリおよび付属のディスプレイを有するコンピュータによって、図形オブジェクトと、これらの図形オブジェクトに関係付けをしたエッジを柔軟に処理することにある。本発明の目的は、図形オブジェクトをメモリにロードし、この図形オブジェクトを複数のエッジ・オブジェクトに変換し、このエッジ・オブジェクトを複数の走査線ピクセルに変換し、この走査線ピクセルをディスプレイ上に表示することによって達成される。本発明は独立項である請求の範囲第１項および第12項で定義されている。その他の請求の範囲には本発明の改善を記載している。図形の簡単な説明第１図は好ましい実施態様に係るパーソナル・コンピュータ・システムのブロック図である。請求の範囲１．閉じた幾何学形状を、オブジェクト指向グラフィック・フレームワークを用いて複数のスキャン・ライン・ピクセルにスキャン変換する方法であって、メモリ(14)を有するコンピュータ・システム(10)上でオペレートする方法であり、複数のエッジ(230)により前記オブジェクトをそれぞれ記述するデータと、前記複数のエッジを前記幾何学形状のアウトラインに変換するオブジェクト関数とを備えたグラフィック・オブジェクトのクラスから導出されたオブジェクトにより、前記幾何学形状を表現する方法において、 (a)エッジ・オブジェクトのクラスからサブクラス(1510,1570)を導出し、導出されたサブクラスから、複数のエッジ・オブジェクト(1800)を作成し、該エッジ・オブジェクトは、それぞれ、予め定めたエッジ形状を記述するためのデータ構造を備え、しかも、前記予め定めたエッジ形状に沿って移動させるための関数を含むステップと、 (b)前記グラフエッジを受ける関数を含むエッジ・エンジン・オブジェクトであって、前記エッジ・オブジェクトのパラメータにより指定されている予め定めた処理ルールに従って、前記スキャンラインとして適正なピクセルのスパンを生成するための遷移関数を含むエッジ・エンジン・オブジェクトの抽象クラス(TEd geEngine)をストアするステップと、 (c)前記抽象サブクラスから、少なくとも１つの塗り潰しフレーム・エッジ・エンジン・サブクラスを作成し、前記抽象サブクラスの各エッジ・エンジン・オブジェクトを、前記エッジ・オブジェクト内および／またはそのエッジ上に存在するスキャンラインのうちのサブクラスID部分の１つから導出するステップと、 (d)前記メモリのグラフィック・オブジェクトをアクセスし、そのグラフィック・オブジェクト内のデータとオブジェクト関数を利用して、前記エッジ・オブジェクトから、前記グラフィック・オブジェクトを表すエッジ・オブジェクトを選択するステップと、 (e)前記エッジ・オブジェクトをスキャン中にエッジが交差したとき、前記選択されたエッジ・オブジェクトにより指定されたエッジ・エンジン・オブジェクトを用いて、前記遷移関数(1910,1920,2010)をコールするステップであって、コールされた前記遷移関数によりパフォームされた前記予め定めた処理ルールに従って、前記スキャンラインのうちの指定された部分を塗り潰し、および／または、フレーミングするためのスキャン・ライン・ピクセル(1940,2030)を作成するステップとを備えたことを特徴とする方法。２．請求の範囲第１項において、前記ステップ(a)は、 (a1)複数のエッジ・オブジェクトに対して単一の名前を選択するステップと、 (a2)選択された名前を前記複数のエッジ・オブジェクトにそれぞれ割り当てるステップと、 (a3)異なるパラメータを前記複数のエッジ・オブジェクトにそれぞれ割り当てるステップとを備えたことを特徴とする方法。３．請求の範囲第１項において、前記ステップ(a)は、 (a3)追加のオブジェクトを作成することができるパラメータのセットを選択するステップを備えたことを特徴とする方法。４．請求の範囲第１項において、前記ステップ(e)は、 (e1)作成されるスキャン・ライン・ピクセルがエッジ内にあるか、エッジ外にあるか（第４図）、あるいはエッジ上にあるか（第６図）を判定するステップを備えたことを特徴とする方法。５．請求の範囲第１項において、前記ステップ(e)は、スキャン・ライン・ピクセルを作成して、前記エッジ（第７図）により定義された前記アウトラインに対して有心フレームを表現するステップを備えたことを特徴とする方法。６．請求の範囲第１項において、前記ステップ(e)は、スキャン・ライン・ピクセルを作成して、インセット・フレーム（第９図）を表現するステップを備えたことを特徴とする方法。７．請求の範囲第１項において、前記ステップ(e)は、スキャン・ライン・ピクセルを作成して、アウトセット・フレーム（第11図）を表現するステップを備えたことを特徴とする方法。８．請求の範囲第１項において、前記ステップ(e1)は、奇偶処理規則を利用して (2010)、スキャン・ライン上のピクセルがエッジ内にあるか、エッジ外にあるか、あるいは、エッジ上にあるかを判定するステップを備えたことを特徴とする方法。９．請求の範囲第１項において、前記ステップ(e1)は、ワインディング数処理規則を利用して(1910,1920)、スキャン・ライン上のピクセルがエッジ内にあるか、エッジ外にあるか、あるいは、エッジ上にあるかを判定するステップを備えたことを特徴とする方法。 10．請求の範囲第１項において、前記ステップ(d)は、 (d1)前記オブジェクト関数を用いて、複数のエッジ・オブジェクトのうちの選択されたエッジ・オブジェクトをアセンブルしてリストにする(1830)ステップと、 (d2)スキャンライン処理中に前記リストを利用して、任意のエッジが前記スキャンラインと交差したか否かを判定する(1880)ステップとを備えたことを特徴とする方法。 11．請求の範囲第１項において、前記ステップ(c)で作成されたサブクラスは、グラフィック・オブジェクト内および／またはそのエッジ上に存在するスキャンラインの部分を識別する複数のスキャンライン関数を備えたアンチエイリアシングされたエッジ・エンジン・オブジェクトを作成するために用いられ、しかも、前記遷移関数によりパフォームされる前記予め定めた処理規則に従って、前記スキャンラインのうちの前記識別された部分を塗り潰しおよび／またはフレーミングするために、アンチエイリアシングされたスキャンライン・ピクセルを作成することを特徴とする方法。 12．閉じた幾何学形状を、オブジェクト指向グラフィック・フレームワークを用い、メモリ(14)を有するコンピュータ・システム(10)を用いて、スキャン変換して複数のスキャンライン・ピクセルにする装置であって、前記オブジェクトをそれぞれ複数のエッジ(230)により記述するデータと、前記複数のエッジを横切ってその形状のアウトラインにするためのオブジェクト関数を備えたグラフィック・オブジェクトのクラスから導出されたオブジェクトにより、前記幾何学形状を表現する装置において、 (a)エッジ・オブジェクトのクラスからサブクラスを導出し(1510,1570)、導出されたサブクラスから複数のエッジ・オブジェクト(1800)を作成する手段であって、前記エッジ・オブジェクトが、それぞれ、予め定めたエッジ形状を記述するデータ構造を備え、しかも、前記予め定めたエッジ形状に沿って移動するための関数を含む手段と、 (b)前記グラフエッジを受ける関数を含むエッジ・エンジン・オブジェクトであって、前記エッジ・オブジェクトのパラメータにより指定されている予め定めた処理規則に従って、前記スキャンラインとして適正なピクセルのスパンを生成するための遷移関数を含むエッジ・エンジン・オブジェクトの抽象クラス(TEdge Engine)をストアする手段と、 (c)前記抽象サブクラスから、少なくとも１つの塗り潰しフレーム・エッジ・エンジン・サブクラスを作成し、前記抽象サブクラスの各エッジ・エンジン・オブジェクトを、前記エッジ・オブジェクト内および／またはそのエッジ上に存在するスキャンラインのうちのサブクラスID部分の１つから導出する手段と、 (d)前記メモリのグラフィック・オブジェクトをアクセスし、そのグラフィック・オブジェクト内のデータとオブジェクト関数を利用して、前記エッジ・オブジェクトから、前記グラフィック・オブジェクトのエッジを表すエッジ・オブジェクトを選択する手段と、 (e)前記エッジ・オブジェクトをスキャン中にエッジが交差したとき、前記選択されたエッジ・オブジェクトにより指定されたエッジ・エンジン・オブジェクトに応答して、前記遷移関数(1910,1920,2010)をコールする手段であって、コールされた前記遷移関数によりパフォームされた前記予め定めた処理ルールに従って、前記スキャンラインのうちの指定された部分を塗り潰し、および／または、フレーミングするためのスキャン・ライン・ピクセル(1940,2030)を作成する手段とを備えたことを特徴とする装置。 13．請求の範囲第12項において、前記エッジ・オブジェクトを作成する手段は、前記複数のエッジ・オブジェクトにそれぞれ単一の名前を割り当てる手段と、前記複数のエッジ・オブジェクトにそれぞれ異なるパラメータを割り当てる手段とを備えたことを特徴とする装置。 14．請求の範囲第12項において、前記パラメータを割り当てる手段は、追加のエッジ・オブジェクトを作成することができるパラメータのセットを利用することを特徴とする装置。 15．請求の範囲第12項において、前記エッジ・エンジン・オブジェクトは、前記複数のエッジ・オブジェクトのうちの選択されたエッジ・オブジェクトに応答して、作成されるスキャンライン・ピクセルが前記エッジ内か、エッジ外か（第４図）、あるいは、エッジ上か（第６図）を判定する手段を備えたことを特徴とする装置。 16．請求の範囲第12項において、前記ピクセル作成手段は、スキャン・ライン・ピクセルを作成して、前記エッジ・オブジェクト（第７図）により定義された前記アウトラインに対する有心フレームを表現することを特徴とする装置。 17．請求の範囲第12項において、前記ピクセル作成手段は、スキャン・ライン・ピクセルを作成して、インセット・フレーム（第９図）を表現することを特徴とする装置。 18．請求の範囲第12項において、前記ピクセル作成手段は、スキャン・ライン・ピクセルを作成して、アウトセット・フレーム（第11図）を表現することを特徴とする装置。 19．請求の範囲第12項において、前記エッジ・エンジン・オブジェクトは、複数のエッジ・エンジンのうちの選択されたエッジ・エンジンに応答して、奇偶処理規則を利用して(2010)、スキャン・ライン上のピクセルがエッジ内にあるか、エッジ外にあるか、あるいは、エッジ上にあるかを判定する手段を備えたことを特徴とする装置。 20．請求の範囲第12項において、前記エッジ・エンジン・オブジェクトは、複数のエッジ・エンジンのうちの選択されたエッジ・エンジンに応答して、ワインディング数処理規則を利用して(1910,1920)、スキャン・ライン上のピクセルがエッジ内にあるか、エッジ外にあるか、あるいは、エッジ上にあるかを判定する手段を備えたことを特徴とする装置。 21．請求の範囲第12項において、前記エッジ・オブジェクト選択手段は、複数のエッジ・エンジンのうちの選択されたエッジ・エンジンをアセンブルしてリストにする(1830)手段を備え、前記エッジ・エンジンは前記リストに応答して、スキャン・ライン処理中に、任意のエッジがスキャン・ラインと交差した否かを判定する(1880)手段を備えたことを特徴とする装置。 22．請求の範囲第12項において、前記サブクラス作成手段は、前記グラフィック・オブジェクト内および／またはそのエッジ上に存在するスキャン・ラインの部分を識別する複数のスキャン・ライン関数を備えたアンチエイリアシングされたエッジ・エンジン・オブジェクトを作成する手段を備え、前記スキャン・ライン作成手段は、アンチエイリアシングされたスキャン・ライン・ピクセルを作成する手段を備えたことを特徴とする装置。

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

Claims

【特許請求の範囲】１．メモリと、付属のディスプレイを有するコンピュータで図形オブジェクトを処理する方法において、 (a)図形オブジェクトをメモリにロードするステップと、 (b)前記図形オブジェクトを複数のエッジ・オブジェクトに変換するステップと、 (c)前記エッジ・オブジェクトを複数の走査線ピクセルに変換するステップと、 (d)前記走査線ピクセルおよび前記図形オブジェクトを前記ディスプレイ上に表示するステップとを備えたことを特徴とする図形オブジェクトを処理する方法。２．請求の範囲第１項において、前記エッジ・オブジェクトを多形的に表すステップを含むことを特徴とする方法。３．請求の範囲第２項において、前記エッジ・オブジェクトを拡張可能な方法で表現するステップを含むことを特徴とする方法。４．請求の範囲第１項において、前記走査線ピクセルが図形オブジェクトの内側にあるか外側にあるかを、拡張可能な方法で判定するステップを含むことを特徴とする方法。５．請求の範囲第４項において、奇偶処理を利用して、前記エッジ・オブジェクトを処理するステップを含むことを特徴とする方法。６．請求の範囲第４項において、ワインディング数処理を利用して、前記エッジ・オブジェクトを処理するステップを含むことを特徴とする方法。７．請求の範囲第４項において、幾何学形状のオブジェクトからエッジを処理するステップを含むことを特徴とする方法。８．請求の範囲第１項において、前記エッジ処理に対してオブジェクト指向の処理を利用するステップを含むことを特徴とする方法。９．図形オブジェクトを処理する装置において、 (a)コンピュータと、 (b)前記コンピュータに駐在するメモリと、 (c)前記コンピュータに付属するディスプレイと、 (d)図形オブジェクトを前記メモリにロードする手段と、 (e)前記図形オブジェクトを複数のエッジ・オブジェクトに変換する手段と、 (f)前記エッジ・オブジェクトを複数の走査線ピクセルに変換する手段と、 (g)前記走査線ピクセルおよび図形オブジェクトを前記ディスプレイ上に表示する手段とを備えたことを特徴とする図形オブジェクトを処理する装置。 10．請求の範囲第９項において、前記エッジ・オブジェクトを多形的に表す手段を含むことを特徴とする装置。 11．請求の範囲第10項において、前記エッジ・オブジェクトを拡張可能な方法で表現する手段を含むことを特徴とする装置。 12．請求の範囲第９項において、前記走査線ピクセルが図形オブジェクトの内側にあるか外側にあるかを拡張可能な方法で判定する手段を含むことを特徴とする装置。 13．請求の範囲第12項において、奇偶処理を利用して、前記エッジ・オブジェクトを処理する手段を含むことを特徴とする装置。 14．請求の範囲第12項において、ワインディング数を利用して、前記エッジ・オブジェクトを処理する手段を含むことを特徴とする装置。 15．請求の範囲第12項において、任意の幾何学オブジェクトからエッジを処理する手段を含むことを特徴とする装置。 16．請求の範囲第９項において、前記エッジ処理のために、オブジェクト指向の処理を利用する手段を含むことを特徴とする装置。 17．請求の範囲第１項において、前記エッジ・オブジェクトを、拡張可能な方法で、ピクセルに変換するステップを含むことを特徴とする方法。 18．請求の範囲第１項において、クリッピング・アルゴリズムを利用して、前記エッジ・オブジェクトを頂部から底部に変換するステップを含むことを特徴とする方法。 19．請求の範囲第１項において、前記エッジ・オブジェクトを拡張可能な方法でピクセルに変換する手段を含むことを特徴とする装置。 20．請求の範囲第１項において、クリッピング・アルゴリズムを利用して、前記エッジ・オブジェクトを頂部から底部に変換する手段を含むことを特徴とする装置。 21．メモリと、付属のディスプレイを有するコンピュータ上で図形オブジェクトを処理する方法において、 (a)図形オブジェクトをメモリにロードするステップと、 (b)前記図形オブジェクトを複数のエッジ・オブジェクトに変換するステップと、 (c)前記エッジ・オブジェクトを複数の走査線ピクセルに変換するステップと、 (d)前記走査線ピクセルをアンチ・エイリアシングするステップと、 (e)前記走査線ピクセルおよび前記図形オブジェクトを前記ディスプレイ上に表示するステップと備えたことを特徴とする図形オブジェクトを処理する方法。