JP3413201B2 - ウィンドウ型及び他の表示オペレーションのためのグラフィックス制御プレーン - Google Patents
ウィンドウ型及び他の表示オペレーションのためのグラフィックス制御プレーンInfo
- Publication number
- JP3413201B2 JP3413201B2 JP51435394A JP51435394A JP3413201B2 JP 3413201 B2 JP3413201 B2 JP 3413201B2 JP 51435394 A JP51435394 A JP 51435394A JP 51435394 A JP51435394 A JP 51435394A JP 3413201 B2 JP3413201 B2 JP 3413201B2
- Authority
- JP
- Japan
- Prior art keywords
- window
- frame buffer
- pixel
- plane
- hidden
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/14—Display of multiple viewports
Description
【発明の詳細な説明】
発明の背景
1.産業上の利用分野
本発明は、一般にはラスタ・グラフィックス・システ
ムの分野に関し、より具体的には、複数のウインドウを
表示するシステムにおいてウインドウ描画を制御するシ
ステム及び方法に関する。
ムの分野に関し、より具体的には、複数のウインドウを
表示するシステムにおいてウインドウ描画を制御するシ
ステム及び方法に関する。
2.関連技術
現代コンピュータ・システムでは、コンピュータ・グ
ラフィックス技術が幅広く使用されている。計算能力の
面から見てパーソナルコンピュータからワークステーシ
ョン、さらにグラフィックス専用システムに亘る広い分
野のコンピュータ・システムで、ラスタ・グラフィック
ス技術はグラフィックス画像を表示する最も有力なメカ
ニズムになってきた。
ラフィックス技術が幅広く使用されている。計算能力の
面から見てパーソナルコンピュータからワークステーシ
ョン、さらにグラフィックス専用システムに亘る広い分
野のコンピュータ・システムで、ラスタ・グラフィック
ス技術はグラフィックス画像を表示する最も有力なメカ
ニズムになってきた。
ラスタ・グラフィックス・システムでは、水平表示線
は、ラスタ線と呼ばれ、一列の画素（ピクセル又はPE
L）で表される。全画面は、ラスタ線の集合を矩形に配
列して得られるが、この配列をラスタと呼ぶ。したがっ
て、ラスタは、１つ以上の画像を保持するのに用いられ
るが、画素のマトリックスから出来ていることになる。
この画素マトリックスは、メモリ・バッファにディジタ
ル情報として記憶される。特に、表示装置に転送される
データを保持するように設計されているメモリ・バッフ
ァを「フレーム・バッファ」と呼ぶ。
は、ラスタ線と呼ばれ、一列の画素（ピクセル又はPE
L）で表される。全画面は、ラスタ線の集合を矩形に配
列して得られるが、この配列をラスタと呼ぶ。したがっ
て、ラスタは、１つ以上の画像を保持するのに用いられ
るが、画素のマトリックスから出来ていることになる。
この画素マトリックスは、メモリ・バッファにディジタ
ル情報として記憶される。特に、表示装置に転送される
データを保持するように設計されているメモリ・バッフ
ァを「フレーム・バッファ」と呼ぶ。
単色システムでは、各画素は普通、フレーム・バッフ
ァの１ビットで表される。ビットの状態（即ち、１又は
０）は対応するビットがオンかオフ（即ち、表示上白又
は黒）かを決定する。そのようなシステムでは、メモリ
・バッファはビットマップと呼ばれる。
ァの１ビットで表される。ビットの状態（即ち、１又は
０）は対応するビットがオンかオフ（即ち、表示上白又
は黒）かを決定する。そのようなシステムでは、メモリ
・バッファはビットマップと呼ばれる。
カラーや３次元（3D）画像のようなより複雑な画像を
保持するように設計されたシステムでは、各画素は、そ
の画素に関する情報を含む複数のビットで表される。各
画素を表すビットには、色情報を記憶するビット、深さ
の情報を表すビット等が含まれる。１画素当り複数ビッ
トを持つシステムのメモリ・バッファ内にある全ビット
のマトリックスをピックスマップと呼ぶ。
保持するように設計されたシステムでは、各画素は、そ
の画素に関する情報を含む複数のビットで表される。各
画素を表すビットには、色情報を記憶するビット、深さ
の情報を表すビット等が含まれる。１画素当り複数ビッ
トを持つシステムのメモリ・バッファ内にある全ビット
のマトリックスをピックスマップと呼ぶ。
画像を表示するには、通常ピックスマップのビットは
フレーム・バッファから一度にラスタ線１本の単位で逐
次走査される。走査されたデータは、表示装置（最も普
通にはCRTビデオモニタ）に転送される。CRTモニタ以外
の表示装置については、通常似通ってはいるが違った走
査及び表示条件がある。
フレーム・バッファから一度にラスタ線１本の単位で逐
次走査される。走査されたデータは、表示装置（最も普
通にはCRTビデオモニタ）に転送される。CRTモニタ以外
の表示装置については、通常似通ってはいるが違った走
査及び表示条件がある。
システムの機能が向上して拡張グラフィックスを提供
出来るようになるに従って、システムの複雑さも増す。
例えば、現代のグラフィックス・システムでは、より高
い分解能（単位面積当りの画素数の増加）及びより多く
の色の選択が可能になってきた。こうした機能拡張には
ピックスマップを構成する大量のビット数が必要とな
る。
出来るようになるに従って、システムの複雑さも増す。
例えば、現代のグラフィックス・システムでは、より高
い分解能（単位面積当りの画素数の増加）及びより多く
の色の選択が可能になってきた。こうした機能拡張には
ピックスマップを構成する大量のビット数が必要とな
る。
メモリの価格が低下するにつれ、システムは同じ価格
目標でより向上した機能を備えたものになってきてい
る。現在入手可能な低価格のランダム・アクセス・メモ
リ（RAM）及び専用ビデオRAM（VRAM）のおかげで、3Dグ
ラフィックスを表示するのに、大容量、高速フレーム・
バッファは極くありきたりのものとなって来ている。
目標でより向上した機能を備えたものになってきてい
る。現在入手可能な低価格のランダム・アクセス・メモ
リ（RAM）及び専用ビデオRAM（VRAM）のおかげで、3Dグ
ラフィックスを表示するのに、大容量、高速フレーム・
バッファは極くありきたりのものとなって来ている。
3Dラスタ・グラフィックス・システムでは「ダブル・
バッファリング」として知られている手法を用いる。ダ
ブルバッファリングにおいては、１つのフレーム・バッ
ファから画像が表示されている時に、第２のフレーム・
バッファではデータが全てクリアされ、次の表示のため
の新しい画像に書き換えられる。
バッファリング」として知られている手法を用いる。ダ
ブルバッファリングにおいては、１つのフレーム・バッ
ファから画像が表示されている時に、第２のフレーム・
バッファではデータが全てクリアされ、次の表示のため
の新しい画像に書き換えられる。
この手法では、ユーザーが前の画像を見ている間に、
フレーム・バッファをアップデートすることが出来る。
このため、フレーム・バッファが消去され再描画される
間に起きる画面のフリッカリングを防ぐことが出来る。
通常、表示装置に画像を表示するのにかかる時間に比し
て描画するには非常に長い時間がかかるのでこの手法が
必要である。
フレーム・バッファをアップデートすることが出来る。
このため、フレーム・バッファが消去され再描画される
間に起きる画面のフリッカリングを防ぐことが出来る。
通常、表示装置に画像を表示するのにかかる時間に比し
て描画するには非常に長い時間がかかるのでこの手法が
必要である。
ラスタ・グラフィックス・システムに関する詳しい解
説には、アディソン・ウエズリー出版社（Addison−Wes
ley Publishing Company）より1990年発行の、ジェイム
ス・Ｄ・フォーリー（James D.Foley、アンドリー・ヴ
ァン・ダム（Andries van Dam）、スティーブン・Ｋ・
ファイナー（Steven K.Feiner）、ジョン・Ｆ・ヒュー
ズ（John F.Hughes）の著書、「Computer Graphics:Pri
ncipla and Practice（コンピュータ・グラフィック
ス：原理と実践）」第２版を参考にすること。特に１
章、4.3章、18章を参照のこと。
説には、アディソン・ウエズリー出版社（Addison−Wes
ley Publishing Company）より1990年発行の、ジェイム
ス・Ｄ・フォーリー（James D.Foley、アンドリー・ヴ
ァン・ダム（Andries van Dam）、スティーブン・Ｋ・
ファイナー（Steven K.Feiner）、ジョン・Ｆ・ヒュー
ズ（John F.Hughes）の著書、「Computer Graphics:Pri
ncipla and Practice（コンピュータ・グラフィック
ス：原理と実践）」第２版を参考にすること。特に１
章、4.3章、18章を参照のこと。
現代のコンピュータ・マーケットで一段と普及してき
たものは「ウインドウ」である。PCやワークステーショ
ンでのウインドウの機能は極く普通のものである。実
際、ウインドウは、Microsoft Windows、X Windows Sys
temのようなグラフィックス・ユーザ・インタフェー
ス、Apple Macintoshコンピュータ用の種々のアプリケ
ーションで欠くことの出来ない要素となっている。
たものは「ウインドウ」である。PCやワークステーショ
ンでのウインドウの機能は極く普通のものである。実
際、ウインドウは、Microsoft Windows、X Windows Sys
temのようなグラフィックス・ユーザ・インタフェー
ス、Apple Macintoshコンピュータ用の種々のアプリケ
ーションで欠くことの出来ない要素となっている。
ラスタ・グラフィックス技術とウインドウ環境を結合
することの必要性は、これら２つの技術が進化していく
過程で自然に生まれてくるものである。しかし、そのよ
うな結合には数多くの問題が存在する。特に、１つの問
題は、動画を表示装置に表示しながら、ダブルバッファ
の画像を入れ替えるというものである。
することの必要性は、これら２つの技術が進化していく
過程で自然に生まれてくるものである。しかし、そのよ
うな結合には数多くの問題が存在する。特に、１つの問
題は、動画を表示装置に表示しながら、ダブルバッファ
の画像を入れ替えるというものである。
動的フレーム・バッファでは、全バッファを高速にス
ワップしたりクリアすることが容易で、従って全表示領
域の内容を変えることは容易である。しかし、ウインド
ウ画面では、表示の一部のみがアップデートされるの
で、いくつかの問題が生じる。ある時点においては、画
面のあるサブセットのみがある１つのウインドウに割り
当てられている。どのウインドウも、ダブルバッファ方
式のフレーム・バッファのどちらのバッファを使用して
もよいので、各ウインドウに選択されたバッファは独立
に制御されなくてはならない。
ワップしたりクリアすることが容易で、従って全表示領
域の内容を変えることは容易である。しかし、ウインド
ウ画面では、表示の一部のみがアップデートされるの
で、いくつかの問題が生じる。ある時点においては、画
面のあるサブセットのみがある１つのウインドウに割り
当てられている。どのウインドウも、ダブルバッファ方
式のフレーム・バッファのどちらのバッファを使用して
もよいので、各ウインドウに選択されたバッファは独立
に制御されなくてはならない。
しかも、常時、前景バッファ（即ち、表示されてるバ
ッファ）は各ウインドウに対して個別に選択されなくて
はならない。しかし、ウインドウは表示のどの画素から
始まり、どの画素で終了してもよいので、この選択は、
表示時に各画素に対しなされねばならない。
ッファ）は各ウインドウに対して個別に選択されなくて
はならない。しかし、ウインドウは表示のどの画素から
始まり、どの画素で終了してもよいので、この選択は、
表示時に各画素に対しなされねばならない。
従来のグラフィックス・システムでは、描画をウイン
ドウ内に制御するのにウインドウID（WID）が用いられ
る。WIDを定義する前に、フレーム・バッファで用いら
れる「プレーン」という用語を定義するのが有用と思わ
れる。プレーンとは、全ての画素で同一のビットから成
るピックスマップのサブセットである。プレーンは、ピ
ックスマップの「水平」断面ともいえる。従って、例え
ば、各画素の第１ビットからなる集合はプレーンを作
る。
ドウ内に制御するのにウインドウID（WID）が用いられ
る。WIDを定義する前に、フレーム・バッファで用いら
れる「プレーン」という用語を定義するのが有用と思わ
れる。プレーンとは、全ての画素で同一のビットから成
るピックスマップのサブセットである。プレーンは、ピ
ックスマップの「水平」断面ともいえる。従って、例え
ば、各画素の第１ビットからなる集合はプレーンを作
る。
WIDを用いるシステムでは、フレーム・バッファ・メ
モリにいくつかのプレーンを追加する。これらのプレー
ンは、WIDと呼ばれるコードを保持する。WIDコードは、
各画素が属するウインドウを指定する。画素がフレーム
・バッファに送られる時、そのWIDコードが、画面上の
その位置に表示されるウインドウを指定するWIDと比較
される。もしその比較が一致すれば、書き込み可能信号
が生成され、その画素はフレーム・バッファに記憶され
る。もしWIDの比較が一致しなければ、書き込み可能信
号は生成されず、その画素はフレーム・バッファに書き
込まれない。
モリにいくつかのプレーンを追加する。これらのプレー
ンは、WIDと呼ばれるコードを保持する。WIDコードは、
各画素が属するウインドウを指定する。画素がフレーム
・バッファに送られる時、そのWIDコードが、画面上の
その位置に表示されるウインドウを指定するWIDと比較
される。もしその比較が一致すれば、書き込み可能信号
が生成され、その画素はフレーム・バッファに記憶され
る。もしWIDの比較が一致しなければ、書き込み可能信
号は生成されず、その画素はフレーム・バッファに書き
込まれない。
複数のフレーム・バッファを用いるシステムでは、WI
Dは、画素データを書き込むフレーム・バッファを制御
するのに用いられる。
Dは、画素データを書き込むフレーム・バッファを制御
するのに用いられる。
WIDに関するより詳しい説明には、Tsujidoに付与され
た米国特許番号4,769,762、Westberg他に付与された米
国特許番号5,101,365、及びCarrie他に付与された米国
特許番号5,091,717を参照のこと。
た米国特許番号4,769,762、Westberg他に付与された米
国特許番号5,101,365、及びCarrie他に付与された米国
特許番号5,091,717を参照のこと。
WIDシステムにはいくつかの欠点がある。まず第１
に、WIDシステムには、データ及びアドレス中のWIDコー
ドをデコードし、それらが一致するかどうかを判定する
ための回路が余分に必要となる。第２に、WIDのサイズ
に制限があるため、複雑な「WID交換」ソフトウエアを
使わないかぎり、この手法は限られた数のウインドウし
か管理することが出来ない。普通のウインドウ・システ
ムでも多くのウインドウが要求される。例えば、３ビッ
トのWIDは、８個の唯一無二のWIDを与えるだけである。
第３には、複雑はシステムにおいてWIDをインプリメン
トするには多くのプレーンが必要となるが、その理由
は、システムのウインドウの数が多くなれば、それだけ
WIDプレーンの数も多くなるからである。例えば、256ウ
インドウ・システムでは８個のWIDプレーンが必要とな
る。これは１個の画素につき８ビットとなる。1k x 2k
のフレーム・バッファでは、８個のWIDプレーンをサポ
ートするには16Mビットが必要となる。
に、WIDシステムには、データ及びアドレス中のWIDコー
ドをデコードし、それらが一致するかどうかを判定する
ための回路が余分に必要となる。第２に、WIDのサイズ
に制限があるため、複雑な「WID交換」ソフトウエアを
使わないかぎり、この手法は限られた数のウインドウし
か管理することが出来ない。普通のウインドウ・システ
ムでも多くのウインドウが要求される。例えば、３ビッ
トのWIDは、８個の唯一無二のWIDを与えるだけである。
第３には、複雑はシステムにおいてWIDをインプリメン
トするには多くのプレーンが必要となるが、その理由
は、システムのウインドウの数が多くなれば、それだけ
WIDプレーンの数も多くなるからである。例えば、256ウ
インドウ・システムでは８個のWIDプレーンが必要とな
る。これは１個の画素につき８ビットとなる。1k x 2k
のフレーム・バッファでは、８個のWIDプレーンをサポ
ートするには16Mビットが必要となる。
発明の要約
本発明は、複数のウインドウをサポート可能なグラフ
ィックス・システムの表示装置への書き込みシステム及
びその方法を提供するものである。本発明はまた、グラ
フィックス・システムのビデオ機能を制御するのに用い
るグラフィックス制御プレーンと呼ばれるいくつかのプ
レーンを提供する。フロント／バック・バッファ選択プ
レーンは、画素が、デュアルバッファ・システムのフロ
ント・バッファかバック・バッファのどちらに属するか
を選択するのに用いられる。ビデオモード選択プレーン
は、複数の画素形式のどれが選択されているかを示す。
例えば、ビデオモード選択プレーンは、12ビット又は24
ビットRGB画素を選択するのに用いることが出来る。さ
らに新たなビデオモード選択プレーンを加え、違ったビ
デオモードをサポートするような柔軟性を提供するよう
にすることも出来る。違ったモードの１つの例は、８プ
レーンのカラー・インデックス・モードである。
ィックス・システムの表示装置への書き込みシステム及
びその方法を提供するものである。本発明はまた、グラ
フィックス・システムのビデオ機能を制御するのに用い
るグラフィックス制御プレーンと呼ばれるいくつかのプ
レーンを提供する。フロント／バック・バッファ選択プ
レーンは、画素が、デュアルバッファ・システムのフロ
ント・バッファかバック・バッファのどちらに属するか
を選択するのに用いられる。ビデオモード選択プレーン
は、複数の画素形式のどれが選択されているかを示す。
例えば、ビデオモード選択プレーンは、12ビット又は24
ビットRGB画素を選択するのに用いることが出来る。さ
らに新たなビデオモード選択プレーンを加え、違ったビ
デオモードをサポートするような柔軟性を提供するよう
にすることも出来る。違ったモードの１つの例は、８プ
レーンのカラー・インデックス・モードである。
書き込み可能プレーンは、グラフィックス・システム
が矩形及び非矩形ウインドウをサポート可能にするため
の重要な機能である。書き込み可能プレーンは、画素が
ウインドウにあるかどうか、さらに具体的には、その画
素が表示されるウインドウの１部にあるかどうかを絶え
ず記録する。
が矩形及び非矩形ウインドウをサポート可能にするため
の重要な機能である。書き込み可能プレーンは、画素が
ウインドウにあるかどうか、さらに具体的には、その画
素が表示されるウインドウの１部にあるかどうかを絶え
ず記録する。
さらに、１つのオブジェクトに対して１回しか書き込
まないようにするシステムの要件をサポートするために
１回書き込みプレーンを含めることも出来る。この要件
は、X Windows環境のような特定の環境でのみ必要であ
る。
まないようにするシステムの要件をサポートするために
１回書き込みプレーンを含めることも出来る。この要件
は、X Windows環境のような特定の環境でのみ必要であ
る。
グラフィックス制御プレーンを用いて、さらに具体的
には、書き込み可能プレーンを用いることにより、従来
のウインドウ描画手法に比べハードウエアを節約できる
ようになる。書き込み可能プレーンは、フレーム・バッ
ファ・メモリのただ１個のプレーンのコストでウインド
ウ・システムに大きな柔軟性をもたらす。
には、書き込み可能プレーンを用いることにより、従来
のウインドウ描画手法に比べハードウエアを節約できる
ようになる。書き込み可能プレーンは、フレーム・バッ
ファ・メモリのただ１個のプレーンのコストでウインド
ウ・システムに大きな柔軟性をもたらす。
書き込み可能プレーンをサポートするため、インポー
トされたウインドウ・パラメータを定義出来るようウイ
ンドウ・データ構造を確立する。ウインドウ・データ構
造は、相対的なウインドウ優先順位（即ち、あるウイン
ドウが他のウインドウに対して上に来るか下に来る
か）、ウインドウ・クリップ境界のようなウインドウの
定義、フィルパターンやブラシの定義を含んでいる。ウ
インドウ・データ構造はまた、１つのウインドウが少な
くも１つの他のウインドウと重なり合う共通部分領域を
定義する共通部分情報も含んでいる。共通部分領域デー
タ構造は、ウインドウ間の共通部分領域、即ち、その座
標及びその共通部分領域を作る重なり合ったウインドウ
を定義する。
トされたウインドウ・パラメータを定義出来るようウイ
ンドウ・データ構造を確立する。ウインドウ・データ構
造は、相対的なウインドウ優先順位（即ち、あるウイン
ドウが他のウインドウに対して上に来るか下に来る
か）、ウインドウ・クリップ境界のようなウインドウの
定義、フィルパターンやブラシの定義を含んでいる。ウ
インドウ・データ構造はまた、１つのウインドウが少な
くも１つの他のウインドウと重なり合う共通部分領域を
定義する共通部分情報も含んでいる。共通部分領域デー
タ構造は、ウインドウ間の共通部分領域、即ち、その座
標及びその共通部分領域を作る重なり合ったウインドウ
を定義する。
システムは、データ構造を用い、オブジェクトを描画
するウインドウが他のウインドウで完全に隠れている
か、部分的に隠れているか、全く隠れていないかを判定
する。もし完全に隠れているなら描画動作は終了し、そ
のウインドウに対する全ての画素は捨て去られる。もし
全く隠れていなければ、ウインドウ・クリップ境界情報
を用いて画素をウインドウに描画する。
するウインドウが他のウインドウで完全に隠れている
か、部分的に隠れているか、全く隠れていないかを判定
する。もし完全に隠れているなら描画動作は終了し、そ
のウインドウに対する全ての画素は捨て去られる。もし
全く隠れていなければ、ウインドウ・クリップ境界情報
を用いて画素をウインドウに描画する。
もしウインドウが他のウインドウで部分的に隠れてい
れば、システムは、最後のオペレーション以後ウインド
ウの定義が変更されたかどうかを決定する。もしそうな
ら、書き込み可能プレーンをアップデートし、ウインド
ウのどの部分が現在隠れていないかを示す。もしウイン
ドウの定義が変更されていなければ、書き込み可能プレ
ーンをアップデートする必要はない。システムは次に、
書き込み可能プレートと共にウインドウ・クリップ境界
を用い、そのウインドウのフレーム・バッファに各画素
を書き込むかどうかを決定する。
れば、システムは、最後のオペレーション以後ウインド
ウの定義が変更されたかどうかを決定する。もしそうな
ら、書き込み可能プレーンをアップデートし、ウインド
ウのどの部分が現在隠れていないかを示す。もしウイン
ドウの定義が変更されていなければ、書き込み可能プレ
ーンをアップデートする必要はない。システムは次に、
書き込み可能プレートと共にウインドウ・クリップ境界
を用い、そのウインドウのフレーム・バッファに各画素
を書き込むかどうかを決定する。
本発明の特長は、画素をフレーム・バッファに書き込
むかどうかの決定を１個の書き込み可能プレーンを用い
て行い得ることである。これは、従来のウインドウID
（WID）システムに比べて大変有利である。従来のシス
テムでは、2nのウインドウをインプリメントするにはｎ
個のプレーンとそれらｎ個のプレーンを解釈する別のハ
ードウエアが必要であった。
むかどうかの決定を１個の書き込み可能プレーンを用い
て行い得ることである。これは、従来のウインドウID
（WID）システムに比べて大変有利である。従来のシス
テムでは、2nのウインドウをインプリメントするにはｎ
個のプレーンとそれらｎ個のプレーンを解釈する別のハ
ードウエアが必要であった。
本発明の他の特長は、もしウインドウの定義が変更さ
れていなければ、書き込み制御プレーンを、オペレーシ
ョンとオペレーションの間にアップデートしなくてもよ
いことである。これは、ウインドウの隠れた領域と隠れ
ていない領域が相補的な形式で定義出来るからである。
この場合、変化するものは単に、画素をフレーム・バッ
ファに書き込むかどうかを決定するために選択されたハ
ードウエアテストだけである。書き込み可能プレーンの
再書き込みが必要ないため、これにより節約が可能とな
る。
れていなければ、書き込み制御プレーンを、オペレーシ
ョンとオペレーションの間にアップデートしなくてもよ
いことである。これは、ウインドウの隠れた領域と隠れ
ていない領域が相補的な形式で定義出来るからである。
この場合、変化するものは単に、画素をフレーム・バッ
ファに書き込むかどうかを決定するために選択されたハ
ードウエアテストだけである。書き込み可能プレーンの
再書き込みが必要ないため、これにより節約が可能とな
る。
また別の特長は、書き込み可能プレーンを用いて、非
矩形ウインドウを利用するウインドウ・アプリケーショ
ンを簡単にサポートすることが出来ることである。
矩形ウインドウを利用するウインドウ・アプリケーショ
ンを簡単にサポートすることが出来ることである。
本発明の他の機能及び特長、さらに本発明の種々の実
施例の構成及び動作について添付の図を参照しながら以
下に詳細に説明する。
施例の構成及び動作について添付の図を参照しながら以
下に詳細に説明する。
図面の簡単な説明
本発明を、添付の図を参照して説明する。図におい
て、同一の要素又は同様の機能を持つ要素は同じ参照番
号で表わされる。さらに、参照番号の一番左の数字は、
その番号が最初に出てくる図面の番号を表す。
て、同一の要素又は同様の機能を持つ要素は同じ参照番
号で表わされる。さらに、参照番号の一番左の数字は、
その番号が最初に出てくる図面の番号を表す。
第１図は、ウインドウIDを用いた従来のグラフィック
ス・システムを示すブロック図である。
ス・システムを示すブロック図である。
第２図は、本発明のグラフィックス制御プレーンをサ
ポートするために用いられるシステムを示すブロック図
である。
ポートするために用いられるシステムを示すブロック図
である。
第３図は、本発明のグラフィックス制御プレーンを示
す。
す。
第４図は、表示画面上で互いに重なり合う複数のウイ
ンドウの例を示す。
ンドウの例を示す。
第５図は、本発明のウインドウ・クリップ境界を示
す。
す。
第６図は、本発明の書き込み可能プレーンをサポート
するのに用いるデータ構造を示す。
するのに用いるデータ構造を示す。
第７図は、本発明の第１の実施例のオペレーションを
示すフローチャートである。
示すフローチャートである。
第８図は、ピックスマップの典型的なインプリメンテ
ーション・プレーンを示す。
ーション・プレーンを示す。
第９図は、本発明の重なり合う複数のウインドウに対
する書き込み可能プレーンの書き込み可能ビットを表
す。
する書き込み可能プレーンの書き込み可能ビットを表
す。
第10〜11図は、本発明の他の実施例の方法を示すフロ
ーチャートである。
ーチャートである。
発明の詳細な説明
本発明は、複数のウインドウをサポートするグラフィ
ックス・システムの表示装置にデータを書き込むシステ
ム及びその方法に関するものである。フレーム・バッフ
ァ又はピックスマップ中のある画素が実行中のウインド
ウで修正されるべきかどうかを制御するためにグラフィ
ックスス制御プレーンが与えられている。本発明によれ
ば、ディスプレイ・コントローラが、画素を修正するか
どうかを決定するのである。この決定は、その画素が属
するウインドウに基づいて行われる。もしその画素を含
むウインドウが実行中のウインドウであれば、画素はそ
のウインドウのカバーされていない部分に入り、それは
描画される。本発明は、描画ハードウエアが実行中のウ
インドウだけに限り描画するような手段を提供する。
ックス・システムの表示装置にデータを書き込むシステ
ム及びその方法に関するものである。フレーム・バッフ
ァ又はピックスマップ中のある画素が実行中のウインド
ウで修正されるべきかどうかを制御するためにグラフィ
ックスス制御プレーンが与えられている。本発明によれ
ば、ディスプレイ・コントローラが、画素を修正するか
どうかを決定するのである。この決定は、その画素が属
するウインドウに基づいて行われる。もしその画素を含
むウインドウが実行中のウインドウであれば、画素はそ
のウインドウのカバーされていない部分に入り、それは
描画される。本発明は、描画ハードウエアが実行中のウ
インドウだけに限り描画するような手段を提供する。
フレーム・バッファと関連した動作の観点から本発明
を説明する。ピックスマップについての動作はフレーム
・バッファのものと同じであることは当業者にとって明
かであろう。
を説明する。ピックスマップについての動作はフレーム
・バッファのものと同じであることは当業者にとって明
かであろう。
フレーム・バッファ又はピックスマップの全ての画素
には、「書き込み可能ビット」という書き込み制御プレ
ーンのビットがある。書き込み制御ビットは、現在の画
素が実行中にウインドウで描画されるべきかどうかを決
定するのに用いられる。書き込み制御ビットを描画制限
（クリップ又は鋏み）許可又は不可の状態にすることが
できる。フレーム・バッファに書き込み可能にする値
は、理論の１又は理論の０としてプログラムすることが
出来る。必ずしも必要ではないが、このプログラム可能
な書き込み可のレベルを持つことで多重ウインドウの描
画により高い柔軟性とより有効な制御が得られるように
なる。どのようにしてこれが実現されるかは以下に説明
する。
には、「書き込み可能ビット」という書き込み制御プレ
ーンのビットがある。書き込み制御ビットは、現在の画
素が実行中にウインドウで描画されるべきかどうかを決
定するのに用いられる。書き込み制御ビットを描画制限
（クリップ又は鋏み）許可又は不可の状態にすることが
できる。フレーム・バッファに書き込み可能にする値
は、理論の１又は理論の０としてプログラムすることが
出来る。必ずしも必要ではないが、このプログラム可能
な書き込み可のレベルを持つことで多重ウインドウの描
画により高い柔軟性とより有効な制御が得られるように
なる。どのようにしてこれが実現されるかは以下に説明
する。
第４図に、表示画面で複数のウインドウを用いている
状態を示す。表示画面422は多重ウインドウ402、404、4
06、408、410、412のグラフィックス情報を表示してい
る。これらのウインドウ402、404、406、408、410、412
は表示画面422上で隠れてしまったり、お互いに部分的
に隠し合ったりすることが出来る。例えば、ウインドウ
402は、ウインドウ410によって部分的に隠されている
が、今度はウインドウ410がウインドウ412によって部分
的に隠されている。従って、ある画素を表示するのかど
うか、もしくは、それが現在実行中でないウインドウの
一部か又は実行中のウインドウのマスクされている部分
なのかを判定することが重要になってくる。
状態を示す。表示画面422は多重ウインドウ402、404、4
06、408、410、412のグラフィックス情報を表示してい
る。これらのウインドウ402、404、406、408、410、412
は表示画面422上で隠れてしまったり、お互いに部分的
に隠し合ったりすることが出来る。例えば、ウインドウ
402は、ウインドウ410によって部分的に隠されている
が、今度はウインドウ410がウインドウ412によって部分
的に隠されている。従って、ある画素を表示するのかど
うか、もしくは、それが現在実行中でないウインドウの
一部か又は実行中のウインドウのマスクされている部分
なのかを判定することが重要になってくる。
先に提起したWIDは、各画素が属するウインドウを指
定するコードを記憶するために付け加えたプレーンであ
る。第１図は、WIDをインプリメントした従来のシステ
ムのブロック図を示している。第１図を参照してWIDを
更に詳しく説明する。動作状態では、ウインドウは、デ
ィスプレイ・コントローラ102（Ｘ−ウインドウ・シス
テムではグラフィックス・サーバ）によって選択され
る。ディスプレイ・コントローラ102は、通常中央処理
ユニット（CPU）を有している。ディスプレイ・コント
ローラ102は、ウインドウマップを作成し、ウインドウ
・マップ・バッファ104にこのマップを格納している。
定するコードを記憶するために付け加えたプレーンであ
る。第１図は、WIDをインプリメントした従来のシステ
ムのブロック図を示している。第１図を参照してWIDを
更に詳しく説明する。動作状態では、ウインドウは、デ
ィスプレイ・コントローラ102（Ｘ−ウインドウ・シス
テムではグラフィックス・サーバ）によって選択され
る。ディスプレイ・コントローラ102は、通常中央処理
ユニット（CPU）を有している。ディスプレイ・コント
ローラ102は、ウインドウマップを作成し、ウインドウ
・マップ・バッファ104にこのマップを格納している。
ウインドウ・マップは、個々のウインドウが使用する
画面中の特定の領域を定義する。ウインドウ・マップ
は、ディスプレイ・コントローラ102が与える値に基づ
いて作られる。これらの値として、画素のアドレス及び
各ウインドウに含まれる各画素のWIDがある。WIDは、ウ
インドウ・マップ・バッファ104内にある特定のウイン
ドウの対応する位置の１つ１つに書き込まれる。あるウ
インドウがウインドウ・マップ・バッファ104に書き込
まれる時、WIDメモリ内でそのウインドウを定義する全
ての位置は夫々そのウインドウのWIDを格納する。第１
のウインドウの前に来る第２のウインドウをウインドウ
・マップ・バッファ104に書き込む時には、第２のウイ
ンドウに対するウインドウ番号が第２のウインドウを表
す各位置に格納される。このようにして、第１のウイン
ドウの上に来る第２のウインドウの部分は、ウインドウ
・マップ・バッファ104内の第１のウインドウの重なり
合う位置の上に書き込まれることになる。その結果、第
２のウインドウのこれらの部分は第１のウインドウを自
動的にカバーしクリップする。表示される全てのウイン
ドウが書き込まれた後では、ウインドウ・マップ・バッ
ファ104には、画面上の各点でどのウインドウが表示さ
れるかを示すマップが出来たことになる。言い換える
と、ウインドウ・マップ・バッファ104には、各画素に
対するウインドウIDが含まれることになり、それはその
画素位置にどのウインドウが表示されるかを示してい
る。
画面中の特定の領域を定義する。ウインドウ・マップ
は、ディスプレイ・コントローラ102が与える値に基づ
いて作られる。これらの値として、画素のアドレス及び
各ウインドウに含まれる各画素のWIDがある。WIDは、ウ
インドウ・マップ・バッファ104内にある特定のウイン
ドウの対応する位置の１つ１つに書き込まれる。あるウ
インドウがウインドウ・マップ・バッファ104に書き込
まれる時、WIDメモリ内でそのウインドウを定義する全
ての位置は夫々そのウインドウのWIDを格納する。第１
のウインドウの前に来る第２のウインドウをウインドウ
・マップ・バッファ104に書き込む時には、第２のウイ
ンドウに対するウインドウ番号が第２のウインドウを表
す各位置に格納される。このようにして、第１のウイン
ドウの上に来る第２のウインドウの部分は、ウインドウ
・マップ・バッファ104内の第１のウインドウの重なり
合う位置の上に書き込まれることになる。その結果、第
２のウインドウのこれらの部分は第１のウインドウを自
動的にカバーしクリップする。表示される全てのウイン
ドウが書き込まれた後では、ウインドウ・マップ・バッ
ファ104には、画面上の各点でどのウインドウが表示さ
れるかを示すマップが出来たことになる。言い換える
と、ウインドウ・マップ・バッファ104には、各画素に
対するウインドウIDが含まれることになり、それはその
画素位置にどのウインドウが表示されるかを示してい
る。
実際には、ウインドウはある与えられた順番で書き込
まれる必要はない。通常、ウインドウ・システム・ソフ
トウエアには、どのウインドウがどのウインドウの上に
来るかという優先順位があるのが普通である。この優先
順位は、ウインドウが作られる順番とは独立に決定され
てもよい。
まれる必要はない。通常、ウインドウ・システム・ソフ
トウエアには、どのウインドウがどのウインドウの上に
来るかという優先順位があるのが普通である。この優先
順位は、ウインドウが作られる順番とは独立に決定され
てもよい。
ディスプレイ・メモリに情報を書き込むため、フレー
ム・バッファの各画素のWIDは、WIDレジスタ106に記憶
され、その画素位置のウインドウ・マップ・バッファ10
4のWIDと比較される。もしウインドウ・マップ・バッフ
ァ104のWIDが表示しようとする画素のWIDと同一なら、
比較回路108は、書き込み可能ロジックがその画素の情
報をフレーム・バッファ110の正しい画素アドレスに書
き込むようにする。これに反して、もしその画素のWID
が、ウインドウ・マップ・バッファ104に記憶されてい
るWIDと同一でないと比較回路108が判定すれば、その画
素の情報はフレーム・バッファ110には書き込まれな
い。従って、ある位置で表示されるウインドウに属する
その位置の画素だけがフレーム・バッファ110に書き込
まれ、引き続き表示されることになる。
ム・バッファの各画素のWIDは、WIDレジスタ106に記憶
され、その画素位置のウインドウ・マップ・バッファ10
4のWIDと比較される。もしウインドウ・マップ・バッフ
ァ104のWIDが表示しようとする画素のWIDと同一なら、
比較回路108は、書き込み可能ロジックがその画素の情
報をフレーム・バッファ110の正しい画素アドレスに書
き込むようにする。これに反して、もしその画素のWID
が、ウインドウ・マップ・バッファ104に記憶されてい
るWIDと同一でないと比較回路108が判定すれば、その画
素の情報はフレーム・バッファ110には書き込まれな
い。従って、ある位置で表示されるウインドウに属する
その位置の画素だけがフレーム・バッファ110に書き込
まれ、引き続き表示されることになる。
このようにして、WIDを用いて、各画素位置の前景ウ
インドウの画素のみがフレーム・バッファに書き込まれ
るのである。
インドウの画素のみがフレーム・バッファに書き込まれ
るのである。
他のシステムでも上記の手法の変形が用いられる。こ
れらのシステムでは、WIDは、各WIDに対応する表示特性
が見いだされるテーブル中の場所を示す指標としての働
きをする。新しい画素値が作られていくにつれて、その
WIDは、その画素の特性を探索するためのアドレスとし
て用いられる。もし実行中のウインドウ（現在描画され
ているウインドウ）が新しい画素位置の前景ウインドウ
と一致するなら、その新しい画素の値は表示用としてフ
レーム・バッファに格納される。
れらのシステムでは、WIDは、各WIDに対応する表示特性
が見いだされるテーブル中の場所を示す指標としての働
きをする。新しい画素値が作られていくにつれて、その
WIDは、その画素の特性を探索するためのアドレスとし
て用いられる。もし実行中のウインドウ（現在描画され
ているウインドウ）が新しい画素位置の前景ウインドウ
と一致するなら、その新しい画素の値は表示用としてフ
レーム・バッファに格納される。
WIDはまた、グラフィックス・コントローラへの制御
情報を提供する。この情報は、通常、ハードウエアのル
ックアップ・テーブルにプログラムされていて、フレー
ム・バッファのバック・バッファの前面が現在表示され
ているかどうかとかCLUT（カラールックアップ・テーブ
ル）が画素のカラープレーンの内容をどのように解釈す
るかというようなことを示す。
情報を提供する。この情報は、通常、ハードウエアのル
ックアップ・テーブルにプログラムされていて、フレー
ム・バッファのバック・バッファの前面が現在表示され
ているかどうかとかCLUT（カラールックアップ・テーブ
ル）が画素のカラープレーンの内容をどのように解釈す
るかというようなことを示す。
ある画素がある特定の画素位置を制御するウインドウ
に属するかどうかを決定する１つの方法は、上に述べた
WIDを用いることである。しかし、インプリメントする
には、複雑なWID交換ソフトウエアを用いない限り、WID
には新たにフレーム・バッファ・メモリ・プレーンと制
御ハードウエアが必要となる。典型的には、グラフィッ
クス・システムが十分な柔軟性と効率を持つには、現
在、フレーム・バッファ・メモリの８個のWIDプレーン
が必要とされる。
に属するかどうかを決定する１つの方法は、上に述べた
WIDを用いることである。しかし、インプリメントする
には、複雑なWID交換ソフトウエアを用いない限り、WID
には新たにフレーム・バッファ・メモリ・プレーンと制
御ハードウエアが必要となる。典型的には、グラフィッ
クス・システムが十分な柔軟性と効率を持つには、現
在、フレーム・バッファ・メモリの８個のWIDプレーン
が必要とされる。
第８図に典型的なフレーム・バッファ又はピックスマ
ップのプレーンの概略図を示す。第８図を参照して、ピ
ックスマップ802は複数のプレーン（プレーン０、プレ
ーン１、等）を用いてインプリメントされている。各プ
レーン０、１、２、...、Ｎは、ビットの２次元マトリ
ックスで（１画素当り１ビット）、個々に或いはセット
として各画素に関する情報を含んでいる。プレーン０、
１、２、...、Ｎの完全なセットはピックスマップを作
り、各画素はＮビットで表される（１ビット／プレー
ン）。
ップのプレーンの概略図を示す。第８図を参照して、ピ
ックスマップ802は複数のプレーン（プレーン０、プレ
ーン１、等）を用いてインプリメントされている。各プ
レーン０、１、２、...、Ｎは、ビットの２次元マトリ
ックスで（１画素当り１ビット）、個々に或いはセット
として各画素に関する情報を含んでいる。プレーン０、
１、２、...、Ｎの完全なセットはピックスマップを作
り、各画素はＮビットで表される（１ビット／プレー
ン）。
例えば、ビット802、804、806、808は夫々プレーン
０、１、２、...、Ｎにあり、単一の画素に対応してい
る。各ビット802、804、806、808はその画素の情報を格
納している。ピックスマップ800の他の全ての画素もそ
れ自身のビットのセット（未表示）を有する（各プレー
ン０、１、２、...、Ｎに対し１ビット）。
０、１、２、...、Ｎにあり、単一の画素に対応してい
る。各ビット802、804、806、808はその画素の情報を格
納している。ピックスマップ800の他の全ての画素もそ
れ自身のビットのセット（未表示）を有する（各プレー
ン０、１、２、...、Ｎに対し１ビット）。
プレーン０、１、２、...、Ｎの数は、グラフィック
ス・システムに与えられる機能の数に依存する。カラ
ー、カラー・インデックス、ｚ−バッファリング等のプ
レーンがある。WIDを用いるシステムに対しては、その
グラフィックス・システムが提供するウインドウの数を
指定するのに十分な数のWIDプレーンがなくてはならな
い。例えば、もしそのグラフィックス・システムが256
のウインドウをサポート出来るなら、８個のプレーンが
必要となり、WIDハードウエアが256のウインドウをサポ
ート出来るようになる。これらのプレーンを新たに付け
加えることにより、以下に示すグラフィックスのハード
ウエア・コストがその分余計に掛かることになる。
ス・システムに与えられる機能の数に依存する。カラ
ー、カラー・インデックス、ｚ−バッファリング等のプ
レーンがある。WIDを用いるシステムに対しては、その
グラフィックス・システムが提供するウインドウの数を
指定するのに十分な数のWIDプレーンがなくてはならな
い。例えば、もしそのグラフィックス・システムが256
のウインドウをサポート出来るなら、８個のプレーンが
必要となり、WIDハードウエアが256のウインドウをサポ
ート出来るようになる。これらのプレーンを新たに付け
加えることにより、以下に示すグラフィックスのハード
ウエア・コストがその分余計に掛かることになる。
本発明では、グラフィックス制御プレーンと呼ばれる
WIDプレーンの代わりとなるプレーンのセットを導入し
てWIDプレーンの必要性を無くす。第３図にはグラフィ
ックス制御プレーンが示されている。好適な実施例で
は、最高５個までのグラフィックス制御プレーンがシス
テム中に存在してもよい。これらのプレーンはダブルバ
ッファにはなっていない。必要なグラフィックス・サブ
システムの機能によりそれ以上又はそれ以下の数のグラ
フィックス制御プレーンをインプリメントすることが可
能である。プレーンの数が少ないシステムでは、インプ
リメントするのも安価になるので、性能／コストのトレ
ードオフが可能である。
WIDプレーンの代わりとなるプレーンのセットを導入し
てWIDプレーンの必要性を無くす。第３図にはグラフィ
ックス制御プレーンが示されている。好適な実施例で
は、最高５個までのグラフィックス制御プレーンがシス
テム中に存在してもよい。これらのプレーンはダブルバ
ッファにはなっていない。必要なグラフィックス・サブ
システムの機能によりそれ以上又はそれ以下の数のグラ
フィックス制御プレーンをインプリメントすることが可
能である。プレーンの数が少ないシステムでは、インプ
リメントするのも安価になるので、性能／コストのトレ
ードオフが可能である。
グラフィックス制御プレーンはフレーム・バッファ
（又はピックスマップ）中のプレーンのサブセットで、
グラフィックス・システムのビデオの機能を制御するの
に用いられる。プレーン（例えば、RGBプレーン）を用
いることはこの分野では周知であるが、本発明が教える
グラフィックス制御プレーンを用いることにより多くの
新しく有用な機能を得ることが出来るのである。
（又はピックスマップ）中のプレーンのサブセットで、
グラフィックス・システムのビデオの機能を制御するの
に用いられる。プレーン（例えば、RGBプレーン）を用
いることはこの分野では周知であるが、本発明が教える
グラフィックス制御プレーンを用いることにより多くの
新しく有用な機能を得ることが出来るのである。
制御プレーンをインプリメントするのに必要なハード
ウエアを第２図に示す。第２図を参照して、グラフィッ
クス・コントローラ212は、画素をフレーム・バッファ2
04に書き込むべきかどうかを決定するためデータ構造
（第６図を参照して後に説明する）を用いる。グラフィ
ックス・コントローラ212は、グラフィックス・サーバ2
06及びディスプレイ・コントローラ202を備える。グラ
フィックス・サーバ（又は、グラフィックス・ソフトウ
エア・ドライバ）206は、ウインドウ・システム・ソフ
トウエアの一部で、多数のクライアント・プロセス210
のタスクを管理するために備えられている。グラフィッ
クス・サーバ206とディスプレイ・コントローラ202の間
の機能の割り振りは、システム要件及び標準的な設計の
慣例に従って行われる。さらに、ディスプレイ・コント
ローラ・メモリ208は、ディスプレイ・コントローラ202
が使用するために設けられている。１つの実施例では、
フレーム・バッファ204に２つのバッファ、即ち、フロ
ント・バッファ204A及びバック・バッファ204Bが設けら
れている。
ウエアを第２図に示す。第２図を参照して、グラフィッ
クス・コントローラ212は、画素をフレーム・バッファ2
04に書き込むべきかどうかを決定するためデータ構造
（第６図を参照して後に説明する）を用いる。グラフィ
ックス・コントローラ212は、グラフィックス・サーバ2
06及びディスプレイ・コントローラ202を備える。グラ
フィックス・サーバ（又は、グラフィックス・ソフトウ
エア・ドライバ）206は、ウインドウ・システム・ソフ
トウエアの一部で、多数のクライアント・プロセス210
のタスクを管理するために備えられている。グラフィッ
クス・サーバ206とディスプレイ・コントローラ202の間
の機能の割り振りは、システム要件及び標準的な設計の
慣例に従って行われる。さらに、ディスプレイ・コント
ローラ・メモリ208は、ディスプレイ・コントローラ202
が使用するために設けられている。１つの実施例では、
フレーム・バッファ204に２つのバッファ、即ち、フロ
ント・バッファ204A及びバック・バッファ204Bが設けら
れている。
ウインドウの隠れた部分の画素を一時的に記憶するた
め補助記憶装置214をオプションとして用いてもよい。
これらの画素は、後刻それらを表示するため呼び出すこ
とが出来る。
め補助記憶装置214をオプションとして用いてもよい。
これらの画素は、後刻それらを表示するため呼び出すこ
とが出来る。
さて第３図を参照して、プレーン322は、ダブル・バ
ッファ・システムで、フロント／バック・バッファ選択
プレーンとして動作する。バッファ選択プレーン322
は、画素がデュアル・バッファ・システムのフロント・
バッファ204Aに属するのか或いはバック・バッファ204B
に属するのかを選択するために用いられる。
ッファ・システムで、フロント／バック・バッファ選択
プレーンとして動作する。バッファ選択プレーン322
は、画素がデュアル・バッファ・システムのフロント・
バッファ204Aに属するのか或いはバック・バッファ204B
に属するのかを選択するために用いられる。
フレーム・バッファで複数の画素形式がサポートされ
ているなら、ビデオモード選択プレーン324が設けら
れ、ビデオモードを示す。ビデオモードは、システム・
モニタ上の画素の表示を制御するフレーム・バッファ20
4の画素の形式を定義する。例えば、ビデオモード選択
プレーン324は、画素が12−ビットのRGBか24−ビットの
RGBかを標示してもよい。８プレーンカラー・インデッ
クス・モードのようなビデオモードを新たに付け加える
には第２のビデオモード選択プレーン326を設けてもよ
い。このように、フレーム・バッファ内の画素の内容を
複数に解釈することが少数のプレーンでインプリメント
可能となる。
ているなら、ビデオモード選択プレーン324が設けら
れ、ビデオモードを示す。ビデオモードは、システム・
モニタ上の画素の表示を制御するフレーム・バッファ20
4の画素の形式を定義する。例えば、ビデオモード選択
プレーン324は、画素が12−ビットのRGBか24−ビットの
RGBかを標示してもよい。８プレーンカラー・インデッ
クス・モードのようなビデオモードを新たに付け加える
には第２のビデオモード選択プレーン326を設けてもよ
い。このように、フレーム・バッファ内の画素の内容を
複数に解釈することが少数のプレーンでインプリメント
可能となる。
書き込み可能プレーン328により、グラフィックス・
システムが複雑な（矩形でない）ウインドウ形状をサポ
ートできるようになる。書き込み可能プレーン328は、
ある画素がウインドウ内にあるか、より具体的には、表
示されるウインドウの一部にあるかどうかを絶えず記録
しておくために備えられている。
システムが複雑な（矩形でない）ウインドウ形状をサポ
ートできるようになる。書き込み可能プレーン328は、
ある画素がウインドウ内にあるか、より具体的には、表
示されるウインドウの一部にあるかどうかを絶えず記録
しておくために備えられている。
画素は一つのオブジェクトに対して１回のみ書き込ま
れるというＸ−ウインドウの要件をサポートするのに１
回書き込みプレーン330を設けてもよい。１回書き込み
プレーン330のあるビットが真とセットされていると、
そのビットに対応する画素は一つのオブジェクトに対し
て１回のみしか書き込まれることはない。
れるというＸ−ウインドウの要件をサポートするのに１
回書き込みプレーン330を設けてもよい。１回書き込み
プレーン330のあるビットが真とセットされていると、
そのビットに対応する画素は一つのオブジェクトに対し
て１回のみしか書き込まれることはない。
表１は、WIDの代わりにグラフィックス制御プレーン
（GCP）を用いるとどれだけの節約が出来るかを示した
ものである。この表では、ハイエンドのシステムとロー
エンドのシステムの２つのタイプに対する節約分が示さ
れている。ハイエンドのシステムについては、どちらの
手法（WID及びGCP）も24個のカラープレーン（赤緑青に
対して各８プレーン）、24個のＺ−バッファプレーン
（３次元グラフィックスに対して256のレベル）、８個
のオーバーレイプレーン、４個のステンシルプレーンを
用いる。本発明のGCPシステムで節約出来るのは、256の
ウインドウをサポートするのにWIDシステムでは８個の
プレーンが必要となるのに引き換え、本発明では単に４
個のプレーン（GCP）でウインドウや第３図を参照して
述べた他のグラフィックス機能を行うことができるとこ
ろにある。GCPが行える全ての機能が必ずしも必要では
ないので、全てのGCPを使用しなければ、それ以上の節
約をすることが出来る。表１に示した例では、システム
は１個のビデオモード選択プレーン326を持つのみであ
る。1280画素x1024画素の表示装置を持つシステムで
は、典型的には、フレーム・バッファは１プレーン当り
2Mビットである。これは、８ビット／バイトのシステム
では、0.25Mバイト／プレーンということである。従っ
て、WIDシステムは17Mバイトのフレーム・バッファ・メ
モリが必要なのに対して、GCPシステムでは単に16Mバイ
トを必要とするだけである。
（GCP）を用いるとどれだけの節約が出来るかを示した
ものである。この表では、ハイエンドのシステムとロー
エンドのシステムの２つのタイプに対する節約分が示さ
れている。ハイエンドのシステムについては、どちらの
手法（WID及びGCP）も24個のカラープレーン（赤緑青に
対して各８プレーン）、24個のＺ−バッファプレーン
（３次元グラフィックスに対して256のレベル）、８個
のオーバーレイプレーン、４個のステンシルプレーンを
用いる。本発明のGCPシステムで節約出来るのは、256の
ウインドウをサポートするのにWIDシステムでは８個の
プレーンが必要となるのに引き換え、本発明では単に４
個のプレーン（GCP）でウインドウや第３図を参照して
述べた他のグラフィックス機能を行うことができるとこ
ろにある。GCPが行える全ての機能が必ずしも必要では
ないので、全てのGCPを使用しなければ、それ以上の節
約をすることが出来る。表１に示した例では、システム
は１個のビデオモード選択プレーン326を持つのみであ
る。1280画素x1024画素の表示装置を持つシステムで
は、典型的には、フレーム・バッファは１プレーン当り
2Mビットである。これは、８ビット／バイトのシステム
では、0.25Mバイト／プレーンということである。従っ
て、WIDシステムは17Mバイトのフレーム・バッファ・メ
モリが必要なのに対して、GCPシステムでは単に16Mバイ
トを必要とするだけである。
ローエンドのシステムでは、もっと著しい節約が可能
となる。双方とも８個のカラープレーンを用いるが、WI
Dシステムでは、256のウインドウを制御するのにやはり
８個のWIDプレーンが必要である。しかし、GCPシステム
は、ビデオ機能を制御するのに単に２プレーンが必要だ
けである。これらは、フレーム・バッファへの画素描画
を制御する書き込み可能プレーン328及びＸ−ウインド
ウの要件を満たすための１回書き込みプレーン330であ
る。Ｘ−ウインドウ・システム以外のシステムでは、１
回書き込みプレーンを省略できるので、さらに0.25Mバ
イトのメモリを節約できる。
となる。双方とも８個のカラープレーンを用いるが、WI
Dシステムでは、256のウインドウを制御するのにやはり
８個のWIDプレーンが必要である。しかし、GCPシステム
は、ビデオ機能を制御するのに単に２プレーンが必要だ
けである。これらは、フレーム・バッファへの画素描画
を制御する書き込み可能プレーン328及びＸ−ウインド
ウの要件を満たすための１回書き込みプレーン330であ
る。Ｘ−ウインドウ・システム以外のシステムでは、１
回書き込みプレーンを省略できるので、さらに0.25Mバ
イトのメモリを節約できる。
グラフィックス制御プレーン、より具体的には、書き
込み可能プレーン328を用いることにより、フレーム・
バッファ・メモリのただ１個のプレーンのコストで、ウ
インドウ・システムに対し大きな柔軟性が得られるので
ある。
込み可能プレーン328を用いることにより、フレーム・
バッファ・メモリのただ１個のプレーンのコストで、ウ
インドウ・システムに対し大きな柔軟性が得られるので
ある。
本発明の書き込み可能プレーン328がもたらす柔軟性
について以下に説明する。書き込み可能プレーン328
は、以下に説明するように、１つ以上の矩形クリッピン
グ境界比較回路と共に用いるのが最善である。
について以下に説明する。書き込み可能プレーン328
は、以下に説明するように、１つ以上の矩形クリッピン
グ境界比較回路と共に用いるのが最善である。
ウインドウ・システムではウインドウ制御のケースと
して５つが挙げられる。本発明はこれらの夫々のケース
を制御することが可能である。これらのケースは以下の
通りである。
して５つが挙げられる。本発明はこれらの夫々のケース
を制御することが可能である。これらのケースは以下の
通りである。
1.第１の矩形ウインドウを描く時他のウインドウが第１
のウインドウのどの部分も隠さない。その例は404、40
6、408、410である。
のウインドウのどの部分も隠さない。その例は404、40
6、408、410である。
2.他のウインドウで隠れた部分がある第１の矩形ウイン
ドウを描画するが、他のウインドウはそれ自身隠れてい
ない。この例としては、ウインドウ412が挙げられる
が、これはウインドウ408により部分的に隠れるが、ウ
インドウ408は他のどのウインドウにも隠されていな
い。
ドウを描画するが、他のウインドウはそれ自身隠れてい
ない。この例としては、ウインドウ412が挙げられる
が、これはウインドウ408により部分的に隠れるが、ウ
インドウ408は他のどのウインドウにも隠されていな
い。
3.他のウインドウで隠れた部分がある第１の矩形ウイン
ドウを描画するが、その他のウインドウ自身部分的に隠
れている。この例はウインドウ402で、これはウインド
ウ410で部分的に隠れているが、ウインドウ410自身ウイ
ンドウ412によって隠れている。
ドウを描画するが、その他のウインドウ自身部分的に隠
れている。この例はウインドウ402で、これはウインド
ウ410で部分的に隠れているが、ウインドウ410自身ウイ
ンドウ412によって隠れている。
4.非矩形の形（例えば、円）のウインドウを隠れがある
なしに拘らず描画する。
なしに拘らず描画する。
5.第１のウインドウが他の重なっているウインドウによ
って完全に隠れている。
って完全に隠れている。
これらのケースを取り扱うために、ウインドウ・デー
タ構造を確立し、重要なウインドウ・パラメータを定義
する。ウインドウ・データ構造に使われる構成の詳細
は、それがウインドウの重なり及びオプションとして書
き込み可能プレーン328の状態を定義するのに十分であ
れば、重要ではない。第６図は、ウインドウに描画する
ためディスプレイ・コントローラ202が用いるウインド
ウ・データ構造600の例を示す。第６図を参照して、ウ
インドウ優先順位データ構造602が各ウインドウの相対
的な優先順位（即ち、あるウインドウが他のウインドウ
に対してその上に来るのか下に来るのかということ）を
リストする。第４図の画面構成の例では、ウインドウ優
先順位データ構造602はウインドウ404がウインドウ402
より高い優先順位を持つことを示している。これは、ウ
インドウ404は、ウインドウ402の上にあり、ウインドウ
404とウインドウ402の共通部分442（両ウインドウが共
存する所）では、ウインドウ404が表示され、ウインド
ウ402は隠れることを意味する。ウインドウ優先順位デ
ータ構造602は、表示領域の全てのウインドウに対して
同様なリストを保守する。ウインドウ優先順位データ構
造602の正確なインプリメンテーションは、表示を制御
する個々のウインドウ・システムの要件に依存する。
タ構造を確立し、重要なウインドウ・パラメータを定義
する。ウインドウ・データ構造に使われる構成の詳細
は、それがウインドウの重なり及びオプションとして書
き込み可能プレーン328の状態を定義するのに十分であ
れば、重要ではない。第６図は、ウインドウに描画する
ためディスプレイ・コントローラ202が用いるウインド
ウ・データ構造600の例を示す。第６図を参照して、ウ
インドウ優先順位データ構造602が各ウインドウの相対
的な優先順位（即ち、あるウインドウが他のウインドウ
に対してその上に来るのか下に来るのかということ）を
リストする。第４図の画面構成の例では、ウインドウ優
先順位データ構造602はウインドウ404がウインドウ402
より高い優先順位を持つことを示している。これは、ウ
インドウ404は、ウインドウ402の上にあり、ウインドウ
404とウインドウ402の共通部分442（両ウインドウが共
存する所）では、ウインドウ404が表示され、ウインド
ウ402は隠れることを意味する。ウインドウ優先順位デ
ータ構造602は、表示領域の全てのウインドウに対して
同様なリストを保守する。ウインドウ優先順位データ構
造602の正確なインプリメンテーションは、表示を制御
する個々のウインドウ・システムの要件に依存する。
ウインドウ定義データ構造604は、ウインドウ・シス
テムによって定義される各ウインドウに対する主要なパ
ラメータを定義する。定義としては、ウインドウ・クリ
ップ境界500、塗りつぶしパターン、文字フォント、各
ウインドウに対するペンやブラシ定義等がある。
テムによって定義される各ウインドウに対する主要なパ
ラメータを定義する。定義としては、ウインドウ・クリ
ップ境界500、塗りつぶしパターン、文字フォント、各
ウインドウに対するペンやブラシ定義等がある。
第５図はウインドウ・クリップ境界500を示す。ウイ
ンドウ・クリップ境界500は、各ウインドウに対する境
界を表示画面の２次元表記で定義する。境界は、Ｘ−mi
n502、Ｙ−min504、Ｘ−max506、Ｙ−max508で定義され
ている。これらの境界は、ウインドウ定義データ構造60
4では一対の２次元座標（X1,Y1）及び（X2,Y2）として
表してもよい、ここでX1はＸ−min502、Y1はＹ−min50
4、X2はＸ−max506、Y2はＹ−max508である。これ以外
に他の従来の表記を用いてもかまわない。ウインドウ・
グリップ境界500は、１つのウインドウのサブセットを
定義するのに用いてもよい。
ンドウ・クリップ境界500は、各ウインドウに対する境
界を表示画面の２次元表記で定義する。境界は、Ｘ−mi
n502、Ｙ−min504、Ｘ−max506、Ｙ−max508で定義され
ている。これらの境界は、ウインドウ定義データ構造60
4では一対の２次元座標（X1,Y1）及び（X2,Y2）として
表してもよい、ここでX1はＸ−min502、Y1はＹ−min50
4、X2はＸ−max506、Y2はＹ−max508である。これ以外
に他の従来の表記を用いてもかまわない。ウインドウ・
グリップ境界500は、１つのウインドウのサブセットを
定義するのに用いてもよい。
ウインドウ共通部分データ構造606は、ディスプレイ
・コントローラが定義する各ウインドウの共通領域を定
義する。共通領域とは、１つのウインドウが少なくも１
つの他のウインドウと重なり合う領域と定義される。共
通領域は、ウインドウ・クリップ境界500を用いて計算
される。例として、共通領域442は、ウインドウ402がウ
インドウ404と重なり合う領域である。第６図は、各ウ
インドウに対してウインドウ共通部分がリストされるよ
うに構成されたウインドウ共通部分データ構造606を示
している。
・コントローラが定義する各ウインドウの共通領域を定
義する。共通領域とは、１つのウインドウが少なくも１
つの他のウインドウと重なり合う領域と定義される。共
通領域は、ウインドウ・クリップ境界500を用いて計算
される。例として、共通領域442は、ウインドウ402がウ
インドウ404と重なり合う領域である。第６図は、各ウ
インドウに対してウインドウ共通部分がリストされるよ
うに構成されたウインドウ共通部分データ構造606を示
している。
共通部分領域データ構造608は、共通部分領域、その
座標、及び重なり合って共通部分領域を形成するウイン
ドウを定義する。例えば、共通部分領域442は、ウイン
ドウ402に対する座標（X1,Y1）及びウインドウ404に対
する座標（X2,Y2）で定義される。共通部分領域データ
構造608は、各共通部分領域の書き込み可能プレーンの
状態も含んでいる。
座標、及び重なり合って共通部分領域を形成するウイン
ドウを定義する。例えば、共通部分領域442は、ウイン
ドウ402に対する座標（X1,Y1）及びウインドウ404に対
する座標（X2,Y2）で定義される。共通部分領域データ
構造608は、各共通部分領域の書き込み可能プレーンの
状態も含んでいる。
第７図は、第１の実施例のフローチャートで、ウイン
ドウ・システムがデータ構造600を用いて、どのように
して、フレーム・バッファ204のウインドウの可視領域
に限って画素を書き込むのかを示している。この実施例
では、ある画素がフレーム・バッファ204に書かれるべ
きかどうかを決定するテストが各ウインドウに対して独
立に存在し、重なり合うウインドウに対し相補的になっ
ている。例えば、ウインドウ402に対するテストは、書
き込み可能ビット（書き込み可能プレーン328内の）が
１の時フレーム・バッファ204に書き込まれ、書き込み
可能ビットが０の時フレーム・バッファに書き込まれな
いというように定義してもよい。この例を用いると、ウ
インドウ402に対して、書き込み可能プレーン328は、ウ
インドウクリッピング境界500で定義されるように領域4
42、444、446、に対して０で、ウインドウ402の他の領
域に対しては１となるだろう。同時にウインドウ410に
対するテストは、書き込み可能ビットが０の時画素はウ
インドウ410に対するフレーム・バッファ204に書き込ま
れ、書き込み可能ビットが１の時書き込まれないという
ように定義されるであろう。従って、ウインドウ410に
関して、領域448に対応する書き込み可能プレーン328の
全てのビットは１であろう。その理由は、領域448はウ
インドウ412により隠されるからである。ウインドウ410
に対してウインドウクリッピング境界500で定義される
書き込み可能プレーンの残りのビットは全て０で、これ
らの画素はフレーム・バッファ204に書き込まれること
になる。
ドウ・システムがデータ構造600を用いて、どのように
して、フレーム・バッファ204のウインドウの可視領域
に限って画素を書き込むのかを示している。この実施例
では、ある画素がフレーム・バッファ204に書かれるべ
きかどうかを決定するテストが各ウインドウに対して独
立に存在し、重なり合うウインドウに対し相補的になっ
ている。例えば、ウインドウ402に対するテストは、書
き込み可能ビット（書き込み可能プレーン328内の）が
１の時フレーム・バッファ204に書き込まれ、書き込み
可能ビットが０の時フレーム・バッファに書き込まれな
いというように定義してもよい。この例を用いると、ウ
インドウ402に対して、書き込み可能プレーン328は、ウ
インドウクリッピング境界500で定義されるように領域4
42、444、446、に対して０で、ウインドウ402の他の領
域に対しては１となるだろう。同時にウインドウ410に
対するテストは、書き込み可能ビットが０の時画素はウ
インドウ410に対するフレーム・バッファ204に書き込ま
れ、書き込み可能ビットが１の時書き込まれないという
ように定義されるであろう。従って、ウインドウ410に
関して、領域448に対応する書き込み可能プレーン328の
全てのビットは１であろう。その理由は、領域448はウ
インドウ412により隠されるからである。ウインドウ410
に対してウインドウクリッピング境界500で定義される
書き込み可能プレーンの残りのビットは全て０で、これ
らの画素はフレーム・バッファ204に書き込まれること
になる。
この例にさらに従うと、ウインドウ402の全ての隠れ
ていない領域は書き込み可能ビットが１で、ウインドウ
402の全ての隠れる領域は書き込み可能ビットが０（隠
れない領域の反対）となる。同時に、ウインドウ410の
全ての隠れない領域は書き込み可能ビット０を持つ。従
って、もしグラフィックス・サーバ206又はディスプレ
イ・コントローラ202が、ウインドウ410に書き込みその
後にウインドウ402に書き込みを行ってフレーム・バッ
ファ204をアップデートするなら、書き込み可能プレー
ンはアップデートする必要はない（ここでウインドウ40
2に対するウインドウ定義が変わっていないと仮定し
て）。これは、領域446の画素位置に対応する書き込み
可能プレーン328の部分にある０は、前の動作では、フ
レーム・バッファ204のその領域に画素を書き込むこと
を許可したからである。現在のオペレーションでは、こ
の同じ０が、フレーム・バッファ204の領域446に画素が
書き込まれるのを禁止している。
ていない領域は書き込み可能ビットが１で、ウインドウ
402の全ての隠れる領域は書き込み可能ビットが０（隠
れない領域の反対）となる。同時に、ウインドウ410の
全ての隠れない領域は書き込み可能ビット０を持つ。従
って、もしグラフィックス・サーバ206又はディスプレ
イ・コントローラ202が、ウインドウ410に書き込みその
後にウインドウ402に書き込みを行ってフレーム・バッ
ファ204をアップデートするなら、書き込み可能プレー
ンはアップデートする必要はない（ここでウインドウ40
2に対するウインドウ定義が変わっていないと仮定し
て）。これは、領域446の画素位置に対応する書き込み
可能プレーン328の部分にある０は、前の動作では、フ
レーム・バッファ204のその領域に画素を書き込むこと
を許可したからである。現在のオペレーションでは、こ
の同じ０が、フレーム・バッファ204の領域446に画素が
書き込まれるのを禁止している。
さて第７図に戻ると、ステップ702で、グラフィック
ス・サーバ206は先ず、オブジェクトを描画しようとす
るウインドウが完全に隠されているかどうかを決定す
る。もしそのウインドウが完全に隠れていれば、ウイン
ドウが見えないのでそのオペレーションは終了し全ての
描画操作は破棄される。この描画破棄は色々な方法で行
うことが出来るが、最も簡単な方法は、データをフレー
ム・バッファ204に渡さないことである。もしウインド
ウが全部隠れていなければ、オペレーションはステップ
704に続く。この決定はデータ構造600を用いて行われ
る。
ス・サーバ206は先ず、オブジェクトを描画しようとす
るウインドウが完全に隠されているかどうかを決定す
る。もしそのウインドウが完全に隠れていれば、ウイン
ドウが見えないのでそのオペレーションは終了し全ての
描画操作は破棄される。この描画破棄は色々な方法で行
うことが出来るが、最も簡単な方法は、データをフレー
ム・バッファ204に渡さないことである。もしウインド
ウが全部隠れていなければ、オペレーションはステップ
704に続く。この決定はデータ構造600を用いて行われ
る。
ステップ704では、グラフィックス・サーバ206は、デ
ータ構造600を用い、そのウインドウが部分的に隠れて
いるかどうかを決定する。ステップ704でウインドウが
部分的に隠れていなければ（そして、ステップ702で決
定されたように完全に隠れていない）、そのウインドウ
には隠れた部分が全くないことになる。これが上述した
最初のケースである。この場合にはオペレーションはス
テップ706に進む。
ータ構造600を用い、そのウインドウが部分的に隠れて
いるかどうかを決定する。ステップ704でウインドウが
部分的に隠れていなければ（そして、ステップ702で決
定されたように完全に隠れていない）、そのウインドウ
には隠れた部分が全くないことになる。これが上述した
最初のケースである。この場合にはオペレーションはス
テップ706に進む。
ステップ706では、ウインドウは隠れていないので、
そのウインドウとして定義されたウインドウ・クリップ
境界500に対して各位置の画素をテストすることによっ
てウインドウクリッピングを行う。もし画素がその境界
500の外にあれば、フレーム・バッファ204に書き込まれ
ない。もしそれが境界内に入れば、そのウインドウは他
のウインドウに隠れていないので間違いなく書き込まれ
る。従って、この場合、書き込み可能プレーン328は必
要でなく、フレーム・バッファ204への書き込み制御は
不可の状態にされている。
そのウインドウとして定義されたウインドウ・クリップ
境界500に対して各位置の画素をテストすることによっ
てウインドウクリッピングを行う。もし画素がその境界
500の外にあれば、フレーム・バッファ204に書き込まれ
ない。もしそれが境界内に入れば、そのウインドウは他
のウインドウに隠れていないので間違いなく書き込まれ
る。従って、この場合、書き込み可能プレーン328は必
要でなく、フレーム・バッファ204への書き込み制御は
不可の状態にされている。
ステップ708では、実行中のウインドウの可視部分
（この場合全ての部分が見えている）の画素は、前のス
テップで定義された制約の集合を用いてフレーム・バッ
ファ204に書き込まれる。
（この場合全ての部分が見えている）の画素は、前のス
テップで定義された制約の集合を用いてフレーム・バッ
ファ204に書き込まれる。
しかし、ステップ704で、ウインドウが部分的に隠れ
ていれば、ステップ710に進む。これは上述した第２、
第３のケースにあたる。ステップ710では、グラフィッ
クス・サーバ206は、最後に行ったオペレーションに比
べてウインドウの定義が変わっているかどうかを決定す
る。ウインドウの定義が変更されるのは、ウインドウが
削除されたり、大きさが変更されたり、その場所が変更
されたり、新しいウインドウが作られたり（そして当ウ
インドウと重なり合う）、さもなければ、ウインドウ間
の上下関係（即ち、相対的な優先順位）が変更されたり
する時である。もしウインドウの定義が変更されていれ
ば、ステップ712に進む。もしウインドウの定義が変更
されていなければ、ステップ714に進む。ウインドウの
定義に変更があれば、データ構造600も変更されること
になる。
ていれば、ステップ710に進む。これは上述した第２、
第３のケースにあたる。ステップ710では、グラフィッ
クス・サーバ206は、最後に行ったオペレーションに比
べてウインドウの定義が変わっているかどうかを決定す
る。ウインドウの定義が変更されるのは、ウインドウが
削除されたり、大きさが変更されたり、その場所が変更
されたり、新しいウインドウが作られたり（そして当ウ
インドウと重なり合う）、さもなければ、ウインドウ間
の上下関係（即ち、相対的な優先順位）が変更されたり
する時である。もしウインドウの定義が変更されていれ
ば、ステップ712に進む。もしウインドウの定義が変更
されていなければ、ステップ714に進む。ウインドウの
定義に変更があれば、データ構造600も変更されること
になる。
ステップ712では、グラフィックス・サーバ206は書き
込み可能プレーン328をアップデートし、そのウインド
ウの隠れていない部分に対応する書き込み可能プレーン
のビット全てが、フレーム・バッファに画素を書き込む
ことを示すようにする（例えば、上の例では、ウインド
ウ402の隠れていない部分に対しては１で、ウインドウ4
04の隠れていない部分に対しては０となる）。
込み可能プレーン328をアップデートし、そのウインド
ウの隠れていない部分に対応する書き込み可能プレーン
のビット全てが、フレーム・バッファに画素を書き込む
ことを示すようにする（例えば、上の例では、ウインド
ウ402の隠れていない部分に対しては１で、ウインドウ4
04の隠れていない部分に対しては０となる）。
ステップ714では、各ウインドウに対するハードウエ
ア書き込み可能テストを、各ウインドウに対して選ばれ
た取り決めに対応するようにセットする。テストは、ウ
インドウの隠れていない部分に対して真になるようにセ
ットされる。例えば、ウインドウ402の境界内の書き込
み可能328に１が存在することは、ウインドウ402の情報
がフレーム・バッファ204に書き込まれることを示す。
従って、書き込み可能プレーン328に１が出てくると、
ウインドウ402に対するテストは真となる。
ア書き込み可能テストを、各ウインドウに対して選ばれ
た取り決めに対応するようにセットする。テストは、ウ
インドウの隠れていない部分に対して真になるようにセ
ットされる。例えば、ウインドウ402の境界内の書き込
み可能328に１が存在することは、ウインドウ402の情報
がフレーム・バッファ204に書き込まれることを示す。
従って、書き込み可能プレーン328に１が出てくると、
ウインドウ402に対するテストは真となる。
ステップ716では、グラフィックス・サーバ206は、ウ
インドウ・クリップ境界500及び書き込み可能プレーン3
28（ウインドウ・クリップ境界500内）を用い、画素を
フレーム・バッファ204に書き込むかどうかを決定す
る。もしこれらのテストが、画素が隠れた領域に入るた
めウインドウに書き込まれないことを示すと、画素はそ
の代わり補助記憶装置214に書き込まれる。
インドウ・クリップ境界500及び書き込み可能プレーン3
28（ウインドウ・クリップ境界500内）を用い、画素を
フレーム・バッファ204に書き込むかどうかを決定す
る。もしこれらのテストが、画素が隠れた領域に入るた
めウインドウに書き込まれないことを示すと、画素はそ
の代わり補助記憶装置214に書き込まれる。
ステップ708では、画像がウインドウに描画される。
このステップで、実行中のウインドウで可視部分内の画
素がフレーム・バッファ204に書き込まれる。
このステップで、実行中のウインドウで可視部分内の画
素がフレーム・バッファ204に書き込まれる。
この実施例において２つの重要な点がある。第１に、
もしウインドウが全く隠れていないか又は完全に隠れて
いる時には書き込み可能プレーンは不要なことである。
全てのグラフィックス・サーバ206が行わなければなら
ないことは、そのウインドウの画素を、そのウインドウ
に対するウインドウ・クリップ境界500によって決めら
れる領域に書き込むことである。第２に、部分的に隠れ
たウインドウに対して、もしウインドウの定義が変化し
ていなければ、オペレーションとオペレーションの間に
書き込み制御プレーンをアップデートしなくてもよいこ
とである。隠れた領域と隠れていない領域は相補的に定
義されているので、もしディスプレイ・コントローラが
一つのウインドウを描画し、引き続き他のものへ移って
も、書き込み可能プレーン328はそのまま同じである。
変化するのは、画素をフレーム・バッファ204に書き込
むかどうかを決定するのに用いられるハードウエア・テ
ストだけである（即ち、０の時書き込みという代わりに
１なら書き込みとする）。これにより書き込み可能プレ
ーン328をアップデートしなければならないオペレーシ
ョンを省くことが出来る。
もしウインドウが全く隠れていないか又は完全に隠れて
いる時には書き込み可能プレーンは不要なことである。
全てのグラフィックス・サーバ206が行わなければなら
ないことは、そのウインドウの画素を、そのウインドウ
に対するウインドウ・クリップ境界500によって決めら
れる領域に書き込むことである。第２に、部分的に隠れ
たウインドウに対して、もしウインドウの定義が変化し
ていなければ、オペレーションとオペレーションの間に
書き込み制御プレーンをアップデートしなくてもよいこ
とである。隠れた領域と隠れていない領域は相補的に定
義されているので、もしディスプレイ・コントローラが
一つのウインドウを描画し、引き続き他のものへ移って
も、書き込み可能プレーン328はそのまま同じである。
変化するのは、画素をフレーム・バッファ204に書き込
むかどうかを決定するのに用いられるハードウエア・テ
ストだけである（即ち、０の時書き込みという代わりに
１なら書き込みとする）。これにより書き込み可能プレ
ーン328をアップデートしなければならないオペレーシ
ョンを省くことが出来る。
第９図は、第４図に示したウインドウに対する書き込
み可能プレーン328のビットを第１の実施例に従って表
示した例である。ウインドウ402においては、１は隠れ
ていない部分を示し、０は実行中の部分を表している。
み可能プレーン328のビットを第１の実施例に従って表
示した例である。ウインドウ402においては、１は隠れ
ていない部分を示し、０は実行中の部分を表している。
次の実施例では書き込み可能プレーン328が用いる取
り決めは全てのウインドウに関して共通である。例え
ば、１はどのウインドウについても隠れていない領域を
表し、０はどのウインドウに対しても隠された領域を表
す。この実施例では、もしディスプレイ・コントローラ
が第１のオペレーションで第１のウインドウに書き込み
を行い、第２のオペレーションで、それに重なり合った
第２のウインドウに書き込みを行う時には、書き込み制
御プレーン328をアップデートしなくてはならない。
り決めは全てのウインドウに関して共通である。例え
ば、１はどのウインドウについても隠れていない領域を
表し、０はどのウインドウに対しても隠された領域を表
す。この実施例では、もしディスプレイ・コントローラ
が第１のオペレーションで第１のウインドウに書き込み
を行い、第２のオペレーションで、それに重なり合った
第２のウインドウに書き込みを行う時には、書き込み制
御プレーン328をアップデートしなくてはならない。
例えば、グラフィックス・サーバ206がウインドウ404
に書き込むと仮定しよう。このオペレーションを可能に
するには、ウインドウ404に対するウインドウ・クリッ
プ境界500内の書き込み可能プレーン328の全てのビット
を１にセットしなくてはならない。もしディスプレイ・
コントローラ202が次にウインドウ402に書き込みたけれ
ば、領域442（ここではウインドウ404は402の上になっ
ている）に対応する書き込み可能プレーン328のビット
は１（前のオペレーションでは書き込みに使われた）か
ら０に変更されなくてはならない。従って、第２の実施
例では、ウインドウの定義が変わっても変わらなくても
ステップ712を実行しなくてはならない。
に書き込むと仮定しよう。このオペレーションを可能に
するには、ウインドウ404に対するウインドウ・クリッ
プ境界500内の書き込み可能プレーン328の全てのビット
を１にセットしなくてはならない。もしディスプレイ・
コントローラ202が次にウインドウ402に書き込みたけれ
ば、領域442（ここではウインドウ404は402の上になっ
ている）に対応する書き込み可能プレーン328のビット
は１（前のオペレーションでは書き込みに使われた）か
ら０に変更されなくてはならない。従って、第２の実施
例では、ウインドウの定義が変わっても変わらなくても
ステップ712を実行しなくてはならない。
第10図は、本発明の第２の実施例による方法を示すフ
ローチャートである。グラフィックス・サーバ206は、
ステップ1002で、ウインドウが完全に隠れているかどう
かを決定する。この決定はデータ構造600に基づいて行
われる。もしウインドウが完全に隠れていれば、オペレ
ーションは終了する。グラフィックス・サーバ206は、
ウインドウが部分的に隠れているかどうかをステップ10
04で決定する。もしウインドウが部分的に隠れていなけ
れば（即ち、全く隠れていなければ）、ディスプレイ・
コントローラ202は、ステップ1006でウインドウ・クリ
ップ境界500を用いて画素をフレーム・バッファ204に書
き込むかどうかを決定する。ディスプレイ・コントロー
ラは、ステップ1012で、適当な画素をフレーム・バッフ
ァ204に書き込む。これらの画素は実行中のウインドウ
の可視部分に入る。
ローチャートである。グラフィックス・サーバ206は、
ステップ1002で、ウインドウが完全に隠れているかどう
かを決定する。この決定はデータ構造600に基づいて行
われる。もしウインドウが完全に隠れていれば、オペレ
ーションは終了する。グラフィックス・サーバ206は、
ウインドウが部分的に隠れているかどうかをステップ10
04で決定する。もしウインドウが部分的に隠れていなけ
れば（即ち、全く隠れていなければ）、ディスプレイ・
コントローラ202は、ステップ1006でウインドウ・クリ
ップ境界500を用いて画素をフレーム・バッファ204に書
き込むかどうかを決定する。ディスプレイ・コントロー
ラは、ステップ1012で、適当な画素をフレーム・バッフ
ァ204に書き込む。これらの画素は実行中のウインドウ
の可視部分に入る。
それに反して、ステップ1004でウインドウが部分的に
隠れていれば、グラフィックス・サーバ206は書き込み
可能プレーン328をアップデートし（ステップ1008）書
き込みをそのウインドウの隠れていない領域のみに許可
する。ステップ1010で、グラフィックス・サーバ206は
この書き込み可能プレーン及びウインドウ・クリップ境
界を用い、画素をフレーム・バッファ204に書き込むか
どうかを決定する。ステップ1012で、実行中のウインド
ウの可視部分の画素をフレーム・バッファ204に書き込
む。オプションで、そのウインドウの隠れた領域の画素
は補助記憶装置214に書き込んでもよい。
隠れていれば、グラフィックス・サーバ206は書き込み
可能プレーン328をアップデートし（ステップ1008）書
き込みをそのウインドウの隠れていない領域のみに許可
する。ステップ1010で、グラフィックス・サーバ206は
この書き込み可能プレーン及びウインドウ・クリップ境
界を用い、画素をフレーム・バッファ204に書き込むか
どうかを決定する。ステップ1012で、実行中のウインド
ウの可視部分の画素をフレーム・バッファ204に書き込
む。オプションで、そのウインドウの隠れた領域の画素
は補助記憶装置214に書き込んでもよい。
本発明では書き込み可能プレーン328は、非矩形のウ
インドウを持つウインドウ・アプリケーションをサポー
トすることが出来る。第11図は、非矩形のウインドウで
の描画をサポートするのに書き込み可能プレーン328を
用いることを示すフローチャートである。非矩形ウイン
ドウはウインドウ・クリップ境界500では完全に定義す
ることができないので、非矩形ウインドウに描画するに
は必ず書き込み可能プレーン328を用いなくてはならな
い。その結果、ウインドウが部分的に隠れているかどう
かは問題にならない（第７図のステップ704）。第11図
は従って、第７図のサブセット（即ち、ステップ704及
び706がない）である。
インドウを持つウインドウ・アプリケーションをサポー
トすることが出来る。第11図は、非矩形のウインドウで
の描画をサポートするのに書き込み可能プレーン328を
用いることを示すフローチャートである。非矩形ウイン
ドウはウインドウ・クリップ境界500では完全に定義す
ることができないので、非矩形ウインドウに描画するに
は必ず書き込み可能プレーン328を用いなくてはならな
い。その結果、ウインドウが部分的に隠れているかどう
かは問題にならない（第７図のステップ704）。第11図
は従って、第７図のサブセット（即ち、ステップ704及
び706がない）である。
さて第11図を参照して、非矩形ウインドウをサポート
するオペレーションを以下に説明する。もしウインドウ
が完全に隠れていれば、ステップ1102に示すように、オ
ペレーションは終了し、画素はフレーム・バッファ204
に書き込まれない。もしウインドウが完全に隠れている
のでなければ、隠れていない領域の画素はフレーム・バ
ッファ204に書き込まれる。第11図の残りのステップ
は、画素が隠れていない領域にあるかどうかを決定する
ためのものである。
するオペレーションを以下に説明する。もしウインドウ
が完全に隠れていれば、ステップ1102に示すように、オ
ペレーションは終了し、画素はフレーム・バッファ204
に書き込まれない。もしウインドウが完全に隠れている
のでなければ、隠れていない領域の画素はフレーム・バ
ッファ204に書き込まれる。第11図の残りのステップ
は、画素が隠れていない領域にあるかどうかを決定する
ためのものである。
ステップ1110では、グラフィックス・サーバ206がウ
インドウの定義が変更されたかどうかを決定する。この
決定は、データ構造600に基づいて行われる。もしウイ
ンドウの定義が最後のオペレーション以降変更されてい
るなら、ステップ1112で共通領域をアップデートし、書
き込み可能プレーンがウインドウのどの部分が隠れてい
ないかを正しく示すようにする。ステップ1114では、ハ
ードウエアの書き込み可能テストを、隠れていない領域
に対しては書き込みを許可し、隠れる領域に対しては書
き込みを抑止するようにセットする。
インドウの定義が変更されたかどうかを決定する。この
決定は、データ構造600に基づいて行われる。もしウイ
ンドウの定義が最後のオペレーション以降変更されてい
るなら、ステップ1112で共通領域をアップデートし、書
き込み可能プレーンがウインドウのどの部分が隠れてい
ないかを正しく示すようにする。ステップ1114では、ハ
ードウエアの書き込み可能テストを、隠れていない領域
に対しては書き込みを許可し、隠れる領域に対しては書
き込みを抑止するようにセットする。
ステップ1116では、書き込み可能プレーンのウインド
ウクリッピング境界を用いて画素をフレーム・バッファ
204に書き込むかどうかを決定する。ステップ1108で
は、先のステップで確立された制約を用いて、実行中の
ウインドウの可視部分の画素がフレーム・バッファ204
に書き込まれる。オプションで、隠れている画素は補助
記憶装置210に書き込んでもよい。
ウクリッピング境界を用いて画素をフレーム・バッファ
204に書き込むかどうかを決定する。ステップ1108で
は、先のステップで確立された制約を用いて、実行中の
ウインドウの可視部分の画素がフレーム・バッファ204
に書き込まれる。オプションで、隠れている画素は補助
記憶装置210に書き込んでもよい。
第７、10、11図はグラフィックス・サーバ206がオペ
レーションを行うとして説明しているが、グラフィック
ス・サーバの代わりに、ディスプレイ・コントローラ20
2を用いてもよい。
レーションを行うとして説明しているが、グラフィック
ス・サーバの代わりに、ディスプレイ・コントローラ20
2を用いてもよい。
当業者には、本発明を、多重ウインドウ・クリップ矩
形を用いるために拡張できることが容易に分かるであろ
う。
形を用いるために拡張できることが容易に分かるであろ
う。
本発明の多くの実施例について上に述べたが、それら
は例として挙げられたものであり、限度を示すためのも
のではない。従って、本発明の広さと範囲は、上述した
いかなる典型的な実施例もその限界を与えるものではな
く、以下の特許請求範囲及びそれと同等のものに従って
のみ定義される。
は例として挙げられたものであり、限度を示すためのも
のではない。従って、本発明の広さと範囲は、上述した
いかなる典型的な実施例もその限界を与えるものではな
く、以下の特許請求範囲及びそれと同等のものに従って
のみ定義される。
─────────────────────────────────────────────────────
フロントページの続き
(58)調査した分野(Int.Cl.7，ＤＢ名)
G09G 5/14
G09G 5/393
G06F 3/14
Claims (36)
- 【請求項１】複数ウインドウを表示するシステムにおけ
るウインドウ内の描画を制御する方法であって、 該システムは、 表示装置に転送されるデータを保持するフレーム・バッ
ファと、 画素を前記フレーム・バッファに書き込むかどうかを決
定するために用いる書き込み可能プレーンと、 各ウインドウの相対的な優先順位を定めたウインドウ優
先順位情報、各ウインドウに対する境界を定義するウイ
ンドウ・クリップ定義情報、ウインドウシステムによっ
て定義される各ウインドウに対するパラメータ等を定義
するウインドウ定義情報、ウインドウの共通部分領域、
その座標、及び重なり合って共通部分領域を形成するウ
インドウを定義する共通部分領域情報からなる構造を有
するデータと を備え、 該方法は、 （ａ）前記構造のデータをチェックすることにより、そ
の前のオペレーション以降、ウインドウの定義が変更さ
れたかどうかを判定する第１のステップと、 （ｂ）前記第１のステップでウインドウの定義が変更さ
れたと判定された場合には、書き込み可能プレーンをア
ップデートして、そのウインドウの隠れていない部分に
対応する書き込み可能プレーンのビット全てが、フレー
ム・バッファに画素を書き込むことを示すように設定す
る第２のステップと、 （ｃ）各ウインドウに対する、画素がフレーム・バッフ
ァに書かれるべきか否かを決定する書き込み可能テスト
を、当該書き込み可能テストの結果がウインドウの隠れ
ていない部分に対して真となるように行う第３のステッ
プと、 （ｄ）前記書き込み可能テストによる、画素がウインド
ウの隠れていない部分であるか否かという結果、及び前
記ウインドウ・クリップ定義情報に基づいて、フレーム
・バッファに書き込むかどうかを決定する第４のステッ
プと から成ることを特徴とする描画制御方法。 - 【請求項２】請求項１記載の描画制御方法であって、前
記第４のステップでフレーム・バッファに書き込むと決
定された画素を、フレーム・バッファに書き込む第５の
ステップを更に備えることを特徴とする描画制御方法。 - 【請求項３】請求項１記載の描画制御方法であって、前
記第１のステップの前に、描画すべきウインドウが完全
に隠れているかどうかを、前記データの共通部分領域情
報、及びウインドウ優先順位情報に基づいて決定するス
テップと、 当該ステップによりウインドウが完全に隠れている場合
には、このウインドウに対するオペレーションを終了す
るステップと を更に備えることを特徴とする描画制御方法。 - 【請求項４】請求項１記載の描画制御方法であって、 （ｅ）前記第１のステップの前に、描画すべきウインド
ウが全く隠れていないかどうかを判定する第６のステッ
プと、 （ｆ）前記第６のステップにより、ウインドウが全く隠
れていない場合には、当該ウインドウのウインドウ・ク
リップ定義情報のみを用いて前記ウインドウをフレーム
・バッファに描画する第７のステップと を更に備え、 前記第６のステップで描画すべきウインドウが部分的に
隠れている場合には前記第１のステップを行う ことを特徴とする描画制御方法。 - 【請求項５】請求項４記載の描画制御方法であって、前
記第６のステップは、 ｉ）描画すべき前記ウインドウが完全に隠れているかど
うかを判定するステップと、 ii）描画すべき前記ウインドウが部分的に隠れているか
どうかを判定するステップと、 を備えることを特徴とする描画制御方法。 - 【請求項６】複数ウインドウを表示するシステムにおけ
るウインドウ内の描画を制御する方法であって、 該システムは、 表示装置に転送されるデータを保持するフレーム・バッ
ファと、 画素を前記フレーム・バッファに書き込むかどうかを決
定するために用いる書き込み可能プレーンと、 各ウインドウの相対的な優先順位を定めたウインドウ優
先順位情報、各ウインドウに対する境界を定義するウイ
ンドウ・クリップ定義情報、ウインドウシステムによっ
て定義される各ウインドウに対するパラメータ等を定義
するウインドウ定義情報、ウインドウの共通部分領域、
その座標、及び重なり合って共通部分領域と形成するウ
インドウを定義する共通部分領域情報からなる構造を有
するデータと を備え、 該方法は、 （ａ）前記構造のデータに基づいて、描画すべきウイン
ドウが部分的に隠れているか否かを判定する第１のステ
ップと、 （ｂ）前記第１のステップで、描画すべきウインドウ部
分的に隠れていると判定された場合、書き込み可能プレ
ーンを、当該ウインドウの隠れていない領域のみに書き
込みを許可するようにアップデートする第２のステップ
と、 （ｃ）前記第２のステップでアップデートされた書き込
み可能プレーンと、前記ウインドウ・クリップ定義情報
に基づいて、画素をフレーム・バッファに書き込むかど
うかを決定する第３のステップと を備えることを特徴とする描画制御方法。 - 【請求項７】請求項６記載の描画制御方法であって、前
記第３のステップでフレーム・バッファに書き込むと決
定された画素を、フレーム・バッファに書き込む第４の
ステップを更に備えることを特徴とする描画制御方法。 - 【請求項８】請求項６記載の描画制御方法であって、前
記第１のステップで、描画すべきウインドウが部分的に
隠れていないと判定された場合、ウインドウ・クリップ
定義情報に基づいて、描画すべきウインドウの画素をフ
レーム・バッファに書き込むかどうかを決定する第５の
ステップ を備えることを特徴とする描画制御方法。 - 【請求項９】請求項８記載の描画制御方法であって、前
記第５のステップでフレーム・バッファに書き込むと決
定された画素を、フレーム・バッファに書き込むステッ
プを更に備えることを特徴とする描画制御方法。 - 【請求項１０】請求項６記載の描画制御方法であって、
前記第１のステップの前に、描画すべきウインドウが完
全に隠れているかどうかを、前記データの共通部分領域
情報、及びウインドウ優先順位情報に基づいて決定する
ステップを更に備え、当該ステップにより当該ウインド
ウが完全に隠れていないと判定された場合には前記第１
のステップを行う ことを特徴とする描画制御方法。 - 【請求項１１】複数ウインドウを表示するシステムにお
けるウインドウ内の描画を制御する方法であって、 該システムは、 表示装置に転送されるデータを保持するフレーム・バッ
ファと、 画素を前記フレーム・バッファに書き込むかどうかを決
定するために用いる書き込み可能プレーンと、 各ウインドウの相対的な優先順位を定めたウインドウ優
先順位情報、各ウインドウに対する境界を定義するウイ
ンドウ・クリップ定義情報、ウインドウシステムによっ
て定義される各ウインドウに対するパラメータ等を定義
するウインドウ定義情報、ウインドウの共通部分領域、
その座標、及び重なり合って共通部分領域を形成するウ
インドウを定義する共通部分領域情報からなる構造を有
するデータと を備え、 該方法は、 （ａ）前記構造のデータに基づいて、その前のオペレー
ション以降、ウインドウの定義が変更されたかどうかを
判定する第１のステップと、 （ｂ）前記第１のステップでウインドウの定義が変更さ
れたと判定された場合には、前記共通部分領域情報をア
ップデートして、書き込み可能プレーンがウインドウの
どの部分が隠れていないかを正しく示すようにする第２
のステップと、 （ｃ）画素がフレーム・バッファに書かれるべきか否か
を決定する書き込み可能テストを、ウインドウの隠れて
いない領域に対しては書き込みを許可し、隠れる領域に
対しては書き込みを抑止するように行う第３のステップ
と、 （ｄ）前記書き込み可能テストによる、画素がウインド
ウの隠れていない領域か、隠れている領域かという結
果、及び前記ウインドウ・クリップ定義情報に基づい
て、フレーム・バッファに書き込むかどうかを決定する
第４のステップと から成ることを特徴とする描画制御方法。 - 【請求項１２】請求項11記載の描画制御方法であって、
前記第４のステップでフレーム・バッファに書き込むと
決定された画素を、フレーム・バッファに書き込む第５
のステップを更に備えることを特徴とする描画制御方
法。 - 【請求項１３】請求項11記載の描画制御方法であって、
前記第１のステップの前に、描画するべきウインドウが
完全に隠れているかどうかを、前記データの共通部分領
域情報、及びウインドウ優先順位情報に基づいて決定す
るステップを更に備え、当該ステップにより、当該ウイ
ンドウが完全に隠れていない場合には前記第１のステッ
プを行う ことを特徴とする描画制御方法。 - 【請求項１４】複数のウインドウの表示を制御するシス
テムであって、該システムは、 （ａ）表示装置に転送されるデータを保持するフレーム
・バッファであって、そのサブセットとして、画素を前
記フレーム・バッファに書き込むかどうかを決定するた
めに用いる書き込み可能プレーンを少なくとも含むグラ
フィックス制御プレーンを有するフレーム・バッファ
と、 （ｂ）各ウインドウの相対的な優先順位を定めたウイン
ドウ優先順位情報、各ウインドウに対する境界を定義す
るウインドウ・クリップ定義情報、ウインドウシステム
によって定義される各ウインドウに対するパラメータ等
を定義するウインドウ定義情報、ウインドウの共通部分
領域、その座標、及び重なり合って共通部分領域を形成
するウインドウを定義する共通部分領域情報からなる構
造を有するデータと、 （ｃ）前記構造のデータをチェックすることにより、そ
の前のオペレーション以降、ウインドウの定義が変更さ
れたかどうかを判定する第１の判定手段と、 （ｄ）前記第１の判定手段でウインドウの定義が変更さ
れたと判定された場合には、書き込み可能プレーンをア
ップデートして、そのウインドウの隠れていない部分に
対応する書き込み可能プレーンのビット全てが、フレー
ム・バッファに画素を書き込むことを示すように設定す
るアップデート手段と、 （ｅ）各ウインドウに対して、画素がフレーム・バッフ
ァに書かれるべきか否かを決定する書き込み可能テスト
手段であって、当該書き込み可能テスト手段によるテス
トの結果がウインドウの隠れていない部分に対して真と
なるように行うテスト手段と、 （ｆ）前記テスト手段の書き込み可能テストによる、画
素がウインドウの隠れていない部分であるか否かという
結果、及び前記ウインドウ・クリップ定義情報に基づい
て、フレーム・バッファに書き込むかどうかを決定する
手段と を備えることを特徴とするシステム。 - 【請求項１５】請求項14記載のシステムであって、 前記第１の判定手段によるウインドウの定義の変更の有
無を判定する前に、描画すべきウインドウが完全に隠れ
ているかどうかを、前記構造のデータの共通部分領域情
報及びウインドウ優先順位情報に基づいて判定する第２
の判定手段と、 前記第２の判定手段によってウインドウが完全に隠れて
いると判定された場合に、そのウインドウに対するオペ
レーションを終了する手段と を更に備えることを特徴とするシステム。 - 【請求項１６】請求項14記載のシステムであって、 前記第１の判定手段によるウインドウの定義の変更の有
無を判定する前に、描画すべきウインドウが完全に隠れ
ていないかどうかを、前記構造のデータの共通部分領域
情報及びウインドウ優先順位情報に基づいて判定する第
２の判定手段と、 前記第２の判定手段によりウインドウが全く隠れていな
いと判定された場合には、該ウインドウのウインドウ・
クリップ定義情報のみを用いて前記ウインドウをフレー
ム・バッファに描画する描画手段とを更に備え、 前記判定手段で描画すべきウインドウが部分的に隠れて
いると判定された場合には前記第１の判定手段によるウ
インドウの定義の変更の有無を判定する ことを特徴とするシステム。 - 【請求項１７】請求項16記載のシステムであって、 前記第２の判定手段は、 ｉ）描画すべき前記ウインドウが完全に隠れているかど
うかを判定する第３の判定手段と、 ii）描画すべき前記ウインドウが部分的に隠れているか
どうかを判定する第４の判定手段と を備えることを特徴とするシステム。 - 【請求項１８】請求項14記載のシステムであって、 前記フレーム・バッファは、 第１のフレーム・バッファと、 前記第１のフレーム・バッファとダブル・バッファリン
グするための第２のフレーム・バッファと で構成され、且つ、 前記グラフィックス制御プレーンには、画素を前記第１
のフレーム・バッファに書き込むか、前記第２のフレー
ム・バッファに書き込むかを選択するためのフロント／
バック・バッファ選択プレーンを 備えることを特徴とするシステム。 - 【請求項１９】請求項14記載のシステムであって、 前記グラフィックス制御プレーンには、ビデオモードを
示すための少なくも１つのビデオモード選択プレーンを 更に備えることを特徴とするシステム。 - 【請求項２０】請求項14記載のシステムであって、 前記グラフィックス制御プレーンには、画素が１つのオ
ブジェクト当たり１回だけ書き込まれるかどうかを示す
ために１回書き込みプレーンを 更に備えることを特徴とするシステム。 - 【請求項２１】請求項14記載のシステムであって、 実行中のウインドウの隠れた領域内に入る少なくも１つ
の画素を格納するための補助記憶装置を 更に備えることを特徴とするシステム。 - 【請求項２２】複数のウインドウの表示を制御するシス
テムであって、該システムは、 （ａ）表示装置に転送されるデータを保持するフレーム
・バッファであって、そのサブセットとして、画素を前
記フレーム・バッファに書き込むかどうかを決定するた
めに用いる書き込み可能プレーンを少なくとも含むグラ
フィックス制御プレーンを有するフレーム・バッファ
と、 （ｂ）各ウインドウの相対的な優先順位を定めたウイン
ドウ優先順位情報、各ウインドウに対する境界を定義す
るウインドウ・クリップ定義情報、ウインドウシステム
によって定義される各ウインドウに対するパラメータ等
を定義するウインドウ定義情報、ウインドウの共通部分
領域、その座標、及び重なり合って共通部分領域を形成
するウインドウを定義する共通部分領域情報からなる構
造を有するデータと、 （ｃ）前記構造のデータに基づいて、描画すべきウイン
ドウが部分的に隠れているか否かを判定する第１の判定
手段と、 （ｄ）前記第１の判定手段で、描画すべきウインドウが
部分的に隠れていると判定された場合、書き込み可能プ
レーンを、当該ウインドウの隠れていない領域のみに書
き込みを許可するようにアップデートするアップデート
手段と、 （ｅ）前記アップデート手段でアップデートされた書き
込み可能プレーンと、前記ウインドウ・クリップ定義情
報に基づいて、画素をフレーム・バッファに書き込むか
どうかを決定する決定手段と を備えることを特徴とするシステム。 - 【請求項２３】請求項22記載のシステムであって、 前記決定手段でフレーム・バッファに書き込むと決定さ
れた画素を、フレーム・バッファに書き込む描画手段 を更に備えることを特徴とするシステム。 - 【請求項２４】請求項22記載のシステムであって、 前記第１の判定手段で描画すべきウインドウが部分的に
隠れていない判定された場合、ウインドウ・クリップ定
義情報に基づいて、描画すべきウインドウの画素をフレ
ーム・バッファに書き込むかどうかを決定する第２の判
定手段と、 前記第２の判定手段でフレーム・バッファに書き込むと
決定された画素を、フレーム・バッファに書き込む描画
手段と を備えることを特徴とするシステム。 - 【請求項２５】請求項22記載のシステムであって、 前記第１の判定手段による描画すべきウインドウが部分
的に隠れているか否かの判定の前に、描画すべきウイン
ドウが完全に隠れているかどうかを、前記データの共通
部分領域情報、及びウインドウ優先順位情報に基づいて
決定する第３の判定手段を更に備え、当該第３の判定手
段により当該ウインドウが完全に隠れていないと判定さ
れた場合には前記第１の判定手段による判定を行う ことを特徴とするシステム。 - 【請求項２６】請求項22記載のシステムであって、 前記フレーム・バッファは、 第１のフレーム・バッファと、 前記第１のフレーム・バッファとダブル・バッファリン
グするための第２のフレーム・バッファと で構成され、且つ、 前記グラフィックス制御プレーンには、画素を前記第１
のフレーム・バッファに書き込むか、前記第２のフレー
ム・バッファに書き込むかを選択するためのフロント／
バック・バッファ選択プレーンを 備えることを特徴とするシステム。 - 【請求項２７】請求項22記載のシステムであって、 前記グラフィックス制御プレーンには、ビデオモードを
示すための少なくも１つのビデオモード選択プレーンを 更に備えることを特徴とするシステム。 - 【請求項２８】請求項22記載のシステムであって、 前記グラフィックス制御プレーンには、画素が１つのオ
ブジェクト当たり１回だけ書き込まれるかどうかを示す
ために１回書き込みプレーンを 更に備えることを特徴とするシステム。 - 【請求項２９】請求項22記載のシステムであって、 実行中のウインドウの隠れた領域内に入る少なくも１つ
の画素を格納するための補助記憶装置を 更に備えることを特徴とするシステム。 - 【請求項３０】複数のウインドウの表示を制御するシス
テムであって、該システムは、 （ａ）表示装置に転送されるデータを保持するフレーム
・バッファであって、そのサブセットとして、画素を前
記フレーム・バッファに書き込むかどうかを決定するた
めに用いる書き込み可能プレーンを少なくとも含むグラ
フィックス制御プレーンを有するフレーム・バッファ
と、 （ｂ）各ウインドウの相対的な優先順位を定めたウイン
ドウ優先順位情報、各ウインドウに対する境界を定義す
るウインドウ・クリップ定義情報、ウインドウシステム
によって定義される各ウインドウに対するパラメータ等
を定義するウインドウ定義情報、ウインドウの共通部分
領域、その座標、及び重なり合って共通部分領域を形成
するウインドウを定義する共通部分領域情報からなる構
造を有するデータと、 （ｃ）前記構造のデータに基づいて、その前のオペレー
ション以降、ウインドウの定義が変更されたかどうかを
判定する第１の判定手段と、 （ｄ）前記第１の判定手段でウインドウの定義が変更さ
れたと判定された場合には、前記共通部分領域情報をア
ップデートして、書き込み可能プレーンがウインドウの
どの部分が隠れていないかを正しく示すようにする手段
と、 （ｅ）画素がフレーム・バッファに書かれるべきか否か
を決定する書き込み可能テストを、ウインドウの隠れて
いない領域に対しては書き込みを許可し、隠れる領域に
対しては書き込みを抑止するように行うテスト手段と、 （ｆ）前記テスト手段の書き込み可能テストによる、画
素がウインドウの隠れていない領域か、隠れている領域
かという結果、及び前記ウインドウ・クリップ定義情報
に基づいて、フレーム・バッファに書き込むかどうかを
決定する決定手段と を備えることを特徴とするシステム。 - 【請求項３１】請求項30記載のシステムであって、 前記決定手段でフレーム・バッファに書き込むと決定さ
れた画素を、フレーム・バッファに書き込む描画手段 を更に備えることを特徴とするシステム。 - 【請求項３２】請求項30記載のシステムであって、 前記第１の判定手段による、その前のオペレーション以
降、ウインドウの定義が変更されたかどうかの判定を行
う前に、描画すべきウインドウが完全に隠れているかど
うかを、前記データの共通部分領域情報、及びウインド
ウ優先順位情報に基づいて決定する第２の判定手段を更
に備え、 当該第２の判定手段により、当該ウインドウが完全に隠
れていない場合には前記第１の判定手段による判定を行
う ことを特徴とするシステム。 - 【請求項３３】請求項30記載のシステムであって、 前記フレーム・バッファは、 第１のフレーム・バッファと、 前記第１のフレーム・バッファとダブル・バッファリン
グするための第２のフレーム・バッファと で構成され、且つ、 前記グラフィックス制御プレーンには、画素を前記第１
のフレーム・バッファに書き込むか、前記第２のフレー
ム・バッファに書き込むかを選択するためのフロント／
バック・バッファ選択プレーンを 備えることを特徴とするシステム。 - 【請求項３４】請求項30記載のシステムであって、 前記グラフィックス制御プレーンには、ビデオモードを
示すための少なくも１つのビデオモード選択プレーンを 更に備えることを特徴とするシステム。 - 【請求項３５】請求項30記載のシステムであって、 前記グラフィックス制御プレーンには、画素が１つのオ
ブジェクト当たり１回だけ書き込まれるかどうかを示す
ために１回書き込みプレーンを 更に備えることを特徴とするシステム。 - 【請求項３６】請求項30記載のシステムであって、 実行中のウインドウの隠れた領域内に入る少なくも１つ
の画素を格納するための補助記憶装置を 更に備えることを特徴とするシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US99373692A | 1992-12-17 | 1992-12-17 | |
| US07/993,736 | 1992-12-17 | ||
| PCT/US1993/011896 WO1994014155A1 (en) | 1992-12-17 | 1993-12-07 | Graphics control planes for windowing and other display operations |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08504961A JPH08504961A (ja) | 1996-05-28 |
| JP3413201B2 true JP3413201B2 (ja) | 2003-06-03 |
Family
ID=25539870
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP51435394A Expired - Fee Related JP3413201B2 (ja) | 1992-12-17 | 1993-12-07 | ウィンドウ型及び他の表示オペレーションのためのグラフィックス制御プレーン |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US5515494A (ja) |
| JP (1) | JP3413201B2 (ja) |
| WO (1) | WO1994014155A1 (ja) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5561755A (en) * | 1994-07-26 | 1996-10-01 | Ingersoll-Rand Company | Method for multiplexing video information |
| JP2729151B2 (ja) * | 1994-10-19 | 1998-03-18 | 日本電気アイシーマイコンシステム株式会社 | 記憶制御装置 |
| US5877762A (en) * | 1995-02-27 | 1999-03-02 | Apple Computer, Inc. | System and method for capturing images of screens which display multiple windows |
| US5793360A (en) * | 1995-05-05 | 1998-08-11 | Wacom Co., Ltd. | Digitizer eraser system and method |
| US5751979A (en) * | 1995-05-31 | 1998-05-12 | Unisys Corporation | Video hardware for protected, multiprocessing systems |
| US5841420A (en) * | 1995-08-18 | 1998-11-24 | International Business Machines Corporation | Method and system in a data processing system windowing environment for displaying previously obscured information |
| US6097388A (en) * | 1995-08-22 | 2000-08-01 | International Business Machines Corporation | Method for managing non-rectangular windows in a raster display |
| US5850232A (en) * | 1996-04-25 | 1998-12-15 | Microsoft Corporation | Method and system for flipping images in a window using overlays |
| US5801717A (en) * | 1996-04-25 | 1998-09-01 | Microsoft Corporation | Method and system in display device interface for managing surface memory |
| US6812930B1 (en) * | 1996-05-10 | 2004-11-02 | Apple Computer, Inc. | Transparent compatibility and adaptation to differing format implementations in a computer system |
| US6522335B2 (en) * | 1999-05-10 | 2003-02-18 | Autodesk Canada Inc. | Supplying data to a double buffering process |
| AU2001257210A1 (en) * | 2000-04-24 | 2001-11-07 | The Trustees Of Columbia University In The City Of New York | System and method for dynamic space management of a display space |
| JP2002006829A (ja) * | 2000-06-26 | 2002-01-11 | Nec Corp | 表示制御装置、表示制御機能を備えた情報処理装置、表示制御方法および記録媒体 |
| US7643024B2 (en) * | 2001-05-17 | 2010-01-05 | The Trustees Of Columbia University In The City Of New York | System and method for view management in three dimensional space |
| US6888550B2 (en) * | 2001-07-19 | 2005-05-03 | International Business Machines Corporation | Selecting between double buffered stereo and single buffered stereo in a windowing system |
| CN100488060C (zh) * | 2001-12-28 | 2009-05-13 | Nxp股份有限公司 | 用于使用数据窗口译码数据的方法 |
| US7310103B2 (en) * | 2002-03-05 | 2007-12-18 | Sun Microsystems, Inc. | Pipelined 2D viewport clip circuit |
| KR100566242B1 (ko) * | 2002-07-19 | 2006-03-29 | 삼성전자주식회사 | 이동통신단말기에서 화면 편집 장치 및 방법 |
| US7286140B2 (en) * | 2002-07-26 | 2007-10-23 | Sun Microsystems, Inc. | Hardware acceleration of display data clipping |
| US7002599B2 (en) * | 2002-07-26 | 2006-02-21 | Sun Microsystems, Inc. | Method and apparatus for hardware acceleration of clipping and graphical fill in display systems |
| JP4158462B2 (ja) * | 2002-09-04 | 2008-10-01 | ソニー株式会社 | 画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラム |
| JP2006510963A (ja) * | 2002-12-18 | 2006-03-30 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ネットワーク上で伝送されるメディア・データのクリッピング |
| US7313764B1 (en) * | 2003-03-06 | 2007-12-25 | Apple Inc. | Method and apparatus to accelerate scrolling for buffered windows |
| JP2004354896A (ja) * | 2003-05-30 | 2004-12-16 | Matsushita Electric Ind Co Ltd | 描画処理装置及び描画処理方法 |
| US20050195206A1 (en) * | 2004-03-04 | 2005-09-08 | Eric Wogsberg | Compositing multiple full-motion video streams for display on a video monitor |
| US7921373B2 (en) * | 2004-04-05 | 2011-04-05 | Panasonic Corporation | Display screen management apparatus |
| DE112004002817B4 (de) * | 2004-04-22 | 2009-10-01 | Fujitsu Microelectronics Ltd. | Bildverarbeitungsvorrichtung und Graphikspeichereinheit |
| US8006196B2 (en) * | 2004-09-10 | 2011-08-23 | Presagis | Multi-application graphic display environment |
| US7747965B2 (en) * | 2005-01-18 | 2010-06-29 | Microsoft Corporation | System and method for controlling the opacity of multiple windows while browsing |
| US7426697B2 (en) | 2005-01-18 | 2008-09-16 | Microsoft Corporation | Multi-application tabbing system |
| US8341541B2 (en) * | 2005-01-18 | 2012-12-25 | Microsoft Corporation | System and method for visually browsing of open windows |
| US20060164431A1 (en) * | 2005-01-26 | 2006-07-27 | Samsung Electronics, Co.,Ltd. | Apparatus and method for displaying graphic objects concurrently |
| CN1300684C (zh) * | 2005-01-31 | 2007-02-14 | 浙江大学 | 确定图形用户界面中窗口剪切关系的方法 |
| US20060184893A1 (en) * | 2005-02-17 | 2006-08-17 | Raymond Chow | Graphics controller providing for enhanced control of window animation |
| JP4302081B2 (ja) * | 2005-06-21 | 2009-07-22 | 富士通株式会社 | ウェブアプリケーションシステム，遠隔操作サーバプログラム及び遠隔操作クライアントプログラム |
| JP4761900B2 (ja) * | 2005-09-15 | 2011-08-31 | パナソニック株式会社 | ステンシルによるウィンドウ処理装置及び方法 |
| US8810480B2 (en) * | 2006-08-04 | 2014-08-19 | Apple Inc. | Methods and apparatuses for controlling display devices |
| US7764291B1 (en) * | 2006-08-30 | 2010-07-27 | Adobe Systems Incorporated | Identification of common visible regions in purposing media for targeted use |
| JP5116514B2 (ja) * | 2008-03-11 | 2013-01-09 | キヤノン株式会社 | 撮像装置および表示制御方法 |
| US8115778B2 (en) * | 2008-09-26 | 2012-02-14 | Nvidia Corporation | System and method for selecting a pixel output format |
| US8713473B2 (en) | 2011-04-26 | 2014-04-29 | Google Inc. | Mobile browser context switching |
| US8610724B2 (en) * | 2011-07-29 | 2013-12-17 | Qualcomm Innovation Center, Inc. | Systems and methods for webpage adaptive rendering |
| US20140028668A1 (en) * | 2011-12-26 | 2014-01-30 | Xianchao James Xu | Multiple scissor plane registers for rendering image data |
| US10114672B2 (en) * | 2013-12-31 | 2018-10-30 | Thomson Licensing | User-centered task scheduling for multi-screen viewing in cloud computing environment |
| CN110989948B (zh) * | 2019-10-31 | 2023-03-21 | 中国航空工业集团公司洛阳电光设备研究所 | 一种基于ufcp绘图帧率提升方法 |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4555775B1 (en) * | 1982-10-07 | 1995-12-05 | Bell Telephone Labor Inc | Dynamic generation and overlaying of graphic windows for multiple active program storage areas |
| US4550315A (en) * | 1983-11-03 | 1985-10-29 | Burroughs Corporation | System for electronically displaying multiple images on a CRT screen such that some images are more prominent than others |
| JPS60232596A (ja) * | 1984-05-02 | 1985-11-19 | 株式会社日立製作所 | マルチウインドウ表示方式 |
| US4823108A (en) * | 1984-05-02 | 1989-04-18 | Quarterdeck Office Systems | Display system and memory architecture and method for displaying images in windows on a video display |
| DE3584718D1 (de) * | 1984-12-07 | 1992-01-02 | Dainippon Screen Mfg | Bilddatenverarbeitungsverfahren und system dafuer. |
| JPS61188582A (ja) * | 1985-02-18 | 1986-08-22 | 三菱電機株式会社 | マルチウインドウ書込み制御装置 |
| JPH0727349B2 (ja) * | 1985-07-01 | 1995-03-29 | 株式会社日立製作所 | マルチウインドウの表示制御方式 |
| US4710767A (en) * | 1985-07-19 | 1987-12-01 | Sanders Associates, Inc. | Method and apparatus for displaying multiple images in overlapping windows |
| DE3650119T2 (de) * | 1985-08-14 | 1995-03-30 | Hitachi Ltd | Verfahren zur Anzeigesteuerung für ein System mit mehreren Bildausschnitten. |
| JP2585515B2 (ja) * | 1985-08-16 | 1997-02-26 | 株式会社日立製作所 | 図形描画方法 |
| US4860218A (en) * | 1985-09-18 | 1989-08-22 | Michael Sleator | Display with windowing capability by addressing |
| US4954818A (en) * | 1985-10-18 | 1990-09-04 | Hitachi, Ltd. | Multi-window display control system |
| US4780709A (en) * | 1986-02-10 | 1988-10-25 | Intel Corporation | Display processor |
| US4868557A (en) * | 1986-06-04 | 1989-09-19 | Apple Computer, Inc. | Video display apparatus |
| US4772881A (en) * | 1986-10-27 | 1988-09-20 | Silicon Graphics, Inc. | Pixel mapping apparatus for color graphics display |
| US4862154A (en) * | 1986-10-31 | 1989-08-29 | International Business Machines Corporation | Image display processor for graphics workstation |
| US4954819A (en) * | 1987-06-29 | 1990-09-04 | Evans & Sutherland Computer Corp. | Computer graphics windowing system for the display of multiple dynamic images |
| US5061919A (en) * | 1987-06-29 | 1991-10-29 | Evans & Sutherland Computer Corp. | Computer graphics dynamic control system |
| US5216413A (en) * | 1988-06-13 | 1993-06-01 | Digital Equipment Corporation | Apparatus and method for specifying windows with priority ordered rectangles in a computer video graphics system |
| US5003496A (en) * | 1988-08-26 | 1991-03-26 | Eastman Kodak Company | Page memory control in a raster image processor |
| US5043923A (en) * | 1988-10-07 | 1991-08-27 | Sun Microsystems, Inc. | Apparatus for rapidly switching between frames to be presented on a computer output display |
| US5101365A (en) * | 1988-10-31 | 1992-03-31 | Sun Microsystems, Inc. | Apparatus for extending windows using Z buffer memory |
| US5091717A (en) * | 1989-05-01 | 1992-02-25 | Sun Microsystems, Inc. | Apparatus for selecting mode of output in a computer system |
| US5220312A (en) * | 1989-09-29 | 1993-06-15 | International Business Machines Corporation | Pixel protection mechanism for mixed graphics/video display adaptors |
| US5276437A (en) * | 1992-04-22 | 1994-01-04 | International Business Machines Corporation | Multi-media window manager |
-
1993
- 1993-12-07 WO PCT/US1993/011896 patent/WO1994014155A1/en active Application Filing
- 1993-12-07 JP JP51435394A patent/JP3413201B2/ja not_active Expired - Fee Related
-
1994
- 1994-12-29 US US08/366,423 patent/US5515494A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH08504961A (ja) | 1996-05-28 |
| WO1994014155A1 (en) | 1994-06-23 |
| US5515494A (en) | 1996-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3413201B2 (ja) | ウィンドウ型及び他の表示オペレーションのためのグラフィックス制御プレーン | |
| US5936641A (en) | Graphics hardware acceleration method, computer program, and system | |
| US4642790A (en) | Presentation space management and viewporting on a multifunction virtual terminal | |
| JP3057370B2 (ja) | コンピュータ・デイスプレイ装置および方法 | |
| US5694560A (en) | Workstation for displaying dynamic image with real-time special effects | |
| US5850232A (en) | Method and system for flipping images in a window using overlays | |
| US5892521A (en) | System and method for composing a display frame of multiple layered graphic sprites | |
| JP3428192B2 (ja) | ウインドウ表示処理装置 | |
| US5101365A (en) | Apparatus for extending windows using Z buffer memory | |
| US6140996A (en) | Display control apparatus | |
| JP2002544544A (ja) | 半透明層の描写 | |
| JPS62191918A (ja) | デ−タ表示方法及びデ−タ表示制御装置 | |
| JPH09245179A (ja) | コンピュータグラフィックス装置 | |
| US5768491A (en) | Display controller with enhanced video window clipping | |
| JP2548765B2 (ja) | 表示装置 | |
| US7663642B2 (en) | Systems and methods for rendering a polygon in an image to be displayed | |
| US4748442A (en) | Visual displaying | |
| JP2858137B2 (ja) | コンピュータ出力装置 | |
| JPS59231591A (ja) | 画像表示装置 | |
| JPH0562348B2 (ja) | ||
| JPH09138683A (ja) | 画像表示制御装置 | |
| US4988985A (en) | Method and apparatus for a self-clearing copy mode in a frame-buffer memory | |
| JPH0782315B2 (ja) | 画像処理装置 | |
| US6002391A (en) | Display control device and a method for controlling display | |
| JPH06124189A (ja) | 画像表示装置および画像表示制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080328 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090328 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090328 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100328 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100328 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120328 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120328 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 10 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 10 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |