JPH09504895A

JPH09504895A - オブジェクト指向ペインタ・メーカ

Info

Publication number: JPH09504895A
Application number: JP7513187A
Authority: JP
Inventors: マーシュ，ドナルド，エム．; ワトソン，ラルフ，トーマス
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1993-11-05
Filing date: 1994-01-03
Publication date: 1997-05-13
Also published as: CA2169627A1; AU6019294A; US5428722A; DE69404469D1; WO1995012865A1; EP0717868B1; DE69404469T2; EP0717868A1

Abstract

(57)【要約】オブジェクト指向ペインタ・メーカが開示されている。本発明は、複数のグラフィカル環境において複数のグラフィカル・プリミティブをレンダリングするためのコンピュータ・ベースのシステムを目的としている。システムは複数のペインタ・メーカ・オブジェクトと、該ペインタ・メーカ・オブジェクトの少なくとも１つを含むペインタ・メーカ・チェインとを含んでいる。タスクはペインタ・メーカ・チェインに結合されていて、特定のグラフィカル環境で特定のグラフィカル・プリミティブをレンダリングする要求をペインタ・メーカ・チェインに引き渡す。ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトは、グラフィカル・レンダリング要求を受け取るとその要求に応答して、各々が特定のグラフィカル・プリミティブのレンダリングに対して特定のグラフィカル・オペレーションを、特定のグラフィカル環境で実行するように最適化された複数のペインタ・オブジェクトを含んでいるペインタ・メーカを作成する。タスクはペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトによって作成されたペインタ・オブジェクトを使用して、レンダリング・オペレーションを特定のグラフィカル環境で実行する。

Description

【発明の詳細な説明】オブジェクト指向ペインタ・メーカ本特許出願の開示内容一部には著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたはレコードに記録されている特許開示内容を何人もが原文とおりに複製することを妨げるものではないが、その他の場合には、一切の著作権を所有することを留保する。発明の分野本発明はコンピュータをベースとするグラフィックス・システムおよび方法を目的とし、具体的には、コンピュータをベースとするオブジェクト指向ペインタ・メーカおよびペインタを目的としている。関連技術レンダリング・ルーチン（レンダリング・ソフトウェア、レンダリング・プログラム、およびレンダ・コードとも呼ばれる）はコンピュータ・システムで実行されて、ポリゴン（多角形）、レクタングル（矩形）、ライン（線）、サークル（円）などのグラフィカル・プリミティブをドローイング（描画）している。コンピュータ・システムは、異なる出力デバイスや異なるレンダリング要求条件といったように、異なるグラフィカル特性をもつ多数のグラフィカル環境を構成していることがよくある。例えば、あるグラフィカル環境では、出力デバイスはフレーム・バッファ・ディスプレイ・デバイス（フレーム・バッファ・ディスプレイ・デバイスは周知である）になっている場合がある。別のグラフィカル環境では、出力デバイスはプリンタ、プロッタ、非フレーム・バッファ・ディスプレイ・デバイス、またはオフスクリーン・バッファになっている場合がある。また、あるグラフィカル環境は、他のグラフィカル環境とは異なるレンダリング要求条件（クリッピングを行う必要性など）をもっている場合もある。以上から理解されるように、あるグラフィカル環境でグラフィカル・プリミティブをドローイングするために必要なソフトウェアが、他のグラフィカル環境でグラフィカル・プリミティブをドローイングするために必要なソフトウェアと異なることはよく起こることである。このようなことが起こるのは、グラフィカル環境が異なると、グラフィカル特性も異なるからである。従来の、ある種のコンピュータ・ベースのグラフィックス・システムでは、レンダリング・ルーチンが各グラフィカル環境ごとに用意されている。例えば、第１のグラフィカル環境（例えば、フレーム・バッファが出力デバイスになっている）と第２のグラフィカル環境（例えば、プリンタが出力デバイスになっている）からなるグラフィックス・システムでは、２つのドロー・レクタングル・レンダリング・ルーチン(draw-rectangle rendering routine)が、各グラフィカル環境用に１つずつ用意されることになる。これらのドロー・レクタングル・レンダリング・ルーチンは、それぞれのグラフィカル環境に特有のものとなっている。しかし、レンダリング・ルーチンを各グラフィカル環境ごとに用意することは、プログラムに組み込まれる内容がさらに複雑化することになるので、理想的な解決法ではない。従来の、他のコンピュータ・ベースのグラフィックス・システムでは、限られた数のレンダリング・ルーチンが用意され、そこではレンダリング・ルーチンの各々は、グラフィカル環境のすべてについてグラフィカル環境特有のコードを含んでいる。この種のグラフィカル環境特有コードの実行は、同じようにレンダリング・ルーチンに含まれている条件ステートメント（"if-then-else"ステートメントなどの）の実行に基づいている。しかし、限られた数のレンダリング・ルーチンを用意し、各ルーチンがグラフィカル環境のすべてについてグラフィカル環境特有コードをもつことは、結果として得られるレンダリング・ルーチンが複雑になり、開発と保守が困難になるので理想的な解決法ではない。発明の概要本発明は、様々なグラフィカル環境でグラフィカル・プリミティブをドローイング（またはレンダリング、またはペインティング）するためのオブジェクト指向ペインタを提供することを目的とし、さらに、グラフィカル環境のグラフィカル特性に従って上記ペインタを選択し、リンクするためのオブジェクト指向ペインタ・メーカを提供することを目的としている。ペインタ・メーカ、より具体的には、本発明のペインタ・メーカ・アーキテクチャは、ピクセル・ペインティング、クリッピング、領域作成、マルチスレッド同期化、ペインタ・キャッシングおよび対話型コンポジション（合成）といったように、異なるグラフィカル環境のグラフィカル特性を取り扱うために必要な異なる機能（関数）を抽象化している。これらの関数をレンダリング・コードから見えないようにすると、様々な状況で同じレンダリング・コードを使用することが可能になる。ペインタ・メーカ・アーキテクチャは、ある状況でペイントするのに２つ以上のペインタが必要になる所定の場合には、複数のペインタを動的に使用することもサポートしている。具体的には、本発明は、複数のグラフィカル環境で複数のグラフィカル・プリミティブをレンダリングするためのコンピュータ・ベース・システムを提供することを目的としている。このシステムは複数のペインタ・メーカ・オブジェクトと、ペインタ・メーカ・オブジェクトの少なくとも１つを含むペインタ・メーカ・チェインとを含んでいる。レンダリング・ルーチンはデバイス・キャッシュ内のペインタ・メーカに対して特定タイプのペインタを作成するように要求する。ペインタ・メーカからは、要求されたタイプのペインタが返却され、このペインタは現環境で正しく機能するようになっている。ペインタはピクセル・プロセッサであり、好適実施例ではフレーム・バッファ・デバイス用に使用されることを主目的としている。しかし、ペインタの機能は非フレーム・バッファ・デバイスもサポートするように十分に豊富になっている。ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトはグラフィカル・レンダリング要求の受け取りに応答して、複数のペインタ・オブジェクトを含んでいるペインタ・チェインを作成する。ペインタ・オブジェクトの各々は、特定のグラフィカル・プリミティブのレンダリングに対して特定のグラフィカル・オペレーションを特定のグラフィカル環境で実行するように最適化されている。タスクは、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトによって作成されたペインタ・オブジェクトを使用して、特定のグラフィカル環境でレンダリング・オペレーションを実行する。本発明には、有利な特徴がいくつかある。例えば、新しいペインタを作成することができ、ペインタ作成が拡張可能である。従って、レンダラ(renderer)を変化するペインタに適応させる必要がない（例えば、レンダリングを領域に行うか、ピクセル・バッファに行うか、あるいはコンポジションを行うか、といった場合）。さらに、異種のペインタをー緒に使用することが可能であり、ペインタ同士が相互について知っている必要がない。好ましくは、レンダラはそのペインタのための単一の公知ソースをコールする。このソースは採用されているタイプのペインティングを抽象化している。この単一ソースは、本明細書ではペインタ・メーカと呼ぶことにする。また、本発明によれば、可能な限り多数の「ペインティング変数」がバインドされてから、ペインティングが多態(polymorphism)を通して開始するようになっている。「フック(hook)」が用意されているので、ペインタ・メーカは繰返し使用されるオブジェクトをキャッシュしておくことができる。キャッシングはレンダラからは見えないように(tranparant)なっている。また、スプライト(sprite) の応答時間（レスポンス・タイム）は、スクリーンの一部がマルチスレッド・セーフ(multi-thread safe)のレンダリングに対してロックされているスコープ（有効範囲）の外で、時間のかかるレンダリング・ステップが実行されるように配慮することにより最適化されている。従って、本発明によれば、ハイパフォーマンスのペインティングが達成される。ペインテイングは本来的に複雑である。本発明によれば、このような複雑性はレンダラから見えないように(hidden)なっている。動的ストレージはスタック・ベースのクリーンアップ・オブジェクトを通して割り当てられるので、例外処理は適切なクリーンアップを行うことができる。本発明には、ペインタおよび関連のオブジェクトの使用を監視する機能が用意されており（その結果、ペインタと関連オブジェクトは正しい使い方がされるようになる）、他にも、正しくない使い方を検出する機能が用意されている（例えば、パフォーマンス上の理由から正しい使い方が強要されていないとき）。本発明のその他の機能（特徴）と利点については、本発明の種々実施例の構造とオペレーションと共に、添付図面を参照して以下で詳しく説明する。図面の簡単な説明以下、添付図面を参照して本発明を説明する。添付図面において、図１は、本発明の好適実施例の構造を示すハイレベル・ブロック図である。図２は、タスクが本発明の好適実施例に従ってディスプレイ・デバイスにレンダリングするときオブジェクト間で受け渡しされるメッセージを示す図である。図３は、本発明のオペレーションを示すフローチャートである。図４Ａは、好適実施例によるペインタ・クラスを示す図である。図４Ｂは、本発明の好適実施例によるペインタ・メーカ・クラスを示す図である。図５は、ペインタ・メーカ・チェインの例を示す図である。図６は、ペインタ・チェインの例を示す図である。図７は、本発明の好適実施例に従ってgrafport用のペインタ・メーカを作成するときの手順を示す図である。図８は、本発明の好適実施例によるクリップ領域クラスを示す図である。好適実施例の詳しい説明１．発明の概観図１は、本発明のコンピュータ・システム１０２の構造を示すハイレベル・ブロック図である。コンピュータ・システム１０２は、ランダムアクセス・メモリ（ＲＡＭ）１０８、中央演算処理ユニット（ＣＰＵ）１１０、および入出力（Ｉ／Ｏ）インタフェース１１２などのハードウェア・コンポーネント１０６を備えているコンピュータ・プラットフォーム１０４を備えている。なお、ＣＰＵ１１０は単ープロセッサを表す場合も、並列に動作する複数のプロセッサを表す場合もある。コンピュータ・システム１０２は、ハードウェア・コンポーネント１０４に接続された周辺デバイスも備えている。これらの周辺デバイスとしては、入力デバイス１２４（キーボード、マウス、ライトペンなど）、データ・ストレージ・デバイス１２２（ハードディスクやフロッピディスクなど）、出力デバイス１２６（フレーム・バッファ・ディスプレイ・デバイス、プリンタ、プロッタ、オフスクリーン・バッファなど）がある。コンピュータ・プラットフォーム１０４には、オペレーティング・システム１１６も含まれているが、マイクロコード１１４を含んでいる場合もある。オペレーティング・システム１１６は、ディスク・オペレーティング・システム（ＤＯＳ）やＵＮＩＸオペレーティング・システムなどの、ほぼ全機能のオペレーティング・システムを表している。しかし、オペレーティング・システム１１６は他のタイプのオペレーティング・システムを表すことも可能である。そのようなものとしては、ＩＢＭ社が開発したＭａｃｈマイクロカーネルなどの、限定機能の手続き型オペレーティング・システムがあるが、これは当該分野では公知である。本発明の好適実施例では、コンピュータ・プラットフォーム１０４はインターナショナル・ビジネス・マシンズ（ＩＢＭ）社コンピュータまたはＩＢＭコンパチブル・コンピュータになっている。本発明の別の実施例では、コンピュータ・プラットフォーム１０４はアップル社コンピュータになっている。コンピュータ・プラットフォーム１０４上で動作するものとしては、アプリケーション・プログラム１１８，１２０がある。これらのアプリケーション・プログラム１１８，１２０の各々はドローイング命令を含んでいる。これらの命令はコンピュータ・プロットフォーム１０４で実行されると、グラフィック・プリミティブを出力ディスプレイ・デバイス１２６上にレンダリングするものである。好ましくは、グラフィック・プリミティブを出力ディスプレイ・デバイス１２６上にレンダリングするとき、多数のオブジェクトが関与する。このようなレンダリングを行うときのメッセージの流れは、図２に示されている。好ましくは、タスク２０２（アプリケーション・プログラムは、その実行時に１つまたは２つ以上のタスクで表されている）は、grafportオブジェクト２０４へのプリミティブ・ドローイング・メッセージをコールする。このプリミティブ・ドローイング・メッセージは、ドローイングすべきプリミティブのタイプ（レクタングルなど）およびドローイングすべきプリミティブの属性（カラーおよび／または塗りつぶし(filling)および／またはフレーミングまたはライン・タイプなど）を指定している。 grafportオブジェクト２０４は各タスクと関連づけられており、これは、そこを通してタスクがディスプレイ・デバイス１２６とやりとりできるウィンドウを表している。grafportオブジェクト２０４はディスプレイ・デバイスをアクセスするときの機能（関数）を抽象化しているので、タスク２０２に実装されているレンダリング・コードは単純化されている。grafportオブジェクト２０４は、ディスプレイ・ピクセル情報などの、タスク特有のグラフィカル情報を表しているキャッシュ２０３を含んでいる。キャッシュ２０３をgrafport２０４で維持する必要があるのは、多数のタスクがディスプレイ・デバイス１２６にレンダリングする可能性があるからである。grafportはキャッシュ用のストレージを維持しているが、ディスプレイ・デバイスは、タスクによる以後のレンダリングを高速化するために情報をストアしておく。GrafDevicesは、スレッド特有データ（キャッシュ）をgrafportに保持すること、および、そのデータを各レンダリング・コールと一緒にgrafdeviceに渡すことによって、マルチスレッド・セイフ(multith read safe)とされている。タスク２０２からのプリミティブ・ドローイング・メッセージの受け取りに応答して、grafport２０４は、メッセージをgrafdeviceオブジェクト２０８へ送って、grafdeviceオブジェクト２０８によって定義された（およびメッセージで識別された）レンダリング・メソッドをgrafdevice２０８に実行させる。grafport ２０４からgrafdevice２０８へ送られるメッセージには、キャッシュ２０３が含まれている。 grafdevice２０８は、多数のディスプレイ・デバイス１２６と関連づけられており、ディスプレイ・デバイス１２６の機能を抽象化している。このようになっているので、タスクとgrafportは、ディスプレイ・デバイスの技術的詳細を知らなくてもディスプレイ・デバイスと一緒に働くことができる。すべてのgrafdevi ceのインタフェースは同じであるので、grafportは、関連のgrafdeviceへ適切なメッセージを送ることにより、すべてのディスプレイ・デバイスと一緒に容易に動作することができる。 grafport２０４からのメッセージの受け取りに応答して、grafdeviceオブジェクト２０８はメッセージで識別されたレンダリング・メソッドを実行する。図３は本発明のハイレベル・オペレーションを示すフローチャートであり、図３に示すように、レンダリング・メソッドの実行中に、タスク２０２に関連するペインタ・メーカ・チェインが使用されて、ペインタのチェインが生成される（ステップ３０８）。ペインタ・メーカ・チェインは以前に生成されたものである（ステップ３０６）。レンダリング・メソッドはこのペインタ・チェインを使用して、ディスプレイ・デバイス１２６にレンダリングする（ステップ３１０）。このオペレーションは以下に詳しく説明されているが、最初に、ペインタとペインタ・メーカについて以下のセクションで説明することにする。２．ペインタペインタは、特定のグラフィカル・レンダリング・オペレーションを実行するオブジェクトである。例えば、ある種のペインタ（スパン・ペインタ(span pain ter)と呼ばれる）はスパンをレンダリングすることに関連づけられている。スパンとは、高さが１ピクセルの水平ラインである。他のペインタ（ヘアライン・ペインタ(hairline painter)と呼ばれる）は、ヘアラインをレンダリングすることに関連づけられている。ヘアラインとは、任意の向きをもち、ヘアラインが表示されるディスプレイ・デバイスの最小太さに等しい太さをもつラインのことである。glyphペインタはglyphをレンダリングすることに関連づけられている。glyp hとは絵文字(character)のことである。３次元（３Ｄ）スパン・ペインタは３Ｄモデルに従ってスパンをレンダリングすることに関連づけられている（例えば、シェーディング（陰影付け）モデルをスパンに適用する）。限定された機能（ペインタがレンダリングすることを受け持つグラフィカル・プリミティブのタイプに対して）を有する、高度に特殊化されたペインタを定義すると、本発明のペインタは、グラフィカル・レンダリングにおいてハイパフォーマンスを達成するように高度に最適化することができる。これは対話型グラフィカル・システムでは非常に重要である。本発明のペインタは、ペインタがレンダリングするグラフィカル・プリミティブのタイプに対して特殊化されているほかに、ペインタがそれぞれのグラフィカル・プリミティブで実行するオペレーションのタイプに対しても特殊化されている。スパン・ペインタを例にして説明する。ある種のスパン・ペインタ（クリッピング・スパン・ペインタ(clipping span painter)と呼ばれる）はクリッピングを取り扱う。クリッピング・スパン・ペインタを使用すると、特定の「クリッピング・エリア」でレンダリングを行うことができる。ウィンドウは、クリッピングを応用した一例である。クリッピング・エリアを採用すると、オーバラップするウィンドウを実現することができる。ある種のスパン・ペインタ（コンポジット・スパン・ペインタ(composite spa n painter)と呼ばれる）はコンポジション（合成）を取り扱う。コンポジット・スパン・ペインタは、２つ以上のタスクが任意のディスプレイ・デバイスの任意の部分に同時にレンダリングすることがないようにする。スクリーン・ペインタ・メーカは、２つ以上のタスクがデバイスの任意のレクタングル・エリアに同時にレンダリングすることがないようにする。また、コンポジット・スパン・ペインタは、スプライト（明滅カーソルや移動するウィンドウなど）とスパンのレンダリングを統合化して、グラフィカルな異常(anomaly)が現れないようにする。コンポジット・スパン・ペインタは、スパン・データとスプライトの両方の組合せを表すグラフィカル・データをレンダリングすることにより（スパン・データをスプライトの上にランダリングするのではなく）これを行う。他のスパン・ペインタ（ピクセル・スパン・ペインタ(pixel span painter)と呼ばれる）はディスプレイ・デバイス・ピクセル・バッファの中にレンダリングすることを取り扱う。ペインタがレンダリングするグラフィカル・プリミティブのタイプに対して、および、ペインタが実行するグラフィカル・プリミティブに対するオペレーションのタイプに対しての両方に特殊化されたペインタを用意することにより、本発明のペインタは非常に最適化されるので、パフォーマンスが向上する。ペインタ・メーカは、特定のレンダリングに関係するペインタだけがペインタ・チェインに含まれるようにする。特定のレンダリング・オペレーションでクリッピングが必要でなければ、クリッピング・ペインタがペインタ・チェインに含まれない。下述するように、本発明のペインタ・メーカは、レンダリングが行われようとするグラフィカル環境の特性に基づいてペインタのチェインを作成する。作成されたペインタ・チェインはレンダリング・ルーチンによって使用されて、ディスプレイ・デバイス１２６にレンダンリングが行われる。図６はペインタ・チェインの例を示す図である。好ましくは、オブジェクト指向ペインタ基底クラスは幾何形状をレンダリングするために使用される標準タイプと拡張不能タイプのペインティングの各々について定義されている。例えば、スパン・ペインタのクラス、ヘアライン・ペインタのクラス、glyphペインタのクラス、および３Ｄスパン・ペインタのクラスが定義されている。特定のグラフィカル・プリミティブ・タイプをレンダリングすることに関連するすべてのペインタは、その特定グラフィカル・プリミティブ・タイプに関係するペインタ・クラスを用いてインスタンス生成される。図４Ａは、好適実施例によるペインタ・クラスのモデルを示す図である。TVerificationSpanPainter４４０のように、クラスは基底クラスのTSpanPainter４４２から派生している。従って、これらのクラスはすべてが共通のプロトコルをもっている。例えば、クリッピング・スパン・ペインタ、コンポジット・スパン・ペインタ、およびピクセル・スパン・ペインタはすべて、スパン・ペインタ・クラスを使用してインスタンス生成されたオブジェクトである。クラスのメソッドは必要に応じてオーバライド(override)される。コード例１は、本発明の好適実施例によるglyphペインタ・クラスのインタフェースを示している（これはＣ++コンピュータ・プログラミング言語で書かれている）。他のペインタ・クラスのインタフェースとインプリメンテーションはこの分野の精通者ならば理解される通りである。３．ペインタ・メーカペインタ・メーカは、拡張が不能である標準タイプのペインタを獲得するときの固定インタフェースとなるものである。これらの標準タイプのペインタは特殊化し、チェイニングすることにより、新しい拡張した動作(behavior)をもつペインタを標準インタフェースを使用して構築することができる。ペインタ・メーカはペインタをこのように構築して、現在のレンダリング要求に見合うように最適化されたペインタを作成する。本発明の範囲には、図４に示すように他のタイプのペインタも含まれている。図４に示す領域ペインタ・メーカ(region painter maker)４０６は、ディスプレイ・デバイスに依存する方法で領域を作成することに関連づけられている。スクリーン・ペインタ・メーカ(screen painter maker)４１０は、ディスプレイ・デバイスへのアクセスをレクタングル・セグメント単位で調整することに関連づけられている。スクリーン・ペインタ・メーカ４１０はコンポジションも取り扱う。領域(region)は、フレーム・バッファ・デバイスで高速クリッピング・オペレーションを行なうために使用されるデータ構造である。領域には、どのピクセルがレンダリング・オペレーション期間に変更されたかが記録されるが、ピクセル・カラーや透明(transparency)といった他の情報は無視される。領域ペインタ・メーカはこのタイプの情報を領域データ構造に記録するように最適化された特殊な領域ペインタを作成する。スクリーン・ペインタ・メーカは、マルチタスクによる共有ディスプレイ・デバイスへのアクセスを調整する。あるタスクがデバイス上のピクセルを変更する必要があるときは、スクリーン・ペインタ・メーカは、ソフトウェア・カーソルやスプライトなどのエレメントを合成していた交差（インタセクション）があるかどうかを特定する。交差があることが特定されると、スクリーン・ペインタ・メーカは、コンフリクト（競合）が起こったときにそのコンフリクトを解消できる特殊なコンポジション・ペインタ(compositing painter)を作成する。好ましくは、デバイス・キャッシュ２０３（図２）とレンダリング・ルーチンには、ペインタ・メーカが単一のオブジェクトとして見えるようになっている。しかし、実際には、チェイニングされるペインタ・メーカは、トップ・ペインタ・メーカの下にいくつでも存在する。チェイン内の各ペインタ・メーカは、チェイン内の次のペインタ・メーカだけを知っており、抽象的にTPainterMarkerとしてそれを知っているだけである（図４）。図５は、ペインタ・メーカ・チェインの例を示す図である。すべてのペインタ・メーカは、好ましくは、単一のペインタ・メーカ・クラスからインスタンス生成されたオブジェクトになっている（図４参照）。本発明の好適実施例によるペインタ・メーカ・クラスのインタフェースは、コード例２に示されている。ペインタ・メーカはペインタを作成するために使用される。最も単純なケースでは、ペインタはピクセル・バッファに直接に書込みを行う単一ピクセル・バッファ・ペインタにすることができる。しかし、もっと複雑なペインティング・シナリオでは、ペインタ・メーカ・チェインから戻されるペインタは、各々がペインティング・プロセスで別々の役割を果たすペインタのチェインの最初のペインタになっている場合がある。例えば、最初のペインタはクリップ・エリアへのペインティングを消去し、二番目のペインタはオーバラップするカーソルでペインティングを合成し、三番目のペインタはピクセル・バッファに直接に書込みを行うことができる（図６）。上述したように、ペインタ・メーカ・チェイン内の各ペインタ・メーカは、レンダリング・ルーチンがディスプレイ・デバイスにレンダリングするとき使用するペインタを作成する。図３のステップ３０８を参照。具体的には、ペインタ・メーカがペインタを作成するためにコールされたとき、そのペインタ・メーカはチェインの次のペインタ・メーカをコールし、そのペインタを戻されたペインタとチェイニングしなければならない。当然のことであるが、最後のペインタ・メーカはこれを行う必要はない。各ペインタ・チェインは、それを作成するペインタ・メーカ・チェインと直接にパラレルになっている。しかし、必ずしもそうである必要はない。ペインタ・メーカは複数の連続するペインタをチェイン内に作成することができる。あるいは、ペインタ・メーカは、次のペインタ・メーカから返されてきたペインタを返すだけで、ペインタを作成しないことを決定することもできる（例えば、クリッピングが必要でないとき）。次に、ペインタ・メーカ・チェインがどのようにして作成されるかについて図７を参照して説明する。好ましくは、ペインタ・メーカ・チェインは、grafdevi ce２０８に対してgrafport２０４を構築するときにインスタンス生成され、インストールされる。この場合、grafport２０４は特定のタスク２０２と関連づけれ、grafdevice２０８は特定のディスプレイ・デバイス１２６と関連づけられている。grafport２０４がインスタンス生成されるとき、grafportコンストラクタ(c onstructor)はCreateGrafCacheと名づけたgrafdeviceメソツドをコールする（これは図７にライン７１８で示されている）。図７に示す例では、フレーム・バッファ・ディスプレイ・デバイスを取り扱っているので、grafdevice ２０８はフレーム・バッファ・オブジェクト７０６で表されている。 CreateGrafCacheはキャッシュ２０３を生成し、これは最終的には、新しく作成されたgrafport２０４にストアされる。キャッシュ２０３の構築中に、フレーム・バッファ・オブジェクト７０６はピクセル・バッファ・オブジェクト７０８に入っているCreatePainterMakerメソッドをコールする（図７にライン７２０で示されている）。ピクセル・バッファ・オブジェクト７０８は、好ましくはディスプレイ・デバイス１２６と関連づけられているが、これは、上述したように、図７の例ではフレーム・バッファ・ディスプレイ・デバイスになっている。 CreatePainterMakerメソッドは、好ましくは、ピクセル・バッファ・ペインタ・メーカ・オブジェクト７１０を作成し、返却するように動作する（図７にライン７２２で示されている）。ピクセル・バッファ・ペインタ・メーカ・オブジェクト７１０はペインタ・メーカ・クラスからインスタンス生成されるが（上記のコード例２）、そこでは、そのメソッドは特定の機能をインプリメントするように必要に応じてオーバライドされている。具体的には、ピクセル・バッファ・ペインタ・メーカ７１０は、特定ピクセル・バッファ・タイプのペインタを作成する。戻されたピクセル・バッファ・ペインタ・メーカ７１０を使用して、フレーム・バッファ・オブジェクト７０６はスクリーン・ペインタ・メーカ７１２を構築する（フレーム・バッファがスクリーンを表している場合。これは図７にライン７２４で示されている）。スクリーン・ペインタ・メーカ・オブジェクト７１２を使用して、フレーム・バッファ・オブジェクト７０６はクリッピング・ペインタ・メーカ７１４を作成する（図７にライン７２６で示されている）。最後に、フレーム・バッファ７０６（または、同等のgrafdevice２０８）はクリッピング・ペインタ・メーカ７１４をデバイス・キャッシュ２０３内のペインタ・メーカ・フィールドに割り当て、デバイス・キャッシュ２０３をgrafport２０４にストアする。これにより、grafport２０４はデバイス・キャッシュ２０３を所有し、それを各レンダ・コールと一緒にgrafdevice２０８に引き渡す。４．発明の動作以下では、本発明の動作について詳しく説明する。各grafdevice２０８には、grafport２０４から各レンダリング・コールと一緒にデバイス・キャッシュ２０３が渡される。デバイス・キャッシュ２０３は、最上部のペインタ・メーカを指しているポインタを供給している。チェイン内の各ペインタ・メーカはチェイン内の次のペインタ・メーカだけを指している。デバイスは、キャッシュを作成するときの一部としてチェインを作成してリンクするので、新しいペインタ・メーカ・チェインはデバイスをサブクラス化することによりインストールされる。レンダリング・ルーチンは、インストールされたペインタ・メーカを使用して、それぞれのペインタを作成する。その結果、同じレンダリング・コードはスクリーンまたは領域内にも、または、それを受け入れる他のオブジェクト内にもレンダリングを行うことができる。レンダリング・メソッドは、そのことを知らない。これらのメソッドはペインタ・メーカを多態的にコールし、ペインタ・メーカからは、適切なグラフィカル・オペレーションを多態的に実行するペインタが戻される。図３を参照して上述したように、タスク２０２からプリミティブ・ドローイング・メッセージの受け取りに応答して、grafport２０４はメッセージをgrafdevi ceオブジェクト２０８に送って、grafdeviceオブジェクト２０８によって定義されたレンダリング・メソッドをgrafdeviceオブジェクト２０８に実行させる。gr afport２０４からgrafdevice２０８へ送られるメッセージには、キャッシュ２０３が含まれている。grafport２０４からのメッセージの受け取りに応答して、gr afdeviceオブジェクト２０８はメッセージで識別されたレンダリング・メソッド（またはルーチン）を実行する。好ましくは、本発明のペインタ・アーキテクチャはレンダリング・ルーチンの内部で起動される。そこで、以下では、本発明のペインタ・アーキテクチャのオペレーション（つまり、ペインタ・メーカとペインタのオペレーション）をコード例３に示すレンダラ・ルーチン例を参照して説明することにする。命令"TDrawingLock"（コード例３のセグメントＡ）はドローイング・ロック(d rawing lock)を構築するように動作するが、このロックはペインタ・クラスのタイプを取るテンプレート・クラスからインスタンス生成されたオブジェクトである。以下で説明するように、２つのペインタを同時に使用できるようにする特殊なドローイング・ロックが用意されている。ドローイング・ロック・オブジェクトは、ペインタ・メソッドがコールされる前にルーチン内のどの個所でも作成することが可能である。このクラスの主目的は、タスクに関するかぎり、ペインタとペインタ・サポート・オブジェクトの例外アンワインディング(exception unw inding)を取り扱うことである。コードをレンダリングしているとき例外が引き起こされた場合は、同期ロックを解放し、ペインタ・ロックを割り当て解除しなければならない。そのような理由から、ドローイング・ロックは、好ましくは、スタック上に割り当てられている。また、ドローイング・ロックはなんらかのキャッシングを行うので、その後で行われるAcquire（獲得）、Release（解放）およびペインティング・コール（下述する）は可能な限り高速化している。 AcquireとReleaseはドローイング・ロックのメソッドである。これらのドローイング・ロック・メソッドは、ペインタ・メーカのメソッドをコールし、レンダリング・ルーチンで使用されるペインタをペインタ・メーカに作成させる。本発明の別実施例では、ドローイング・ロックは使用されない。その代わりに、ペインタ・メーカ・メソッドがレンダリング・ルーチンから直接にコールされる。レンダラ（つまり、レンダリング・ルーチン）はペインタ・メソッドをコールする準備状態になると（ディスプレイ・デバイスにレンダリングするために）、ドローイング・ロック・テンプレートに渡されたタイプに一致するペインタ・ポインタを作成し、ドローイング・ロックのAcquireメソッドをコールする（セグメントＥ）。ドローイング・ロックのAcquireメソッドはこのポインタを適切なペインタを指すように変更する。このペインタはペインタ・メーカ・チェインによって生成されたものである（具体的には、Acquireメソッドはペインタ・メーカ・チェインの適切なメソッドをコールし、ペインタ・メーカ・チェインが次にペインタを生成する）。動的環境によっては、ドローイング・ロックは、領域にクリッピングし、共有デバイスへのマルチスレッド・アクセスに参加し、コンポジション・オペレーションを実行し、正しいかどうかを検証し、あるいは領域構造内にペインティングすることができるペインタを返却する。そのピクセルがどこに移動するかは、レンダラに知らされない。正しいポインタを返すためには、Acquireメソッドはレンダリングしようとしている領域の境界(bounds)を知っている必要がある。そのようにする必要があるのは、ある種のペインタのオペレーションがレンダリングしようとする境界に左右されるからである（例えば、クリッピング・ペインタ）。そのような境界は境界パラメータ(bounds parameter)によってレンダリング・ルーチンに渡される。なお、この境界パラメータはドローイング・ロックを作成するコールの中で渡される（セグメントＡ）。また、この境界パラメータは、レンダリングしようとするエリアの左境界と右境界を判断するためにもアクセスされる（セグメントＢ）。さらに、この境界パラメータは、レンダリングしようとするエリアを垂直方向に繰り返すために使用されるWHILEループ（セグメントＣから始まる）の出口条件を定義するためにアクセスされる。WHILEループ（セグメントＣ）を繰り返すごとにレンダリングしようとするサブエリアは、セグメントＤのステートメントによって定義されている。レンダリング・ルーチンがペインタ（これはセグメントＥでAcquireメソッドによって戻されたものである）を得ると、レンダリング・ルーチンはペインタを使用してディスプレイ・デバイスにレンダリングする。具体的には、レンダリング・ルーチンはペインタの適切なメソッドをコールし、これらのペインタ・メソッドはディスプレイ・デバイスにレンダリングする。これはセグメントＧで表されているが、ペインタ・メソッドへの実際のコールが示されていないのは、これらがインプリメンテーションに依存するためである。セグメントＤのステートメントで定義されたサブエリアで実行しようとしているグラフィカル・レンダリング・オペレーションのすべてを、レンダリング・ルーチンが実行すると、レンダリング・ルーチンはペインタを解放し（セグメントＨ）、WHILEループを再び繰り返すことにより次のサブエリアのドローイングを開始する。カーソルやスプライトなどの対話型スクリーン・エレメントの応答性を保証するためには、レンダラはAcquireコールからReleaseコールまでの計算を最小限に抑える必要がある。上述したように、ドローイング・ロックはペインタ・メーカ・オブジェクトのメソッドをコールする（別の方法として、レンダリング・ルーチンがこれらのペインタ・メーカ・メソッドを直接にコールすることも可能である）。デバイスは１つのアクティブ・ペインタ・マーカをもっており、これはドローイング・ロックがデバイス・キャッシュから取り出したものである。下に示す表１は、ドローイング・ロックとペインタ・メーカの双方に行われるコールの時間順の概略で（上述したとおり）、各コールの機能（関数）の簡単なコメントを示している。５．例以下、レンダリングの例を用いて本発明をさらに詳しく説明するが、この例では、クリッピング、コンポジション、およびマルチスレッド同期化を取り扱う必要のあるレンダリングがスクリーン・デバイス上で行われものである。このセクションでは、そのような場合に使用されるペインタ・メーカと、表１に概略として示されているコールに対するペインタ・メーカの応答について説明する。前述したように、ドローイング・ロックが作成された後（コード例３のセグメントＡ）、ドローイング・ロックはペインタ・メーカをデバイス・キャッシュ２０３から取り出すことから開始する。デバイス・キャッシュ２０３は、デバイスと現環境に応じて、単純ペインタ・メーカを含んでいる場合と複合ペインタ・メーカを含んでいる場合がある。この例では、デバイス・キャッシュから戻されるペインタ・メーカは複合ペインタ・メーカ(complex painter maker)であり、図５に示すように３つのペインタ・メーカからなっている。ドローイング・ロックは、まず、ペインタ・メーカのUsePaintメソッドをコールする。このコールでは、ドローイング・ロックは使用しようとするペインタのタイプを指定している（ドローイング・ロックを作成したレンダリング・ルーチンの中のステートメントで与えられた情報から）。コード例２に示すように、ペインタ・メーカ・クラスは以下に示すタイプのペインタに対するUsePaintメソッドを定義している。つまり、スパン・ペインタ、ヘアライン・ペインタ、ビットマップ・グリフ(glyph)・ペインタ、および３Ｄスパン・ペインタである。しかし、他のタイプのペインタも、本発明の範囲と精神に属するものである。UsePai ntに渡される他のパラメータは実行すべきペインティングのタイプを記述している。例えば、ペイント・パラメータはカラーを指定している。トランスファモード(transfermode)パラメータは、ペイントをどのように適用するかを指定している（例えば、レンダリングされるイメージ（画像）を半透明(translucent)にする）。境界パラメータはペインティングを行おうとしているエリアを指定している。 UsePaintによると、ローレベル・ペインタ・メーカ（ピクセル・バッファ・ペインタ・メーカ５０８など）は、このペインティング・オペレーションに対してペインタをキャッシュすることができるので、パフォーマンスがさらに向上する。ピクセル・バッファ・ペインタ・メーカ５０８が、UsePaintのオペレーションの間にペインタを作成し、キャッシュするものとする。正しいペインタを作成するためには、TPixelBufferPainterMaker５０８は、ペインタとペインタ・タイプ (TSpanPainter、TGlyphPainterなど)の両方を知っている必要がある。適切なペインタ・クラスのNILポインタが渡されて、オーバライドされた適切なUsePaint コールが選択される。TPixelBufferPainterMakerはペイント・パラメータに入っている値を調べ、対応するペインタが作成するのに高速であるかどうか、あるいはキャッシュすべきかどうかを判断する。そのペインタがキャッシュの候補になっていれば、これはすでにキャッシュにある可能性があるので、ピクセル・バッファ・ペインタ・メーカ５０８はそこを調べる。いずれの場合も、ペインタを作成するか、あるいはそれをキャッシュから取り出すことになる。そのあとで、ペインタを指すポインタを、ペインタ・メーカ５０８内部の特殊なスロットにストアしておくので、ペインタは動的フェーズの各部分で調べることなく、そこから取り出されることになる。しばらくの間先に進むことにして、理解されるように、対応するTPainterMake r::DoneWithPaintsメソッドを使用すると、TPixelBufferPainterMaker５０８は、必要ならばそのペインタを削除することができる。このメソッドはドローイング・ロックのデストラクタ(destructor)によってコールされる。ペインタ・アーキテクチャの動的フェーズは、レンダラが実際にピクセルのドローイングを開始する準備状態になったとき開始する。なお、任意の量の初期設定または計算をドローイング・ロックが作成されてから、使用することができる。即時にペインティングを開始する意図があることをペインタ・アーキテクチャに知らせるには、レンダラは、コード例３のセグメントＥ中のドローイング・ロックのAcquireメソッドをコールする。 Acquireメソッドは、適切なペインタのペインタ・メーカStartDrawingメソッドをコールする（コード例２参照。ここではペインタ・メーカ・オブジェクトは各ペインタ・タイプ別にStartDrawingメソッドをもっていることが示されている）。ペインタ・メーカはStartDrawingメソッドを使用して、どの種類のクリッピング、コンポジション、およびマルチスレッド同期化が必要であるかを動的に判断する。単一のプリミティブのレンダリングをペインタ・アーキテクチャを通る複数の小さなパスに分割することが可能であり、その場合、各パスは、クリッピングとコンポジションに関するかぎり、同様の問題を取り扱う。これは、オリジナル境界以下のものを許可することにより行なわれる。ペインタ・メーカは、レンダリングを制限するようにboundsBottomパラメータを変更することができる。なお、境界は垂直方向にだけ制限することができる。Acquireメソッドが戻ると、レンダラは、ロックが解放され、再獲得されるまで、スキャンラインをboun dsBottom（これは含まない）まで変更することが許される。 StartDrawingコールは、TCippingPainterMaker５０４から始まるペインタ・メーカ・チェインをたどって伝わっていく。各ペインタ・メーカの応答の仕方は次のとおりである。まず、その環境をチェックして、境界レクタングルを制限する必要があるかどうかを判断する。そうであれば、boundsBottomパラメータを現在値の最小値およびペインタ・メーカの限界値になるように変更する。（boundsBo ttomが現在３０であり、TScreenPainterMake５０６はペインティングをスキャンライン２０に制限してスキャンライン２１から始まるスプライトを避けようとしていると想定する。）次に、ペインタ・メーカはチェイン内の次のペインタ・メーカのStartDrawingメソッドをコールしてそのペインタを得る。そのあと、現在のペインタ・メーカは、必要ならば、自身のペインタを次のペインタ・メーカから返されたペインタの上にチェインする。ここで述べている例では、TClippingPainterMaker５０４はTScreenPainterMak er５０６のStartDrawingメソッドをコールする(TClippingPainterMaker５０４は、下位レベルのStartDrawingメソッドが終了した後、その作業のすべてを行う) 。TScreenPainterMaker５０６は境界レクタングルを、スプライトやラバーバンドなどの種々のコンポジットされたアイテムの境界と交差させる。交差(interse ction)が見つかつたとき、boundsBottom値を制限すると最も効率のよいペインタを使用することができる。次に、境界（boundsBottomによって変更されている）のサイズのスクリーン・シールドが作成されて、スクリーンのその部分が排他的にアクセスできるようにする。そのあと、TScreenPainterMaker５０６はTPixelBufferPainterMaker５０８のStartDr awingメソッドをコールする。 TPixelBufferPainterMaker５０８は、自身が作成したペインタをUsePainterメソッドの間にキャッシュから取り出す。なお、StartDrawingは、UsePaintよりも相当コールされるので、ルックアップおよび／または作成費用のすべてはUsePai ntに配置し、StartDrawingは高度に最適化されることになる。ある種のペインタは、そこにドローイングしようとするレクタングルの境界を知っている必要があるので（自身のポインタ、パターンへのオフセットをキャッシュするか、またはメモリをロックするために）、TPixelBufferPainterMaker５０８はペインタのSe tBoundsメソッドをコールしてその情報を伝達する。そのあと、自身が作成したペインタを返却する。ピクセル・バッファは、通常は、ドローイングの境界を制約することがないので、boundsBottomパラメータは通常、変更されない。デバイスの境界へのクリッピングは、パイプライン中でもっと早い時点で行われている。ここでの説明において、ペインタ・メーカがペインタを「作成する」というときは、ペインタ・メーカ・オブジェクトが新しいペインタ・オブジェクトをインスタンス生成するという意味である。新しいペインタ・オブジェクトは適切なペインタ・クラスを用いてインスタンス生成される（すべに述べたように、ペインタ・クラスは各グラフィカル・プリミティブごとに異なっている）。コード例１を参照。新しいペインタ・オブジェクトをインスタンス生成するとき、クラス・メソッドは、ペインタ・オブジェクトがレンダリングを実行しようとしている特定のグラフィカル環境で必要とする機能（関数）を実行できるように、必要に応じてオーバライドされる。コントロール（制御権）はTScreenPainterMaker５０６のStartDrawingメソッドに戻される。適切なペインタ・チェインを作成するために、ペインタ・チェイン内の各ペインタはチェインの次のペインタを指すポインタをもっているので、チェインの存在は明示(explicit)の外部リストではなく、黙示(implicit)である。ペインタ・メーカ・チェイン内の各ペインタ・メーカは、ゼロ個または１個以上のペインタを作成し、これらをペインタ・メーカ・チェインの次のペインタ・メーカから返されたペインタとチェイニングする。TScreenPainterMaker５０６は最も適切な（つまり、最も効率的な）ペインタを作成し、返却する。多くの場合、このジョブを最適に行うには、２つ以上のペインタが必要になる。例えば、２つのスプライトの下にレンダリングしようとするラインは、単純ピクセル・バッファ・ペインタを使用して、そのラインのうち隠されていない部分をペイントし、そのあとで単純コンポジション・パインタを使用して、１つのスプライトの下に置かれているラインの部分をペイントし、そのあとで複合コンポジション・ペインタを使用して、両方のスプライトの下に置かれている部分をペイントし、最後に単純ペインタを使用して、再びスクリーンに直接にペイントすることができる。本発明のペインタ・アーキテクチャによれば、好ましくは、一度に戻されるペインタは１つだけとしているので、TScreenPainterMaker５０６は最初のペインタを返却し、boundsBottomパラメータは、レンダラに追加のドローイング・ロックAcquireコールを行わせて、他のペインタを得るように変更される。この方法は相対的に複雑であるが、不必要なコンポジション・オーバヘッド、バックバッファ割当て、およびシールドの存続期間（これはスプライトの応答性に影響する）が大幅に節減される。また、この動作はコンポジション・アーキテクチャによってチューニングできるので、単一の複合ペインタの実行効率がロックを何度も獲得する場合よりもすぐれていれば、これはどのレンダリング・コードを変更しなくても行うことができる。この時点で、コントロールはTClippingPainterMaker５０４に戻される。これは、単純ピクセル・バッファ・ペインタ（コンポジションを行う必要がない場合）またはコンポジション・ペインタ・ラッパ(compositing painter wrapper)のどちらかであるペインタを受け取る。TClippingPainterMakerは境界レクタングル（boundsBottomによって変更されている）とクリッピング領域の間に交差があるかどうかをチェックする。交差が見つからなければ、その下に置かれたペインタ・メーカから受け取ったペインタとboundsBottom値を返却する。そうでなければ、クリッピング・ペインタをペインタ・チェインに追加する。 TScreenPainterMaker５０６の場合と同じ方法でドローイングを中断する必要が起こったときは、boundsBottomを変更することが許される。そのあと、コントロールはTDrawingLockのAcquireメソッドに戻される。ペインタはAcquireメソッドに返却されている。その場合、返されたペインタは、そこでドローイングしようとしている動的環境によっては、ペインタ・チェインになっている場合がある。ペインタとboundsBottom値はドローイング・ロック・クライアント（つまり、レンダリング・ルーチン）に返される。レンダラはさらに進んで、TDrawingLockから受け取ったペインタにコールを行う（コード例３のセグメントＧに示されている）。これらのコールは次のような形式になっている（少なくとも、スパン・ペインタの場合。他のペインタはメソッドが異なっている）。スクリーン・デバイスでレンダリングを行うとき、ペインタ・コールはタイム・クリティカル(time-critical)である。従って、レンダラはAcquireメソッドがコールされる前またはReleaseメソッドがコールされたあと、重要な計算を行う必要がある。レンダラが完了したとき、あるいはboundsBottom値まで達したとき、あるいはペインタ・コール間で別の計算を行うために休止する必要が起こったとき、TDra wingLock::Releaseをコールする（コード例３のセグメントＨ）。これにより、ペインタ・メーカのStopDrawingメソッドがコールされる。TClippingPainterMak er５０４、TScreenPainterMaker５０６、およびTPixelBufferPainterMaker５０８のStopDrawingメソッドは順番にコールされる。StartDrawingパスの間に自身が作成したクリッピング・ペインタを削除する必要がなければ、TClippingPaint erMaker５０４が行う仕事はほとんどない。TScreenPainterMaker５０６はスクリーン・シールドを解放し、他のスレッドがスクリーンのこの部分を再び変更できるようにする。TPixelBufferPainterMaker５０８は多分なにもしない（そのペインタの破壊が後続のDoneWithPaintsコールまで行われないのは、追加のStartDrawingコールがこのペインタを使用して行われる可能性があるからである）。レンダラは、独自のアルゴリズムに従って、あるいはペインタ・メーカによって課されたboundsBottomの制約に応じて、AcquireメソッドとReleaseメソッドを複数回コールすることができる。最終的に終了すると、スタック・ベースのTDra wingLockはレンダリング・ルーチンから出るとき自動的に破壊される。この時点で、ペインタ・マーカは最後のコールDoneWithPaintsを取得し、これは各ペインタ・メーカに渡される。この時点で、TPixelBufferMaker５０８は使用していたペインタを削除するか、あるいはキャッシュする。ペインタ・メーカがそのペインタを削除するか、キャッシュするかどうか、およびこれをStopDrawingコール中で行うか、DoneWithPaintsコール中で行うかどうかは、作成されたペインタの有効な存続によって決まる。６．２ペインタの同時使用ある種のレンダラは２つのペインタを同時に使用して、例えば、塗りつぶしやフレーミングを行う必要が起こることがある。重要なことは、２つのペインタは多数のものを共有するので（境界レクタングル、クリッピングおよびスクリーン・ペインタ、およびスクリーン・シールド）、この使い方を予測しておくことである。これはパフォーマンス向上が得られるだけでない。これらのペインタが独立に扱われると、同じスクリーン・シールドを予約しようとしたとき、問題が発生することになる。本発明によれば、特殊なドローイング・ロックTDoubleDrawingLockが２つのペインタを同時使用することをサポートしている。これらの２ペインタはクラスが同じでも、異なっていても構わない。好ましくは、３つ以上のペインタが同時にアクティブになっていることはない。この制約により、一定数のペインタをTPix elBufferPainterMakerレベルでキャッシュすることが最適化される。以下は、２ペインタ・レンダラから抜粋したサンプル・コードである。コード例４のレンダリング・ルーチンのオペレーション、具体的には、本発明のペインタ・メーカへのコールとその後のオペレーションは、ドローイング・ロックがある種のペインタ・メーカ・メソッドを複数回コールし、その他は一度だけコールすることを除けば、単一ペインタ・レンダラと同じである。例えば、Tr imBoundsメソッドを一度だけコールするだけで済むのは、同じクリッピング領域が両方のペインタで使用されるからである。他方、２つのUsePaintコールが行われるのは、最下位ペインタ・メーカに両方のペインタをキャッシュするためである。この場合には、TPixelBufferPainterMakerは２つのアクティブ・ペインタを１回でキャッシュするストラテジをもち、これらをStarDrawingコールの間に即時に返却できることが必要である。UsePaintコールは２回であるのに対し、１回のDoneWithPaintsコールだけが必要である。 TDoubleDrawingLockは、TPainterMaker::StartDrawingへの各コールでどちらのペインタが必要であるかを指定している。クリッピングとスクリーン・ペインタ・メーカのようなペインタ・メーカが余分の仕事を行うのは、最初のペインタのときだけである。例えば、スクリーン・ペインタ・メーカは最初のパスのときだけシールドを予約する。二番目のパスで再びそれを行おうとすると、永久にブロックされることになる。７．検査ペインタレンダリング・コードを書く人が本発明のペインタ・メーカとペインタを誤った使い方をする場合、それは様々である。プログラマがユーザ・フレンドリで強固な環境で作業できるようにするために、本発明は、プログラマが犯し易いエラーを検出する機能を用意している。以下は、本発明によって検出されるエラーを列挙したものである。・ TDrawingLock::Acquireに渡された境界は、ドローイング・ロック・コンストラクタに渡された境界より大きい。・ペインタ・コールは、TDrawingLock::Acquire中で境界（boundsBottomで変更されている）の外で行われた。・ペインタ・コールは、ドローイング・ロックAcquire/Releaseペアの外で行われた。・ペインタ・コールは、ペインタのロックが壊されたあとで行われた。これらの各々は、ドローイング・ロックがパラメータとして各ペインタ・メソッドに渡されていれば、比較的チェックが容易である（アサーション(assertion )を使用すると）。しかし、ペインタにドローイング・ロックを知らせるアーキテクチャ上の理由はほかにないので、その解決法は理想的でない。改善された解決法では、条件付きでインストールされた検査ペインタ・マーカがペインタ・メーカ・チェインに含まれている。この検査ペインタ・マーカは正しいかどうかのチェックを次のように行う。検査ペインタ・メーカのStartDrawingメソッドでは、境界レクタングルはUseP aintコールの間に検出された境界と比較される。新しい境界（boundsBottomによって変更）は返却されたペインタにコピーされる。ペインタは各ペインタ・コールをインターセプトし、これらの境界と突き合わせてそれを検査する。境界を越えているペインタ・コールがあれば、アサーションが引き起こされる。ペインタ・メーカのStopDrawingコールは、検査ペインタを削除しない。境界を空にセットするだけである。ドローイング・ロックReleaseコールのあとでドローイングしようとすると、アサーションが引き起こされる。ドローイング・ロックが破壊されたあとでは、検査ペインタもDoneWithPaints コールを受けて破壊されるので、ペインタの使用を検出することは困難である。その仮想テーブル(virtual table)がまだ影響を受けていなければ、削除された検査ペインタがコールされる可能性がある。その場合、その境界がまだ空であるおそれがあるので、その試みはアサーションを引き起こすことになる。なお、その保証はない。これはロック・パラメータを使用する解決法と対照的であり、この場合には、ロックがないとペインタがコールされないという保証が得られる。８．クリップ領域の作成このアーキテクチャが解決することを目的としている別の問題は、クリッピング領域の作成と関係がある。このような領域を作成するためには、レンダラは通常のピクセル・バッファではなく、領域にペイントを行う特殊なペインタを使用する必要があるが、同じレンダリング・パイプライン・コードをすべて再利用することが望ましい。この新しいアーキテクチャによれば、特殊な領域ペインタを作成する方法を知っている、別のペインタ・メーカをデバイス・キャッシュに挿入すると、この問題は簡単に解決する。このペインタ・メーカはCreateRegionペインタ・メーカと呼ばれる。これを真のオブジェクト指向方式で行うために、CreateRegionペインタ・メーカはデバイス・キャッシュの内部を調整するだけではない。その代わりに、そのペインタ・マーカを要求された場合を除き、通常のフレームバッファ・キャッシュと同じ働きをするフレームバッファ・キャッシュ・サブクラス８０４（図８参照）を作成する。その時点で、その特殊なTRegionPainterMakerを返却し、これは特殊なデバイス依存領域データ構造に「ペイントする」ペインタを作成する。フレームバッファ・キャッシュをライトウィエト方式でサブクラス化するために、TFrameBufferCache８０４は、TStandardFrameBufferCache８０６とTLinkedR egionPainterMakerCache８０８の２つのサブクラスをもつライトウェイト抽象クラスである。TLinkedRegionPainterMakerCache８０８はGetPainterMakerメソッドだけをインプリメントしており、このメソッドはコールされると、キャッシュにそのペインタ・メーカ（つまり、そこにストアされたペインタ・メーカ）を返却させる。その他はすべてTFrameBufferCache８０４へ送り返され、これによってTLinkedRegionPainterMakerCache８０８が作られる。CreateRegionペインタ・メーカは、その特殊フレームバッファ・キャッシュ８０８を、コールしたレンダリング・メソッドに引き渡す。９．ピクセル・ストリーマこれまでに説明してきたアーキテクチャは、ペインタを使用するどのレンダリング・ルーチンに対しても有効である。しかし、本発明のアーキテクチャによれば、ピクセル・バッファに書き込む方法が他にもいくつか用意されている。最も重要なケースの１つではピクセル・ストリーマ(pixel streamer)を含み、それは大部分のイメージ・レンダリング・オペレーションで使用されている。ピクセル・ストリーマとペインタとの主な違いは、ピクセル・ストリーマをペア（リーダとライタ）にすると、ピクセル・データを一方のフォーマットから他方のフォーマットへ変換できることである。なお、このペアリングはオプションである。ソースとデスティネーションのピクセル・バッファが同じフォーマットを共有するときは、ジョブを処理するには一方のピクセル・ストリーマだけが必要である。２つのストリーマが必要になるような場合には、リーダを一度だけ割り当て、初期化すればよい。これは、ライタに影響する同じ動的制約（クリッピング、コンポジション、マルチスレッド同期化）を受けないからである。リーダは常にオフスクリーン・バッファから読み取る（これはアーキテクチャ上の制約である）。これとは逆に、ライタはペインタと同じ動的制約の対象となる。ペインタと共有する類似性が多数あるため、ピクセル・ストリーマは同じペインタ・メーカ・クラスを通して取り扱われる。違いもあるため、ペインタ・メーカ・クラス内に新しいメソッドが必要であり、別種のドローイング・ロックが採用されている。これらは、一方または他方のケースで未使用になっている多数のパラメータを受け渡ししないと統合化できない（例えば、ストリーマはTPaintパラメータを使用しない）。類似性と相違点は、コード例５に示す例を参照して下述する。この例に示すように、トリビアル・リジェクト(trivial reject)・クリッピングおよびドローイング・ロック構築を行うコードはペインタで使用されるものと同じである。１つの違いは、TPixelStreamerDrawingLockがテンプレート・クラスでないことであるが、これは、異なるピクセル・ストリーマがすべて共通の基底ベースから派生しているためである。ペインタの場合ではそうでない。最大の違いは、ドローイング・ロックに余分のコールGetPixelStreamerReader があることである。ピクセル・ストリーム・リーダは一度だけ割り当てられる必要があるのに対し、ピクセル・ストリーム・ライタは、クリッピング、コンポジション、およびマルチスレッド同期化を可能にするために、動的にラップ（循環）することが可能である。パフォーマンス上の理由から、この費用のかかるルックアップはAcquireコールの外に移動して、何度でも実行できるようにしている。GetPixelStreamReaderコールに渡される最後のパラメータはenum（列挙型）であり、これは、リーダが必要でない場合（同じピクセル・フォーマットの２ピクセル・バッファ間で転送するにはピクセル・ストリーマは１つで十分である）、リーダがオプションである場合（ピクセル・バッファは変換が必要かどうかを判断する）、およびリーダが必要である場合（ある種のフィルタリング・オプションでは、特定のピクセル・フォーマットを想定している）を区別するために使用される。１０．スクロールエリアイメージ・レンダリングに対するドローイング・ロック・サポートでは、パフォーマンス上の理由から重要な想定を行っている。その想定とは、リーダがクリッピング、コンポジション、またはマルチスレッド同期化の問題を気にする必要がないことである。言い換えれば、リーダは非共有のオフスクリーン・データから読み取らなければならない。この想定には、スクローリングをサポートするために必要なスクリーン間のコピーは除外されている。スクリーン・デバイス・サブクラスは、その特定スクリーン・デバイスで意味をもつような形で、スクローリング・メソッドをインプリメントしている。最悪の場合でも、スクリーン全体をロックすることができ、ピクセル情報をオフスクリーン・バッファに転送することができ（スプライトを考慮に入れていることは勿論である）、オフスクリーン・バッファをあとで新しいスクリーン位置に書き込むことができる。殆どの場合、もっと効率的な別の方法が用意されている。１１．３Ｄサポート３Ｄレンダリングは、ドローイング・ロック・コンストラクタが、ペインタとトランスファ・モードではなく、拡張可能シェーディング・アルゴリズムをインプリメントしているシェーダ・オブジェクトを受け取る点を除けば、２Ｄのそれと同じである。３Ｄでは、シングルとダブルのドローイング・ロックがまだあり、これらはまだテンプレート化されているが、好ましくは、２つの３Ｄスパン・ペインタ用のダブル・ドローイング・ロックだけが使用されている。次の例は、３Ｄドローイング・ロックの使い方を示したものである。１２．拡張可能性本発明は、（1）新しいタイプのペインタ・メーカを作成するようにTPainterM akerをサブクラス化し、（2）そのような新ペインタ・メーカをペインタ・メーカ・チェインにインストールすることにより拡張可能である。新ペインタ・メーカのインストールは、ピクセル・バッファをサブクラス化し、デバイスがそれをコールしてチェインの最後のペインタ・メーカを作成するか、あるいはデバイスをサブクラス化し、そのピクセル・バッファから返されたものの上に他のペインタ・メーカを階層化する機会をそのデバイスに与えることにより行われる。ペインタ・メーカは，将来必要になると予想されるペインタをキャッシュしておくことができる。そのために、キャッシュをメンバ・データとしてストアしておく。TPainterMaker::UsePaintメソッドとTPainterMaker::DoneWithPaintsメソッドは、チェイン内の各ペインタ・メーカにキャッシュを割り当て、その割当てを解除する機会を与える。本発明の種々実施例について上述してきたが、これらの実施例は単なる例示であり、これらに限定されるものではない。従って、本発明の技術範囲と効力が及ぶ範囲は上述した実施例のいずれにも制限されるものではなく、請求の範囲に明確化されている内容およびその均等なものに従ってのみ判断されるものである。

【手続補正書】特許法第１８４条の８【提出日】１９９５年１０月２３日【補正内容】（原文明細書第２頁）従来の、他のコンピュータ・ベースのグラフィックス・システムでは、限られた数のレンダリング・ルーチンが用意され、そこではレンダリング・ルーチンの各々は、グラフィカル環境のすべてについてグラフィカル環境特有のコードを含んでいる。この種のグラフィカル環境特有コードの実行は、同じようにレンダリング・ルーチンに含まれている条件ステートメント（"if-then-else"ステートメントなどの）の実行に基づいている。しかし、限られた数のレンダリング・ルーチンを用意し、各ルーチンがグラフィカル環境のすべてについてグラフィカル環境特有コードをもつことは、結果として得られるレンダリング・ルーチンが複雑になり、開発と保守が困難になるので理想的な解決法ではない。オブジェクト指向環境で実現されている従来のビジュアルおよびグラフィック・システムは、W. J.Schroeder 著"VISAGE"Proceedings Visualization 19 October 1992，Los Ala mitos，pp.219-226に開示されている。オブジェクト指向イメージ処理環境を示す別の文献としては、Drake著「オブジェクトおよびイメージ(Objects and Imag es)」（Computer Systems Europe 10(1990)January，No.1 pp.31-32）に記載されているものがある。発明の概要本発明は、様々なグラフィカル環境でグラフィカル・プリミティブをドローイング（またはレンダリング、またはペインティング）するためのオブジェクト指向ペインタを提供することを目的とし、さらに、グラフィカル環境のグラフィカル特性に従って上記ペインタを選択し、リンクするためのオブジェクト指向ペインタ・メーカを提供することを目的としている。ペインタ・メーカ、より具体的には、本発明のペインタ・メーカ・アーキテクチャは、ピクセル・ペインティング、クリッピング、領域作成、マルチスレッド同期化、ペインタ・キャッシングおよび対話型コンポジション（合成）といったように、異なるグラフィカル環境のグラフィカル特性を取り扱うために必要な異なる機能（関数）を抽象化している。これらの関数をレンダリング・コードから見えないようにすると、様々な状況で同じレンダリング・コードを使用することが可能になる。ペインタ・メーカ・アーキテクチャは、ある状況でペイントするのに２つ以上のペインタが必要になる所定の場合には、複数のペインタを動的に使用することもサポートしている。具体的には、本発明は、複数のグラフィカル環境で複数のグラフィカル・プリミティブをレンダリングするためのコンピュータ・ベース・システムを提供することを目的としている。このシステムは複数のペインタ・メーカ・オブジェクトと、ペインタ・メーカ・オブジェクトの少なくとも１つを含むペインタ・メーカ・チェインとを含んでいる。レンダリング・ルーチンはデバイス・キャッシュ内のペインタ・メーカに対して特定タイプのペインタを作成するように要求する。請求の範囲１．複数のグラフィカル環境の少なくとも１つで複数のグラフィカル・プリミティブをレンダリングするコンピュータ・ベース・システムであって、常駐しているオペレーティング・システムをもつ中央処理ユニットと、該オペレーティング・システム用のストレージ手段と、該コンピュータ・ベース・システムを使用して適当なグラフィカル環境でグラフィカル・プリミティブをドローイングするグラフィカル出力デバイスとを含んでいるコンピュータ・プラットフォームを備えたものにおいて、複数のペインタ・メーカ・オブジェクトと、複数のペインタ・メーカ・オブジェクトの少なくとも１つを備えるペインタ・メーカ・チェインと、グラフィカル・レンダリング要求を前記ペインタ・メーカ・チェインに渡して、前記グラフィカル環境でグラフィカル・プリミティブをレンダリングするグラフィカル・レンダリング手段と、前記ペインタ・メーカ・オブジェクトは、前記ペインタ・メーカ・チェイン内にあって、グラフィカル・レンダリング要求の受け取りに応答して、特定のグラフィカル・プリミティブをレンダリングすることに対してグラフィカル・オペレーションを実行するメソッドを備えるペインタ・オブジェクトを作成するペインタ作成手段と、グラフィカル要求を満たすようにグラフィカル・オペレーションを実行するメソッドを有するペインタ・オブジェクトを備えるペインタ・オブジェクト・チェインに前記ペインタ・オブジェクトをチェイニングする手段とを備えており、前記グラフィカル・レンダリング手段は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトによって生成されたペインタ・オブジェクトを使用して、前記グラフィカル環境でレンダリング・オペレーションを実行する手段も備えることを特徴とするコンピュータ・ベース・システム。２．ペインタ・メーカ・オブジェクトの各々は、スパン・ペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。３．ペインタ・メーカ・オブジェクトの各々は、ヘアライン・ペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。４．ペインタ・メーカ・オブジェクトの各々はグリフ(glyph)・ペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。５．ペインタ・メーカ・オブジェクトの各々は、３次元スパン・ペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。６．ペインタ・メーカ・オブジェクトの各々は、クリッピングを実行するペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。７．ペインタ・メーカ・オブジェクトの各々は、コンポジションを実行するペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。８．ペインタ・メーカ・オブジェクトの各々は、ピクセル・バッファに書き込むペインタを生成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。９．各々がグラフィカル・プリミティブの１つと関連づけられた複数のペインタ基底クラスが定義されていて、その場合、ペインタ作成手段はペインタ基底クラスを使用してペインタ・オブジェクトを作成する手段を備えることを特徴とする請求項１に記載のコンピュータ・ベース・システム。１０．複数のグラフィカル環境で複数のグラフィカル・プリミティブをレンダリングするコンピュータに実装された方法であって、（ａ）タスクのためにペインタ・メーカ・チェインを生成するステップであって、該ペインタ・メーカ・チェインは複数のペインタ・メーカ・オブジェクトを備えるものと、（ｂ）特定のグラフィカル環境で特定のグラフィカル・プリミティブをレンダリングする要求をタスクから受け取るステップと、（ｃ）レンダリング要求を受け取りに応答して、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してペインタ・オブジェクトのチェインを作成するステップであって、該ペインタ・オブジェクトの各々は、ペインタ・オブジェクトのチェインがレンダリング要求を満たすように複数のグラフィカル・オペレーションを実行するようにグラフィカル・オペレーションを実行するものと、（ｄ）ペインタ・チェイン内のペインタ・オブジェクトのチェインを使用して特定のグラフィカル環境でレンダリング・オペレーションを実行するステップとを備えていることを特徴とするコンピュータ実装方法。１１．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してスパン・ペインタを作成し、該スパン・ペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１２．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してヘアライン・ペインタを作成し、該ヘアライン・ペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１３．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してグリフ(glyph)ペインタを作成し、該グリフ・ペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１４．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用して３次元スパン・ペインタを作成し、該３次元スパン・ペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１５．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してクリッピングを行うペインタを作成し、該クリッピング・ペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１６．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してコンポジションを行うペインタを作成し、該コンポジション・ペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１７．ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してピクセル・バッファに書き込むペインタを作成し、該ピクセル・バッファ書込みペインタをペインタ・チェインに追加するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。１８．複数のペインタ基底クラスがグラフィカル・プリミティブの各々に関連づけられていて、ペインタ基底クラスを使用してペインタ・オブジェクトを作成するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実装方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ (72)発明者ワトソン，ラルフ，トーマスアメリカ合衆国 95014 カリフォルニア州クパチーノレバノンドライブ 10191

Claims

【特許請求の範囲】１．複数のグラフィカル環境で複数のグラフィカル・プリミティブをレンダリングするコンピュータ・ベース・システムであって、複数のペインタ・メーカ・オブジェクトと、ペインタ・メーカ・オブジェクトの少なくとも１つを含んでいるペインタ・メーカ・チェインと、ペインタ・メーカ・チェインに結合されていて、特定のグラフィカル環境で特定のグラフィカル・プリミティブをレンダリングする要求をペインタ・メーカ・チェインへ渡すためのグラフィカル・レンダリング手段とを備えていて、前記ペインタ・メーカ・チェインに含まれる前記ペインタ・メーカ・オブジェクトの各々は、グラフィカル・レンダリング要求を受けるとそれに応答して、特定のグラフィカル・プリミティブをレンダリングすることに対して特定のグラフィカル・オペレーションを、特定のグラフィカル環境で実行するように最適化されたペインタ・オブジェクトを作成するペインタ作成手段を含んでおり、前記グラフィカル・レンダリング手段は、ペインタ・メーカ・チェインに含まれるペインタ・メーカ・オブジェクトによって生成されたペインタ・オブジェクトを使用して、レンダリング・オペレーションを特定のグラフィカル環境で実行する手段も含んでいることを特徴とするコンピュータ・ベース・システム。２．ペインタ・メーカ・オブジェクトの各々は、スパン・ペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。３．ペインタ・メーカ・オブジェクトの各々は、ヘアライン・ペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。４．ペインタ・メーカ・オブジェクトの各々は絵文字(glyph)ペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。５．ペインタ・メーカ・オブジェクトの各々は、３次元スパン・ペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。６．ペインタ・メーカ・オブジェクトの各々は、クリッピングを実行するペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。７．ペインタ・メーカ・オブジェクトの各々は、コンポジションを実行するペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。８．ペインタ・メーカ・オブジェクトの各々は、ピクセル・バッファに書き込むペインタを生成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。９．単一のペインタ・メーカ基底クラスからペインタ・メーカ・オブジェクトをサブクラス化する手段をさらに含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。１０．各々がグラフィカル・プリミティブの１つと関連づけられた複数のペインタ基底クラスが定義されていて、その場合、ペインタ作成手段はペインタ基底クラスを使用してペインタ・オブジェクトを作成する手段を含んでいることを特徴とする請求項１に記載のコンピュータ・ベース・システム。１１．複数のグラフィカル環境で複数のグラフィカル・プリミティブをレンダリングするコンピュータに実装された方法であって、（ａ）タスクのためにペインタ・メーカ・チェインを生成するステップであって、該ペインタ・メーカ・チェインは複数のペインタ・メーカ・オブジェクトを含んでいるものと、（ｂ）特定のグラフィカル環境で特定のグラフィカル・プリミティブをレンダリングする要求をタスクから受け取るステップと、（ｃ）レンダリング要求を受けると、それに応答して、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用して、ペインタ・オブジェクトのチェインを作成するステップであって、該ペインタ・オブジェクトの各々は特定のグラフィカル・プリミティブをレンダリングすることに対して特定のグラフィカル・オペレーションを、特定のグラフィカル環境で実行するように最適化されているものと、（ｄ）ペインタ・チェイン内のペインタ・オブジェクトを使用して、特定のグラフィカル環境でレンダリング・オペレーションを実行するステップとを含んでいることを特徴とするコンピュータ実装方法。１２．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してスパン・ペインタを作成し、該スパン・ペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１３．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してヘアライン・ペインタを作成し、該ヘアライン・ペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１４．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用して絵文字(glyph)ペインタを作成し、該絵文字ペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１５．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用して３次元スパン・ペインタを作成し、該３次元スパン・ペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１６．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してクリッピングを行うペインタを作成し、該クリッピング・ペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１７．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してコンポジションを行うペインタを作成し、該コンポジション・ペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１８．ステップ（ｃ）は、ペインタ・メーカ・チェイン内のペインタ・メーカ・オブジェクトを使用してピクセル・バッファに書き込むペインタを作成し、該ピクセル・バッファ書込みペインタをペインタ・チェインに追加するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。１９．ステップ（ａ）は、単一のペインタ・メーカ基底クラスからペインタ・メーカ・オブジェクトをサブクラス化するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。２０．各々がグラフィカル・プリミティブの１つに関連づけられた複数のペインタ基底クラスが定義されていて、ステップ（ｃ）はペインタ基底クラスを使用してペインタ・オブジェクトを作成するステップを含んでいることを特徴とする請求項１１に記載のコンピュータ実装方法。