JPH08504961A

JPH08504961A - ウィンドウ型及び他の表示オペレーションのためのグラフィックス制御プレーン

Info

Publication number: JPH08504961A
Application number: JP6514353A
Authority: JP
Inventors: デレクレンツ
Original assignee: Seiko Epson Corp
Current assignee: Seiko Epson Corp
Priority date: 1992-12-17
Filing date: 1993-12-07
Publication date: 1996-05-28
Anticipated expiration: 2018-06-03
Also published as: JP3413201B2; WO1994014155A1; US5515494A

Abstract

(57)【要約】本発明は、複数のウインドウを表示するコンピュータ・グラフィックス・システムに於て画素表示及びアップデートを制御するシステム及び方法である。当装置は表示する画素データを格納するフレーム・バッファを備えている。フレーム・バッファは、画素が実行中のウインドウの可視部分にあるかどうかを表示するように構成された書き込み可能プレーンを備えている。当装置はまた、ウインドウ・データ構造を格納するためのメモリを備え、そのデータ構造は、書き込み可能プレーンを効率的に管理するため、ウインドウ優先順位、ウインドウ境界、ウインドウ共通部分を含んでいる。グラフィックス・サーバは、画素をフレーム・バッファに書き込むかどうかを決定するが、その決定は、書き込み可能プレーン及びウインドウ・クリップ境界に基づいて行われる。フロント及びバックのフレーム・バッファの選択及びビデオモードの選択のためにいくつかのプレーンをオプションとしてさらに設けてもよい。さらにその上、画素が１つのオブジェクトに対して１回のみ書き込まれるかどうかを示すための１回書き込みプレーンを設けてもよい。

Description

【発明の詳細な説明】ウインドウ型及び他の表示オペレーションのためのグラフィックス制御プレーン（Graphics Control Planes For Windowing And Other Display Operations）発明の背景１．産業上の利用分野本発明は、一般にはラスタ・グラフィックス・システムの分野に関し、より具体的には、複数のウインドウを表示するシステムにおいてウインドウ描画を制御するシステム及び方法に関する。２．関連技術現代コンピュータ・システムでは、コンピュータ・グラフィックス技術が幅広く使用されている。計算能力の面から見てパーソナルコンピュータからワークステーション、さらにグラフィックス専用システムに亘る広い分野のコンピュータ・システムで、ラスタ・グラフィックス技術はグラフィックス画像を表示する最も有力なメカニズムになってきた。ラスタ・グラフィックス・システムでは、水平表示線は、ラスタ線と呼ばれ、一列の画素（ピクセル又はＰＥＬ）で表される。全画面は、ラスタ線の集合を矩形に配列して得られるが、この配列をラスタと呼ぶ。したがって、ラスタは、１つ以上の画像を保持するのに用いられるが、画素のマトリックスから出来ていることになる。この画素マトリックスは、メモリ・バッフアにディジタル情報として記憶される。特に、表示装置に転送されるデータを保持するように設計されているメモリ・バッファを「フレーム・バッファ」と呼ぶ。単色システムでは、各画素は普通、フレーム・バッフアの１ビットで表される。ビットの状態（即ち、１又は０）は対応するビットがオンかオフ（即ち、表示上白又は黒）かを決定する。そのようなシステムでは、メモリ・バッファはビットマップと呼ばれる。カラーや３次元（３Ｄ）画像のようなより複雑な画像を保持するように設計されたシステムでは、各画素は、その画素に関する情報を含む複数のビットで表される。各画素を表すビットには、色情報を記憶するビット、深さの情報を表すビット等が含まれる。１画素当り複数ビットを持つシステムのメモリ・バッファ内にある全ビットのマトリックスをピックスマップと呼ぶ。画像を表示するには、通常ピックスマップのビットはフレーム・バッフアから一度にラスタ線１本の単位で逐次走査される。走査されたデータは、表示装置（最も普通にはＣＲＴビデオモニタ）に転送される。ＣＲＴモニタ以外の表示装置については、通常似通ってはいるが違った走査及び表示条件がある。システムの機能が向上して拡張グラフィックスを提供出来るようになるに従って、システムの複雑さも増す。例えば、現代のグラフィックス・システムでは、より高い分解能（単位面積当りの画素数の増加）及びより多くの色の選択が可能になってきた。こうした機能拡張にはピックスマップを構成する大量のビット数が必要となる。メモリの価格が低下するにつれ、システムは同じ価格目標でより向上した機能を備えたものになってきている。現在入手可能な低価格のランダム・アクセス・メモリ（ＲＡＭ）及び専用ビデオＲＡＭ（ＶＲＡＭ）のおかげで、３Ｄグラフィックスを表示するのに、大容量、高速フレーム・バッフアは極くありきたりのものとなって来ている。３Ｄラスタ・グラフイックス・システムでは「ダブル・バッフアリング」として知られている手法を用いる。ダブルバッファリングにおいては、１つのフレーム・バッファから画豫が表示されている時に、第２のフレーム・バッファではデータが全てクリアされ、次の表示のための新しい画像に書き換えられる。この手法では、ユーザーが前の画像を見ている間に、フレーム・バッファをアップデートすることが出来る。このため、フレーム・バッファが消去され再描画される間に起きる画面のフリッカリングを防ぐことが出来る。通常、表示装置に画像を表示するのにかかる時間に比して描画するには非常に長い時間がかかるのでこの手法が必要である。ラスタ・グラフィックス・システムに関する詳しい解説には、アデイソン・ウエズリー出版社（Addison-Wcsley Publishing Company）より1990年発行の、ジェイムス・Ｄ・フオーリー（James Ｄ.Foley、アンドリー・ヴァン・ダム（ Andries van Dam）、スティーブン・Ｋ・ファイナー（Steven Ｋ．Feiner）、ジョン・Ｆ・ヒユーズ（John Ｆ．Hughes）の著書、「Computer Graphics:Princip la and Practice（コンピュータ・グラフィックス：原理と実践）」第２版を参考にすること。特に１章、4.3章、18章を参照のこと。現代のコンピュータ・マーケットで一段と普及してきたものは「ウインドウ」である。ＰＣやワークステーションでのウインドウ機能は極く普通のものである。実際、ウインドウは、MicrosoftWindows、Ｘ Windows Systemのようなグラフィックス・ユーザ・インタフエース、Apple Macintoshコンピュータ用の種々のアプリケーションで欠くことの出来ない要素となっている。ラスタ・グラフィックス技術とウインドウ環境を結合することの必要性は、これら２つの技術が進化していく過程で自然に生まれてくるものである。しかし、そのような結合には数多くの問題が存在する。特に、１つの問題は、動画を表示装置に表示しながら、ダブルバッファの画像を入れ替えるというものである。動的フレーム・バッファでは、全バッファを高速にスワップしたりクリアすることが容易で、従って全表示領域の内容を変えることは容易である。しかし、ウインドウ画面では、表示の一部のみがアップデートされるので、いくつかの問題が生じる。ある時点においては、画面のあるサブセットのみがある１つのウインドウに割り当てられている。どのウインドウも、ダブルバッファ方式のフレーム・バッファのどちらのバッファを使用してもよいので、各ウインドウに選択されたバッファは独立に制御されなくてはならない。しかも、常時、前景バッファ（即ち、表示されてるバッファ）は各ウインドウに対して個別に選択されなくてはならない。しかし、ウインドウは表示のどの画素から始まり、どの画素で終了してもよいので、この選択は、表示時に各画素に対しなされねばならない。従来のグラフィックス・システムでは、描画をウインドウ内に制御するのにウインドウＩＤ（ＷＩＤ）が用いられる。ＷＩＤを定義する前に、フレーム・バッファで用いられる「プレーン」という用語を定義するのが有用と思われる。プレーンとは、全ての画素で同一のビットから成るピックスマップのサブセットである。プレーンは、ピックスマップの「水平」断面ともいえる。従って、例えば、各画素の第１ビットからなる集合はプレーンを作る。ＷＩＤを用いるシステムでは、フレーム・バッファ・メモリにいくつかのプレーンを追加する。これらのプレーンは、ＷＩＤと呼ばれるコードを保持する。ＷＩＤコードは、各画素が属するウインドウを指定する。画素がフレーム・バッファに送られる時、そのＷＩＤコードが、画面上のその位置に表示されるウインドウを指定するＷＩＤと比較される。もしその比較が一致すれば、書き込み可能信号が生成され、その画素はフレーム・バッファに記憶される。もしＷＩＤの比較が一致しなければ、書き込み可能信号は生成されず、その画素はフレーム・バッフアに書き込まれない。複数のフレーム・バッファを用いるシステムでは、ＷＩＤは、画素データを書き込むフレーム・バッファを制御するのに用いられる。ＷＩＤに関するより詳しい説明には、Tsujidoに付与された米国特許番号4 ,769,762、Westberg他に付与された米国特許番号5,101,365、及びCarrie他に付与された米国特許番号5,091,717を参照のこと。ＷＩＤシステムにはいくつかの欠点がある。まず第１に、ＷＩＤシステムには、データ及びアドレス中のＷＩＤコードをデコードし、それらが一致するかどうかを判定するための回路が余分に必要となる。第２に、ＷＩＤのサイズに制限があるため、複雑な「ＷＩＤ交換」ソフトウエアを使わないかぎり、この手法は限られた数のウインドウしか管理することが出来ない。普通のウインドウ・システムでも多くのウインドウが要求される。例えば、３ビットのＷＩＤは、８個の唯一無二のＷＩＤを与えるだけである。第３には、複雑なシステムにおいてＷＩＤをインプリメントするには多くのプレーンが必要となるが、その理由は、システムのウインドウの数が多くなれば、それだけＷＩＤプレーンの数も多くなるからである。例えば、256ウインドウ・システムでは８個のＷＩＤプレーンが必要となる。これは１個の画素につき８ビットとなる。1kｘ2kのフレーム・バッファでは、８個のＷＩＤプレーンをサポートするには16Ｍビットが必要となる。発明の要約本発明は、複数のウインドウをサポート可能なグラフィックス・システムの表示装置への書き込みシステム及びその方法を提供するものである。本発明はまた、グラフィックス・システムのビデオ機能を制御するのに用いるグラフィックス制御プレーンと呼ばれるいくつかのプレーンを提供する。フロント／バック・バッフア選択プレーンは、画素が、デュアルバッファ・システムのフロント・バッファかバック・バッファのどちらに属するかを選択するのに用いられる。ビデオモード選択プレーンは、複数の画素形式のどれが選択されているかを示す。例えば、ビデオモード選択プレーンは、12ビット又は24ビットＲＧＢ画素を選択するのに用いることが出来る。さらに新たなビデオモード選択プレーンを加え、違ったビデオモードをサポートするような柔軟性を提供するようにすることも出来る。違ったモードの１つの例は、８プレーンのカラー・インデックス・モードである。書き込み可能プレーンは、グラフィックス・システムが矩形及び非矩形ウインドウをサポート可能にするための重要な機能である。書き込み可能プレーンは、画素がウインドウにあるかどうか、さらに具体的には、その画素が表示されるウインドウの１部にあるかどうかを絶えず記録する。さらに、１つのオブジェクトに対して１回しか書き込まないようにするシステムの要件をサポートするために１回書き込みプレーンを含めることも出来る。この要件は、Ｘ Windows環境のような特定の環境でのみ必要である。グラフィックス制御プレーンを用いて、さらに具体的には、書き込み可能プレーンを用いることにより、従来のウインドウ描画手法に比ベハードウエアを節約できるようになる。書き込み可能プレーンは、フレーム・バッフア・メモリのただ１個のプレーンのコストでウインドウ・システムに大きな柔軟性をもたらす。書き込み可能プレーンをサポートするため、インポートされたウインドウ・パラメータを定義出来るようウインドウ・データ構造を確立する。ウインドウ・データ構造は、相対的なウインドウ優先順位（即ち、あるウインドウが他のウインドウに対して上に来るか下に来るか）、ウインドウ・クリップ境界のようなウインドウの定義、フィルパターンやブラシの定義を含んでいる。ウインドウ・データ構造はまた、１つのウインドウが少なくも１つの他のウインドウと重なり合う共通部分領域を定義する共通部分情報も含んでいる。共通部分領域データ構造は、ウインドウ間の共通部分領域、即ち、その座標及びその共通部分領域を作る重なり合ったウインドウを定義する。システムは、データ構造を用い、オブジェクトを描画するウインドウが他のウインドウで完全に隠れているか、部分的に隠れているか、全く隠れていないかを判定する。もし完全に隠れているなら描画動作は終了し、そのウインドウに対する全ての画素は捨て去られる。もし全く隠れていなければ、ウインドウ・クリップ境界情報を用いて画素をウインドウに描画する。もしウインドウが他のウインドウで部分的に隠れていれば、システムは、最後のオペレーシヨン以後ウインドウの定義が変更されたかどうかを決定する。もしそうなら、書き込み可能プレーンをアップデートし、ウインドウのどの部分が現在隠れていないかを示す。もしウインドウの定義が変更されていなければ、書き込み可能プレーンをアップデートする必要はない。システムは次に、書き込み可能プレーンと共にウインドウ・クリップ境界を用い、そのウインドウのフレーム・バッファに各画素を書き込むかどうかを決定する。本発明の特長は、画素をフレーム・バッファに書き込むかどうかの決定を１個の書き込み可能プレーンを用いて行い得ることである。これは、従来のウインドウＩＤ（ＷＩＤ）システムに比べて大変有利である。従来のシステムでは、２ⁿのウインドウをインプリメントするにはｎ個のプレーンとそれらｎ個のプレーンを解釈する別のハードウエアが必要であった。本発明の他の特長は、もしウインドウの定義が変更されていなければ、書き込み制御プレーンを、オペレーションとオペレーションの間にアップデートしなくてもよいことである。これは、ウインドウの隠れた領域と隠れていない領域が相補的な形式で定義出来るからである。この場合、変化するものは単に、画素をフレーム・バッファに書き込むかどうかを決定するために選択されたハードウエアテストだけである。書き込み可能プレーンの再書き込みが必要ないため、これにより節約が可能となる。また別の特長は、書き込み可能プレーンを用いて、非矩形ウインドウを利用するウインドウ・アプリケーシヨンを簡単にサポートすることが出来ることである。本発明の他の機能及び特長、さらに本発明の種々の実施例の構成及び動作について添付の図を参照しながら以下に詳細に説明する。図面の簡単な説明本発明を、添付の図を参照して説明する。図において、同一の要素又は同様の機能を持つ要素は同じ参照番号で表わされる。さらに、参照番号の一番左の数字は、その番号が最初に出てくる図面の番号を表す。第１図は、ウインドウＩＤを用いた従来のグラフィックス・システムを示すブロック図である。第２図は、本発明のグラフィックス制御プレーンをサポートするために用いられるシステムを示すブロック図である。第３図は、本発明のグラフィックス制御プレーンを示す。第４図は、表示画面上で互いに重なり合う複数のウインドウの例を示す。第５図は、本発明のウインドウ・クリップ境界を示す。第６図は、本発明の書き込み可能プレーンをサポートするのに用いるデート構造を示す。第７図は、本発明の第１の実施例のオペレーションを示すフローチャートである。第８図は、ピックスマップの典型的なインプリメンテーション・プレーンを示す。第９図は、本発明の重なり合う複数のウインドウに対する書き込み可能プレーンの書き込み可能ビットを表す。第10〜11図は、本発明の他の実施例の方法を示すフローチャートである。発明の詳細な説明本発明は、複数のウインドウをサポートするグラフィックス・システムの表示装置にデータを書き込むシステム及びその方法に関するものである。フレーム・バッファ又はピックスマップ中のある画素が実行中のウインドウで修正されるべきかどうかを制御するためにグラフィックス制御プレーンが与えられている。本発明によれば、ディスプレイ・コントローラが、画素を修正するかどうかを決定するのである。この決定は、その画素が属するウインドウに基づいて行われる。もしその画素を含むウインドウが実行中のウインドウであれば、画素はそのウインドウのカバーされていない部分に入り、それは描画される。本発明は、描画ハードウエアが実行中のウインドウだけに限り描画するような手段を提供する。フレーム・バッファと関連した動作の観点から本発明を説明する。ピックスマップについての動作はフレーム・バッファのものと同じであることは当業者にとって明かであろう。フレーム・バッフア又はピックスマップの全ての画素には、「書き込み可能ビット」という書き込み制御プレーンのビットがある。書き込み制御ビットは、現在の画素が実行中のウインドウで描画されるべきかどうかを決定するのに用いられる。書き込み制御ビットを描画制限（クリップ又は鋏み）許可又は不可の状態にすることができる。フレーム・バッファに書き込み可能にする値は、論理の１又は諭理の０としてプログラムすることが出来る。必ずしも必要ではないが、このプログラム可能な書き込み可のレベルを持つことで多重ウインドウの描画により高い柔軟性とより有効な制御が得られるようになる。どのようにしてこれが実現されるかは以下に説明する。第４図に、表示画面で複数のウインドウを用いている状態を示す。表示画面422は多重ウインドウ402、404、406、408、410、412のグラフィックス情報を表示している。これらのウインドウ402、404、406、408、410、412は表示画面42 2上で隠れてしまったり、お互いに部分的に隠し合ったりすることが出来る。例えば、ウインドウ402は、ウインドウ410によって部分的に隠されているが、今度はウインドウ410がウインドウ412によって部分的に隠されている。従って、ある画素を表示するのかどうか、もしくは、それが現在実行中でないウインドウの一部か又は実行中のウインドウのマスクされている部分なのかを判定することが重要になってくる。先に提起したＷＩＤは、各画素が属するウインドウを指定するコードを記憶するために付け加えたプレーンである。第１図は、ＷＩＤをインプリメントした従来のシステムのブロック図を示している。第１図を参照してＷＩＤを更に詳しく説明する。動作状態では、ウインドウは、ディスプレイ・コントローラ102 （Ｘ-ウインドウ・システムではグラフイックス・サーバ）によって選択される。ディスプレイ・コントローラ102は、通常中央処理ユニット（ＣＰＵ）を有している。ディスプレイ・コントローラ102は、ウインドウマップを作成し、ウインドウ・マップ・バッファ104にこのマップを格納している。ウインドウ・マップは、個々のウインドウが使用する画面中の特定の領域を定義する。ウインドウ・マップは、ディスプレイ・コントローラ102が与える値に基づいて作られる。これらの値として、画素のアドレス及び各ウインドウに含まれる各画素のＷＩＤがある。ＷＩＤは、ウインドウ・マップ・バッファ104 内にある特定のウインドウの対応する位置の１つ１つに書き込まれる。あるウインドウがウインドウ・マップ・バッファ104に書き込まれる時、ＷＩＤメモリ内でそのウインドウを定義する全ての位置は夫々そのウインドウのＷＩＤを格納する。第１のウインドウの前に来る第２のウインドウをウインドウ・マップ・バッファ104に書き込む時には、第２のウインドウに対するウインドウ香号が第２のウインドウを表す各位置に格納される。このようにして、第１のウインドウの上に来る第２のウインドウの部分は、ウインドウ・マップ・バッファ104内の第１のウインドウの重なり合う位置の上に書き込まれることになる。その結果、第２のウインドウのこれらの部分は第１のウインドウを自動的にカバーしクリップする。表示される全てのウインドウが書き込まれた後では、ウインドウ・マップ・バッファ104には、画面上の各点でどのウインドウが表示されるかを示すマップが出来たことになる。言い換えると、ウインドウ・マップ・バッファ104には、各画素に対するウインドウＩＤが含まれることになり、それはその画素位置にどのウインドウが表示されるかを示している。実際には、ウインドウはある与えられた順番で書き込まれる必要はない。通常、ウインドウ・システム・ソフトウエアには、どのウインドウがどのウインドウの上に来るかという優先順位があるのが普通である。この優先順位は、ウインドウが作られる順番とは独立に決定されてもよい。ディスプレイ・メモリに情報を書き込むため、フレーム・バッファの各画素のＷＩＤは、ＷＩＤレジスタ106に記憶され、その画素位置のウインドウ・マップ・バッファ104のＷＩＤと比較される。もしウインドウ・マップ・バッファ1 04のＷＩＤが表示しようとする画素のＷＩＤと同一なら、比較回路108は、書き込み可能ロジックがその画素の情報をフレーム・バッファ110の正しい画素アドレスに書き込むようにする。これに反して、もしその画素のＷＩＤが、ウインドウ・マップ・バッファ104に記憶されているＷＩＤと同一でないと比較回路108が判定すれば、その画素の情報はフレーム・バッファ110には書き込まれない。従って、ある位置で表示されるウインドウに属するその位置の画素だけがフレーム・バッフア110に書き込まれ、引き続き表示されることになる。このようにして、ＷＩＤを用いて、各画素位置の前景ウインドウの画素のみがフレーム・バッファに書き込まれるのである。他のシステムでも上記の手法の変形が用いられる。これらのシステムでは、ＷＩＤは、各ＷＩＤに対応する表示特性が見いだされるテーブル中の場所を示す指標としての働きをする。新しい画素値が作られていくにつれて、そのＷＩＤは、その画素の特性を探索するためのアドレスとして用いられる。もし実行中のウインドウ（現在描画されているウインドウ）が新しい画素位置の前景ウインドウと一致するなら、その新しい画素の値は表示用としてフレーム・バッファに格納される。ＷＩＤはまた、グラフィックス・コントローラへの制御情報を提供する。この情報は、通常、ハードウエアのルックアップ・テーブルにプログラムされていて、フレーム・バッファのバック・バッファの前面が現在表示されているかどうかとかＣＬＵＴ（カラールックアップ・テーブル）が画素のカラープレーンの内容をどのように解釈するかというようなことを示す。ある画素がある特定の画素位置を制御するウインドウに属するかどうかを決定する１つの方法は、上に述べたＷＩＤを用いることである。しかし、インプリメントするには、複雑なＷＩＤ交換ソフトウエアを用いない限り、ＷＩＤには新たにフレーム・バッファ・メモリ・プレーンと制御ハードウエアが必要となる。典型的には、グラフィックス・システムが十分な柔軟性と効率を持つには、現在、フレーム・バッファ・メモリの８個のＷＩＤプレーンが必要とされる。第８図に典型的なフレーム・バッファ又はピックスマップのプレーンの概略図を示す。第８図を参照して、ピックスマップ802は複数のプレーン（プレーン０、プレーン１、等）を用いてインプリメントされている。各プレーン０、１、２、...、Ｎは、ビットの２次元マトリックスで（１画素当り１ビット）、個々に或いはセットとして各画素に関する情報を含んでいる。プレーン０、１、２、...、Ｎの完全なセットはピックスマップを作り、各画素はＮビットで表される（１ビット／プレーン）。例えば、ビット802、804、806、808は夫々プレーン０、１、２、...、Ｎにあり、単一の画素に対応している。各ビット802、804、806、808はその画素の情報を格納している。ピックスマップ800の他の全ての画素もそれ自身のビットのセット（未表示）を有する（各プレーン０、１、２、...、Ｎに対し１ビット）。プレーン０、１、２、...、Ｎの数は、グラフィックス・システムに与えられる機能の数に依存する。カラー、カラー・インデックス、z-バッファリング等のプレーンがある。ＷＩＤを用いるシステムに対しては、そのグラフィックス・システムが提供するウインドウの数を指定するのに十分な数のＷＩＤプレーンがなくてはならない。例えば、もしそのグラフィックス・システムが256のウインドウをサポート出来るなら、８個のプレーンが必要となり、ＷＩＤハードウエアが256のウインドウをサポート出来るようになる。これらのプレーンを新たに付け加えることにより、以下に示すグラフィックスのハードウエア・コストがその分余計に掛かることになる。本発明では、グラフィックス制御プレーンと呼ばれるＷＩＤプレーンの代わりとなるプレーンのセットを導入してＷＩＤプレーンの必要性を無くす。第３図にはグラフィックス制御プレーンが示されている。好適な実施例では、最高５個までのグラフィックス制御プレーンがシステム中に存在してもよい。これらのプレーンはダブルバッファにはなっていない。必要なグラフィックス・サブシステムの機能によりそれ以上又はそれ以下の数のグラフィックス制御プレーンをインプリメントすることが可能である。プレーンの数が少ないシステムでは、インプリメントするのも安価になるので、性能／コストのトレードオフが可能である。グラフィックス制御プレーンはフレーム・バッファ（又はピックスマップ）中のプレーンのサブセットで、グラフィックス・システムのビデオの機能を制御するのに用いられる。プレーン（例えば、ＲＧＢプレーン）を用いることはこの分野では周知であるが、本発明が教えるグラフィックス制御プレーンを用いることにより多くの新しく有用な機能を得ることが出来るのである。制御プレーンをインプリメントするのに必要なハードウエアを第２図に示す。第２図を参照して、グラフィックス・コントローラ212は、画素をフレーム・バッファ204に書き込むべきかどうかを決定するためデータ構造（第６図を参照して後に説明する）を用いる。グラフィックス・コントローラ212は、グラフィックス・サーバ206及びディスプレイ・コントローラ202を備える。グラフィックス・サーバ（又は、グラフィックス・ソフトウエア・ドライバ）206は、ウインドウ・システム・ソフトウエアの一部で、多数のクライアント・プロセス210 のタスクを管理するために備えられている。グラフィックス・サーバ206とディスプレイ・コントローラ202の間の機能の割り振りは、システム要件及び標準的な設計の慣例に従って行われる。さらに、ディスプレイ・コントローラ・メモリ208は、ディスプレイ・コントローラ202が使用するために設けられている。１つの実施例では、フレーム・バッファ204に２つのバッファ、即ち、フロント・バッファ204A及びバック・バッファ204Bが設けられている。ウインドウの隠れた部分の画素を一時的に記憶するため補助記憶装置214 をオプシヨンとして用いてもよい。これらの画素は、後刻それらを表示するため呼び出すことが出来る。さて第３図を参照して、プレーン322は、ダブル・バッファ・システムで、フロント／バック・バッファ選択プレーンとして動作する。バッファ選択プレーン322は、画素がデュアル・バッファ・システムのフロント・バッファ204Aに属するのか或いはバック・バッファ204Bに属するのかを選択するために用いられる。フレーム・バッファで複数の画素形式がサポートされているなら、ビデオモード選択プレーン324が設けられ、ビデオモードを示す。ビデオモードは、システム・モニタ上の画素の表示を制御するフレーム・バッファ204の画素の形式を定義する。例えば、ビデオモード選択プレーン324は、画素が12-ビットのＲＧＢか24-ビットのＲＧＢかを標示してもよい。８プレーンカラー・インデックス・モードのようなビデオモードを新たに付け加えるには第２のビデオモード選択プレーン326を設けてもよい。このように、フレーム・バッファ内の画素の内容を複数に解釈することが少数のプレーンでインプリメント可能となる。書き込み可能プレーン328により、グラフィックス・システムが複雑な（矩形でない）ウインドウ形状をサポートできるようになる。書き込み可能プレーン328は、ある画素がウインドウ内にあるか、より具体的には、表示されるウインドウの一部にあるかどうかを絶えず記録しておくために備えられている。画素は一つのオブジェクトに対して１回のみ書き込まれるというｘ-ウインドウの要件をサポートするのに１回書き込みプレーン 330を設けてもよい。１回書き込みプレーン330のあるビットが真とセットされていると、そのビットに対応する画素は一つのオブジェクトに対して１回のみしか書き込まれることはない。表１は、ＷＩＤの代わりにグラフィックス制御プレーン（ＧＣＰ）を用いるとどれだけの節約が出来るかを示したものである。この表では、ハイエンドのシステムとローエンドのシステムの２つのタイプに対する節約分が示されている。ハイエンドのシステムについては、どちらの手法（ＷＩＤ及びＧＣＰ）も24個のカラープレーン（赤緑青に対して各８プレーン）、24個のＺ-バッファプレーン（３次元グラフィックスに対して256のレベル）、８個のオーバーレイプレーン、４個のステンシルプレーンを用いる。本発明のＧＣＰシステムで節約出来るのは、256のウインドウをサポートするのにＷＩＤシステムでは８個のプレーンが必要となるのに引き換え、本発明では単に４個のプレーン（ＧＣＰ）でウインドウや第３図を参照して述べた他のグラフィックス機能を行うことができるところにある。ＧＣＰが行える全ての機能が必ずしも必要ではないので、全てのＧＣＰを使用しなければ、それ以上の節約をすることが出来る。表１に示した例では、システムは１個のビデオモード選択プレーン326を持つのみである。1280画素ｘ1024画素の表示装置を持つシステムでは、典型的には、フレーム・バッフアは１プレーン当り2Ｍビットである。これは、８ビット／バイトのシステムでは、0 .25Ｍバイト／プレーンということである。従って、ＷＩＤシステムは17Ｍバイトのフレーム・バッファ・メモリが必要なのに対して、ＧＣＰシステムでは単に 16Ｍバイトを必要とするだけである。ローエンドのシステムでは、もっと著しい節約が可能となる。双方とも８個のカラープレーンを用いるが、ＷＩＤシステムでは、256のウインドウを制御するのにやはり８個のＷＩＤプレーンが必要である。しかし、ＧＣＰシステムは、ビデオ機能を制御するのに単に２プレーンが必要だけである。これらは、フレーム・バッファへの画素描画を制御する書き込み可能プレーン328及びＸ-ウインドウの要件を満たすための１回書き込みプレーン330である。Ｘ-ウインドウ・システム以外のシステムでは、１回書き込みプレーンを省略できるので、さらに0. 25Ｍバイトのメモリを節約できる。グラフィックス制御プレーン、より具体的には、書き込み可能プレーン32 8を用いることにより、フレーム・バッファ・メモリのただ１個のプレーンのコストで、ウインドウ・システムに対し大きな柔軟性が得られるのである。本発明の書き込み可能プレーン328がもたらす柔軟性について以下に説明する。書き込み可能プレーン328は、以下に説明するように、１つ以上の矩形クリッピング境界比較回路と共に用いるのが最善である。ウインドウ・システムではウインドウ制御のケースとして５つが挙げられる。本発明はこれらの夫々のケースを制御することが可能である。これらのケースは以下の通りである。１．第１の矩形ウインドウを描く時他のウインドウが第１のウインドウのどの部分も隠さない。その例は404、406、408、412である。２．他のウインドウで隠れた部分がある第１の矩形ウインドウを描画するが、他のウインドウはそれ自身隠れていない。この例としては、ウインドウ 414が挙げられるが、これはウインドウ408により部分的に隠れるが、ウインドウ 408は他のどのウインドウにも隠されていない。３．他のウインドウで隠れた部分がある第１の矩形ウインドウを描画するが、その他のウインドウ自身部分的に隠れている。この例はウインドウ402で、これはウインドウ410で部分的に隠れているが、ウインドウ410自身ウインドウ412によって隠れている。４．非矩形の形（例えば、円）のウインドウを隠れがあるなしに拘らず描画する。５．第１のウインドウが他の重なっているウインドウによって完全に隠れている。これらのケースを取り扱うために、ウインドウ・データ構造を確立し、重要なウインドウ・パラメータ定義する。ウインドウ・データ構造に使われる構成の詳細は、それがウインドウの重なり及びオプションとして書き込み可能プレーン328の状態を定義するのに十分であれば、重要ではない。第６図は、ウインドウに描画するためディスプレイ・コントローラ202が用いるウインドウ・データ構造600の例を示す。第６図を参照して、ウインドウ優先順位データ構造602が各ウインドウの相対的な優先順位（即ち、あるウインドウが他のウインドウに対してその上に来るのか下に来るのかということ）をリストする。第４図の画面構成の例では、ウインドウ優先順位データ構造602はウインドウ404がウインドウ402 より高い優先順位を持つことを示している。これは、ウインドウ404は、ウインドウ402の上にあり、ウインドウ404とウインドウ402の共通部分442（両ウインドウが共存する所）では、ウインドウ404が表示され、ウインドウ402は隠れることを意味する。ウインドウ優先順位データ構造602は、表示領域の全てのウインドウに対して同様なリストを保守する。ウインドウ優先順位データ構造602の正確なインプリメンテーションは、表示を制御する個々のウインドウ・システムの要件に依存する。ウインドウ定義データ構造604は、ウインドウ・システムによって定義される各ウインドウに対する主要なパラメータを定義する。定義としては、ウインドウ・クリップ境界500、塗りつぶしパターン、文字フォント、各ウインドウに対するペンやブラシ定義等がある。第５図はウインドウ・クリップ境界500を示す。ウインドウ・クリップ境界500は、各ウインドウに対する境界を表示画面の２次元表記で定義する。境界は、Ｘ-min 502、Ｙ-min 504、Ｘ-max 506、Ｙ-max 508で定義されている。これらの境界は、ウインドウ定義データ構造604では一対の２次元座標（Ｘ₁，Ｙ₁）及び（Ｘ₂，Ｙ₂）として表してもよい、ここでＸ₁はＸ-mi n 502、Ｙ₁はＹ-min 504、Ｘ₂はＸ-max 506、Ｙ₂はＹ-max 508である。これ以外に他の従来の表記を用いてもかまわない。ウインドウ・クリップ境界500は、１つのウインドウのサブセットを定義するのに用いてもよい。ウインドウ共通部分データ構造606は、ディスプレイ・コントローラが定義する各ウインドウの共通領域を定義する。共通領域とは、１つのウインドウが少なくも１つの他のウインドウと重なり合う領域と定義される。共通領域は、ウインドウ・クリップ境界500を用いて計算される。例として、共通領域442は、ウインドウ402がウインドウ404と重なり合う領域である。第６図は、各ウインドウに対してウインドウ共通部分がリストされるように構成されたウインドウ共通部分データ構造606を示している。共通部分領域データ構造608は、共通部分領域、その座標、及び重なり合って共通部分領域を形成するウインドウを定義する。例えば、共通部分領域442 は、ウインドウ402に対する座標（Ｘ₁，Ｙ₁）及びウインドウ404に対する座標（Ｘ₂，Ｙ₂）で定義される。共通部分領域データ構造608は、各共通部分領域の書き込み可能プレーンの状態も含んでいる。第７図は、第１の実施例のフローチャートで、ウインドウ・システムがデータ構造600を用いて、どのようにして、フレーム・バッファ204のウインドウの可視領域に限って画素を書き込むのかを示している。この実施例では、ある画素がフレーム・バッファ204に書かれるべきかどうかを決定するテストが各ウインドウに対して独立に存在し、重なり合うウインドウに対し相補的になっている。例えば、ウインドウ402に対するテストは、書き込み可能ビット（書き込み可能プレーン328内の）が１の時フレーム・バッファ204に書き込まれ、書き込み可能ビットが０の時フレーム・バッファに書き込まれないというように定義してもよい。この例を用いると、ウインドウ402に対して、書き込み可能プレーン328は、ウインドウクリッピング境界500で定義されるように領域442、444、446、に対して０で、ウインドウ402の他の領域に対しては１となるだろう。同時にウインドウ410に対するテストは、書き込み可能ビットが０の時画素はウインドウ410に対するフレーム・バッフア204に書き込まれ、書き込み可能ビットが１の時書き込まれないというように定義されるであろう。従って、ウインドウ410に関して、領域448に対応する書き込み可能プレーン328の全てのビットは１であろう。その理由は、領域448はウインドウ412により隠されるからである。ウインドウ410に対してウインドウクリッピング境界500で定義される書き込み可能プレーンの残りのビットは全て０で、これらの画素はフレーム・バッフア204に書き込まれることになる。この例にさらに従うと、ウインドウ402の全ての隠れていない領域は書き込み可能ビットが１で、ウインドウ402の全ての隠れる領域は書き込み可能ビットが０（隠れない領域の反対）となる。同時に、ウインドウ410の全ての隠れない領域は書き込み可能ビット０を持つ。従って、もしグラフィツクス画面206 又はディスプレイ・コントローラ202が、ウインドウ410に書き込みその後にウインドウ402に書き込みを行ってフレーム・バッファ204をアップデートするなら、書き込み可能プレーンはアップデートする必要はない（ここでウインドウ402に対するウインドウ定義が変わっていないと仮定して）。これは、領域446の画素位置に対応する書き込み可能プレーン328の部分にある０は、前の動作では、フレーム・バッファ204のその領域に画素を書き込むことを許可したからである。現在のオペレーションでは、この同じ０が、フレーム・バッファ203の領域446に画素が書き込まれるのを禁止している。さて第７図に戻ると、ステップ702で、グラフィックス画面206は先ず、オブジェクトを描画しようとするウインドウが完全に隠れているかどうかを決定する。もしそのウインドウが完全に隠れていれば、ウインドウが見えないのでそのオペレーションは終了し全ての描画操作は破棄される。この描画破棄は色々な方法で行うことが出来るが、最も簡単な方法は、データをフレーム・バッファ204に渡さないことである。もしウインドウが全部隠れていなければ、オペレーションはステップ704に続く。この決定はデータ構造600を用いて行われる。ステップ704では、グラフィックス・サーバ206は、データ構造600を用い、そのウインドウが部分的に隠れているかどうかを決定する。ステップ704でウインドウが部分的に隠れていなければ（そして、ステップ702で決定されたように完全に隠れていない）、そのウインドウには隠れた部分が全くないことになる。これが上述した最初のケースである。この場合にはオペレーシヨンはステップ 706に進む。ステップ706では、ウインドウは隠れていないので、そのウインドウとして定義されたウインドウ・クリップ境界500に対して各位置の画素をテストすることによってウインドウクリッピングを行う。もし画素がその境界500の外にあれば、フレーム・バッファ204に書き込まれない。もしそれが境界内に入れば、そのウインドウは他のウインドウに隠れていないので間違いなく書き込まれる。従って、この場合、書き込み可能プレーン328は必要でなく、フレーム・バッファ204への書き込み制限は不可の状態にされている。ステップ708では、実行中のウインドウの可視部分（この場合全ての部分が見えている）の画素は、前のステップで定義された制約の集合を用いてフレーム・バッファ204に書き込まれる。しかし、ステップ704で、ウインドウが部分的に隠れていれば、ステップ710に進む。これは上述した第２、第３のケースにあたる。ステップ710では、グラフィックス・サーバ206は、最後に行ったオペレーシヨンに比べてウインドウの定義が変わっているかどうかを決定する。ウインドウの定義が変更されるのは、ウインドウが削除されたり、大きさが変更されたり、その場所が変更されたり、新しいウインドウが作られたり（そして当ウインドウと重なり合う）、さもなければ、ウインドウ間の上下関係（即ち、相対的な優先順位）が変更されたりする時である。もしウインドウの定義が変更されていれば、ステップ712に進む。もしウインドウの定義が変更されていなければ、ステップ714に進む。ウインドウの定義に変更があれば、データ構造600も変更されることになる。ステップ712では、グラフィックス・サーバ206は書き込み可能プレーン32 8をアップデートし、そのウインドウの隠れていない部分に対応する書き込み可能プレーンのビット全てが、フレーム・バッファに画素を書き込むことを示すようにする（例えば、上の例では、ウインドウ402の隠れていない部分に対しては１で、ウインドウ404の隠れていない部分に対しては０となる）。ステップ714では、各ウインドウに対するハードウエア書き込み可能テストを、各ウインドウに対して選ばれた取り決めに対応するようにセットする。テストは、ウインドウの隠れていない部分に対して真になるようにセットされる。例えば、ウインドウ402の境界内の書き込み可能328に１が存在することは、ウインドウ402の情報がフレーム・バッフア204に書き込まれることを示す。従って、書き込み可能プレーン328に１が出てくると、ウインドウ402に対するテストは真となる。ステップ716では、グラフィックス・サーバ206は、ウインドウ・クリップ境界500及び書き込み可能プレーン328（ウインドウ・クリップ境界500内）を用い、画素をフレーム・バッファ204に書き込むかどうかを決定する。もしこれらのテストが、画素が隠れた領域に入るためウインドウに書き込まれないことを示すと、画素はその代わり補助記憶装置210に書き込まれる。ステップ708では、画像がウインドウに描画される。このステップで、実行中のウインドウで可視部分内の画素がフレーム・バッファ204に書き込まれる。この実施例において２つの重要な点がある。第１に、もしウインドウが全く隠れていないか又は完全に隠れている時には書き込み可能プレーンは不要なことである。全てのグラフィックス・サーバ206が行わなければならないことは、そのウインドウの画素を、そのウインドウに対するウインドウ・クリップ境界500によって決められる領域に書き込むことである。第２に、部分的に隠れたウインドウに対して、もしウインドウの定義が変化していなければ、オペレーションとオペレーションの間に書き込み制御プレーンをアップデートしなくてもよいことである。隠れた領域と隠れていない領域は相補的に定義されているので、もしディスプレイ・コントローラが一つのウインドウを描画し、引き続き他のものへ移っても、書き込み可能プレーン328はそのまま同じである。変化するのは、画素をフレーム・バッファ204に書き込むかどうかを決定するのに用いられるハードウエア・テストだけである（即ち、０の時書き込みという代わりに１なら書き込みとする）。これにより書き込み可能プレーン328をアップデートしなければならないオペレーションを省くことが出来る。第９図は、第４図に示したウインドウに対する書き込み可能プレーン328 のビットを第１の実施例に従って表示した例である。ウインドウ402においては、１は隠れていない部分を示し、０は実行中の部分を表している。次の実施例では書き込み可能プレーン328が用いる取り決めは全てのウインドウに関して共通である。例えば、１はどのウインドウについても隠れていない領域を表し、０はどのウインドウに対しても隠された領域を表す。この実施例では、もしディスプレイ・コントロラが第１のオペレーションで第１のウインドウに書き込みを行い、第２のオペレーションで、それに重なり合った第２のウインドウに書き込みを行う時には、書き込み制御プレーン328をアップデートしなくてはならない。例えば、グラフィックス・サーバ206がウインドウ404に書き込むと仮定しよう。このオペレーションを可能にするには、ウインドウ404に対するウインドウ・クリップ境界500内の書き込み可能プレーン328の全てのビットを１にセットしなくてはならない。もしディスプレイ・コントローラ202が次にウインドウ402に書き込みたければ、領域442 （ここではウインドウ404は402の上になっている）に対応する書き込み可能プレーン328のビットは１（前のオペレーションでは書き込みに使われた）から０に変更されなくてはならない。従って、第２の実施例では、ウインドウの定義が変わっても変わらなくてもステップ712を実行しなくてはならない。第10図は、本発明の第２の実施例による方法を示すフローチャートである。グラフィックス・サーバ206は、ステップ1002で、ウインドウが完全に隠れているかどうかを決定する。この決定はデータ構造600に基づいて行われる。もしウインドウが完全に隠れていれば、オペレーションは終了する。グラフィックス・サーバ206は、ウインドウが部分的に隠れているかどうかをステップ1004で決定する。もしウインドウが部分的に隠れていなければ（即ち、全く隠れていなければ）、ディスプレイ・コントローラ202は、ステップ1006でウインドウ・クリップ境界500を用いて画素をフレーム・バッファ204に書き込むかどうかを決定する。ディスプレイ・コントローラは、ステップ1012で、適当な画素をフレーム・バッファ204に書き込む。これらの画素は実行中のウインドウの可視部分に入る。それに反して、ステップ1004でウインドウが部分的に隠れていれば、グラフィックス・サーバ206は書き込み可能プレーン328をアップデートし（ステップ 1008）書き込みをそのウインドウの隠れていない領域のみに許可する。ステップ 1010で、グラフィックス・サーバ206はこの書き込み可能プレーン及びウインドウ・クリップ境界を用い・画素をフレーム・バッファ204に書き込むかどうかを決定する。ステップ1012で、実行中のウインドウの可視部分の画素をフレーム・バッファ204に書き込む。オプションで、そのウインドウの隠れた領域の画素は補助記憶装置210に書き込んでもよい。本発明では書き込み可能プレーン328は、非矩形のウインドウを持つウインドウ・アプリケーションをサポートすることが出来る。第11図は、非矩形のウインドウでの描画をサポートするのに書き込み可能プレーン328を用いることを示すフローチャートである。非矩形ウインドウはウインドウ・クリップ境界500では完全に定義することができないので、非矩形ウインドウに描画するには必ず書き込み可能プレーン328を用いなくてはならない。その結果、ウインドウが部分的に隠れているかどうかは問題にならない（第７図のステップ704）。第11図は従って、第７図のサブセット（即ち、ステップ704及び706がない）である。さて第11図を参照して、非矩形ウインドウをサポートするオペレーションを以下に説明する。もしウインドウが完全に隠れていれば、ステップ1102に示すように、オペレーションは終了し、画素はフレーム・バッファ204に書き込まれない。もしウインドウが完全に隠れているのでなければ、隠れていない領域の画素はフレーム・バッファ204に書き込まれる。第11図の残りのステップは、画素が隠れていない領域にあるかどうかを決定するためのものである。ステップ1110では、グラフィックス・サーバ206がウインドウの定義が変更されたかどうかを決定する。この決定は、データ構造600に基づいて行われる。もしウインドウの定義が最後のオペレーション以降変更されているなら、ステップ1112で共通領域をアップデートし、書き込み可能プレーンがウインドウのどの部分が隠れていないかを正しく示すようにする。ステップ1114では、ハードウエアの書き込み可能テストを、隠れていない領域に対しては書き込みを許可し、隠れる領域に対しては書き込みを抑止するようにセットする。ステップ1116では、書き込み可能プレーンのウインドウクリッピング境界を用いて画素をフレーム・バッフア204に書き込むかどうかを決定する。ステップ1108では、先のステップで確立された制約を用いて、実行中のウインドウの可視部分の画素がフレーム・バッファ204に書き込まれる。オプションで、隠れている画素は補助記憶装置210に書き込んでもよい。第7、10、11図はグラフィックス・サーバ206がオペレーションを行うとして説明しているが、グラフィックス・サーバの代わりに、ディスプレイ・コントローラ202を用いてもよい。当業者には、本発明を、多重ウインドウ・クリップ矩形を用いるために拡張できることが容易に分かるであろう。本発明の多くの実施例について上に述べたが、それらは例として挙げられたものであり、限度を示すためのものではない。従って、本発明の広さと範囲は、上述したいかなる典型的な実施例もその限界を与えるものではなく、以下の特許請求範囲及びそれと同等のものに従ってのみ定義される。

【手続補正書】特許法第１８４条の８【提出日】１９９４年１１月２３日【補正内容】請求の範囲１．複数ウインドウ（422）を表示するシステム（204,208,212）におけるウインドウ内の描画を制御する方法であって、該システム（204,208,212）は、書き込み可能テスト（710-716,1110-1116）を備え、且つ、単一書き込み可能プレーン（328）、ウインドウ定義（602,604）、ウインドウ共通部分領域（606,608）及びウインドウ・クリップ境界（604）を有するデータ構造（600）から成り、該方法は、 a）その前のオペレーション以降当ウインドウ定義（602,604）が変更されたかどうかを判定するためにデ一夕構造（600）をチェックする（710,1110）ステップと、 b）単一書き込み可能プレーン（328）の、ウインドウに対応する全ての隠れた領域が第１の論理レベルに設定されるように、また、単一書き込み可能プレーン（328）の隠れていない全ての領域が第２の論理レベルに設定されるように、データ構造（600）のウインドウ共通部分領域（606,608）を用いて単一書き込み可能プレーン（328）をアップデートし、単一書き込み可能プレーン（328）は前記その前のオペレーション以降当ウインドウ定義（602,604）が変更したときにのみアップデートされる、アップデートの（712,1112）ステツプと、 c）表示すべき該ウインドウの隠れていない領域に対して書き込み可能テストを真に設定する（714,1114）ステツプと、 d）該書き込み可能プレーン（328）及びウインドウ・クリップ境界（604 ）に基づいて画素をフレーム・バッファ（328）に書き込むかどうかを決定する（716,1116）ステップと、から成ることを特徴とする描画制御方法。２．請求項第１項記載の方法であって、画素をフレーム・バッフア（328）に書き込む（708,1108）ステップからさらに成ることを特徴とする方法。３．請求項第１項記載の方法であって、描画すべきウインドウが完全に隠れているかどうかを、データ構造（600）の共通部分領域（606,608）情報及びウインドウ優先順位情報（602）に基づいて決定する（702,1102）ステップからさらに成ることを特徴とする方法。４．請求項第１項記載の方法であって、さらに、 e）描画すべきウインドウが全く隠れていないかどうかを判定する（704）ステップと、 f）もし描画すべき前記ウインドウが全く隠れていない時には該ウインドウのウインドウ・クリップ境界（604）のみを用いて前記ウインドウを描画する（706-708）ステツプと、から成ることを特徴とする方法。５．請求項第４項記載の方法であって、前記ステップ（e）は、 i）描画すべき前記ウインドウが完全に隠れているかどうかを判定する（7 02）ステップと、 ii）描画すべき前記ウインドウが部分的に隠れているかどうかを判定する（704）ステツプと、から成ることを特徴とする方法。６．複数のウインドウ（422）の表示を制御するシステムであって、該システム（204,208,212）は、書き込み可能テスト（710-716,1110-1116）を備え、且つ、ウインドウ定義（602,604）、ウインドウ共通部分領域（606,608）及びウインドウ・クリップ境界（604）を有するデータ構造（600）から成り、該システムは表示するピックスマップを格納するフレーム・バッファ手段（204）で、前記フレーム・バッファ手段（204）は画素がウインドウ境界（604）内にあるかどうか、また、前記画素がより優先度の高いウインドウ（602）によって隠されているかどうかを示すように構成された単一書き込み可能プレーン（328）から成るフレーム・バッフア手段（204）と、その前のオペレーション以降当ウインドウ定義（602,604）が変更されたかどうかを判定するためにデータ構造（600）をチェツクする手段（212,710,1110）と、単一書き込み可能プレーン（328）の、ウインドウに対応する全ての隠れた領域が第１の論理レベルに設定されるように、また、単一書き込み可能プレーン（32 8）の隠れていない全ての領域が第２の論理レベルに設定されるように、データ構造（600）のウインドウ共通部分領域（606,608）を用いて単一書き込み可能プレーン（328）をチエツクし、単一書き込み可能プレーン（328）は前記その前のオペレーション以降当ウインドウ規定（602,604）が変更したときにのみアップデートされる、チェックの手段（212,712,1112）と、表示すべきウインドウの隠れていない領域に対して書き込み可能テストを真に設定する手段（212,714,1114）と、書き込み可能プレーン（238）及びウインドウ・クリップ境界（604）に基づいて画素を前記フレーム・バッファ手段（204）に書き込むかどうかを決定する手段（212,716,1116）と、から成ることを特徴とするシステム。７．請求項第６項記載のシステムであって、描画すべきウインドウが完全に隠れているかどうかを、データ構造（600）の共通部分領域情報（606,608）及びウインドウ優先順位情報（602）に基づいて決定する手段（212,702,1102）からさらに成ることを特徴とするシステム。８．請求項第６項記載のシステムであって、（e）描画すべきウインドウが全く隠れていないかどうかを判定する（2 12,704）手段と、（f）もし描画すべき前記ウインドウが全く隠れていない時には当ウインドウのウインドウ・クリップ境界（604）のみを用いて描画すべき前記ウインドウを描画する（212,706-708）ステップと、からさらに成ることを特徴とする方法。９．請求項第８項記載のシステムであって、前記判定手段（212,704）は、 i）描画すべき前記ウインドウが完全に隠れているかどうかを判定する手段（212,702）と、 ii）描画すべき前記ウインドウが部分的に隠れているかどうかを判定する手段（212,704）と、から成ることを特徴とするシステム。 10．請求項第６項記載のシステムであって、前記フレーム・バッファ手段（20 4）は第１のフレーム・バッファ（204A）及び前記ピックスマップをダブル・バッファリングするための第２のフレーム・バッフア（204B）、並びに画素を前記フレーム・バッファ手段（204）に書き込むかどうかを選択するためのフロント／バック・バッファ（322）選択プレーンとをさらに備えたことを特徴とするシステム。 11．請求項第6項記載のシステムであって、前記フレーム・バッファ手段（204 ）は、ビデオモードを示すために少なくも１つのビデオモード選択プレーン（32 4,326）をさらに備えたことを特徴とするシステム。 12．請求項第６項記載のシステムであって、前記フレーム・バッファ手段（20 4）は、画素が１つのオブジェクト当たり１回だけ書き込まれるかどうかを示すために１回書き込みプレーン（330）をさらに備えたことを特徴とするシステム。 13．請求項第６項記載のシステムであって、実行中のウインドウの隠れた領域内に入る少なくも１つの画素を格納する補助記憶装置（214）をさらに備えたことを特徴とするシステム。

Claims

【特許請求の範囲】特許請求の範囲は以下の通りである。１．複数のウインドウを表示するシステムにおいて画素の書き込みを制御する装置であって、画素がウインドウ境界内にあるかどうかを示し、もし境界内にあるなら、前記画素がそのウインドウよりも優先順位の高いウインドウに隠れているかどうかを示すように構成された書き込み可能プレーンを備える、表示するためのピックスマップを格納するフレーム・バッファ手段と、前記フレーム・バッファ手段及び前記メモリ手段に電気的に結合され、画素を前記フレーム・バッファ手段に書き込むかどうかを決定するグラフィックス・コントローラとから成り、前記決定は書き込み可能プレーン及びウインドウ・クリップ境界データに基づいてなされることを特徴とする装置。２．請求項第１項の装置であって、前記グラフィックス・コントローラ手段に接続された、ウインドウ・データ構造を格納するメモリ手段をさらに含み、前記ウインドウ・データ構造はウインドウ優先順位データ、ウインドウ・クリップ境界データ、ウインドウ共通部分データ、共通領域構造データから成ることを特徴とする装置。３．請求項第１項の装置であって、前記書き込み可能プレーンは、画素を前記フレーム・バッファ手段に書き込むかどうかを決定する相補的テストを用いることを特徴とする装置。４．請求項第１項の装置であって、前記フレーム・バッファ手段はさらに、第１のフレーム・バッファ、第２のフレーム・バッファ、及び画素を前記フレーム・バッファ手段に書き込むかどうかを選択するためのフロント／バック・バッファ選択プレーンを備えることを特徴とする装置。５．請求項第１項の装置であって、前記フレーム・バッファ手段はさらに、ビデオモードを表示するためのビデオモード選択プレーンを少なくも１個備えることを特徴とする装置。６．請求項第１項の装置であって、実行中のウインドウの隠れた領域に入る少なくも１個の画素を格納するための補助記憶装置をさらに備えることを特徴とする装置。７．請求項第１項の装置であって、前記フレーム・バッファ手段はさらに、１つのオブジェクトに対して画素を１回だけ書き込むかどうかを表示する１回書き込みプレーンを備えることを特徴とする装置。８．請求項第１項の装置であって、前記グラフィックス・コントローラは、グラフィックス・サーバ及び前記グラフィックス・サーバに接続されたディスプレイ・コントローラを備えることを特徴とする装置。９．書き込み可能プレーン及びウインドウ・クリップ境界を備え、複数ウインドウを表示するシステムでウインドウ内の描画を制御する方法であって、（a）ディスプレイ・コントローラが当ウインドウの隠れていない領域に画素を書き込めるよう書き込み可能プレーンをアップデートするステップと、（b）画素をフレーム・バッファに書き込むかどうかを決定するためにウインドウ・クリップ境界及び書き込み可能プレーンを用いるステップと、から成ることを特徴とする描画制御方法。 10．請求項第７項の方法であって、さらに、ウインドウが全く隠れていないかどうかを決定するステップと、もし全く隠れていなければ、画素をフレーム・バッファに書き込むかどうかを決定するためにウインドウ・クリップ境界のみを用いるステップとを有することを特徴とする方法。 11．請求項第７項の方法であって、さらに、画素をフレーム・バッファに書き込むステップを有することを特徴とする方法。 12．書き込み可能テストを備え、且つ、書き込み可能プレーン、ウインドウ定義、ウインドウ共通部分及びウインドウ・クリップ境界を有するデータ構造を備え、複数ウインドウを表示するシステムでウインドウ内の描画を制御する方法であって、前のオペレーシヨン以降当ウインドウ定義が変更されたかどうかを決定するためにデータ構造をチェックするステップと、書き込み可能プレーンの隠れた領域が合致し、書き込み可能プレーンの隠れていない全ての領域が隠れた領域の反対になるように、データ構造のウインドウ共通部分を用いて書き込み可能プレーンをアップデートするステップで、前のオペレーション以降当ウインドウ定義が変更したときにのみ書き込み可能プレーンをアップデートするステップと、当ウインドウの隠れていない領域に対して書き込み可能テストを真に設定するステップと、前記書き込み可能テスト及びウインドウ・クリップ境界に基づいて画素をフレーム・バッファに書き込むかどうかを決定するステップと、から成ることを特徴とする描画制御方法。 13．請求項第12項の方法であって、さらに、画素をフレーム・バッファに書き込むステップを有することを特徴とする方法。 14．請求項第12項の方法であって、さらに、描画するウインドウが完全に隠れているかどうかを、データ構造の共通部分情報及びウインドウ優先順位情報に基づいて決定するステップを有することを特徴とする方法。 15．請求項第12項の方法であって、さらに、（e）描画するウインドウが全く隠れていないかどうかを決定するステップと、（f）もし描画する前記ウインドウが全く隠れていない時にはそのウインドウのウインドウ・クリップ境界のみを用いて描画する前記ウインドウを描画するステップとを、有することを特徴とする方法。 16．請求項第15項の方法であって、ここで前記ステップ（e）は、（i）描画する前記ウインドウが完全に隠れているかどうかを決定するステップと、（ii）描画する前記ウインドウが部分的に隠れているかどうかを決定するステップとを、有することを特徴とする方法。 17. 書き込み可能テストを備え、且つ、書き込み可能プレーン、ウインドウ定義、ウインドウ共通部分及びウインドウ・クリップ境界を有するデータ構造を備え、複数ウインドウを表示するシステムでウインドウの描画を制御するシステムであって、前のオペレーション以降当ウインドウ定義が変更されたかどうかを決定するためにデータ構造をチェックする手段と、書き込み可能プレーンの隠れた領域が合致し、書き込み可能プレーンの隠れていない全ての領域が隠れた領域の反対になるように、データ構造のウインドウ共通部分を用いて書き込み可能プレーンをアップデートする手段で、前のオペレーシヨン以降当ウインドウ定義が変更したときにのみ書き込み可能プレーンをアップデートする手段と、当ウインドウの隠れていない領域に対して書き込み可能テストを真に設定する手段と、前記書き込み可能テスト及びウインドウ・クリップ境界に基づいて画素をフレーム・バッファに書き込むかどうかを決定する手段と、から成ることを特徴とする描画制御システム。 18. 請求項第17項のシステムであって、さらに、描画するウインドウが完全に隠れているかどうかを、データ構造の共通部分情報及びウインドウ優先順位情報に基づいて決定する手段を備えたことを特徴とするシステム。 19. 請求項第17項のシステムであって、さらに、（e）描画するウインドウが全く隠れていないかどうかを決定する手段と、（f）もし描画する前記ウインドウが全く隠れていない時には当ウインドウのウインドウ・クリップ境界のみを用いて描画する前記ウインドウを描画する手段とを、備えたことを特徴とする方法。 20. 請求項第17項のシステムであって、ここで前記決定手段は、（i）描画する前記ウインドウが完全に隠れているかどうかを決定する手段と、（ii）描画する前記ウインドウが部分的に隠れているかどうかを決定する手段とを、有することを特徴とするシステム。