JPH0365987A - ダブルフレームバッファ使用時のウィンド管理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔概　　要〕 外部記憶装置に格納された画像データをフレームバッフ
ァメモリに高速に読み出すためのダブルフレームバッフ
１使用・時ウィンド管理方式に関し、ウィンドマネージ
ャ使用時においてもダブルフレームバッファメモリを使
った高速表示切り換えが可能なダブルフレームバッファ
使用時のウィンド管理方式を提供することを目的とし、
ダブルフレームバックァメモリヲ持つワークステーショ
ンにおいて、いずれかがフレームバッファの内容が表示
されていることを示すフラグを記憶する表示バッファフ
ラグ記憶手段と、各フレームバッファの内容が表示され
ているウィンドに関する管理情報を記憶するウィンド情
報管理記憶手段と、各ウィンドを表示する処理、フレー
ムバッファ切り換え時の処理及びマウスクリックイベン
ト受信時の処理を前記２つの手段を用いて制御する制御
手段を有するように構成する。

〔産業上の利用分野〕

本発明は、ワークステーションにおける画面の表示方式
に係り、さらに詳しくは、外部記憶装置に格納された画
像データをフレームバッファメモリに高速に読み出すた
めのダブルフレームバ、アップ使用時ウィンド管理方式
に関する。

ワークステーションの画面の表示方式は多様化され、特
に、複数のウィンドを１画面上に表示し、各ウィンド内
で独立に処理するマルチウィンド方式が有効に利用され
るようになってきた。ワークステーションのデイスプレ
ィは一般に、例えば１０２４　Ｘ　１０２４ドツト程度
の解像度を持ち、さらにカラービットマツプデイスプレ
ィでは１画像あたり１バイトを使用するものとするなら
ば、画面全体の容量は１バイト×ＩＭドツトのＩＭバイ
ト分の画像データとなる。１画面分の画像データすなわ
ち１フレームの画像を、画面の１画像が１アドレスに対
応しているフレームバッファメモリ上に読み出して表示
する。各フレームはハードディスク等の外部記憶装置に
保存してあり、要求されたフレームバッファメモリに書
き込んで表示する。１つのフレームから次のフレームに
書き換える場合には、外部記憶装置から新しいフレーム
を読み出すため、５〜１０秒程度の時間がかかるという
問題がある。従ってフレームの入れ換えの時間を短縮す
る技術の必要性が高まってきた。

〔従来の技術〕

従来、フレームの入れ換えを高速に行う手法として、ダ
ブルフレームバッファ方式がある。

第８図はダブルフレームバッファ方式の概念図である。

図中、１はデイスプレィ、２はハードディスク、３と４
はともにフレームバッファである。ダブルフレームバッ
ファ方式では、例えばフレームバッファ＃１を表示中に
、次に表示する画像データをハードディスクからフレー
ムバッファ＃２に読み込んでおく。その後、ハードウェ
アでデイスプレィに表示するバッファの切り換えを行え
ば、フレームバッファ＃１に対応する画面からフレーム
バッファ＃２に格納された画面が、即座に入れ代わって
デイスプレィ上に表示されることになる。同様に、フレ
ームバッファ＃２を表示中にフレームバッファ＃１に画
像データを読み込んでおき、その後バッファ切り換えを
行うということを順次繰り返していけば表示の高速切り
換えが可能となる。

第９図は従来方式に基づくダブルフレームバッファ方式
におけるウィンドマネージャのウィンドの重なりに対す
る概念図である。

図中、Ａ、Ｂ、Ｃ，Ａ’、Ｂ’、Ｃ′はウィンドであり
、ウィンドＡ、Ｂ、Ｃがフレームバッファ＃１に格納さ
れ、Ａ’、Ｂ”、Ｃ’がフレームバッファ＃２に格納さ
れているものとする。従来方式では、２つのフレームバ
ッファ内にあるウィンドを例えば、Ｃ，Ｂ、Ａ、Ｃ’、
Ｂ′、Ａ’の順に作成したものとすると、ウィンドマネ
ージャではダブルフレームバッファであることを意識し
ていないため、あたかも１つのフレームバッファ上にそ
れらの６つのウィンドが存在し、それらの重なりは作成
した順に下から積み上げる管理を行っていた。

（発明が解決しようとする課題〕 すなわち、画面では重なりの低いウィンドであるＡ、Ｂ
、Ｃがフレームバッファ＃１を介して現在表示されてい
るが、管理上では作成した順に下から積み上げるとすれ
ば、図に示すように、Ａ′Ｂ’、Ｃ’はＡ、Ｂ、Ｃより
上位にある。このときユーザが現在表示されているウィ
ンドＡ、　Ｂ。

Ｃの中の上位のウィンドＡ上の点Ｐでマウスクリックし
ても、ウィンドマネージャは点Ｐの位置に表示をしてい
るウィンドの中で最も上位のウィンドに対し・て、その
マウスクリックを告げるイベントを渡すことになる。す
なわち、この例ではウィンドＡではなくてＡ′にイベン
トが渡される。例えば、消去処理であるならば、ウィン
ドＡを消去するべきところをＡ′が消去されるという結
果になる。すなわちウィンドの関わりの管理やキーボー
ド、マウスなどのデバイスからの信号の受信などに対し
て一括管理を行うウィンドマネージャは、例えばマウス
クリックのイベントを受信すると、表示をやめる消去処
理である場合には、消去すべきウィンドではないウィン
ドを消去してしまうという大きな問題点が生じていた。

本発明は、ウィンドマネージャ使用時においてもダブル
フレームバッファメモリを使った高速表示切り換えが可
能なダブルフレームバッファ使用時のウィンド管理方式
を提供することを目的とする。

〔課題を解決するための手段〕

第１図は本発明の原理図である。

本発明はダブルフレームバッファメモリを持つワークス
チーシランに関する。

表示バッファフラグ記憶手段１２は、いずれかがフレー
ムバッファの内容が表示されていることを示すフラグを
記憶する。

ウィンド情報管理記憶手段１３は、各フレームバッファ
の内容が表示されているウィンドに関する管理情報を記
憶する。

制御手段１４は、各ウィンドを表示する処理、フレーム
バッファ切り換え時の処理及びマウスクリックイベント
受信時の処理を前記２つの手段を用いて制御する。

〔作　　　用〕

本発明では、各フレームバッファに表示されているウィ
ンドの情報を別々に管理し、各フレームバッファにウィ
ンドの重なりに対応するエントリを順に格納するウィン
ド情報テーブルを用いる。

そして、フレームバッファの切り換え時に表示しようと
するウィンド群を他方のフレームバッファに表示されて
いるウィンド群の上に位置するように、ウィンドマネー
ジャが管理するようにする。

〔実　　施　　例〕

本発明の実施例を図面を参照して説明する。

第２図は本発明の詳細な説明するためのワークステーシ
ョン上の画面表示の実施例図である。

図中、Ａはフレームバッファ＃１の表示であり、Ｂはフ
レームバッファ＃２の表示の実施例図ある。

これら２つのフレームバッファ上において、６つのウィ
ンドＣ，Ｂ、Ａ、Ｃ”、Ｂ’、Ａ”をこの順序にＣ，Ｂ
、Ａはフレームバッファ＃１に、モしてＣ’、Ｂ′、Ａ
’はフレームバッファ＃２に作成したものとする。フレ
ームバッファ＃１は現在ワークステーション上のデイス
プレィ画面に表示されているもので、Ｃの上にＢがあり
、Ｂの上にＡがある形でウィンドが構成されている。一
方、フレームバッファ＃２は次にデイスプレィ上に表示
されるものであって、Ｃ′の上にＢ′とＡ′が重ならな
いで存在しているものである。ダブルフレームバッファ
方式では、フレームバッファ＃１を表示中に次に表示す
る画像データをフレームバッファ＃２に読み込んでおき
、その後ハードウェアでデイスプレィに表示するバッフ
ァの切り換えを行えば、瞬時に表示画面の変更を行うこ
とができる。

一方、ワークスチーシランでは、−船釣にウィンドマネ
ージャがあり、これによってウィンドの集合の管理、キ
ーボード、マイクなどのデバイスからの信号の受信など
によってウィンドの管理を行っている０例えば、フレー
ムバッファ＃１の表示において、ウィンドＡの点Ｐにお
いてマウスクリックのイベントを受信させると、ウィン
ドＡの表示をやめる、すなわち、クローズするというイ
ベントが生成され、この場合ウィンドマネージャは点Ｐ
の位置に表示をしているウィンドの中で、最上位のもの
、すなわち、ウィンドＡにイベントが渡される。また次
のフレームバッファ＃２が表示された場合には、ユーザ
が点Ｐ′でマウスクリックすれば点Ｐ′の位置に表示を
しているウィンドの中で最上位のもの、すなわちＡ′に
そのマウスクリックを告げるイベントを渡すようにしな
くてはならない、従来ではこのようなウィンドマネージ
ャを使っているときに、ダブルフレームバッファを使用
することができないという問題があった。そこで、本発
明では、フレームバッファの切り換え時にそのバッファ
の表示されているウィンド群をもう一方のフレームバッ
ファに表示されているウィンド群の上に位置するように
ウィンドマネージャに要求を渡す。これによりユーザの
要求したウィンドにイベントが渡るようにすることが可
能となる。以下に、本発明の方式について順を追って説
明する。

第３図は本発明に利用されるウィンドマネージャに関す
るソフトウェアとハードウェアの構成図である。

ソフトウェア８は最上位にアプリケーションプログラム
５があり、その下にウィンドマネージャ６があり、その
下にデバイスドライバ７がある。

そしてハードウェア９としては、ダブルフレームバッフ
ァメモリ１０とキーボード及びマウス１１がある。アプ
リケーションプログラム５はウィンドマネージャ６に対
してウィンド表示などの各種要求を行い、デバイスドラ
イバ７に対してはフレームバッファの切り換え要求を出
す。一方、ウィンドマネージャ６はアプリケーション５
に対してウィンドの重なりに関するイベント及び各種デ
バイスからのイベントを与える。アプリケーション５よ
りフレームバッファの切り換え要求があった場合には、
デバイスドライバはダブルフレームバッファメモリ１０
すなわちフレームバッファ＃ｌと＃２の内容に対してバ
ッファを切り換えて表示する。ウィンドマネージャ６は
アプリケーション５よりウィンド表示などの各種要求に
答えてウィンドの重なり等の管理を行い、デバイスドラ
イバ７を介してダブルフレームバッファメモリ１０の内
容を書き換えてウィンドの制御を行う。また、キーボー
ドやマウス１１からウィンド等の指定などが行われた場
合には、デバイスドライバ７を介してウィンドマネージ
ャ６にその要求が渡される。

ウィンドマネージャ６は各種そのようなデバイスからの
要求があったことをアプリケーションにインベントとし
て通知し、イベントに対するウィンドの管理を行う。ま
たウィンドマネージャ６はアプリケーション５に対して
ウィンドの集合に関するイベントをすぐにアプリケーシ
ョン５に通知する。

本発明ではこのようなシステムにおいて、ウィンドマネ
ージャ６を使っているときにダブルフレームバッファ１
０を使用できるようにするもので、本発明では、特に、
各フレームバッファに表示されているウィンドの情報を
別々に管理するものである。

第４図は本発明に利用される表示バッファフラグとウィ
ンド情報テーブルの実施例図である。

図中、（ａ）が表示バッファフラグであり、（ｂ）と（
Ｃ）はそれぞれフレームバッファ＃１及び＃２に表示さ
れているウィンド情報を格納するウィンド情報テーブル
である。表示バッファフラグがＯである場合には、フレ
ームバッファ＃ｌを現在表示中であることを意味し、フ
ラグが１である場合にはフレームバッフア＃２を現在表
示中であることを意味する。

同図（ロ）のウィンド情報は第２図（ａ）のフレームバ
ッファ＃１に表示するべきウィンドの位置関係に対応し
て、エントリが格納されている。第２図（ａ）に示され
るように、Ｃ，Ｂ、Ａはこの順序で下から重なっている
。これに対応してテーブル上ではＣに相当するウィンド
ＩＤが１であり、Ｂに相当するウィンドＩＤが２であり
、ウィンドＡに相当するウィンドＩＤが３として下から
順に格納されている。ウィンドＣは、左上の座標は（０
，Ｏ）であるから、ウィンドの左上座標は（０，０）が
格納され、そしてウィンドの高さと幅は画面全体である
として、それぞれ、１０２４と１０２４が格納されてい
る。また、その上のレベルにあるウィンドＢは、ウィン
ドＩＤが２であって、ウィンドの左上座標は、Ｘが１５
０で、ｙが１５０の位置にあって、ウィンドの高さは５
００１幅が５５０である。またウィンドＡはウィンド１
０が３の行に示され、ウィンドの左上座標がｘ　＝５０
０　、　ｙ　＝３００であってウィンドの高さと幅はそ
れぞれ４００．５５０である。

第４図（Ｃ）はフレームバッファ＃２に対するウィンド
情報が格納されている。第２図い）に示すように、ウィ
ンドＣ′がウィンドＩＤの４に対応して、ウィンドの左
上の座標は（０，０）でウィンドの高さの幅は画面全体
であるから、それぞれ１０２４と１０２４である。ウィ
ンドＩＤの５はウィンド１０に相当し、ウィンドの左上
座標はＸが５０．ｙが５０である。そしてウィンドの高
さと幅は４００と８００である。ウィンドＣ′はウィン
ド【Ｄが６である行になっており、ウィンドの位置はＸ
が５００．　　ｙが３００である。そしてウィンドの高
さと幅は４００と５５０である。このように本発明では
、表示バッファフラグすなわちどちらのフレームバッフ
ァの内容が現在表示中であるかどうかを示すフラグと、
各フレームバッファに表示されているウィンドの情報を
別々に管理し、ウィンド情報テーブルはウィンドの重な
りと一致するようにエントリの下から上に向かって使用
されていくものとする。

次に、これらの表示バッファフラグとウィンド情報テー
ブルを用いて第２図（ａ）、Φ）に対する表示処理と、
フレームバッファ切り換え時の処理及びマウスクリック
イベントを受信したアプリケーションの処理シーケンス
を説明する。

第５図（ａ）及び（ｂ）は第２図の画面を表示するまで
の処理シーケンサに対する機能ブロック図である。

処理が始まると、ＳＰＩにおいて、第２図（ａ）のウィ
ンドＣのオープン要求がアプリケーションより出される
。要求に対する引数は、ウィンドの左上座標のＸ、ｙと
縦、横のサイズである。これらの情報は第４図（ｂ）の
ウィンドＩＤＩに示されている。このウィンドＣのオー
プン要求がアプリケーションよりウィンドマネージャに
渡されると、ウィンドマネージャはデバイスに対して、
ウィンド表示処理を行うための管理を行う。そのために
まず、ウィンドマネージャは要求されたウィンドの左上
座標と縦、横のサイズを管理テーブルへ登録し、さらに
割り当てられたウィンドＩＤすなわち１というＩＤをア
プリケーションの方に通知する（Ｓ２）、第２図（ａ）
のような画面を作るためには、さらにウィンドＢとＡと
を登録する必要があり、Ｓ３において、ウィンドＡすな
わちテーブルの最終であって、その上には何もない未使
用エントリの位置で一番最後に近いもの、すなわちウィ
ンドＩＤ３のエントリの登録をして登録の終了となる。

次に、Ｓ４でウィンドＣの表示要求を出す前に、アプリ
ケーションは表示データをハードディスクよりメインメ
モリへ読み出しておく。この場合の要求に対する引数は
ウィンドＩＤすなわちウィンドＣに相当するウィンドＩ
ＤＩであって、表示データの格納しであるメインメモリ
の先頭アドレスの引数としてイ吏う。すなわち、どのウ
ィンドをメインメモリのどこに格納するかという引数が
要求の対象となる。これらの要求をウィンドマネージャ
に対して行うと、ウィンドマネージャは、Ｓ５において
、デバイスに対して表示処理を行い、表示した結果をア
プリケーションへ結果を通知する。

するとウィンドＣが表示される。

以上の動作をウィンドＢとＡについても同様な処理を行
うと、フレームバッファ＃１が表示される。この場合は
表示バッファフラグは０である。

その次にフレームバッファ＃２の内容をデイスプレィに
表示する場合、表示バッファフラグをＩにしてフレーム
バッファ＃２を有効にする。そしてデイスプレィ表示を
フレームバッファ＃１からフレームバッファ＃２へ切り
換える（Ｓ７）。

以下のルーチンはフレームバッファ＃１に対する画面表
示の処理とほぼ同じであって、ＳＰ７において、第２図
（ｂ）のウィンドＣ′のオープン要求を行う、このとき
、引数はウィンドの左上座標と縦、横のサイズである。

ウィンドマネージャに対して要求を行うと、ウィンドマ
ネージャはデバイスへウィンド表示処理を行う。そのた
めに、まずＳ９で、ウィンドマネージャは使用している
管理テーブルへ第４図（Ｃ）の内容を登録することにな
る。

すなわち、まずウィンドＩＤ４のＣ′の情報をテーブル
に形成する。そして割り当てられたウィンドＩＤをアプ
リケーションへ通知すると、第４図（Ｃ）のテーブルの
最終まで、すなわち、ウィンド■Ｄ４，５．６の情報が
格納されて未使用エントリのうちで１番最後に近いウィ
ンド１０６に対応するエントリの登録が終わる（３１０
）。すると８１１のアプリケーションでは、第２図（ｂ
）のウィンドＣ′の表示要求を出す前にまず表示データ
をハードディスクよりメインメモリへ読み出す。この場
合の引数はウィンドＩＤと表示データの格納しであるメ
インメモリの先頭アドレスである。その引数を用いてウ
ィンドマネージャはデバイスへ表示処理を行い、アプリ
ケーション結果を通知する（３１２）。すなわちまずＣ
′を表示する。

以上の動作をウィンドＩＤとＡ′についても同様な処理
を行う（Ｓ１３）とフレームバッファ＃２の内容、すな
わち第２図（ｂ）のウィンドの重なりとしての表示がデ
イスプレィ上に表れる（３１４）。

従って、最初にフレームバッファ＃１の内容の第２図（
ａ）の表示内容が表示され、そのあとに、それに入れ代
わってフレームバッファ＃２の内容すなわち第２図（ｂ
）の画面が表示されることになる。

第６図中）及び（Ｃ）は第５図（ａ）及び（ロ）の機能
ブロック図に従って表示されるフレームバッファ＃１と
＃２のウィンドの重なりの関係を示す実施例図である。

第６図（Ｃ）はフレームバッフア＃ｌが表示されている
場合のウィンドマネージャが管理しているウィンドの重
なり状態を示すもので、点線より上が第２図（ａ）の表
示に対応してウィンドＣ，Ｂ、Ａの順序で下から重なっ
た形となっている。そしてこれが現在表示されているも
のである。そして画面表示されていないが、フレームバ
ッファ＃２の中にはウィンドがＣ′の上にＡ′とＢ′が
ある。重なった形すなわち第２図中）の表示としてウィ
ンドの重なりが形成されているものである。第６図（ｂ
）はその逆で、フレームバッファ＃２が表示している場
合のウィンドマネージャが管理しているウィンドの重な
り関係である。この場合には現在表示されているものは
、フレームバッファ＃２であるから表示バッファフラグ
が１となっている場合であって、このフラグが１である
方は上位側すなわち点線より上側にあって、第２図（ｂ
）の表示内容である。従って、ウィンドＣ′の上にＡ′
とＢ′が重なった形となっている。一方、下側は表示バ
ッファフラグが現在１であるから、フレームバッファ＃
２が表示されているので、フレームバッファ＃１は表示
されない状態で下のレベルになって点線より下側になっ
ている。すなわち第２図（ａ）の表示内容であって、Ｃ
の上にり、Ａの順序で重なっている様子が示されている
。

第６図（ａ）はフレームバッファ切り換え時の処理シー
ケンサに対する機能ブロック図である。

アプリケーションプログラムからまずＳ１５でデイスプ
レィ表示を第２図（ｂ）から（ａ）の状態へ瞬時に切り
換えるため、フレームバッファ切り換え要求を出す。そ
の要求を受けるのはフレームバッファ用のデバイスドラ
イバであって、その要求に従って５１６でフレームバッ
ファデバイスにバッファ切り換え要求を出したことをア
プリケーションに応答を返す。フレームバッファ用デバ
イスドライバのルーチンはこれでエンドとなる。一方、
アプリケーションの方では、フレームバッファデバイス
にバッファ切り換え要求を出したことの通知を受けると
、５１７の処理を行う、すなわち、第２図（ロ）が表示
されているとき、すなわち、フレームバッファ＃２を表
示中で表示バッファフラグが１である場合には、ウィン
ドマネージャは、第６図（ｂ）のように、ウィンドが重
なっているものとして管理している。そのため画面上で
は第１図中）になっているが、第２図（ａ）の表示をす
るためには、ウィンドマネージャに第６図（Ｃ）のよう
にウィンドが重なるようにするべきだと判断させなくて
はならない、そのため、ウィンドＣを最上位へもってく
る要求を出す。この場合の引数はウィンドＩＤのみであ
って、テーブルに示されているように、ウィンドＣのウ
ィンドＩＤの引数は１となる。この要求は、ウィンドマ
ネージャに対して行う。するとウィンドマネージャは、
Ｓ１８において、ウィンドマネージャの管理テーブルを
変更し、Ｃが最上位になるように管理する。これでウィ
ンドＣに対する管理が終了するので、その旨をアプリケ
ーションに通知すると、同様な処理をウィンドＢとＡに
対しても行う。すなわちＳ１９に入って、ウィンドＢと
Ａに対してもウィンドマネージャは第６図（Ｃ）のよう
にウィンドが重なっているものと判断する。このように
して管理テーブルが構成される。このとき、マウスクリ
ックなどのイベントはウィンドの意志に反したウィンド
に伝えられることがないものとする。次に、アプリケー
ションは、Ｓ２０に移って、第４図（ａ）の表示バッフ
ァフラグをバッファ＃１の表示中を意味する０に変更す
る。このときはすでに管理テーブルはすべてエントリが
格納されているので、第２図（ロ）から（ａ）の表示切
り換えを行えば管理テーブルの内容、すなわち第４図（
ハ）のウィンド情報に従って第２図（ａ）が表示される
ことになる（Ｓ２１）。

第７図は、本発明のマウスクリックイベント受信時の処
理シーケンスに対する機能ブロック図である。イベント
としてウィンドＡを消去し、その消去された後にその下
にかくされていたウィンドＢとＣの一部の書き直しを行
うルーチンを実施例として説明する。まず、ウィンドマ
ネージャが、３２２において、現在表示されている第２
図（ａ）の画面、すなわち、ウィンドＣの上にＢとＡが
重なっているものに対して、フレームバッファ＃ｌを表
示している最中にユーザが第２図（ａ）に示される点Ｐ
をマウスクリックしたとすると、ウィンドマネージャは
それをアプリケーションへ通知する。

この場合の引数はウィンドＩＤすなわちウィンドＩＤの
３とその座標すなわち点Ｐの座標である。

この引数をもらったアプリケーションは、Ｓ２３におい
て、第２図（ａ）のウィンドＡを消去させる要求を出し
、第４図（ｂ）の該当エントリの情報をクリアする。す
なわち、ウィンドＩＤの３の行をクリアしてそこを空き
領域とする。その空き領域を詰めるため、まずデータテ
ーブルのソーティングを行う、すなわちウィンドＩＤが
３である行を探し出し、そこを空き領域とする。この場
合の引数はウィンドＩＤのみである。すると、Ｓ２４で
、ウィンドマネージャはデバイスに対してウィンドＡの
表示部分の消去処理を行う管理を実行する。すなわち、
ウィンドマネージャの管理テーブルから該当データを削
除したものをアプリケーションへ通知する。すると、Ｓ
２５で、ウィンドＡが画面から消えることになる。ウィ
ンドＡが消えた後は、そこの部分はまったくないため、
その下に隠されていたＢとＣが一部欠けたことになるの
で、ＢとＣに対応するウィンドの欠けた部分を写し出す
必要がある。そのため３２６において、ウィンドマネー
ジャはウィンドＡが画面から消えた後、その下に隠され
ていたＢとＣの一部が現れたことを知らせるイベントが
アプリケーションへ通知する。

このときの引数はウィンドＩＤすなわちＢとＣに対応す
る２と１であって、それから表れた矩形領域の左上座標
と縦、横のサイズをアプリケーションに渡す。すると、
Ｓ２７において、アプリケーションプログラムは第２図
（ａ）のＢの一部の書き直し要求を出す。この場合の引
数はウィンドＩＤであるから、ＢとＣに対応する２と１
であって、表示データの格納しであるメインメモリの先
頭アドレス及び書き直し矩形領域の左上座標と縦、横の
サイズが引数となってウィンドマネージャに渡す。

すると、３２８で、デバイスへウィンドマネージャが該
当領域の表示処理を行って、ウィンドＡが画面から消え
た後そこに写すべきウィンドＢとＣの一部を表示した結
果をアプリケーションへ通知する。この処理はＢに対し
て行われるが、以上の動作はウィンドＣについても行う
ことになる（Ｓ２９）。そして処理が終了する。

〔発明の効果〕

Ｏ３やウィンドマネージャ、デバイスドライバ等のソフ
トウェアと、ダブルフレームバッツァメモリやキーボー
ド、マウス等のハードウェアを一切変更することなしに
、ワークステーションユーザに高速な表示切り換え可能
なウィンドマネージャ環境を提供する。

【図面の簡単な説明】

第１図は本発明の原理ブロック図、 第２図（ａ）、（ロ）は本発明におけるワークステーシ
ョン上の画面表示の実施例図、 第３図は本発明に利用されるウィンドマネージャに関す
るソフトウェアとハードウェアの構成国、第４図（ａ）
は本発明に利用される表示バッファフラグの実施例図、
第４図（ｂ）及び（Ｃ）はウィンド情報テーブルの実施
例図、 第５図（ａ）及び（ｂ）は第２図（ａ）及びＣｂ）の画
面を表示するまでの処理シーケンサに対するフローチャ
ート、 第６図（ａ）はフレームバッファ切り換え時の処理シー
ケンス別図、第６図中）及び（Ｃ）は第５図（ａ）及び
（ロ）のフローチャートに従って表示されるフレームバ
ッファのウィンドの重なりの関係を示す実施例図、 第７ずはマウスクリックイベント受信時の処理シーケン
ス別図、 第８図は従来のダブルフレームバッファ方式の概念図、 第９図は従来のウィンドマネージャのウィンドの重なり
に対する概念図である。 １２　・・・　表示バッファフラグ記憶手段、１３　・
・・　ウィンド情報記憶手段、１４　・・・　制御手段
。

Claims (1)

1. 【特許請求の範囲】 １）ダブルフレームバッファメモリを持つワークステー
   ションにおいて、 いずれかがフレームバッファの内容が表示されているこ
   とを示すフラグを記憶する表示バッファフラグ記憶手段
   （１２）と、 各フレームバッファの内容が表示されているウィンドに
   関する管理情報を記憶するウィンド情報管理記憶手段（
   １３）と、 各ウィンドを表示する処理、フレームバッファ切り換え
   時の処理及びマウスクリックイベント受信時の処理を前
   記２つの手段を用いて制御する制御手段（１４）を有す
   ることを特徴とするダブルフレームバッファ使用時のウ
   ィンド管理方式。 ２）前記ウィンド情報管理記憶手段（１３）は、各フレ
   ームバッファごとに存在するテーブルのそれぞれにウィ
   ンドＩＤ、ウィンドの位置、ウィンドの大きさの情報を
   ウィンド情報としてウィンドごとに有することを特徴と
   する請求項１記載のダブルフレームバッファ使用時のウ
   ィンド管理方式。 ３）前記各テーブル内のウィンド情報は、画面の重なり
   の順序に対応してテーブル内に記憶されることを特徴と
   する請求項１記載のダブルフレームバッファ使用時のウ
   ィンド管理方式。