JPH08512412A

JPH08512412A - ディスプレイ・コンポジティング・システム

Info

Publication number: JPH08512412A
Application number: JP7504012A
Authority: JP
Inventors: マーシュ，ドナルド，エム．; ズィアス，ジェフ
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-07-09
Filing date: 1994-01-03
Publication date: 1996-12-24
Anticipated expiration: 2019-04-26
Also published as: AU5989594A; EP0698265B1; CA2144871A1; WO1995002236A1; EP0698265A1; DE69405225D1; US5487145A; JP3522275B2

Abstract

(57)【要約】ディスプレイ・コンポジティング・システムを提供することを目的としている。コンポジティング・アーキテクチャによれば、別のグラフィック・イメージの下にあるグラフィック・イメージの部分に対応するデータをバッファに入れておくことにより、別のイメージの上に浮動しているイメージが移動または操作されて、より深い層にあるグラフィック・イメージのピクセルが見えるようになったとき、ピクセルを高速に復元することによって、それぞれのグラフィック・イメージのオーバラップしている不透明および半透明領域のレンダリングを正確に行うことができる。グラフィック・イメージを表すデータは、グラフィック・イメージの不透明と深さ順序が判断されると、ペインタへ選択的に転送される。複数のペインタは、長さが異なるイメージ・レンダリング・パイプラインを備えていることが好ましい。ペインタは、コンポジットされるイメージの数に従って選択される。データ・バッファリングは、グラフィック・イメージの交差する領域に従ってバッファを動的に作成し、削除することにより最小化されている。

Description

【発明の詳細な説明】ディスプレイ・コンポジティング・システム発明の背景発明の分野本発明は、一般的には、ユーザに表示するためのコンピュータ・イメージの生成に関し、さらに具体的には、特にスクリーン（画面）がマルチタスキング環境で複数のタスクによって共有されている場合に、同一ディスプレイ・スペース（表示空間）上にオーバレイされることがある、不透明(opaque)、半透明(translu cent)、透明(transparent)または半透明(semi-transparent)のアイテム（項目）またはオブジェクトのイメージをレンダリング(rendering)するコンポジティング（合成）・サブシテム(compositing subsystem)のアーテキテチャに関する。従来技術の説明データ・プロセシング・デバイスまたはシステムとオペレータと間の通信インタフェースとしてビジュアル・ディスプレイが非常に好ましいことは、以前から認められていた。ビジュアル・ディスプレイでは、入力したアクションをオペレータが確認できると共に、該当する入力オプションや指示(instructions)が多くの場合、アイコンおよび／またはメニューの形で表示され、マルチタスキング環境などにおいて、データ・プロセシング・システム上で同時並行に実行されている複数のアプリケーションを制御できるようになっている。現在では、ビジュアル・ディスプレイはかなり高度になり、ユーザとの通信を強化するするために種々の表示属性が使用されている。可視性を向上するためにカラー・アイコンとアニメーションが使用されているが、これらはシステム関数 (system function)はもちろんのこと、カーソル関数(cursor function)とアイデンティティ(ID)（例えば、カーソルを制御する入力デバイス）の両方も示している。ビジュアル・ディスプレイの体裁は、種々のディスプレイ機能(display fea tures)が用意されていればそれらも含めて、特定のデータ・プロセシング・アプリケーションの「外観と感触」(look and feel)の主要要因となっている。同じ意味で、ディスプレイの見かけ上の体裁は、特に、ユーザ・コマンドまたはシステム関数やオペレーションを受けて変更されたときの見かけ上の体裁は、ユーザがデータ・プロセシング・システムとそこで実行されるアプリケーションの両方を信頼し、満足するときの主要要因となっている。また、複数のディスプレイ機能を１つまたは複数のアプリケーションが利用するためには、そのプレゼンテーションに一定の順序（ディスプレイ・スクリーン・イメージ生成のレベルでは、「コンポジティング」(compositing)とも呼ばれている）が守られている必要があり、これにより、各イメージ部分の該当のレンダリングが達成される。例えば、ウィンドウ・ディスプレイ環境では、オーバラップして表示されるウィンドウ間に一定の順序を設定して、あるアクティブ・ウィンドウで操作中のデータが別のウィンドウに関連するオブジェクトで隠されないようにする必要がある。少なくともアクティブ・ウィンドウのメニューは隠されてはならない。カーソルは、カーソルが操作の対象としているデータによって隠されてはならないが、メイン・カーソル(main cursor)と呼ばれるものを除き、ウィンドウやメニューがその上にかぶさることは可能である。スプライト(spr ite)はカーソルとしても、アプリケーション・レベルのオブジェクトとしても使用できる。そのようなものとして、対応する可視要件をもつアイコン（アニメーション付きの場合と、アニメーションなしの場合とがある）がある。マルチタスキング環境でよく使用されているウィンドウでは、順序付けがさらに複雑になっている。ウィンドウ自体は不透明(opaque)とも、透明(transparent )とも言われることがある。さらに、グラフィックス・アプリケーションがいずれかのウィンドウで実行されていると、そのウィンドウには、多数のオブジェクトが多数のカラーで（カーソル、メニュー、その他のディスプレイ機能と一緒に）表示されることがあり、これらはオーバラップすることがあり（例えば、種々の組合せと順序でお互いを隠すこと）、また、不透明や透明（例えば、半透明）の程度が様々であり、カラー、パターン、テクスチャ(texture)、輝度(intensity)、アニメーション、その他の表示属性をもっている場合もある。別の複雑さは、ディスプレイ・イメージ機能の予想される作用(behavior)から生じている。例えば、ヘルプ・ウィンドウやバルーン(baloon)などのポップアップ機能およびプルダウン・メニューはウィンドウ内で静止しているのが普通であるが、これらは現れると、ほとんど瞬時に、しかも、ブランク・スペースや古くなったイメージなどのアーティファクト(artifact)を残さないでウィンドウから消えることが期待される（例えば、あるオブジェクトのイメージが別のイメージで隠されている間に、それを変更しておく必要があった場合）。グラフィック・オブジェクトのイメージはあるロケーションから別のロケーションへドラッグされる場合もあれば、そのオブジェクトの境界(border)、コーナまたは他の部分のハンドルをドラッグすると歪んだり、サイズが変わる場合もあるので、オブジェクトやバックグランドで隠されていた部分は、そのオブジェクトで隠す必要がなくなったとき、即時に見えるようにして、正しくレンダリングされるようにすべきである。同様に、３次元オブジェクトのイメージは空間で回転されることもあるので、スクリーンの平面で投影を行うと、オブジェクトの表示されている境界が変わることがある。ユーザは、オブジェクトがスクリーンやウィンドウに追加されたり、そこから削除されるとき、スクリーンの再ドローイング（描画）に要する時間に不満をもたないのが普通であるが、多くの他のユーザはデータ・プロセシング・システムと対話(interaction)しているとき迅速な応答を期待している。ディスプレイ生成は、高解像度の色彩、輝度および色相(hue)で制御されるピクセルの数と、サポートしなければならないオブジェクトの数、ディスプレイ機能とスクリーンおよびそれらの間のやりとり(interaction-相互作用)の点で、計算集中型(computationally intensive)のプロセスである。従って、ディスプレイ生成は、処理時間とイメージ・データ保管の点で非常に高価であるのが普通である。そのために、すべてのオブジェクトとディスプレイ機能をバッファリングしても（最終的イメージで隠されている場合であっても）、ディスプレイの応答時間を高速化する問題の解決にはならない。このように潜在的に大量の記憶容量が必要になるため、管理とアクセスとための処理時間が大幅に必要になる。さらに、レンダリングの完全な一般原理では、下位に位置する各層がその上のすべての層のレンダリングに影響を及ぼす潜在性をもっている。このため、ディスプレイ・デバイスの制御のための正しいピクセル・イメージ値を開発する際に考慮する必要のあるデータ層の数と共に、計算時間が指数的に増加する。つまり、コンポジティング・プロセスは、半透明カラー・フィルタ(colored filters) がオーバレイしたときの影響のシミュレーションをサポートしていなければならない。そうすれば、その下のグラフィックをフリッカしたり、そのレンダリングを妨げることなく、それぞれの上と下に浮動して現れることができる不透明または半透明の形状でディスプレイを作ることが可能になる。現時点では、コンポジティングの一般原理では、控え目に見ても、大量のハードウェアを準備する必要がある。そして、また、許容時間制約内に高度化されたイメージ処理が収まる程度の必要なイメージ処理時間は、最大のものは別として、すべてのデータ・プロセシング・システムの能力を越えている。発明の概要従って、本発明の目的は、多数のウィンドウ、オブジェクトおよびスクリーン機能のコンポジションを効率よく高速に行うことを可能にし、これらが相互の上に浮動して見えるようにするイメージ・コンポジティング・サブシステム(image compositing subsytem)のアーキテクチャを提供することである。本発明の別の目的は、複数の不透明および半透明オブジェクトとスクリーン機能（以下、これらを「アイテム」と総称する）のレンダリングを正しく、フレキシブルに行うことをサポートするイメージ・コンポジティング・サブシテムのアーキテチャを提供することである。さらに、本発明の別の目的は、少ないハードウェアで実現することが可能であり、その結果、応答時間を短縮してディスプレイ生成を可能にする、汎用性が向上したコンポジティング・サブシステムと方法を提供することである。さらに、本発明の別の目的は、現イメージ・アイテムでの応答をほぼ即時化し、アーティファクトをレンダリングすることから解放することである。本発明の上記および他の目的を達成するために、データ・プロセシング・システムのディスレプイの、ある領域で交差する可能性がある複数のグラフィック・イメージをレンダリングする方法が提供されている。この方法は、複数のグラフィック・イメージをいくつかのグループに分割するステップであって、各グループはレベルをもち、グループ内の各イメージはそのグループ内でレベルをもつものと、アクティブ・イメージを含んでいるグループ内のイメージがそのアクティブ・イメージと交差しているかどうかをテストするステップであって、このテストは、アクティブ・イメージを含んでいるグループを他のグループと突き合わせてテストして、交差するイメージを含むことができないグループを判別することも含んでいるものと、交差が検出されたとき、下位レベル・イメージからのイメージ・データをインターセプト(intercept)するステップとからなることを特徴としている。本発明の別の側面によれば、イメージ・コンポジティング方法が提供されている。この方法は、複数のアイテムの各々に対応するイメージ・データを生成するステップであって、各アイテムはレベルをもっているのものと、それぞれのアイテムの交差を検出し、比較的下位レベルにあるアイテムに対応するイメージ・データをインターセプトするステップと、インターセプトしたイメージ・データをバッファと動的に選択されたペインタ(painter)のうち少なくとも一方へ転送するステップとからなることを特徴としている。さらに、本発明の別の側面によれば、オーバラップする可能性のあるグラフィック・イメージを表示する方法が提供されている。この方法は、グラフィック・イメージのオーバラップしている部分の深さ順序(depth order)を検出するステップと、深さ順序の検出を受けて、前記グラフィック・イメージを表しているデータをペインタへ選択的に送るステップと、少なくとも１つのグラフィック・イメージの少なくとも１つのオーバラップされた部分であって、該少なくとも１つのグラフィック・イメージのオーバラップされた部分を隠している、別のグラフィック・イメージの部分の深さより大きい深さをもつものを、下方バッファ(beneath buffer)にストアするステップとを含んでいることを特徴としている。さらに、本発明の別の側面によれば、ディスプレイ上のグラフィック・イメージをレンダリングする方法が提供されている。この方法は、一定順序に配列された複数のイメージ・データに基づいてイメージ値を生成するステップであって、イメージ・データは少なくとも２つのグラフィック・イメージの相対的深さの層に従って配列されているものと、少なくとも一方のグラフィック・イメージの少なくとも１つのオーバラップされた部分であって、該少なくとも一方のグラフィック・イメージの該少なくとも１つのオーバラップされた部分を隠している、前記グラフィック・イメージのうちの他方の部分の深さより大きい深さをもつものを、下方バッファにストアするステップとを含んでいることを特徴としている。さらに、本発明の別の側面によれば、ディスプレイ・コンポジティング方法が提供されている。この方法は、それぞれのグラフィック・イメージを表しているデータをストアするための複数の下方バッファを作成するステップと、これらの下方バッファをウィンドウが現れるときのウィンドウの深さに従ってグループ化するステップと、少なくとも１つのグループが収めている各下方バッファを、そのグループから指しているポインタを作るステップと、低位の深さにある次のグループを指しているポインタを作るステップと、前記少なくとも１つのグループ内のイメージと交差する可能性のあるグラフィック・イメージを表しているデータを収めている各グループを指しているポインタを作るステップとを含んでいることを特徴としている。さらに、本発明の別の側面によれば、ディスプレイ方法が提供されている。この方法は、ディスプレイ上の少なくとも１つのウィンドウを移動するステップと、ウィンドウがディスプレイ上で移動すると、それを受けて該ディスプレイ上のドローイング活動を凍結(freeze)するステップと、該ディスプレイ上の少なくとも１つのエリアをバッファリングするステップとを含んでいることを特徴としている。さらに、本発明の別の側面によれば、コンポジティング・ディスプレイ方法が提供されている。この方法は、表示しようとするオブジェクトと境界をなしているスクリーン領域に対してドローイング・ロック(drawing lock)を要求するステップと、そのスクリーン領域にコンポジット・アイテム(composited item)があるかどうかを検査するステップと、スクリーン領域のうち、１つまたは複数のオブジェクトの単一組合せだけを含んでいる第１領域についてドローイング・ロックを許可するステップと、１つまたは複数のオブジェクトの単一組合せに対応するペインタをコールするステップと、ドローイング・ロックを解除するステップとからなることを特徴としている。図面の簡単な説明上記およびその他の目的、側面および利点をもっと理解しやすくするために、以下、添付図面を参照して本発明の好適実施例について詳しく説明する。添付図面において、第1A図は、好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。第1B図は、好適実施例によるデータ・プロセシング・システムを示す概略図である。第２図は、好適実施例によるコンポジティング問題の例を絵で表して示す図である。第３図は好適実施例によるプルダウン・メニューを示し、複数カーソル操作環境においてメニューがどのようにして下位カーソルを隠すかを絵で表して示す図である。第４図と第５図は好適実施例によるグラフィック・オブジェクトを示し、スプライトがユーザ制御のカーソルによって他のグラフィック・オブジェクトの個所にドラッグされる様子を絵で表して示す図である。第６図は、好適実施例によるマルチグラフィック・ウィンドウを絵で表して示す図である。第７図は、好適実施例においてピクセル値をフレーム・バッファ・デバイスにバッファリングするためにピクセル・バッファがどのように使用されるかを示すブロック図である。第８図は、本発明を実施するときのTBeneathBufferGroups(BBGs)の関係を示すブロック図である。第９図はカーソルと交差している長い対角線を示し、好適実施例において動的ペインタの使われ方を絵で表して示す図である。第10図は、好適実施例において半透明レッド・カーソルを使用して半透明グリーン・オブジェクトをドラッグする様子を絵で表して示す図である。第11図は、好適実施例において２つの不透明コンポジット・アイテムがアクティブ・ドローイングで交差している様子を絵で表して示す図である。第12A図、第12B図、第12C図および第12D図は、好適実施例において第11図に示すディスプレイを生成するに当たり、本発明によって実現されたバッファ作成および削除プロセスを絵で表して示す図である。発明の好適実施例の詳しい説明好適実施例は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアップル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータ上に置かれているオペレーティング・システムの環境（コンテキスト）で実施される。代表的なハードウェア環境は第1A図に示されているが、同図は、従来のマイクロプロセッサのような中央演算処理ユニット10、およびシステム・バス12を介して相互に接続された複数の他のユニットを装備した、本発明によるワークステーションの代表的ハードウェア構成を示している。第1A図に示すワークステーションはランダム・アクセス・メモリ(RAM)14、リード・オンリ・メモリ(ROM)16、ディスク・ユニット20などの周辺デバイスをバスに接続するための入出力アダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などのユーザ・インタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプタ22、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ34、およびバスをディスプレイ・デバイス38に接続するための表示アダプタ36を装備している。ワークステーションには、アップル社System/7（登録商標）オペレーティング・システムなどのオペレーティング・システムが置かれている。以下、図面を参照して説明するが、特に、第1B図には、本発明110を含んでいるデータ・プロセシング・システム100の概略ブロック図が示されている。データ・プロセシング・システム100内では、ストアされているデータや入力されたデータについて必要なオペレーションを行うために１つまたは２つ以上のアプリケーションが実行されている。説明の便宜上、以下では、アプリケーション111 が、マウス、トラックボール、タブレット、ライトペン、ジョイスティック、データ・グローブなどの位置決め入力デバイス（グラフィックス入力デバイスとも呼ばれる）から入力を受け取り、表示されるグラフィックス機能（graphic feat ures）の制御を行うものと想定している（ただし、そのようなグラフィックス機能がシステムのハードウェアやアプリケーションのソフトウェアによってサポートされることを条件としている）。例えば、アプリケーションは入力テキストと、少なくとも基本的またはデフォルト形状をもつ、少なくともメイン・カーソル・イメージの表示を直接に制御できるものと想定している。スプライト(sprite)112(カーソルはこれで実現することが好ましい)、メニュー114およびラバーバンド(rubber band)116といったグラフィック・ディスプレイ強化機能(graphic display enhancement features)は、アプリケーションから提供することも、システムの一部として提供することも、あるいはこれらの組合せで提供することも可能である。同様に、システムまたはアプリケーションはこのような機能の各々を、図中に113,115,117で示すように、少なくとも１つの入力デバイス（例えば、マウス、ライトペン、データ・グローブなど）と関連づけてその制御を行うことも、特定のディスプレイ・デバイスと関連づけて、そこでかかる機能をレンダリングすることも可能である。このようにして得られた出力はデバイス依存(device-dependent)にすることが好ましい。つまり、機能で実行できる操作とその機能がレンダリングされるディスプレイ・デバイスに従って最適化すれば、様々な種類のディスプレイ・アクセラレーション(display acc eleration)を採用することが可能になる。また、アプリケーションは、図中にグラフィックス・システム118で示すように、オブジェクトのグラフィック・イメージの生成を制御できるものと想定している。グラフィックス・システム118によって処理されたオブジェクトは、カーソルを使用して、あるいはアプリケーション自身によってドローイングされていた可能性のあるオブジェクトを表示するが、これらのオブジェクトは、コンポジティングを必要とする他のアイテムの間に組み込まれていなければならない。そのため、データ・プロセシング・システム100はディスプレイを制御するための複数のデータ・ソースを含んでいるが、これらのデータ・ソースはなんらかの方法で結合して、ディスプレイ130の各ピクセルごとに表示値をレンダリング・エンジン(rendering engine) 120から得て、その間に、表示されたアイテムのレンダリングを高速かつ正確に行わなければならない。ユーザ・アクションに対する応答を迅速化するためには、コンポジティングされる各アイテムの生成は、コンポジティングされる他のアイテムの生成と同期して行われることがあるので、１つまたは非常に少数のディスプレイ・フレーム内で再ドローイングして、表示できるようにする必要がある。アプリケーション内のどのスレッド(thread)も、スクリーンの自分の部分を非同期に更新することができるので、他のスレッドによって生成されたアイテムが占めているスクリーン部分の上に、異なるスレッドが統一的にかつ正確にグラフィックを表示することは容易になっていない。従って、本発明が提供するコンポジティング・アーキテクチャ110では、透明や不透明といったアイテム属性とアイテム優先度を複数のアイテムに対して組み合わせて、高速にレンダリング・エンジンへ渡すことができ、しかも、データと属性の正しいレンダリングが、必要なメモリ量を増やすことなく正しく行えるような形で行われる。本発明のコンポジティング・アーキテクチャによれば、コンポジティング・オペレーションは、下位レベルのレンダリング・パイプラインとそこから下方バッファまでの経路でピクセル値をインターセプトすることにより行われ、これらのピクセル値は、隠しているアイテムが移動したとき下方バッファから再コールすることによってディスプレイ応答を高速化している。動的ペインタ・インスタンス化(dynamic painter instantiation)に基づくストラテジを使用して、レンダリング時間が最小化されている。必要な記憶量は、下方バッファを動的に作成し、削除すると共に、頻繁に変化することが予想される交差アイテムが見つかったディスプレイの小さなエリアだけでコンポジティングを行うことにより最小化している。他の場合には、従来のクリップと更新ストラテジが使用される。隠されているアイテムを見つける探索も単純化され、下方バッファをいくつかのグループに分け、ポインタで探索を短縮化することによって高速化されている。第２図は、コンピュータ生成イメージを図１のスクリーン130上に形成する際に起こる、基本的であるが、なお困難であるコンポジティング問題を示している。２つのコンポジット・アイテム212と213（図には、それぞれ不透明スプライトＡおよび透明スプライトＢと示されている）の下にライン211が引かれるとき、ラインの中間(211a)と終端にあるピクセルをスクリーン上に引かなければならない。スプライトＡとＢの形状とラインの特徴（例えば、幅）はその属性と同じように、レンダリングを制御する情報を収めているが、他の場合には、本発明によるコンポジティング・アーキテチャにとって重要でないオブジェクトのクラスに従って判断することが好ましい。不透明スプライトＡの下のライン211（またはバックグラウンド）を表すピクセルは、「下方バッファ」と呼ばれる特殊なバッファへ送っておくことが好ましい。そうすれば、スプライトＡが移動したり、イメージから削除されたりしたとき、これらのピクセルを迅速に再コールすることが可能になる。半透明スプライトＢの下のピクセルも下方バッファへ送っておくことが好ましいが、これらはスプライトＢのイメージと一緒にレンダリング・パイプラインでコンポジットして、スクリーン130に再ドローイングしなければならない。ドロップ・シャドゥ(drop shadow)を含めて、半透明アイテムのコンポジティングを可能にするには、イメージ・アイテムの少なくとも一部について２つの判断を行わなければならない。特定のスクリーン・ロケーションについては、あるアイテムが上位レベル（例えば、高優先度の層）のアイテムで隠されているかどうか、上位レベルのアイテムが不透明であるかどうかを判断しなければならない。このプロセスとそれを実現するハードウェアまたはソフトウェアは、以下で説明するように短縮化することが可能である。あるアイテムが特定のスクリーン・ロケーションに存在していて、そのアイテムの一部（これは、数値位置と層番号の比較を高速に実行することで判断できる）で隠されていなければ（例えば、別のオブジェクトがその上に浮動している）、情報は多かれ少なかれ直接にスクリーン・メモリへ送ることができる。アイテムがあるロケーションにあって、そのロケーションで上位レベルのアイテムで隠されていれば、イメージ値はインターセプトされる。そのアイテムのインターセプトされたイメージ値（これは、そこではどのロケーションでも任意であり、アニメーション化することも、時間と共に変化させることもできる）は、上位レベル・アイテムが半透明であるかどうかを判断するテストに従って送られる。具体的に説明すると、不透明の上位レベル・アイテムがなければ、イメージ値はレンダリング・パイプラインの順次ステージに置かれると共に、そのアイテムの下方バッファにも置かれて、隠しているアイテムが移動または削除されたとき、イメージ値が高速に回復される。この点に関して述べておきたいことは、あるアイテムが、頻繁に移動することが予想されない別の不透明アイテムによって隠されているときは、そのアイテム自身のイメージ値は時間の経過に対して相対的に静的であり、アイテム処理を短縮化することが好ましいことである。従って、隠されているアイテムの処理は、そのアイテムが隠されている間省くことができ、イメージ値は、そのアイテムが隠しているアイテムの下からスイッチ341′に対応するスイッチの上に現れたとき（およびそのアイテムの再計算された表示値が多数のデータ・プロセシング・サイクルのあとで使用可能になったとき）特殊バッファから取り出される。同じ意味で、２つ以上のアイテムによって隠されていて、そのうちの少なくとも１つが相対的に静的であるか、あるいはアクティブ・コントロール下に置かれているようなアイテムに対応するバッファは、省くことができるのが通常であり、かかる特殊バッファの数は本発明によれば動的に変更することができる。これらのセーブ(save)、取出し(retrieval)およびレンダリング(render)オペレーションは、その領域における他のレンダリングまたはドローイングと同期させる必要があるが、これはスクリーンまたはウィンドウ位置に基づく公知の方法によって簡単に行うことができる。もう１つ触れておきたいことは、イメージ・レンダリング・パイプラインを単一のマルチステージ（多段）パイプラインにする必要がないことである。例えば、１つのアイテムだけがあるウィンドウまたはスクリーン・ロケーションに存在していれば、パイプラインは、基本的に縮退パイプライン(degenerate pipeline )にすることができるので、上述したように、多かれ少なかれ直接にスクリーン・メモリに書くことができる。また、不透明アイテムが見つかると、パイプラインのステージへの入力（例えば、下位レベル・アイテムからの）はそこへ入力されることが中止され、その代わりに、インターセプトされて特殊バッファへ送られる。これが重要であるのは、レンダリング・パイプラインで実際に使用されているステージ数によって、正しいレンダリングを得るために必要な時間量が決まるからである。従って、本発明の重要な特徴は、本発明によると、イメージ値を選択して、それを長さが異なるパイプラインを含む複数のパイプライン回路に入力して、あるアイテムと上位レベルのすべての透明アイテムを表すデータを最適に処理できることである。これについては、以下で詳しく説明する。本発明によれば、上位レベル・アイテムによって隠されているアイテムのレンダリングは公知のシステムに比べて大幅に単純化されているが、これは、上位レベルのアイテムを探す検査がレンダリング・オペレーションとは基本的に逆に行われるように、コンポジティング・サブシステムのアーキテクチャを構成し、オーバレイしているアイテムまたはウィンドウや機能エリアが不透明であるか、透明であるかに応じてイメージ・データをレンダリング・パイプラインまたはオフスクリーン・ストア(off-screen store)へ送ることによって実現している。本発明によれば、コンポジティングを行うときの順序付け規則は、カーソルとその操作対象となるアイテムとが強く結びついているという基本原理に基づいている。例えば、ドラッグされるアイテムは、それをドラッグしているカーソルと強く結びついている。他のどのオブジェクトも、カーソルとドラッグされるアイテムとの間に表示されることは許されない（別のカーソルであっても許されない）。同様に、メニューはそれをアクティベートするカーソルと強く結びついている。この点がマッキントッシュ（登録商標）システム7.0と異なっている。このシステムでは、ユーザがコマンド・キーを使用してバックグラウンド・ウィンドウをドラッグすると、アウトラインが表示され、これはフォアグラウンド・ウィンドウによってクリップされている。このアウトラインは、小さなバックグラウンド・ウィンドウが大きなフォアグラウンド・ウィンドウの下にドラッグされると完全に見えなくなる。これに対して、本発明が実現されている環境の好ましい作用では、層の順序が並べ替えられるので、ユーザが操作中のオブジェクトを見失うことがないようになっている。本発明の好ましいアプリケーションと環境では、複数カーソルは、複数の入力デバイスで駆動させることも（これらはデバイス・カーソルと呼ぶことにする）、ネットワークを通して共同で作業しているリモート・ユーザが駆動させることもできる（これらはリモート・カーソルと呼ぶことにする）。リモート・カーソルには２種類ある。１つは、特定の協同アプリケーションのビュー(view)内だけでアクティブになっているものであり、もう１つは、デスクトップ全体をアクセスできるので、その縦横にわたって無制限に移動できるものである。複数カーソルは深さの順序(depth ordering)が決まっているが、これはユーザが変更することができる。例えば、マウスによって駆動されるカーソルはデータ構造によって駆動されたカーソルの上に現れるが、これはユーザがコントロール・パネルからこの順序を変更するまでそこに現れている。メイン・カーソル(main cursor)は、ユーザが他のすべてのカーソルの上に現れるように選択したカーソルである（システム・マウス・デバイスでは、デフォルトを使用することが好ましい）。この深さ順序を除けば、すべてのカーソルはコンポジティング・アーキテクチャから見たとき同等になっている。メイン・カーソルは、ユーザの選択によってすべての上に現れるものとしたデバイス・カーソルである。メイン・カーソルが隠されることはない。これはフリッカすることもなく、切れることもなく、デスクトップの境界に固定している。例えば、図３において、トップまたはメイン・カーソル410は、アプリケーション・スクリーンやウィンドウの上方に設けられているのが普通である、メニュー・ラベルが置かれているバー420からメニュー450をプルダウンしている。同図に示すように、メニュー450は下位カーソル430を隠し、下位カーソル440を部分的に隠している。カーソル430と440の相対レベルは重要ではない。その理由はメイン・カーソル410に最高優先度が与えられており、あるカーソルとそのカーソル（この例ではメイン・カーソル）が操作しようとするアイテムとの間に他のアイテムが入り込むことが許されないためである。メニューとヘルプ・バルーン(help balloon)がコンポジティング・サポートの候補となっているのは、これらが非同期にドローイングが行われている可能性のあるすべてのウィンドウとその内容の上に現れるので、即時に消す必要があるためである。メニューを即時に消す唯一の方法は、その下のスクリーンの内容をバッファに入れておくことである。しかし、スクリーン内容の一部をバッファに入れておくと、メニューが表示されている間にその領域が変更されるという可能性はなくなる。しかしながら、このようなバッファリングは、本発明のコンポジティング・アーキテクチャによれば、現スクリーン情報がインターセプトされてバッファに入れられるので、メニューの下のすべての活動を凍結しなくても行うことができる。他のコンポジット・アイテムに対するメニューの深さ順序は、それをアクティベートしたカーソルの深さ順序によって決まる。しかし、メニューは、メニューのイメージ（ロケーションではなく）がユーザ・アクションに応答して即時に変化しなければならない点で（例えば、ユーザがその上をカーソルを通過させると異なるアイテムがハイライトになる）、カーソルと異なっている。メニュー・ピクセル（バルーン・ヘルプ・オブジェクト内のアニメーションのピクセルを含む）はディスプレイ・バッファから取り出すことができるので、メニューまたはその一部が選択されたときやカーソルによって隠されるときは特殊バッファを用意したり、生成したりする必要がない。しかし、メニューは即時に消えなければならないので、少なくとも一部の下位レベル・アイテム（これらはウィンドウ枠を越えることがある）用に特殊バッファを用意または生成することが好ましい。この場合も、カーソルとその操作対象となっているメニューの間に他のアイテムが入り込むことは許されない。ドラッグのビジュアル効果は、ドラッグを行うときの事情が異なると異なる。アイテムのロケーションは調整されるだけのときもあるので、アイテムの最終的体裁は、ドラッグするときに、できる限りその体裁に近くなるようにシミュレートしておく必要がある。そのような場合には、ドラッグされて、オーバラップしているオブジェクトで正しく隠されているアイテムを実線で表したものを使用することが望ましい。別の場合には、ドラッグされたアイテムは、相対的に小さなターゲット上でドロップしなければならない。ターゲットが隠れるのを防止するには、ドラッグされたアイテムを半透明かアウトラインかアイコンで表した方が望ましく、そのようにすると、スプライトで簡単に実現することができる。ドラッグされたアイテムは、ドラッグのやりとりのタイプに応じて、アウトラインまたは実線スプライトで表示することが好ましい。実線スプライトの方がイメージの最終的体裁に近い体裁を表現するが、アウトラインを使用すると、スプライトの下のターゲットの収集が容易になる。本発明によれば、スプライト510 は、第４図に示すように、アウトライン510aで表示することも半透明スプライトで表示することもでき、操作はアウトラインに基づいて行うことができる。これは、スプライトが本来もつ機能ではないが、本発明によれば、ドラッギング・オペレーションの開始時にあるいは隠しているオブジェクトが見つかったとき、スプライトのグラフィックをいずれかのアウトライン・グラフィックにセットすることで簡単に行うことができる。コンポジティングの目的に異なるレベルでセットすることも可能である。ドラッギングを行うと、アウトラインはカーソルの下に表示され（例えば、スプライトをカーソルのレベルに隣接するレベルに表示されるアウトライン「アイテム」に変換することによって）、カーソルとスプライトの間に入り込むアイテムによってクリップされない。これに対して、実線スプライトは、従来の手法と同じように、スプライトがドラッグされたときアイテム520によって隠されると、クリップされることがあり、アウトライン510a′はユーザには見えなくなる。任意のレベルにある実線スプライトがドラッグされるとき望ましいことは、カーソルのすぐ下のレベルに代用(surrogate)オブジェクトを作ることである。そうすれば、コンポジティングを行っていないと、クリッピングが行われるはずの個所を判断することが容易になる。その場合には、代用物と実線スプライトの間でオブジェクトにオーバラップしている代用物が検出されると、クリップされる実線スプライトの個所が明確化されることになる。最初の２モード（つまり、クリップされた実線とアウトライン）は本発明を使用すると、組み合わせることも可能である。スプライト510bを実線で表したものは、スプライトがオーバラップしているオブジェクト530,540によって代用オブジェクトに従ってクリップされる個所を除き、第５図に示されている。クリッピングが行われる個所では、クリップされていないアウトラインは、コンポジティングが行われる個所で上位レベルにある代用オブジェクトに従って、実線スプライトをアウトライン・スプライト・グラフィックで置き換えることにより上に表示される。隠されていないスプライトの部分では、コンポジティングを行う必要がなく、オリジナル・グラフィックは、特にクリップされた個所を迅速に復元するために使用できる。これにより、実線グラフィックを「物理的」感触でドラッギングすることがシミュレートされるが、ドラッグされたオブジェクトが隠されたとき、位置と形状に関する情報がユーザに与えられる。ユーザは、スプライトをそれが完全には隠されない位置まで移動するだけで、実線スプライト・グラフィック内の情報（例えば、モーダル機能情報(modal functionality information )）を即時に得ることができる。マッキントッシュ（登録商標）システム7.0と同じように、ユーザがバックグラウンド・ウィンドウをドラッグし、そのあとでアウトラインとして表されるのを許される場合が時にはある（その代表例は第４図にも示されている）。ウィンドウを表すアウトラインはフル・ウィンドウ（またはスプライト）が隠されるのと同じように、また同じ理由でフォアラウンド・ウィンドウによって隠される。これは、小さなウィンドウが大きなフォアグラウンド・ウィンドウの下にドラッグされると、上述したようにスプライトをドラッグした場合と同じように、アウトラインが完全に見えなくなるので、混乱することになる。ウィンドウは、本発明によれば、スプライトと同じように処理できるので、この混乱は同じように回避される。しかし、スプライトの処理の他に、移動するウィンドウまたはビュー（グラフィック・データとコントロール・アイテムまたは「ツール」の両方を含んでいる）は、スクリーン上のすべてのドローイング活動を凍結することが好ましい。そうすれば、スクリーンの以前に隠されていなかったエリアのバッファリングが可能になるが、変化するイメージの大きなエリアをコンポジティングするときの計算負担から生じる応答時間が大幅に増加することはない。ウィンドウ・アウトラインは大きくなり、単純化される傾向にあるので、特に最適化するのに格好の候補である。ウィンドウ・オープニングや「アンドゥ」(undo)アニメーションなどの、ラバーバンディング(rubberbanding)、ウィンドウ再サイジング(resizing) およびスクリーン・アニメーションは、ウィンドウ・アウトラインと同じように表示される。上述したように、必要とするハードウェアと処理オーバヘッドを最小化するためには、オーバラップまたは交差しているオブジェクトの検出がコンポジティングをいつ行うかの判断の基礎になっている。以下では、本発明による好ましい探索ストラテジの実現方法について説明する。第６図は、ディスプレイ・スクリーンの概念化した部分の例を示す図である。ウィンドウ３のＤの個所のアクティブ・ドローイングは、ウィンドウ１が不透明であるので、ウィンドウ１の内側のスプライトＡと交差することはできない。これがウィンドウ４内のスプライトＣとも交差できないのは、ウィンドウ４がウィンドウ３の下にあるためである。しかし、スプライトＢは透明ウィンドウ２の内側にあり、ウィンドウ２はウィンドウ３にオーバラップしている。通常、このようになっていると、スプライトＢは交差の候補となるが、この場合には、ウィンドウ２の境界はスプライトＤの個所のアクティブ・ドローイングの境界と交差していないので、取り囲まれたスプライトはいずれも交差することができない。他方、ライン650は透明ウィンドウ２と交差しているので、ライン650については透明ウィンドウと共にコンポジティングが行われるはずである。好ましい探索ストラテジは、ビューまたはウィンドウ内のコンポジット・アイテムをグループ化して交差テストとウィンドウ・レンダリングを行いやすくするように実現されている。そのような理由から、スクリーン・フレーム・バッファからサブクラス化したオブジェクトの下方バッファ・グループ・クラス (beneath buffer group class-BBG)を用意しておくと、本発明を実施する上で好都合である。BBGは、特定のウィンドウ内のコンポジット・アイテムに関連する下方バッファのリストを維持している。第７図は、この側面から見たアーキテクチャを示す図である。ピクセル・バッファは、フレーム・バッファ・デバイスにピクセル値をバッファリングするために使用される。バウンド・レクタングル(b ounds rectangle)651は即時に検査されて、ウィンドウ内の下方バッファで、アクティブ・ドローイングと交差するおそれのものがあるかどうかが判断される。 BBGのリストは、フレーム・バッファによって共有メモリに維持されている。共有メモリが実装されていると、オーバラップしているコンポジット・アイテムを各ドローイング・コール時に判断するとき必要になるプロセス間通信(interproc ess communication)を省くことができる。ピクセル・バッファは、下方バッファが特定のスプライトのために作成されたとき、その下方バッファからのスプライト・バッファからピクセル値を入手する。クリッピングとコンポジティングは、オブジェクトまたはアイテムをどのようにレンダリングするかの情報を収めている下方バッファ基底クラス(base class) でサポートされている。クリッピングとコンポジティングは相互に排他的であるので、１つのメソッド・コールに一本化することはできない。下方バッファの特定サブクラスはクリッピングかコンポジティングのどちらかを実装し、両方を実装することはない。サブクラスは、クリッピングを使用すべきか、コンポジティングを使用すべきか（つまり、どちらのメソッドをコールすべきか）をコンポジティング・アーキテクチャに判断させるタイプのメソッドを無効化(override)する。コンポジティングを実装するサブクラスは「コンポジティング」下方バッファと呼ばれるのに対し、クリッピングを実装するサブクラスは「クリッピング」下方バッファと呼ばれる。不透明アイテムは、効率性に応じてクリッピングとコンポジティングのどちらでも使用できるが、半透明アイテムは正しい結果を得るためにコンポジティング下方バッファを使用しなければならない。これらの一般タイプの２下方バッファの他に、サブクラス化(subclassing)によると、コンポジット・アイテムの特定タイプ別の記憶とコンポジティングの実装を最適化することができる。例えば、ラバーバンドは、スパース(sparse-疎)で動的性格をもつラバーバンドに適した特殊下方バッファ・サブクラス上に構築することが可能である。第６図に示すように、アプリケーションは、ウィンドウ３でライン650を引こうとしているが、ウィンドウ３は不透明ウィンドウ１と半透明ウィンドウ２の下にある。コンポジット・アイテムは８つあり（この例では、スプライトA-H）、これらは引こうとしているラインにオーバラップする可能性がある。効率化のために、交差テスト(intersection test)は、実際に交差する可能性のあるスプライトだけに対して行われる。スプライトＣが交差することがないのは、これがウィンドウ４にあり、ウィンドウ４がウィンドウ３の下にあるためである。スプライトＡが交差することがないのは、これが不透明ウィンドウ１にあるためである。交差テストは、ライン650と同じウィンドウにあるスプライトＤとＥとＨ、透明ウィンドウ２にあるスプライトＢとＧ、およびデスクトップ・スプライトであるスプライトＦに対して行わなければならない。第８図は対応するBBGリストを示している。各BBGは特定のウィンドウまたはビュー内に置かれている、コンポジット・アイテムに対応する下方バッファ（第７図にＯとｎの基数表記(cardinality designation)で示されている）のリストを維持している。また、各BBGは、次のBBGと次に関心のあるBBGを指している、少なくとも２つのポインタをもっている。「関心のある」BBGとは、下位層でドローイングに交差する可能性のあるスプライトを含んでいるようなBBGである。例えば、BBG1とBBG2の間では、これらのポインタが同じになっているのは、ウィンドウ１とウィンドウ２が交差しないためである。不透明BBGが関心のあるBBGとならないのは、下位層でのレンダリングがこれらに、あるいは取り囲まれたコンポジット・アイテムに影響しないからである。さらに、交差テストを行いやすくするために、第８図に示すリスト中の各BBGは、その下方バッファを指しているポインタをもっている。ライン650を引くことを始める前に、交差テストは矢印で示すようにBBG3から始められる。下位層のスプライトは、交差に関しては無視しても構わない。下方バッファ５，６および８は交差テストが行われる。次に、関心のあるBBGポインタはBBG2までトラバース(traverse-走査)される。これにより、BBGIでの無用なテストが防止される。BBG2の境界は引こうとするラインの境界と交差しているので、BBG2内のすべてのコンポジット・アイテムはテストしなければならない。従って、交差テストは下方バッファ２と３に対して行われる。最後に、関心のある BBGポインタはデスクトップBBGまでトラバースされる。デスクトップBBGの境界は、デバイス全体をカバーしているので、これもラインの境界と交差するので、交差テストが下方バッファ１に対して行われる。どのピクセルもペイントするためには、その前に、特定のペイント・オペレーション（カラー、トランスファ・モード、およびパターンを指定する）に基づいてTPainterを作成しておかなければならない。コンポジティング・アーキテクチャが要求する同期条件を満足するためには、レンダラ(renderer)は、TDrawingLo ckと名づけたスタック・ベースのオブジェクト(stack-based object)を通してペインタを取得しなければならない。TDrawingLockは、簡単に言えば、スタック・ベースのラッパ(stack-based wrapper)であり、例外処理を行っているとき資源を回復する目的だけに存在するものである。プリミティブ(primitive)がレンダリングされる前に、レンダラは、次のようなコードを実行しなければならない。 TDrawing1ock myLock(thePaint,deviceCache)； TDrawingLockは、thePaintに対応するペインタをdeviceCacheに要求することにより、簡略TPainterオブジェクトを取得する。デバイス・キャッシュは、該当するTPainterをすでにそのキャッシュにもっている場合がある。そうでなければ、それを作成する。 TDrawingLockが作成されたあと、レンダラは必要とするどのような種類の準備または計算でも、自由に行うことができる。ロックが実際に獲得されるのは、ランダラがなんらかのピクセルをペイントする準備状態になったときである。この時点で、レンダラはTPainterオブジェクト上のメソッドをコールする必要があるが、メソッドをまだもっていない。そこでlockにメソッドを要求して取得する。 lockメソッドは、まず、共有フレーム・バッファのエリアをロックダウンすることが好ましく、そうすれば、このレンダリング・タスクが排他的にアクセスすることができる。スプライト、コンポジット・アイテムまたは他のドローイング・タスクは、このロックが取得される時間の間干渉することは許されない。第２に、lockメソッドは、オーバラップするコンポジット・アイテムの下にレンダリングするとき必要とされる、いずれかのコンポジティング・オペレーションを実行できる動的ペインタを作成することが好ましい。レンダラは、変更しようとするエリアのバウンディング・レクタングル（方形境界線）を判断し（これはプリミティブ全体の境界と同じように単純であることもあれば、次のいくつかのペインタ・コールだけをカバーするサブレクタングルであることもある）、これをlockメソッド・オブジェクトに引き渡す。なお、lo ckはこの要求の一部だけを許可することを決定する場合がある。lockからは最後のスキャン・ライン（走査線）のＹ座標が返却され、レンダラはロックを再獲得しなくても、それをアクセスすることが許される。本発明のこの特徴によれば、ドローイング・ロックは、コンポジット・アイテムが存在するかどうかに応じて、異なるペインタを返却することができる。例えば、第９図に示すケースを検討することにする。長い対角線900は、カーソルの１つのピクセルと交差している。ドローイング・ロックがラインのバウンディング・レクタングル全体に対応する１つのペインタだけを返却することを許されていれば、事物全体に対して非常に高価なペインタを返却しなければならないことになる。その代わりに、lockは、ラインの一部だけを収めている、901と名づけたサブレクタングルに対してダイレクト・ペインタ(direct painter)を返却することができる（これにより、事実上コンポジティングは無効化される）。レンダラはレクタングル901内のライン部分をレンダリングしたあと、バウンド・レクタングルの残余部分またはラインの残余部分のバウンド・レクタングルに対するロックを獲得しようとする。その間にカーソルが動いていなければ、lockはコンポジティング・ペインタと変更されたＹ値を返却し、可能な限り小さなエリア（オブジェクト、つまり、ラインとカーソルの１つの組合せを含んでいるレクタングル902）で高価なペインタが使用されるようにする。最後に、レンダラは三回目のロックを獲得し、サブレクタングル903のためのダイレクト・ペインタを取得するが、このサブタングルは、レクタングル901と同様に、ラインだけを含んでいる。この種のオペレーションによると、少数のピクセルだけがコンポジティングを必要とするとき、処理時間が大幅に削減されるので、単一のピクセルをコンポジティングするとき（例えば、カーソルのホットスポット(hot spot)の場合）最適化される特殊ケース・プロセスで行うことが好ましい。スクリーン・フレーム・バッファ・クラス内のオブジェクトは、ある与えられたバウンド・レクタングルと交差するすべてのコンポジット・アイテムにわたってイタレータ（iterator：反復子）を返却するメソッドを提供する。 TBeneathBufferIterator MScreenFrameBuffer::CreateBeneathBufferIterator(c onst TLongRect& bounds，const TGrafState&)；このコールは、バウンド・レクタングルにオーバラップするすべての下方バッファにわたって繰り返すイタレータを作成するが、交差する下方バッファが見つからなければNILを返却する（これは空のイタレータが作成されるのを禁止するので速度が最適化される）。TGrafStateパラメータは、現ウィンドウに対応するBB Gを指すポインタを含んでいる。このウィンドウの下のウィンドウ内のコンポジット・アイテムは無視しても構わない。 CreateBeneathBufferIteratorからNILが返されたときは、オブジェクトのドローイングを開始するコマンド(StartDrawing)は、簡略ペインタを返してくるので、レンダラはこれを使用して、スクリーン上に直接にドローイングする。Create BeneathBufferIteratorから返却されたポインタが非NILポインタならば、イタレータ・インタフェースが有用になる。交差する下方バッファのリストは、そのあとに続く処理のときに前方向と逆方向にトラバースされなければならない。イタレータ(TBeneathBufferIterator)は、すべての非交差下方バッファを考慮外におくことにより、以後に行われるトラバースを最適化する。ペインタが返却されるが、これは、クリッピングまたはコンポジティングの動的に選択されたコンポジティング・ストラテジを実装している。レンダラは、次に、返却されたペインタを使用してプリミティブをドローイングする。これらが終わると、レンダラはドローイング・ロックの解除を要求する。これにより、コンポジティング・アーキテクチャはコンポジティング・オペレーションを終了し、その結果をスクリーンへ転送し、スプライト移動を可能にし、場合によっては、コンポジティング・ペインタおよび関連のデータ構造を削除する。本発明のオペレーションの例として、第10図に示すように、複数のコンポジティング下方バッファがレンダリングしようとするプリミティブの境界に交差していると、コンポジット・アイテムは相互にオーバラップする可能性があるので、正しい結果を得るためには複数のコンポジティング・ステップと下方バッファの更新が必要になる。第10図に示すように、ユーザは、半透明レッド・カーソル10 02を使用して半透明グリーン・オブジェクト1005をドラッグしようとしている。これと同時に、別のスレッドは、ドラッグされるオブジェクト1005の現在位置の下にブルー・ライン1001を引こうとしている。ラインがスプライトと交差していない個所にはブルー・ピクセルが、ラインがグリーン・オブジェクトと交差する個所(1004)にはシアン・ピクセルが、ラインがグリーン・オブジェクトとレッド・カーソルの両方と交差する個所(1003)にはダークピンク・ピクセルが表示されるはずである。透明レッド・カーソルは、それがドラッグされるグリーン・オブジェクトの上に重なっている個所ではイエローで現れる。上記のような場合には、ドローイング・ロックは、レンダラがラインを短い線分(segment)で引くように強制する。ある線分は簡略ペインタを用いてスクリーンに直接に引くことができ、別の線分は短パイプライン・ペインタを使用し（ラインがグリーン・スプライトだけで隠される個所に）、ラインが両方のオブジェクトで隠される個所にはもっと高価な複数オブジェクト・コンポジティング・ペインタが使用される。複数オブジェクト・コンポジティングの場合のペインタは、バウンド・レクタングルの交差と同一サイズのバッファを作成する。これはスクリーン内容をコピーしてバッファに入れ、各コンポジット・アイテムの下方バッファの内容をコピーしてバッファに入れることによって内容を「アンワインド(unwind)」する。最終的には、レンダラは、スクリーン・ピクセルのイメージをすべてのコンポジット・アイテムの下に構築している。次に、レンダラは線分を引いてこのバッファに入れる。StopDrawing メソッドによると、各コンポジット・アイテムは再結合されてバッファに入れられて、最終結果がスクリーンにフラッシュ(flush) される。 TBeneathBufferIteratorは、上から下へ向かってリストをトラバースしてコンポジット・アイテムを「アンドロー」(undraw)するときにも、再コンポジティング時に下から上へ向かってトラバースするときにも、有用なインタフェースとなっている。第11図は、２つの不透明コンポジット・アイテムがアクティブ・ドローイングと交差するとき、これがどのような働き方をするかを示している。第11 図に示すように、不透明カーソルは、ラインを両方の下に引かなければならないとき、不透明の星形オブジェクトをドラッグしている。ステップＡでは、第12A 図に示すように、第11図のバウンディング領域1104に対応して新しいコンポジティング領域が割り振られる。次に、第12B図に示すように、星形オブジェクトからの形状領域はマージされてコンポジティング領域に入れられる（ステップＢ）。コンポジティング領域のこの部分にあるピクセルは、ペイントして星形の下方バッファに入れる簡略ペインタを指している。第12C図に示すように、カーソルに属する形状領域はステップＣでマージされ、これらのピクセルは、ペイントしてカーソルの下方バッファに入れるペインタを指している。ここで触れておきたいことは、カーソルの形状領域は、星形の形状領域によってまだカバーされていないエリアだけでマージされて、カーソルの下方バッファに入れられることである。これは、星形がカーソルの下にあるためである。２つがオーバラップするときは、星形の下方バッファは、ラインで書かれたピクセルがカーソルの下方バッファに到達する前に、これらのピクセルをインターセプトしなければならない。複数オブジェクト・クリップ・ペインタが返却されると、すべてのペインタ・コールがインターセプトされて、コンポジティング領域が示すように該当のペインタへ転送される。単一ペインタ・コールは、コンポジティング領域内の異なるデスティネーション（宛先）へ転送されるピクセルに影響を与える場合には、複数ペインタ・コールに分割することが可能である。完了すると、コンポジティング領域は削除される。それ以降のピクセル転送は不要である。スクリーンと下方バッファはすでに更新されているからである。ステップＤで、コンポジティング領域は削除される。以上説明してきたことから理解されるように、本発明が提供するアーキテクチャによれば、不透明、半透明および透明グラフィック・イメージの交差を即時に検出して、オーバラップしている領域が高速に変化するときでも正しくレンダリングすることができる。また、本発明によれば、必要なハードウェア記憶量が最小化され、レンダリング速度が動的に最適化されると共に、マルチタスキングとマルチウィンドウ・ディスプレイがサポートされる。

【手続補正書】特許法第１８４条の８【提出日】１９９５年７月１２日【補正内容】請求の範囲１．複数のオーバラップする不透明のおよび不透明でないグラフィック・イメージ(530,540,510b)からコンポジット・グラフィック・イメージ(110)を生成する方法であって、前記各複数のグラフィック・イメージは複数のグループのひとつに含まれ、ひとつのグループ内で、前記グラフィック・イメージは、前記グループの他のイメージと相対的な観察者(viewer)からの前記グラフィック・イメージの視覚上の距離を決定する深さのレベルで表示され、前記各複数のグループは、その他のグループと相対的な前記観察者(viewer)からの前記各グループの視覚上の距離を表わすグループ・レベルに関連している（第1b図）前記方法において、 (a)前記複数のグラフィック・イメージからアクティブ・イメージを選び、前記アクティブ・イメージが位置している前記複数のグループのうちのひとつを決定し(530)、 (b)前記アクティブ・イメージが前記ひとつのグループに位置しており、かつ、より大きい深さのレベルをもつグラフィック・イメージと交差しているかどうかを判別し（第７図）、 (c)前記ひとつのグループより高位のグループ・レベルをもつ前記複数のグループのどれかにあるグラフィック・イメージが前記アクティブ・イメージと交差しているかどうかを判別し(510b,530,540)、 (d)交差した不透明でないイメージと前記アクティブ・イメージを結合して前記コンポジット・グラフィック・イメージを生成する（第５図）ステップを具備することを特徴とする方法。２．(e)共通基底クラスのバッファ・サブクラスから各前記複数のグラフィック・イメージに対する下方バッファ・オブジェクトをダイナミックに生成し、前記下方バッファ・オブジェクトは、前記各グラフィック・イメージを含むグループとリンクされ、前記イメージの深さのレベルを表わす深さの順序をもつ（第７図）ステップをさらに具備することを特徴とする請求の範囲第１項に記載の方法。３．前記ステップ(e)が、 (e1)前記各複数のグループに対する下方バッファ・グループ・オブジェクトを生成し、グループに対する前記下方バッファ・グループ・オブジェクトが前記グループに含まれる下方バッファ・オブジェクトへのポインタをもち、前記グループに含まれる前記下方バッファ・オブジェクトに対するリンクを提供する（第７図と第８図）ステップをさらに具備することを特徴とする請求の範囲第２項に記載の方法。４．(f)ピクセルがそこからレンダリングされるピクセル・バッファ・オブジェクトを、前記共通基底クラスのピクセル・サブクラスから生成するステップをさらに具備し、ステップ(d)が (d1)前記アクティブ・イメージを前記交差したイメージと結合させ、前記結合を前記ピクセル・バッファ・オブジェクトへ置く（第７図）ステップを具備することを特徴とする請求の範囲第３項に記載の方法。５．前記共通基底クラスが仮想メソッドを具備し、かつ前記ステップ(e)が (e2)各バッファ・サブクラスの前記仮想メソットをオーバライドするサブクラスから前記下方バッファ・オブジェクトを生成し、前記ステップ(f)は (f1)前記ピクセル・サブクラスの前記仮想メソッドをオーバライドするサブクラスから前記ピクセル・バッファ・オブジェクトを生成し、前記ピクセル・バッファ・オブジェクトに置かれた結合データが、イメージデータを定義するタイプに基づいて下方バッファ・オブジェクトあるいはピクセル・バッファ・オブジェクトをダイナミックに選択することにより、下方バッファ・オブジェクトが前記イメージ・データをインターセプトすることを可能にする（第８図）ステップを具備することを特徴とする請求の範囲第４項に記載の方法。６．前記ステップ(d)が、 (d1)前記アクティブ・イメージと交差するイメージとの最小の交差で定義される前記アクティブ・イメージの領域をロックして、ロックされるイメージ・データの量を最小化するステップを具備することを特徴とする請求の範囲第１項に記載の方法。７．前記アクティブ・イメージと前記交差したイメージとのふたつの共通の範囲のうちの小さい方で前記領域を定義すること（第10図）を特徴とする請求の範囲第５項に記載の方法。８．(g)そのサロゲート(surrogate)・イメージ・オブジェクトが前記アクティブ・イメージの深さのレベルからひとつ下位のレベルの深さのレベルをもつ前記アクティブ・イメージを表わすサロゲート・イメージ・オブジェクトを生成し、 (h)ステップ(b)と(c)にしたがって前記サロゲート・イメージが他のイメージと交差するかどうかを判別し、 (i)ステップ(g)で判別される前記交差で定義される前記アクティブ・イメージの前記部分をクリッピングし、ステップ(d)にしたがって前記アクティブ・イメージの残りの部分を結合する（第４図）ステップをさらに具備することを特徴とする請求の範囲第２項に記載の方法。９．複数のオーバラップする不透明のおよび不透明でないグラフィック・イメージ(530,540,510b)からコンポジット・グラフィック・イメージ(110)を生成する装置であって、前記各複数のグラフィック・イメージは複数のグループのひとつに含まれ、ひとつのグループ内で前記グラフィック・イメージは前記グループの他のイメージと相対的な観察者からの前記グラフィック・イメージの視覚上の距離を決定する深さのレベルで表示され、前記各複数のグループは、その他のグループに関し前記観察者からの前記各グループと相対的な視覚上の距離を表わすグループ・レベルに関連している（第1b図）前記装置において、 (a)前記複数のグラフィック・イメージからアクティブ・イメージを選ぶ手段と、前記アクティブ・イメージの選択に応じて前記アクティブ・イメージが位置している前記複数のグループのうちのひとつを決定する手段(530)と、 (b)前記複数のグラフィック・イメージに応じて、前記ひとつのグループに位置しており、かつ、より大きい深さのレベルをもち前記アクティブ・イメージと交差するグラフィック・イメージを判別する第１手段（第７図）と、 (c)前記複数のグラフィック・イメージに応じて、前記ひとつのグループより高位のグループ・レベルをもつ前記複数のグループのどれかにありそして前記アクティブ・イメージと交差するグラフィック・イメージを判別する第２手段(510 b,530,540)と、 (d)前記第１判別手段と前記第２判別手段により判別された前記複数のグラフィック・イメージのいくつかに応じて、前記アクティブ・イメージを交差するすべての不透明でないイメージと結合して前記コンポジット・グラフィック・イメージを生成する手段（第５図）とを具備することを特徴とする装置。 10．(e)前記複数のグラフィック・イメージに応じて、共通基底クラスのバッファ・サブクラスから各前記複数のグラフィック・イメージに対する下方バッファ・オブジェクトをダイナミックに生成し、前記下方バッファ・オブジェクトは、各前記グラフィック・イメージを含むグループとリクされ、前記イメージの深さのレベルを表わす深さの順序をもつ手段（第７図）とをさらに具備することを特徴とする請求の範囲第９項に記載の装置。 11．前記下方バッファ・オブジェクト生成手段が、前記複数の下方バッファ・グループに応じて前記各複数の下方バッファ・グループに対する下方バッファ・グループ・オブジェクトを生成する手段をさらに具備し、グループに対する前記下方バッファ・グループ・オブジェクトが前記グループに含まれる下方バッファ・オブジェクトへのポインタをもち、前記グループに含まれる前記下方バッファ・オブジェクトに対するリンクを備えること（第７図と第８図）を特徴とする請求の範囲第10項に記載の装置。 12．ピクセルがそこからレンダリングされるピクセル・バッファ・オブジェクトを、前記共通基底クラスのピクセル・サブクラスから生成する手段と、前記アクティブ・イメージおよび前記第１判別手段と前記第２判別手段により判別された前記複数のグラフィック・イメージのいくつかに応じて、前記アクティブ・イメージを前記交差したイメージと結合させ、前記結合を前記ピクセル・バッファ・オブジェクトへ置く手段をさらに具備すること（第７図）を特徴とする請求の範囲第１項に記載の装置。 13．前記共通基底クラスが仮想メソッドを具備し、前記下方バッファ・オブジェクト生成手段が各バッファ・サブクラスの前記仮想メソッドをオーバライドするサブクラスから前記下方バッファ・オブジェクトを生成する手段を具備し、前記ピクセル・バッファ・オブジェクト生成手段が前記ピクセル・サブクラスの前記仮想メソッドをオーバライドするサブクラスから前記ピクセル・バッファ・オブジェクトを生成する手段を具備し、前記ピクセル・バッファ・オブジェクトに置かれた結合データが、イメージ・データを定義するタイプに基づいて下方バッファ・オブジェクトまたはピクセル・バッファ・オブジェクトをダイナミックに選択し下方バッファ・オブジェクトが前記イメージ・データをインターセプトすることを可能にすること（第８図）を特徴とする請求の範囲第12項に記載の装置。 14．第２判別手段が、前記アクティブ・イメージと交差するイメージとの最小の交差で定義される前記アクティブ・イメージの領域をロックしてロックされるイメージ・データの量を最小化する手段を具備すること（第９図）を特徴とする請求の範囲第９項に記載の装置。 15．前記アクティブ・イメージと前記交差するイメージとの２つの共通の範囲のうちの小さい方で前記領域を定義すること（第10図）を特徴とする請求の範囲第 14項に記載の装置。 16．(f)前記アクティブ・イメージ・オブジェクトに応じて、そのサロゲート・イメージ・オブジェクトが前記アクティブ・イメージの深さのレベルからひとつ下位のレベルの深さのレベルをもつ前記アクティブ・イメージを表わすサロゲート・イメージ・オブジェクトを生成する手段と、 (g)前記サロゲート・イメージ・オブジェクトに応じて、前記サロゲート・イメージが、前記第１判別手段と前記第２判別手段とにより判別される他のイメージと交差するかどうかを判別する手段と、 (h)前記イメージ交差手段により判別される前記交差で定義される前記アクティブ・イメージの部分に応じて、前記アクティブ・イメージの残りの部分を結合し前記コンポジット・グラフィック・イメージを生成する手段（第４図）とをさらに具備することを特徴とする請求の範囲第10項に記載の装置。

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

Claims

【特許請求の範囲】１．データ・プロセシング・システムのディスプレイの領域で交差する可能性のある複数のグラフィック・イメージをレンダリングする方法であって、 (a) 複数のグラフィック・イメージをいくつかのグループに分割するステップであって、各グループはレベルをもち、グループ内の各イメージはそのグループ内でレベルをもっているものと、 (b) アクティブ・イメージを含んでいるグループ内のイメージがそのアクティブ・イメージと交差しているかどうかをテストするステップであって、このテスト・ステップは、アクティブ・イメージを含んでいるグループを他のグループと突き合わせてテストして交差するイメージを含むことができないグループを判別することを含んでいるものと、 (c)テスト・ステップで交差が検出されたとき、下位レベル・イメージからのイメージ・データをインターセプトするステップとからなることを特徴とする方法。２．請求の範囲第１項に記載の方法において、グラフィック・イメージの２つまたはそれ以上が交差している個所の、ディスプレイの領域の境界に従って選択された選択ロケーションで、複数のイメージのうちのイメージをサブイメージに分割するステップを含んでいることを特徴とする方法。３．請求の範囲第２項に記載の方法において、選択ロケーションは、グラフィック・イメージの２つまたはそれ以上が交差している個所の、ディスプレイの領域の境界のうち少なくとも１つのバウンディング・レクタングルを含むことを特徴とする方法。４．イメージ・コンポジティング方法であって、 (a)複数のアイテムの各々に対応するイメージ・データを生成するステップであって、各アイテムはレベルをもっているものと、 (b)アイテムの１つひとつの交差を検出するステップと、 (c)交差を検出するステップで交差が検出されると、比較的に下位レベルをもつアイテムに対応するイメージ・データをインターセプトするステップと、 (d)イメージ・データをインターセプトするステップでインターセプトされたイメージ・データを、バッファおよび動的に選択されたペインタの少なくとも一方へ転送するステップとからなることを特徴とする方法。５．請求の範囲第４項に記載の方法において、バッファを動的に作成し、削除するステップを含んでいることを特徴とする方法。６．請求の範囲第４項に記載の方法において、イメージ・データを少なくとも２つのペインタの一方へ転送するステップを含み、少なくとも２つのペインタの少なくとも一方は、あるロケーションで交差していると検出された特定数のイメージをドローイングするように最適化されていることを特徴とする方法。７．オーバラップしている可能性のあるグラフィック・イメージを表示する方法であって、 (a)グラフィック・イメージのオーバラップしている部分の深さ順序を検出するステップと、 (b)深さ順序を検出するステップで深さ順序が検出されると、グラフィック・イメージを表すデータをペインタへ選択的に送るステップと、 (c)少なくとも１つのグラフィック・イメージの少なくとも１つのオーバラップされた部分であって、少なくとも１つのグラフィック・イメージの少なくとも１つのオーバラップされた部分を隠している、別のグラフィック・イメージの部分の深さより大きい深さをもつものを下方バッファにストアするステップとを含んでいることを特徴とする方法。８．請求の範囲第７項に記載の方法において、グラフィック・イメージの各々の不透明を検出するステップを含んでいて、データを選択的に送るステップは少なくとも１つのグラフィック・イメージを表すデータをインターセプトして、下方バッファへ転送するステップをさらに含んでいることを特徴とする方法。９．請求の範囲第７項に記載の方法において、データを下方バッファからペインタへ転送するステップを含んでいることを特徴とする方法。 10．ディスプレイ上のグラフィック・イメージをレンダリングする方法であって、 (a)一定順序に並んだ複数のイメージ・データに基づいてイメージ値を生成するステップであって、イメージ・データはグラフィック・イメージの少なくとも２つの相対的深さ層に従って順序付けされているものと、 (b)少なくとも１つのグラフィック・イメージの少なくとも１つのオーバラップされた部分であって、少なくとも１つのグラフィック・イメージの少なくとも１つのオーバラップされた部分を隠している、別のグラフィック・イメージの部分の深さより大きい深さをもつものを下方バッファにストアするステップとを含んでいることを特徴とする方法。 11．請求の範囲第10項に記載の方法において、データを下方バッファからペインタへ転送するステップをさらに含んでいることを特徴とする方法。 12．ディスプレイ・コンポジティング方法であって、 (a)それぞれのグラフィック・イメージを表すデータをストアするための複数の下方バッファを作成するステップと、 (b)下方バッファを、ウィンドウが現れるときのウィンドウの深さに従ってグループ化するステップとを含んでいて、下方バッファをグループ化するステップは、 (c)少なくとも１つのグループから、そのグループが含んでいる各下方バッファを指しているポインタを作成するステップと、 (d)下位の深さにある次のグループを指しているポインタを作成するステップと、 (e)少なくとも１つのグループ内のイメージと交差する可能性のあるグラフィック・イメージを表すデータを含んでいる各グループを指しているポインタを作成するステップとを含んでいることを特徴とする方法。 13．ディスプレイ方法であって、 (a)ディスプレイ上の少なくとも１つのウィンドウを移動するステップと、 (b)ディスプレイ上のウィンドウを移動するステップでウィンドウが移動されると、ディスプレイ上のドローイング活動を凍結するステップと、 (c)ディスプレイ上の少なくとも１つのエリアをバッファリングするステップとを含んでいることを特徴とする方法。 14．コンポジティング・ディスプレイ方法であって、 (a)表示しようとするオブジェクトと境界を接しているスクリーン領域についてドローイング・ロックを要求するステップと、 (b)スクリーン領域にコンポジット・アイテムがあるかどうかをチェックするステップと、 (c)１つまたは２つ以上のオブジェクトの単一組合せだけを含んでいる、スクリーン領域の第１領域についてドローイング・ロックを許可するステップと、 (d) １つまたは２つ以上のオブジェクトの単一組合わせに対応するペインタをコールするステップと、 (e)ドローイング・ロックを解除するステップとを含んでいることを特徴とする方法。 15．請求の範囲第14項に記載の方法において、 (a)スクリーン領域に残っている第２スクリーン領域でドローイング・ロックを要求するステップと、 (b)コンポジット・アイテムがあるかどうかをチェックするステップ、第２スクリーン領域の少なくとも一部についてドローイング・ロックを許可するステップ、ペインタをコールするステップ、およびドローイング・ロックを解除するステップを繰り返すステップとを含んでいることを特徴とする方法。 16．データ・プロセシング・システムのディスプレイの領域で交差する可能性のある複数のグラフィック・イメージをレンダリングする方法であって、 (a)複数のグラフィック・イメージをいくつかのグループに分割するステップと、 (b)アクティブ・イメージを含んでいるグループ内のイメージがそのアクティブ・イメージと交差しているかどうかをテストするステップであって、このテスト・ステップは、アクティブ・イメージを含んでいるグループを他のグループと突き合わせてテストして交差するイメージを含むことができないグループを判別することを含んでいるものと、 (c)テスト・ステップで交差が検出されたとき、下位レベル・イメージからのイメージ・データをインターセプトするステップとからなることを特徴とする方法。 17．請求の範囲第16項に記載の方法において、ラバーバンディングされたイメージをアクティブ・イメージとして表示するステップを含んでいることを特徴とする方法。 18．請求の範囲第17項に記載の方法において、カーソルをアクティブ・イメージとして表示するステップを含んでいることを特徴とする方法。 19．請求の範囲第18項に記載の方法において、スプライトをアクティブ・イメージとして表示するステップを含んでいることを特徴とする方法。 20．データ・プロセシング・システムのディスプレイの領域で交差する可能性のある複数のグラフィック・イメージをレンダリングする装置であって、 (a)プロセッサと、 (b)プロセッサに接続され、その制御を受けるメモリと、 (c)プロセッサに接続され、その制御を受けるディスプレイと、 (d)複数のグラフィック・イメージをメモリにストアし、該複数のグラフィック・イメージをいくつかのグループに分割する手段と、 (e)アクティブ・イメージを含んでいるイメージ・グループがディスプレイ上でそのアクティブ・イメージと交差しているかどうかをテストする手段であって、該テスト手段は、アクティブ・イメージを含んでいるグループを他のグループと突き合わせてテストして、交差するイメージを含むことができないグループを判別する手段を含んでいるものと、 (f)ディスプレイ上でテスト手段によって交差が検出されたとき、メモリ内のイメージ・データをインターセプトする手段とを備えていることを特徴とする装置。