JPH06259214A - ウィンドウ再描画方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 マルチウィンドウ画面の上位のウィンドウの
消失等により下位のウィンドウの再描画が必要になった
時に、再描画の処理時間をより短縮する。 【構成】 サーバはポート３０を介した再描画要求イベ
ントに対するクライアントＡからの応答信号に応じ、よ
り優先度の高い専用のポート３１を開設してリクエスト
信号を入力し、リクエスト信号が終了するとポート３１
を閉鎖する。この間、他のクライアントＢから何等かの
信号がポート３０に入力しても、その処理を保留する。
したがって、途中で入力したクライアントＢからの信号
を処理する時間だけ、リクエスト信号の入力時間が短縮
され、再描画に要する処理時間が短縮される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明はマルチウィンドウシス
テムの上位のウィンドウが消去された時に、それより下
位のウィンドウの消去されたウィンドウによって覆われ
ていた部分を再描画するウィンドウ再描画方法に関す
る。

【０００２】

【従来の技術】マルチウィンドウシステムの初期のウィ
ンドウ再描画方法は、ディスプレイ上に表示されている
すべてのウィンドウのビットマップデータを保存してお
き、再描画時に覆われていた部分を表示フレーム（ビッ
トマップメモリ）に転送するバッキングストア方式が代
表的なものであった。

【０００３】このバッキングストア方式は高速性におい
て優れているが、同時に表示するウィンドウの数の増加
に供なって膨大な容量のメモリが必要となるため、当時
に比べてコンピュータの処理速度が格段に上った現在で
は、特に高速性を必要とする時の補助手段として用いる
場合を除いては、一般に使われなくなり、下位のウィン
ドウの覆われた部分の再描画はそのウィンドウの描画リ
クエストを出力したアプリケーション側に委ねる方式に
変って来ている。

【０００４】すなわち、或るウィンドウの描画の各部の
詳細を指示するリクエスト信号を出力するクライアント
に対して、そのリクエスト信号に応じて表示フレームに
描画を行ない、それらのウィンドウを管理するサーバ
は、再描画の必要が発生した時に、当該ウィンドウのリ
クエスト信号を出力したクライアントに再描画要求イベ
ントを発行し、該イベントに応じてクライアントから入
力する応答信号に続くリクエスト信号に応じて再描画を
行なうものである。

【０００５】

【発明が解決しようとする課題】しかしながら、再描画
の必要が発生した時に出来るだけ短時間にその処理を終
了することは、ユーザが常に要求している点であると共
に、全体の処理時間を短縮することでもあるから、いか
にコンピュータの処理速度が向上してもその重要性は変
ることがない。したがって、少しでもウィンドウ再描画
の処理時間を短縮することは、それに関係する技術者に
とって、常に考えていなければならない問題である。

【０００６】この発明は上記の点に鑑みてなされたもの
であり、ウィンドウの再描画に要する処理時間をより短
縮することを目的とする。

【０００７】

【課題を解決するための手段】この発明は上記の目的を
達成するため、ディスプレイ上に複数のウィンドウを表
示するマルチウィンドウシステムの上位のウィンドウが
消去されることによりそれより下位のウィンドウの上位
のウィンドウによって覆われていた部分を再描画するウ
ィンドウ再描画方法において、描画処理を行なうサーバ
が出力した再描画要求イベントに応じてクライアントか
ら応答信号が入力した時に、該応答信号に続いてクライ
アントから入力して来る再描画を具体的に指示するリク
エスト信号を、サーバが専用の通信手段を設けて受信す
るものである。

【０００８】また、再描画すべき下位のウィンドウが複
数個ある時に、サーバが出力する１回の再描画要求イベ
ントに応じて、クライアントが複数の下位のウィンドウ
に関するリクエスト信号を一連の情報として出力するも
のである。

【０００９】あるいは、サーバがディスプレイ上に表示
されている複数のウィンドウのプロトコル情報を記憶し
ておき、下位のウィンドウの再描画の必要が発生した際
に該下位のウィンドウに変更がない場合は、該下位のウ
ィンドウの再描画をサーバがその記憶しているプロトコ
ル情報に基いて行なうものである。

【００１０】さらに、サーバから入力した再描画要求イ
ベントに対してクライアントが直ちに応答信号を出力出
来ない場合に、クライアントは再描画要求イベントを記
憶して応答信号出力可能になった時に応答信号を出力
し、該応答信号の入力によりサーバが応答信号に続いて
入力してくるリクエスト信号に応じた再描画を開始する
ものである。

【００１１】

【作用】上記のウィンドウ再描画方法によれば、サーバ
はその出力した再描画要求イベントに応じてクライアン
トから応答信号が入力した時に専用の通信手段を設け、
該通信手段によって応答信号に続いてクライアントから
入力して来るリクエスト信号を受信して再描画を行な
う。従って、より優先度の高い割込みが発生しない限り
他のクライアントからの信号等に煩らわされることがな
いから、その分だけ短時間で所要の再描画を終了するこ
とが出来る。

【００１２】また、再描画すべき下位のウィンドウが複
数個ある時に、サーバが出力する１回の再描画要求イベ
ントに応じて、クライアントが複数の下位のウィンドウ
に関するリクエスト信号を一連の情報として出力するか
ら、ウィンドウが変る度に通信時間と専用の通信手段を
設定し直す時間の必要がなく、その分だけ再描画の処理
時間が短縮される。

【００１３】あるいは、サーバがディスプレイ上に表示
されている複数のウィンドウのプロトコル情報を記憶し
ておき、下位のウィンドウの再描画が発生した際に該下
位のウィンドウに変更がなければ、サーバは記憶してい
るプロトコル情報に基いて再描画を行なう。従って、そ
の都度クライアントとの間で通信を行なう必要がないか
ら、再描画は短時間で終了する。また、プロトロル情報
で記憶しているから、大容量のメモリを必要とせず、安
いコストで実現することができる。

【００１４】さらに、何等かの事情でクライアントが再
描画要求イベントに直ちに応答出来ない場合には、該イ
ベントを記憶して出力可能になった時に応答信号を出力
し、サーバは続いて入力してくるリクエスト信号に応じ
た再描画を開始する。したがって、サーバは応答信号が
入力するまで再描画要求イベントの出力を繰返す必要が
なく、待っている間に別の処理を実行することにより、
全体の処理時間を短縮することが出来る。

【００１５】

【実施例】図２は、この発明によるウィンドウ再描画方
法を適用する情報処理装置の一実施例の構成を示すブロ
ック図である。

【００１６】図２に示した情報処理装置はＣＰＵ１と、
ＣＰＵ１をバックアップするＲＯＭ，ＲＡＭ等からなる
メインメモリ２及び文字フォントを格納しているフォン
トＲＯＭ３と、描画処理とウィンドウ管理を行なうため
の描画プロセッサ４，ウィンドウ管理メモリ５と、それ
ぞれビットマップメモリである表示フレーム６，イメー
ジメモリ７と、入出力制御装置８とから構成されてい
る。

【００１７】表示フレーム６はビットマップに展開した
ウィンドウ等の表示データを記憶し、該表示データを表
示する液晶ディスプレイ装置（以下「ＬＣＤ」という）
１０が接続されている。入出力制御装置８には、それぞ
れ入力装置である既によく知られているキーボード１
１，マウス１２と、図示しないプリンタ等の出力装置及
びディスク装置等の外部記憶装置が接続されている。

【００１８】ＣＰＵ１は、メインメモリ２をバックアッ
プメモリとして情報処理装置全体の制御と情報処理を行
なうと共に、描画プロセッサ４，ウィンドウ管理メモリ
５等を駆使して画像処理やウィンドウ描画等を実行させ
る。

【００１９】また、ＣＰＵ１や描画プロセッサ４は、フ
ォントＲＯＭ３に格納されている各種書体の文字フォン
トによって文字コード（プロトコル情報の一種）をビッ
トマップに変換し、表示フレーム６又はイメージメモリ
７上に展開する。

【００２０】図３はＬＣＤ１０に表示されるマルチウィ
ンドウ画面の一例を示す図である。図３に示されたマル
チウィンドウ画面２０には、上位から順に、ウィンドウ
２１，２２，２３，２４の４個のウィンドウが表示され
ている。

【００２１】最上位のウィンドウ２１より下位のウィン
ドウ２２，２３，２４は、その一部がより上位のウィン
ドウにより覆われている。最上位のウィンドウ２１は、
特にスタックトップ・ウィンドウとも呼ばれている。

【００２２】図４は、図３に示されたスタックトップ・
ウィンドウ２１が消去された時のマルチウィンドウ画面
２０ａを示す図であり、図３と同一部分には同一符号を
付している。

【００２３】図４に示されたマルチウィンドウ２０ａに
おいて、ウィンドウ２２乃至２４の斜線を施した部分２
２ｓ乃至２４ｓは、仮想線で示す消去されたウィンドウ
２１により覆われていた各ウィンドウの陰の部分で、再
描画の必要が発生した部分である。

【００２４】図１はこの発明によるウィンドウ再描画方
法の第１実施例と、それ以前の方法とを対比して示す動
作フロー図である。図１は説明を容易にするために後に
説明する図５乃至図７と同じく、実施例を各図の（Ａ）
に、該実施例に対応するそれ以前の方法を同図の（Ｂ）
に、それぞれ並べて示している。

【００２５】図１の（Ａ）において、それぞれサーバ側
の通信手段であるポート３０，３１は、サーバが設ける
専用の通信手段であるポート３１の方が、ポート３０よ
りも優先度が高く、サーバがクライアントからリクエス
ト信号を受信する間だけ開設されるポートである。

【００２６】例えばスタックトップ・ウィンドウ２１
（図３）が消失したことにより、それより下位のウィン
ドウ２２，２３，２４の部分２２ｓ，２３ｓ，２４ｓ
（図４）の再描画の必要が発生すると、サーバは先ず部
分２２ｓについて、前にウィンドウ２２のリクエスト信
号を出力したクライアントＡに対して、ポート３０から
再描画要求イベント（以下単に「イベント」ともいう）
を出力する。

【００２７】該イベントが入力すると、クライアントＡ
はイベントに対する応答信号をサーバに出力し、サーバ
はポート３０を介して応答信号を受信すると、応答信号
に続くリクエスト信号を受信するために、直ちにポート
３１を開いて部分２２ｓの再描画をスタンバイする。

【００２８】クライアントＡは、応答信号に続いて部分
２２ｓの情報毎に、再描画のスタート座標と再描画すべ
きプロトコルデータとからなるリクエスト信号を出力
し、サーバはポート３１から入力したリクエスト信号に
応じて、再描画時に表示フレーム６の指定された場所に
部分２２ｓのビットマップを展開する。

【００２９】一連のリクエスト信号が入力している間
は、ポート３１より優先度の高い割込みが発生しない限
り、サーバはリクエスト信号の入力を続行する。したが
って、例えば他のクライアントＢから何等かの信号がポ
ート３０に入力しても、部分２２ｓのリクエスト信号の
入力が終了してポート３１が閉じられるまで、その処理
は保留される。

【００３０】一方、従来の方法は、図１の（Ｂ）に示し
たように、応答信号やその他の信号とリクエスト信号と
が同じポート３０に入力するため、クライアントＢから
信号が入力すると、クライアントＡからのリクエスト信
号といずれを優先するかを判断し、図示したようにリク
エスト信号が優先すると判断されても、クライアントＢ
との通信と判断に要する時間だけ、図１の（Ａ）に示し
た実施例よりもリクエスト信号入力の終了が遅れる。

【００３１】他のクライアントからの信号の数は１回と
は限らないから、信号数が多ければ多い程それによる遅
れが大きくなる。もし、クライアントＢからの信号が優
先すると判断されれば、その処理に要する時間だけ、部
分２２ｓのリクエスト信号入力が大幅に遅れることにな
る。

【００３２】すなわち、通常の通信手段（ポート３０）
より優先する専用の通信手段（ポート３１）を設けて、
リクエスト信号を受信することにより、それに要する処
理時間を短縮することが出来る。

【００３３】図５はウィンドウ再描画方法の第２実施例
と、それ以前の方法とを対比して示す動作フロー図であ
る。図５の（Ａ）に示した第２実施例は、第１実施例
（図１）における再描画要求イベント，応答信号の通信
時間と、ポート３１の開閉に要する時間を減らして、さ
らに処理時間を短縮するものである。

【００３４】例えば、下位のウィンドウ２２，２３が同
じクライアントＡからの、下位のウィンドウ２４は異な
るクライアントＢからの、それぞれリクエスト信号によ
り描画されたものであるとすれば、クライアントＡにサ
ーバから再描画要求イベントが入力した時に、クライア
ントＡは該イベントに対する応答信号に続いて、部分２
２ｓ，２３ｓのリクエスト信号を一連の情報として出力
する。

【００３５】すなわち、図５の（Ａ）に示したように、
サーバはポート３０を介してクライアントＡにイベント
を出力して、再描画を必要とするのはウィンドウ２２，
２３の部分２２ｓ，２３ｓであることを知らせる。クラ
イアントＡが該イベントに対する応答信号を出力する
と、サーバは該応答信号に応じて第１実施例と同様にポ
ート３１を開く。

【００３６】応答信号に続いてクライアントＡは、開か
れたポート３１を介して、部分２２ｓを再描画するため
の一連のリクエスト信号を出力する。ここまでは図５の
（Ｂ）に示した第１実施例と同様である。

【００３７】その後、第１実施例では部分２２ｓの最後
のリクエスト信号が入力すると、サーバはポート３１を
閉じ、改めてウィンドウ２３の部分２３ｓについてのイ
ベントをクライアントＡに出力して、部分２２ｓと同様
の操作を行なう。

【００３８】しかしながら、図５の（Ａ）に示した第２
実施例は、部分２２ｓの最後のリクエスト信号に続い
て、ウィンドウ２３の部分２３ｓを再描画するための一
連のリクエスト信号を出力する。サーバは部分２３ｓの
最後のリクエスト信号が入力して始めてポート３１を閉
じ、次にクライアントＢに対するウィンドウ２４の部分
２４ｓについてのイベントの出力に移る。

【００３９】このように、複数のウィンドウに関係する
クライアントに対して、１回のイベントによって再描画
を要するウィンドウの部分をまとめた一連のリクエスト
信号を出力させることにより、図５の（Ｂ）に示した、
その都度のポート３１の閉鎖と、ウィンドウ２３の部分
２３ｓについてのイベント出力と、該イベントに応じた
クライアントＡの応答信号入力と、改めてのポート３１
開設とが不要になり、それだけリクエスト信号入力の所
要時間が短縮される。

【００４０】図６はウィンドウ再描画方法の第３実施例
と、それ以前の方法とを対比して示す動作フロー図であ
る。

【００４１】図６の（Ａ）に示した第３実施例は、サー
バが表示されている各ウィンドウの描画時にそのプロト
コル情報を記憶しておき、再描画の必要が生じた場合に
そのウィンドウに変更がなければ、改めてクライアント
にイベントを出力することなく、記憶してある当該ウィ
ンドウのプロトコル情報によって必要な部分の再描画を
行なうものである。

【００４２】すなわち、ウィンドウ２２が最初に描画さ
れた時に、第３実施例はそれ以前の図６の（Ｂ）に示し
た方法と同じく、サーバは通常のイベント出力，応答信
号入力，ポート３１開設，一連のリクエスト信号入力，
ポート３１閉鎖の一連の処理を行なう。

【００４３】しかしながら、第３実施例がそれ以前の方
法と異なる点は、入力したウィンドウ２２のプロトコル
情報をメインメモリ２（図２）のＲＡＭに記憶し、ウィ
ンドウ２２が消去される時まで保持していることであ
る。

【００４４】ウィンドウ２２の部分２２ｓの再描画の必
要が発生した時に、図６の（Ｂ）に示した以前の方法な
らば、第１又は第２実施例と同様に、イベント出力から
ポート閉鎖に至る通信及びポート処理を実行する。

【００４５】それに対して第３実施例では、イベント出
力からポート閉鎖までの通信及びポート処理を行なうこ
となく、直ちに記憶しているウィンドウ２２のプロトコ
ル情報による表示フレーム６への再描画に移る。

【００４６】したがって、通信及びポート処理のための
時間が全く不要になるから、再描画の所要時間は大幅に
短縮される。もし、上位のウィンドウに覆われている間
にウィンドウ２２の変更があった場合には、第１又は第
２実施例や最初の描画の時と同様に、通常の通信及びポ
ート処理を行なって、入力したリクエスト信号の新しい
プロトコル情報を記憶する。

【００４７】図７はウィンドウ再描画方法の第４実施例
とそれ以前の方法とを対比して示す動作フロー図であ
る。

【００４８】図７の（Ａ）に示した第４実施例は、サー
バからイベントが入力した時に、クライアントが何等か
の事情で直ちに応答信号を出力出来なかった場合、サー
バはイベントを再出力せず、クライアントはイベントの
入力を記憶して、応答出来るようになれば直ちに応答信
号を出力するものである。

【００４９】すなわち、第４実施例以前の方法は、図７
の（Ｂ）に示したように、サーバは最初のイベントに対
する応答信号が入力しなければ、予め設定したインター
バルで２回目，３回目のイベントを出力し、クライアン
トは応答出来る状態になってから入力したイベントに対
して応答信号（及びそれに続くリクエスト信号）を出力
していた。

【００５０】この方法では、サーバが一定のインターバ
ルでイベントを出力しなければならず、クライアントは
応答出来る状態になっても次のイベントが入力するまで
は応答信号を出力しないから、イベント発行の処理と次
のイベントが入力するまでの無駄な時間がかかってい
た。

【００５１】第４実施例は、図７の（Ａ）に示したよう
に、サーバは最初のイベントを出力すれば、応答信号が
戻って来なくてもイベントを再出力しないから、余分な
処理が不要になり、他の処理を行なうことが出来る。ク
ライアントは、例えばフラグを立てる等によってイベン
トの入力を記憶し、応答可能になればフラグを検出して
直ちに応答信号を出力するから、次のイベント入力を待
つ時間が無くなる。

【００５２】したがって、イベント出力時にクライアン
トがビジィであった場合には、もっとも短かい時で再描
画を開始することが出来るから、再描画の必要が発生し
てから再描画を終了するまでの時間を短縮することが出
来る。

【００５３】

【発明の効果】以上説明したようにこの発明によるウィ
ンドウ再描画方法は、ウィンドウの再描画に要する処理
時間をより短縮することが出来る。

【図面の簡単な説明】

【図１】図１はこの発明によるウィンドウ再描画方法の
第１実施例とそれ以前の方法とを対比して示す動作フロ
ー図である。

【図２】この発明によるウィンドウ再描画方法を適用す
る情報処理装置の一実施例の構成を示すブロック図であ
る。

【図３】図２に示したＬＣＤに表示されるマルチウィン
ドウ画面の一例を示す図である。

【図４】図３に示したスタックトップ・ウィンドウが消
去された時のマルチウィンドウ画面を示す図である。

【図５】ウィンドウ再描画方法の第２実施例とそれ以前
の方法とを対比して示す動作フロー図である。

【図６】ウィンドウ再描画方法の第３実施例とそれ以前
の方法とを対比して示す動作フロー図である。

【図７】ウィンドウ再描画方法の第４実施例とそれ以前
の方法とを対比して示す動作フロー図である。

【符号の説明】

１ ＣＰＵ ４ 描画プロセッサ ５ ウィンドウ管理メモリ ６ 表示フレーム １０ ＬＣＤ(液晶ディスプレイ装置：ディスプレイ) ２０，２０ａ マルチウィンドウ画面 ２１ （最上位の）ウィンドウ ２２，２３，２４ （下位の）ウィンドウ ２２ｓ，２３ｓ，２４ｓ ウィンドウの部分（覆われて
いた部分） ３０ ポート ３１ ポート（専用の通信手段）

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ディスプレイ上に複数のウィンドウを表
   示するマルチウィンドウシステムの上位のウィンドウが
   消去されることにより、それより下位のウィンドウの前
   記上位のウィンドウによって覆われていた部分を再描画
   するウィンドウ再描画方法において、 描画処理を行なうサーバが出力した再描画要求イベント
   に応じて、クライアントから応答信号が入力した時に、
   該応答信号に続いて前記クライアントから入力して来る
   再描画を具体的に指示するリクエスト信号を、前記サー
   バが専用の通信手段を設けて受信することを特徴とする
   ウィンドウ再描画方法。
2. 【請求項２】 請求項１記載のウィンドウ再描画方法に
   おいて、 再描画すべき前記下位のウィンドウが複数個ある時に、
   前記サーバが出力する１回の再描画要求イベントに応じ
   て、前記クライアントが前記複数の下位のウィンドウに
   関するリクエスト信号を一連の情報として出力すること
   を特徴とするウィンドウ再描画方法。
3. 【請求項３】 請求項１記載のウィンドウ再描画方法に
   おいて、 前記サーバが前記ディスプレイ上に表示されている複数
   のウィンドウのプロトコル情報を記憶しておき、前記下
   位のウィンドウの再描画の必要が発生した際に該下位の
   ウィンドウに変更がない場合は、該下位のウィンドウの
   再描画を前記サーバがその記憶しているプロトコル情報
   に基いて行なうことを特徴とするウィンドウ再描画方
   法。
4. 【請求項４】 請求項１記載のウィンドウ再描画方法に
   おいて、 前記サーバから入力した再描画要求イベントに対して前
   記クライアントが直ちに応答信号を出力出来ない場合
   に、前記クライアントは前記再描画要求イベントを記憶
   して応答信号出力可能になった時に前記応答信号を出力
   し、該応答信号の入力により前記サーバが前記応答信号
   に続いて入力してくるリクエスト信号に応じた再描画を
   開始することを特徴とするウィンドウ再描画方法。