JPS6329290B2

JPS6329290B2 -

Info

Publication number: JPS6329290B2
Application number: JP59180906A
Authority: JP
Inventors: Suchuaato Rukyatsushu Jofurei; Rin Man Joi
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1983-10-17
Filing date: 1984-08-31
Publication date: 1988-06-13
Also published as: US4651146A; JPS60151743A; CA1216368A

Description

【発明の詳細な説明】〔産業上の利用分野〕この発明はコンピユータ表示装置に関し、より
具体的にはCRT（陰極線管）、ガスパネル、液晶
表示装置（LCD）その他コンピユータやデータ
処理システムで広く用いられる表示装置に多重デ
ータウインドウを表示するハードウエアおよびソ
フトウエア実現形態に関する。この発明はマルチ
タスク・コンピユータ環境下でとくに適用され、
このような環境下ではウインドウの各々が複数の
タスクのうちの異なる１つからのデータを表示す
る。

〔従来技術〕

ラスク走査CRT用のビデオデータの生成はよ
く知られている。第７図は典型的な実現形態を示
す。CRT制御回路１０は表示リフレツシユ・バ
ツフア１２用のメモリアドレスを生成するのに用
いられる。選択回路１４は制御回路１０およびバ
ツフア１２の間に介挿され、択一的にアドレス源
を与えてリフレツシユ・バツフアの内容を変更可
能にするために用いられる。すなわち、選択回路
１４は制御回路１０からのリフレツシユ・アドレ
スまたはシステムアドレスバスを介してのアドレ
スを表示リフレツシユ・バツフア１２に送出す
る。リフレツシユ・バツフア１２のバンド幅を時
分割多重（TDM）してリフレツシユとシステム
アクセスとの間の干渉を除去できるようにしてい
る。英数字キヤラクタ表示装置の場合、表示リフ
レツシユ・バツフア１２は通常キヤラクタコード
ポイントおよび関連の属性を記憶している。キヤ
ラクタコードポイントはキヤラクタ発生器１６を
アドレスするのに用いられる。キヤラクタ発生器
１６の出力はCRT制御回路１０からの走査線計
数出力に同期して生成させられる。反転ビデオ、
ブリンク（点滅）、アンダーライン等のような属
性機能はキヤラクタ発生器１６の出力に属性論理
回路１８によつて付加され、この結果としてのペ
ル（picture element）がシリアル化されてビデ
オモニタに送られる。

多くのオペレーテイング・システム（OS）や
適用業務プログラムではコンピユータが同時に多
数のタスクを継続できるようになつている。たと
えば、前景のワード処理のタスク中に背景のデー
タ処理のタスクが続行される。背景データ処理に
関しては、タスクはデータ処理タスクで生成させ
られたデータから円グラフまたは棒グラフを作る
グラフイツク発生タスクであることが多い。これ
らタスクのすべてに含まれるデータは組み合わさ
れて単一のドキユメントを形成するかもしれな
い。多重タスク操作は単一コンピユータたとえば
市場にある一般的なマイクロコンピユータの１つ
で実行できるであろうし、ホストコンピユータに
連結されたマイクロコンピユータによつても実行
できる。後者の場合、ホストコンピユータが一般
には背景データ処理機能を実行し、他方マイクロ
コンピユータが前景操作を実行する。複合表示リ
フレツシユバツフアを設ければ、第７図のシステ
ムもまた多重タスクからのウインドウを表示する
のに用いることができる。各タスクは他のタスク
とは独立であり、システムメモリ中に非重複のス
ペースを有する。システムメモリ中にあるユーザ
定義可能なタスク用ウインドウは、画面サイズに
より課される限界内で、処理中の各タスクからの
データを表示するように構成されている。第８Ａ
図および第８Ｂ図はこの概念を表わす。ユーザの
構想にしたがつてウインドウは第８Ａ図に示され
るようにそれぞれが重複せずに表示されてもよ
く、また第８Ｂ図に示されるように多層に、すな
わち重複して表示されてもよい。ただし、第８Ｂ
図に示される種類の重複表示を行つてもシステム
メモリ中のデータが喪失されないことは当業者に
より容易に理解されるであろう。他方隠蔽してい
るウインドウが表示画面上を移動し、またはさら
に表示画面から除去された際にリフレツシユ・バ
ツフア１２を更新して下がわの表示データを見る
ことができるようにするよう各タスク用のデータ
を保持しておく必要がある。

第７図に示す実現態様はある種類の用途には適
しているけれども、表示ウインドウやタスクの数
が増加し、または表示画面のサイズが増大した際
には、この実現態様は効率上制限を受けたものと
なつてしまうにちがいない。表示リフレツシユバ
ツフアを更新するのに必要とされる時間は著しく
増大するので、システム応答時間が増大し、ま
た、それゆえスループツトが減少してしまう。シ
ステム応答が遅くなる要因はつぎのようなもので
あろう。

(1) 表示画面にウインドウされているシステムメ
モリ内のロケーシヨンをタスクが更新するたび
に、表示リフレツシユバツフアを更新しなけれ
ばならない。制御ソフトウエア、通常ではOS
がこのような状態の発生をモニタして検出しな
ければならない。

(2) １つまたはそれ以上の表示ウインドウ内でデ
ータをスクロールすると、表示リフレツシユバ
ツフア内の対応するロケーシヨンを更新する必
要がある。このことは第９図を参照してより良
く理解されるであろう。第９図は第８Ａ図のよ
うに非重複のウインドウの場合を示している。
スクロールは、システムメモリ内の可視ウイン
ドウを移動させることによつて達成される。も
ちろん、第８Ｂ図にあるように重複ウインドウ
内でデータをスクロールするときにも同様の手
法を用いる。

(3) ウインドウの大きさや位置を変えるときはい
つでも、表示リフレツシユバツフアをシステム
メモリからの適切なロケーシヨンで更新しなけ
ればならない。

〔発明が解決しようとする問題点〕

この発明は以上の事情を考慮してなされたもの
であり、コンピユータ表示装置における多重デー
タウインドウ表示であつて、データウインドウ数
が増大した際にもシステム応答時間に不都合を与
えないものを提供することを目的としている。

また、多重タスク環境での使用に特に有効な多
重データウインドウ表示を実現することをも目的
としている。

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

この発明のシステムは以上の問題点を解決する
ために、表示画面に表示し得る適用業務プログラ
ムのデータからなる走査画像規定データを蓄える
少なくとも１つの画面バツフアと、走査画像規定
データに応じてビデオ表示信号を発生するビデオ
手段と、各適用業務プログラムからの走査画像規
定データに対する表示領域に対応して表示画面を
各領域に割り付けるマツプを蓄えるタスク選択メ
モリ手段と、表示可能データからなる複数のウイ
ンドウごとに、適用業務プログラムのデータを受
け取る表象スペース手段であつて、ウインドウが
対応する表象スペースの全部または一部を規定す
るものと、タスク選択メモリ手段に応じて表象ス
ペース手段からのデータをフイルタして画面バツ
フアに送る制御手段とを有している。

〔実施例〕

この発明はCRT表示装置に用いられるものと
して説明される。しかしながら、このCRT表示
装置はこの発明を実際に使用し得る多くの種類の
表示装置（ガスパネルや液晶表示装置が含まれ
る）の１つである。それゆえ、当業者には、
CRT表示装置の記載が単に具体例にすぎないこ
とが理解できるであろう。この結果としてリフレ
ツシユバツフアという用語はCRT表示装置に適
用される際に特別な意味を有するものの、この用
語は表示されるべきデータを蓄えるハードウエア
画面バツフアまたはソフトウエア画面バツフアと
全く等価であることも理解される。

多重タスク環境下での多重表示ウインドウ用の
応答速度が遅いという問題は第１図〜第３図に示
される一実施例を利用することにより克服され
る。ここではまず同様の問題を解消し得る構成例
につき説明を加え上述実施例の理解を助けること
とする。この構成例はハードウエアにより多くの
改良を加えてこの目的を達成するものである。本
実施例はソフトウエアにより改良を加え、この構
成例に較べ一層の向上を図つたものである。

第４図はこの比較構成例を示す。この第４図に
おいては第７図と同一または類似の箇所には同一
の参照番号を付している。各タスクには専用のリ
フレツシユバツフアが与えられこれらバツフアは
直接にアドレスできるようになつている。ただ
し、これらアドレスをシステムマツプ内に有する
ということを、上述のことが論理的には排斥する
ものでないことは当業者であれば理解できるであ
ろう。各タスクに１つずつリフレツシユバツフア
１２₁〜１２_oが設けられている。各リフレツシユ
バツフア１２₁〜１２_oは対応するセレクタ１４₁
〜１４_oを有している。ただし、CRT制御回路１
０からのリフレツシユアドレスは直接にはこれら
セレクタ１４₁〜１４_oには与えられない。そのか
わり、CRT制御回路１０からのリフレツシユア
ドレスを加算器２０₁〜２０_oのオペランド入力の
１つに供給する。これら加算器２０₁〜２０_oの
各々には対応するオフセツトレジスタ２２₁〜２
２_oから他のオペランド入力が供給されている。
CRT制御回路１０から供給されたアドレスを、
関連のオフセツトレジスタ２２₁〜２２_oに先に蓄
えられている値に加算し、これによりリフレツシ
ユバツフア１２₁〜１２_oの任意の１つに対する有
効なリフレツシユアドレスを発生する。第４図に
示す例では共通リフレツシユバツフアが用いられ
るので、フオーマツトデータの幅はリフレツシユ
バツフア１２₁〜１２_o全部について同一でなけれ
ばならない。リフレツシユバツフア１２₁〜１２_o
の各々を個別にアドレスし、しかも付加的なハー
ドウエアを設けて各バツフアの読み出しの同期を
維持すれば、リフレツシユバツフア１２₁〜１２_o
の各々のフオーマツトデータの幅を異ならせるこ
とが可能なことは当業者に理解されるであろう。
この付加的な自由度はかなり構成を複雑にすると
いう犠牲のもとに達成されるということもあり、
またこの構成例のより良い理解を図るためにも簡
単な場合のみ説明される。

表示リフレツシユ用に、すべてのリフレツシユ
バツフア１２₁〜１２_oはパラレルにアクセスされ
る。タスク選択メモリ２４もまたそのセレクタ２
６を介してパラレルにアクセスされ単一のリフレ
ツシユバツフア１２₁〜１２_oの出力をイネーブル
とする。ここでセレクタ２６はCRT制御回路１
０で生成されたアドレスを用いている。このイネ
ーブル動作はデコーダ２８によつて達成されてい
る。このデコーダ２８はタスク選択メモリ２４か
ら読み出されたコードに応じてイネーブル出力１
〜ｎを発生する。これらイネーブル出力は、任意
の所定時点にたつた１つのリフレツシユバツフア
１２₁〜１２_oが読み出され、その出力がキヤラク
タ発生器１６および属性論理回路１８に送出され
るように、対応するリフレツシユバツフア１２₁
〜１２_oに供給される。

この構成例の動作は第５図を参照してより良好
に理解できるであろう。この第５図は単純な場
合、すなわち２つのタスクを表示し、画面が16行
CRT上に垂直に分割され、さらに１行あたり16
キヤラクタだけあるという場合についての、リフ
レツシユバツフア１２₁，１２₂およびタスク選択
バツフア２４のマツプを示すものである。８ビツ
ト加算器２０₁，２０₂をこの例では考える。リフ
レツシユバツフア１２₁は数字データを有し、他
方リフレツシユバツフア１２₂は英文字データを
有する。リフレツシユバツフア１２₁用のオフセ
ツトレジスタ２２₁には16進アドレスF8“ｘ”が
転送され、またリフレツシユバツフア１２₂用の
オフセツトレジスタ２２_oには16進アドレス10
“ｘ”が転送される。タスク選択バツフア２４は
マツピングされてタスク２からのデータが画面の
左半分に表示され、またタスク１からのデータが
画面の右半分に表示されるようになつている。こ
のことにより図示のようなCRT表示結果が形成
される。

この構成例の主たる特徴は以下のとおり要約で
きる。

(1) 各タスクは他のタスクと完全に独立してい
る。

(2) リフレツシユバツフアの更新は単にタスクに
より制御され、それゆえ個別にリフレツシユバ
ツフアを再構成する必要がなくなる。

(3) スクローリングはタスク基準では、単にアド
レスオフセツトレジスタの値を更新することに
よつて達成される。

(4) 重複して重なりあう多重ウインドウ表示が選
択メモリの使用により達成され、この際リフレ
ツシユバツフアの内容に影響を与えることがな
い。

(5) システムメモリバスの利用が減少する。

第４図に示されたシステムを簡略化した変形例
は第６図に示すように実現できる。リフレツシユ
メモリ１２₁〜１２_oの１つを非透明性に指定して
タスク選択バツフア２４（第４図）が省略されて
いる。第６図に示す例では、リフレツシユバツフ
ア１２₁がそのように指定されている。デコーダ
２８はそのままとされ、ゲート３０が付加されて
いる。個別のコードポイントが非透明性リフレツ
シユバツフア１２₁に転送され、これらコードポ
イントを透明性のままのリフレツシユバツフア１
２₂〜１２_o用の選択メカニズムとしてそののち用
いることができる。これら選択バツフアコードポ
インタがない場合には非透明性表示バツフア１２
_１の出力がゲート３０によつてキヤラクタ発生器
１６にゲートさせられることとなる。この変形例
では、非透明性リフレツシユバツフア１２₁に起
因するパフオーマンスの低下のかわりにハードウ
エアが削減される。

つぎにこの発明の一実施例について詳述しよ
う。この実施例ではウインドウの画面への割り付
けを画面マトリクス４０に蓄え、これによつて多
重ウインドウの管理を行う点に特徴がある。

第１図はこの一実施例を示し、この第１図にお
いては２つのハードウエアバツフア１２₁および
１２₂が用いられる。図示の具体例では、マイク
ロコンピユータがホストコンピユータに接続さ
れ、このマイクロコンピユータはバツフア１２₂
がそイクロコンピユータのバツフアであるものと
して考えることとする。ただし、十分なシステム
メモリがあるならばこの手法を単一のコンピユー
タにも適用することは当業者には理解できるであ
ろう。図示のとおり、この実現形態は画面制御部
３２、ウインドウ制御部３４、表象スペース制御
部３６、表象スペース３８および画面マトリクス
４０を採用している。たとえば画面制御部３２は
10個、ウインドウ制御部３４は10組あつてもよ
い。それぞれは画面レイアウトの各々のためのも
のである。所定の画面制御部３２は対応する一組
のウインドウ制御部３４をポイントする。各表象
スペース３８は１画面レイアウトあたり少なくと
も１つのウインドウを有する。これら表象スペー
ス３８は全画面につき共通である。しかし、ウイ
ンドウはそうではない。その画面レイアウト中の
所定の表象スペース３８に対応するウインドウ制
御部３４は表象スペース中のウインドウの起点
（左右すみ）を定義し、表示画面上のウインドウ
の起点を定義し、さらに表象スペース中のそのウ
インドウの幅および高さを定義する。画面マトリ
クス４０は表示データのマツプであり、またこの
実施例では画面マトリクス４０がCRT画面に表
示し得るキヤラクタを１つ１つマツピングする。
ただし、このマツピングはペルを基準にしてもよ
いであろうし、他の何らかの基準で行つてもよい
であろう。いくつかのタスクからの適用業務出力
はメモリに案内され、具体的にはハードウエアリ
フレツシユバツフアでなく表象スペース３８に案
内される。第１図においては、IBMパーソナル
コンピユータ（PC）のようなマイクロコンピユ
ータが、IBM3274コントローラのようなコント
ローラを介してIBM3270コンピユータのような
ホストコンピユータに結合されているものとす
る。この場合、PCのハードウエアバツフア１２₂
はPCの表象スペースとして働らく。各表象スペ
ースには識別タグが割り当てられ、またオペレー
タまたは適用業務プログラムによつて大きさおよ
び画面位置の定義された関連ウインドウを有して
いる。オペレータまたは適用業務プログラムがウ
インドウを他のウインドウに対して調整するとき
には、システムが、適切なロケーシヨンに配列さ
せられた識別タグからなる画像を画面マトリクス
４０中に形成する。オーバラツプウインドウを重
ね書きにより形成できるようなCRT画面上にそ
れらウインドウが現われる順序と逆の順序で、マ
トリクス４０を生成してもよい。そのかわりに、
比較機能を利用して頂部ウインドウから順にマト
リクス４０を生成してもよい。マトリクス４０を
どの手法で生成するかの選択は所望のシステムパ
フオーマンスに左右される。このシステムはすべ
ての画面更新データを画面マトリクス４０を通じ
てフイルタすることによりリフレツシユバツフア
１２₁，１２₂への出力を管理している。そして、
このシステムは画面に実際に反映すべきキヤラク
タをそのようにし、反映する必要のないキヤラク
タを反映させず、これによつてオーバラツプ・ウ
インドウシステムの効率的なインクリメントを可
能にしている。そして不必要な書き変えを引き起
こさないこととなる。このような不必要な書き変
えがないので、ウインドウの１つの内容を改変し
たとき常に全ウインドウを頻繁に更新しなければ
ならないという問題はなくなつた。

キヤラクタを書くために、IBM3274コントロ
ーラ、監視適用業務またはPCが表象スペース３
８中にキヤラクタコードを書き込む。この書き込
みのロケーシヨンはこの表象スペース３８のカー
ソル値制御部によつて指定される。他の更新は必
要ではない。新しいキヤラクタがウインドウ制御
部３４により指定された対応ウインドウ内に配さ
れ、かつ画面マトリクス４０によつて表示用に指
定されたウインドウの一部であるかどうかに応じ
てその新しいキヤラクタは表示されまたは表示さ
れないこととなる。PCバツフア１２₂を用いるに
は、他のいかなるウインドウ制御部３４と同様な
幅、高さ、表象スペース起点および画面起点を有
するPC用ウインドウ制御部が設けられる。画面
マトリクスが更新されると、ウインドウ制御部３
４により定義されたPCバツフア１２₂中のウイン
ドウからのデータは、画面マトリクス４０によつ
て許容される範囲でCRT画面上に現われること
となる。ウインドウ中のデータはそのウインドウ
の起点のＸまたはＹ値をインクリメントまたはデ
クリメントすることによつてスクロールされ得
る。他の制御を更新する必要はない。単に画面バ
ツフア１２₁中の対応するウインドウが書き変え
られる。またはCPウインドウ１２₂であればオフ
セツトレジスタ（ウインドウ制御部３４）が可変
させられる。ウインドウは、このウインドウ用の
ウインドウ制御部３４中の起点座標を変化させる
ことにより画面上に再配置できる。画面マトリク
ス４０が更新されると、純然たる非PC画面バツ
フア１２₁は非PCのタスク用のデータおよびPC
用のコード（16進のFF）で書き換えられる。ス
クロールを行うことなく表象スペースの可視部分
を増大するには、この表象スペース３８用のウイ
ンドウ制御部３４がまず更新される。これは幅ま
たは高さを変えることにより行われる。これはウ
インドウの右部分または下部分の付加のみであ
る。これはウインドウの起点の変化をともなわな
い場合である。通常では、表象スペースまたは画
面からのオーバーフローがないかぎり、起点の変
化はない。オーバーフローの場合には、対応する
起点が可変させられる。つぎに、画面マトリクス
４０のウインドウ指定コードを重ね書きして画面
マトリクス４０を更新する。これは最も優先度の
低いウインドウ制御部３４から始める。こうし
て、非PCリフレツシユバツフア１２₁に対する全
ウインドウが非PCのウインドウ用の表象スペー
スからのデータおよびPCウインドウからの16進
コードFFで書き換えられる。

第２図はウインドウ更新プロセスのフローチヤ
ートを示す。ステツプ42においては、表象スペー
ス（PS）の行が更新を必要とする第1PS行にセ
ツトされる。画面の行はPS行の表示画面上の行
にセツトされる。PS列は更新を必要とする第
1PS列にセツトされる。画面列はPS列の画面上
の列にセツトされる。行数は更新すべきPS行の
数にセツトされる。そして、列数は更新すべき
PS列の数にセツトされる。以下に続く手順は更
新すべき行数だけ実行される。更新すべき列数だ
け、マトリクス４０がチエツクされて画面の行お
よび列が更新すべきウインドウ内かどうかの判別
が行われる。これは判別ブロツク４４によつて示
されている。テストはPCに対して行われる。ハ
ードウエアバツフア１２₂はPC用の表象スペース
であり、しかも16進コードFFはPCウインドウを
表わすのに使用されているからである。判別ボツ
クス４４の判別がイエスであれば、画面の行およ
び列がステツプ46で示されるようにPS行および
列にセツトされ、また画面の列およびPS列がス
テツプ48で示されるようにインクリメントされ
る。判別ボツクス４４の判別がノーであれば、画
面の行および列をPSの行および列にセツトする
ことなしに画面の列およびPSの列がインクリメ
ントされる。このプロセスが更新すべき列数につ
き完了されるとき、ステツプ50に示すようにPS
列は更新を要する第1PS列に更新される。そのの
ち、PS行がインクリメントされ、また画面行が
インクリメントされる。これはステツプ52に示す
とおりである。

第３図は画面マトリクス４０を形成するフロー
チヤートを示す。まず、ステツプ54に示すように
ウインドウが最下部ウインドウにセツトされる。
そののち、隠すべきかどうか不明なウインドウす
べてについて以下の手順が実行される。ステツプ
56においては、列が画面上の第１ウインドウ列に
セツトされ、行が画面上の第１ウインドウ行にセ
ツトされる。ウインドウ行の数だけステツプ58で
示される手順が継続する。そして、この手順では
ウインドウ列の数だけステツプ60で示される手順
が行われる。ステツプ60においては、マトリクス
行および列がステツプ62に示されるようにウイン
ドウ識別子にセツトされる。つぎに、列がステツ
プ64に示されるようにインクリメントされる。ス
テツプ60が終了すると（ステツプ58は依然行われ
ているが）、列がステツプ66に示されるように画
面上の第１ウインドウ列にセツトされる。そのの
ち、列がステツプ68に示されるように、インクリ
メントされる。こうしてステツプ58が終了する
と、ステツプ70に示されるように、ウインドウが
つぎのウインドウにインクリメントされる。

この発明のシステムの好ましい実施例において
は、つぎのいずれかの手法によつて多重ウインド
ウを描画する機能が駆動される。

PCのカーソルレジスタの更新 PCのテキスト／グラフイツクス・ノードレ
ジスタの更新ウインドウ制御部、画面制御部または表象ス
ペース制御部における変化表象スペースデータの変化適用業務プログラムは上述、の場合につき
描画機能を生じさせることができる。なおこの発
明は上述実施例に限定されるものではなく、この
発明の趣旨を逸脱することなく種々変更しうるこ
とはもちろんである。たとえば第１図に示すシス
テムにおいて、PC用のシステムメモリ中に表象
スペースを設ければハードウエアバツフア１２₂
を省略することができるであろう。また、説明し
てきた例ではキヤラクタ・ボツクス表示バツフア
を考えてきたけれども、この発明の原理をグラフ
イツク表示支援用の全点アドレス型（All Point
Adressable：APA）バツフアにも等しく適用で
きる。

〔発明の効果〕

以上説明したようにこの発明によればデータウ
インドウ数が増加してもシステム応答時間に不具
合のない多重データウインドウシステムを実現で
きる。

また、画面バツフアの個数は少なくとも１つで
あればよく、ハードウエア上の要請を緩和するこ
とができる。

【図面の簡単な説明】

第１図はこの発明の一実施例を示すブロツク
図、第２図および第３図は第１図実施例を説明す
るためのフローチヤート、第４図、第５図および
第６図は第１図実施例の理解を助けるための多重
ウインドウ表示システムの構成例を説明する図、
第７図、第８Ａ図、第８Ｂ図および第９図は従来
例を説明するための図である。１２₁，１２₂……画面バツフア、１６……キヤ
ラクタ発生器、４０……画面マトリクス、３８…
…表象スペース。

Claims

【特許請求の範囲】１多重タスク環境下での独立な適用業務プログ
ラムからのデータを共通の表示画面に表示するよ
うな多重データウインドウ表示システムにおい
て、上記表示画面に表示し得る適用業務プログラム
のデータからなる走査画像規定データを蓄える少
なくとも１つの画面バツフアと、上記走査画像規定データに応じてビデオ表示信
号を発生するビデオ手段と、上記各適用業務プログラムからの上記走査画像
規定データに対する表示領域に対応して上記表示
画面を各領域に割り付けるマツプを蓄えるタスク
選択メモリ手段と、表示可能データからなる複数のウインドウごと
に、上記適用業務プログラムのデータを受け取る
表象スペース手段であつて、上記ウインドウが対
応する表象スペースの全部または一部を規定する
ものと、上記タスク選択メモリ手段に応じて上記表象ス
ペース手段からのデータをフイルタして上記画面
バツフアに送る制御手段とを有することを特徴と
する多重データウインドウ表示システム。