JP2892898B2 - ウインドウ管理方法及びラスタ表示ウインドウ管理システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はラスタ表示における情報
の管理に関し、特にウインドウと称される表示の領域に
おける情報の管理に関する。

【０００２】

【従来の技術】ラスタ表示は、例えば、１０２４ｘ１０
２４個のある固定されたサイズの画素、即ち、ピクセル
から成る矩形として表される。この表示領域内におい
て、ウインドウのセットを管理することが望ましい。ウ
インドウとは、表示の特定の領域に取り出されるテキス
トと図形情報の内の少なくとも一方のパターンである。
領域とは、表示ピクセルのあらゆる任意のサブセットで
ある。ウインドウはユーザに情報を提示し、コマンドと
データが図形制御及びデータ入力フィールドを介して入
力できるよう図形ユーザインタフェーシングを提供する
ため、データ処理システムにおいて広範囲に使用され
る。これらのウインドウは、情報の入出力のため標準化
された矩形の表示領域に提供される。しかしながら、全
てのウインドウが矩形というわけではない。図形及び他
の目的のため、標準化されていない、即ち、カスタマイ
ズされたウインドウを提供する他のウインドウ表示構成
があり、種々の形状、サイズ及び情報内容を備えてもよ
い。

【０００３】従来より、表示ウインドウが有する積み重
ね（スタッキング）順序では、積み重ね順序において上
部にあるウインドウがより下にある他のウインドウを不
明瞭にする。従って、ウインドウは、最上部のシートだ
けが完全に見えるが、いくつかのシートは全く見えない
紙のシートのようにデスクトップに配置される。紙の束
と同様に、ウインドウは表示において周期的に追加、削
除若しくは再配置される。これは一連のデータ処理ステ
ップを必要とし、ウインドウ操作と称される。ウインド
ウ操作は、以下のタスクのいずれかが要求されるときに
行われる。 １．表示の領域上に新たなウインドウを作成する。 ２．ウインドウを破壊する。 ３．ウインドウが画定される領域を変更する。 ４．ウインドウの積み重ね順序を変更する。 これらの操作のいずれもが、表示情報の再編成を表示す
る表示更新のリストとなる。各更新によって、あるウイ
ンドウの現れた部分、若しくは背景と共に表示の領域を
書き込む。

【０００４】一般的なウインドウ操作は、図１及び図２
に示される。３個の円形のウインドウＡ、Ｂ及びＣは、
ＡＢＣの順序で積み重ねられている。ウインドウＢが上
方へ動かされるならば、１とラベル付けされた領域はウ
インドウＢの内容と共に描き直され、２とラベル付けさ
れた領域はウインドウＣの内容と共に描き直されなけれ
ばならない。この問題を扱うために使用される標準的な
手法は、まず変更される領域の全てを包囲する矩形を計
算することである。例えば、ウインドウを削除する場
合、矩形はウインドウを包囲する。ウインドウを移動す
ると、矩形は以前のウインドウの位置及び新たなウイン
ドウの位置の双方を包囲する。いったん画定されると、
矩形は背景色へとクリアされる。次に、矩形と交差する
全てのウインドウが描き直される。描き直しは矩形にク
リップ（制限）されて、矩形内のピクセルのみが描き直
される。ウインドウは、最下部から最上部へと、逆の順
序で描き直されなければならない。矩形と交差しないウ
インドウは、描き直されない。

【０００５】前述の手順が多くの市販の図面エディタ
（編集プログラム）において使用されるが、いくつかの
不利な点がある。第１に、その方法は、多くのウインド
ウが描き直される必要があるならば遅くなる。第２に、
破壊された領域は何度も描き直されて領域のちらつきを
もたらし、ユーザに迷惑となる。第３に、処理されたウ
インドウ外にあるが計算された矩形内にあるピクセルを
不必要に再ペイント（描画）するため、矩形でないウイ
ンドウが表示されると非効率的となる。従って、表示の
更新の間に矩形でない（及び矩形の）ウインドウへの多
くの変更が可能だが、更新が要求されると最小の数のピ
クセルが描き直されるような、ウインドウ管理方法に対
する必要性が明らかである。この方法によって、処理時
間は短縮され、表示のちらつきが回避される。

【０００６】

【発明が解決しようとする課題】本発明の目的は、ラス
タ表示においてウインドウを管理するための方法を提供
することである。

【０００７】

【課題を解決するための手段と作用】本方法は、第１表
示画像を構成するラスタ表示において一連の画素ランを
識別する値から成る、第１表示マップの生成を含む。各
識別された画素ランは、ランの画素を共通に含むウイン
ドウのセットを有する。ウインドウは積み重ね順序で配
置され、ラスタ表示において描き直される最上部のウイ
ンドウ、及び最上部のウインドウによって覆われるその
他のウインドウを備える。ウインドウが追加、削除又は
移動されるとき及び、ウインドウ積み重ね順序が変更さ
れるときにウインドウ操作が生じる。ウインドウ操作に
対応して、第２表示画像を構成するラスタ表示において
一連の画素ランを識別する値から成る、第２表示マップ
が生成される。各識別された画素ランは、ランの画素を
共通に含むウインドウのセットを有する。ウインドウは
積み重ね順序で配置され、ラスタ表示において描き直さ
れる最上部のウインドウ、及び最上部のウインドウによ
って覆われるその他のウインドウを備える。ラスタ表示
を復元するため、第１表示マップは第２表示マップと比
較されて、最上部のウインドウが変更された画素を識別
する。ラスタ表示は、識別された画素の最上部のウイン
ドウからデータと共に変更された画素を書き込むことに
よって再ペイントされる。

【０００８】

【実施例】ウインドウ管理システムの概要 図３を参照すると、本発明のウインドウ管理システムは
従来の設計のデータ処理装置１０に実施されてもよく、
データ処理装置１０はスタンドアロン又はネットワーク
型パーソナルコンピュータ（ＰＣ）、ワークステーショ
ン又は中間範囲又はメインフレームコンピュータシステ
ムで操作されるよう構成される端末を含む。データ処理
装置１０は概して、ＣＰＵ１２と、キーボードデバイス
１４及びオプションとしてマウス１６を有する入力シス
テムと、データ記憶デバイス１８と、ラスタ表示デバイ
ス２０を含む出力システムと、を備える。データ記憶デ
バイス１８は、データ処理装置１０を制御するためのプ
ログラムを含み、ラスタ表示デバイス２０において画像
を生成する。従来のとおり、ラスタ表示デバイスは、図
３に示されるように、一連の水平な走査線に配置される
複数の照射された画素、即ち、ピクセルによって形成さ
れる画像を生成する。

【０００９】データ記憶デバイス１８は、ラスタ表示デ
バイス２０において表示されるべきウインドウを画定す
るためのプログラミング資源を記憶する。これらの資源
３０は、図４において集合的に示されている。ウインド
ウ情報は、従来技術に従って種々の方法で記憶されてよ
い。例えば、ウインドウはピクセルアレイとして記憶さ
れ、ここでシーケンシャルなメモリ位置が表示の個々の
画素を駆動するための情報を記憶する。表示更新は、記
憶されたピクセルアレイ情報を読み取ることによって生
成される。他の場合では、例えば、もしウインドウが図
形を管理するのに使用されるならば、ウインドウはソリ
ッドカラー（全面色）で構成される。これらのウインド
ウは、ピクセル値の範囲、対応する色及び他の表示情報
を識別することによって記憶されてもよい。他の場合に
おいて、ウインドウは、再ペイント動作が発生するとき
に実行されるプログラミングコードによって画定され
る。

【００１０】ウインドウは表示（ディスプレイ）の領域
上に画定される。ウインドウが表示上にない領域も含む
ように画定されてもよいが、表示されたウインドウ部分
のみが管理を必要とする。図３に示されるように、表示
２０の左上のピクセルは（０、０）とラベル付けされ、
ｘは左から右に走行し、ｙは上から下に走行する。図３
は、以下の論議を簡単にするため、各々１０個のピクセ
ルから成る１０本の走査線を有する表示で図示されてい
る。上記されたように、従来の表示は１０２４ｘ１０２
４個のピクセルから成るアレイを備える。３つのウイン
ドウＡ、Ｂ及びＣは、図示される積み重ね順序で重なり
関係にあるように示されている。ウインドウの形状は矩
形だが、円形又は多くの他の形状であってもよいと理解
される。

【００１１】図４を参照すると、表示２０は、ウインド
ウ操作を制御するためのアプリケーションソフトウェア
資源３０及びウインドウ管理システム３２に関連して示
される。ウインドウ管理システム３２は、表示に関連し
て以下の操作を実行しなければならない。 １．表示の領域上に新たなウインドウを作成する。 ２．ウインドウを破壊する。 ３．ウインドウが画定される領域を変更する。 ４．ウインドウの積み重ね順序を変更する。

【００１２】操作３及び４は、操作１及び２に関連して
派生する。ウインドウの領域を変更するため、ウインド
ウは破壊され、新たな領域と共に再生成される。同様
に、ウインドウを再度積み重ねるため、ウインドウは破
壊されて、新たなウインドウが新たな位置において積み
重ね順序で生成される。いかなる数のウインドウ操作動
作も実行でき、表示更新が要求されてもよい。更新時に
おいて、表示の変更された部分が描き直される。

【００１３】ウインドウ管理システム３２は、３つの主
なデータ構造タイプ、即ち、ウインドウ記述子アレイ３
４、カバー収集３６、古い表示マップ３８と新たな表示
マップ４０、を生成し、実行する。ウインドウ記述子ア
レイ３４は、ウインドウ記述子構造４２の収集に対する
ポインタのリストであり、ウインドウ管理システム３２
によって生成される。各ウインドウ記述子構造は対応す
る表示ウインドウを識別し、ウインドウ積み重ね順序に
おけるウインドウの位置に関する情報を含む。

【００１４】カバー収集３６は、共通のウインドウを共
有するピクセル・ランを識別するため使用される。各ウ
インドウは表示上のピクセルのあるサブセットを含む。
各ピクセルに対して、そのピクセルを含むウインドウの
あるサブセットもある。ウインドウの順序がウインドウ
記述子構造４２から分かるため、各ピクセルは、ピクセ
ルを含む各ウインドウにつき１ビットから成る、ビット
の列によって特徴付けられてもよい。ビットがオンなら
ば、ウインドウはピクセルを含む。ビットがオフなら
ば、ウインドウはそのピクセルを含まない。このビット
列は、ピクセルの「カバー」と称される。一般に、カバ
ーはピクセルに対して固有ではない。多くのピクセルは
同一のセットのウインドウによって含まれ、同一のカバ
ーを共有する。カバー収集３６は、表示マップになお使
用される全ての別々のカバーのセットである。

【００１５】表示マップ３８及び４０は、表示上のピク
セルのラン長符号化を識別する値のアレイである。これ
らのラン長表示は、ウインドウ領域においてどのピクセ
ルが含まれるかを決定するために使用される。各行（ウ
インドウ領域と交差する表示の走査線）において、以下
のことが記録される。 ・走査線のｙ値 ・走査線におけるピクセルランの数 ・走査線のラン長符号化

【００１６】ラン長符号化は長さのアレイである。第１
長は、領域内にある走査線の左エッジからのピクセルの
数（ゼロであってもよい）である。次のラン長は、領域
内にないこの群の後のピクセルの数である。続くランで
は、領域内のピクセルの数と領域外のピクセルの数を交
互に示す。全てのランの全長は、表示幅に等しくなけれ
ばならない。ピクセルの各ランは、同一のカバーを共有
する。換言すれば、ランにおける全てのピクセルはウイ
ンドウの同一のセットに含まれる。２つの表示マップが
保持される。一群のウインドウ操作が開始されると、現
在の表示マップが「古い」表示マップ３８としてセーブ
される。操作が進行するにつれて、「新たな」表示マッ
プ４０が生成される。更新時に古い表示マップと新たな
表示マップが比較されて、表示が描き直される。

【００１７】前述のデータ構造は、簡単に表示及び操作
されるよう表示上のウインドウの複雑な重なりを可能に
する。表示の一部を新たなウインドウで更新するのに必
要な時間は、主に、ウインドウのサイズとそのウインド
ウをカバーする他のウインドウの数との関数である。ウ
インドウの全数は、表示を変更するための時間に間接的
に影響を及ぼすだけに過ぎない。

【００１８】ウインドウ記述子アレイ 前述のように、表示内の各ウインドウは、ウインドウ記
述子構造４２においてウインドウ管理システム３２によ
って識別される。ウインドウ記述子アレイ３４は、ウイ
ンドウ記述子構造に"maxwindows"（処理できるウインド
ウの最大の数）ポインタのリストを提供する。図５は、
図３に示されるウインドウＡ、Ｂ及びＣに対応する３つ
のウインドウ記述子構造４２ａ、４２ｂ及び４２ｃを示
す。ウインドウ記述子アレイ３４は、これらの構造に対
するポインタＷ_A 、Ｗ_B 及びＷ_Cを含む。各ウインドウ
記述子４２ａ、４２ｂ及び４２ｃは、ウインドウＡ、Ｂ
及びＣのための以下の情報を含む。 index ウインドウ記述子構造を指すウインドウ記
述子アレイにおける位置。 depth 積み重ね順序においてウインドウの位置を
示すアプリケーションソフトウェアによって提供される
整数。ウインドウＡの深度がウインドウＢの深度より小
さいならば、ウインドウＡは積み重ね順序においてウイ
ンドウＢより上にある。 below ウインドウ積み重ね順序においてこのウイ
ンドウより下のウインドウへのポインタ。 above ウインドウ積み重ね順序においてこのウイ
ンドウより上のウインドウへのポインタ。 destroyed ウインドウが破壊されたことを示すフラ
グ。 従って、ウインドウ記述子構造はウインドウＡ、Ｂ及び
Ｃの積み重ね順序を指定する。更に、ウインドウは、
「より上(above) 」ポインタ及び「より下(below)」ポ
インタを用いて二重連係リストに配置される。更に頂部
ウインドウＡは変数"topwindow" （図示せず）に記録さ
れ、底部ウインドウＣは変数"bottomwindow"（図示せ
ず）に記録される。

【００１９】カバー収集 上述のように、カバー収集３６はウインドウ"covers"の
リストである。従って、カバー収集３６における入力
で、表示上に重なるウインドウのセットを示す。図６
は、図３に示されるように、表示２０におけるウインド
ウＡ、Ｂ及びＣの配置を表すカバーを含むカバー収集を
示す。各カバーは、以下の情報を含む。 cover index カバー収集におけるカバーの位置。 bitmap 各々が"window"アレイにおける位置に
対応する"maxwindow" ビットのアレイ。もしビットがオ
ンならば、対応するウインドウはカバー内にある。 refcount このカバーを有する表示ピクセルの
数。 topmost カバービットマップにある最上の（深
度の最も小さい）ウインドウの"index" （"windows" ア
レイにおける位置）。

【００２０】図３の表示２０において、全体で８個の別
々のカバーがあることが分かる。カバー収集３６におい
てカバーインデクッスゼロ(0) で示される第１カバー
は、ゼロ、即ち、カバー収集ビットマップにおいてウイ
ンドウビットセットがない背景カバーである。最初に、
カバー収集は表示ピクセルの全てを含むゼロカバーのみ
を備える。ウインドウが表示に追加されるにつれて、カ
バー収集が拡大される。表示２０のカバー表示におい
て、背景カバーはカバーインデックスゼロの"refcount"
値に示されるように、３７個のピクセルを含む。カバー
１は全てのピクセルを含むウインドウＡのみに適用す
る。カバー１のrefcount値は１７で、topmostはＷ_A で
ある。カバー２は全てのピクセルを含むウインドウＢの
みに適用する。カバー２のrefcount値は１６で、topmos
t はＷ_B である。カバー３は全てのピクセルを含むウイ
ンドウＡとＢのみに適用する。カバー３のrefcount値は
５で、topmost はＷ_A である。カバー４は全てのピクセ
ルを含むウインドウＡ、Ｂ及びＣのみに適用する。カバ
ー４のrefcount値は１で、topmost はＷ_A である。カバ
ー５は全てのピクセルを含むウインドウＢとＣのみに適
用する。カバー５のrefcount値は３で、topmost はＷ_B
である。カバー６は全てのピクセルを含むウインドウＣ
のみに適用する。カバー６のrefcount値は１９で、topm
ost はＷ_C である。カバー７は全てのピクセルを含むウ
インドウＡとＣのみに適用する。カバー７のrefcount値
は２で、topmost はＷ_A である。

【００２１】現在作動中のカバーのセットは、２つの方
法でアクセスできる。 ・ピクセルの特定のランのカバーが必要なとき、cover
_- index を用いて。 ・ウインドウを生成又は削除することで新たなカバーが
生成されるとき、bitmapを用いて。 cover _- index によるアクセスを処理するため、カバー
はカバー収集３６にアレイとして保持される。アレイは
ヒープ記憶装置から割り当てられ、全ての作動カバーを
保持するため必要に応じて拡張されてもよい。cover _-
index はカバーが生成されるとき割り当てられ、カバー
のアレイにおける位置である。ビットマップによってア
クセスを処理するため、ハッシュテーブル（図示せず）
がカバー上に生成される。ハッシュインデックスは、ビ
ットマップパターンから生成される。カバーがもはや使
用中ではないとき、フリー（空いた）カバーのリスト
（図示せず）に追加される。フリーのときのカバー記述
子の有効フィールドのみが、cover _- index である。新
たなカバーが必要とされると、カバーアレイを拡張する
前にフリーリストが検査される。

【００２２】表示マップ 前述のように、表示マップ３８及び４０は、表示の走査
線あたり１エントリをもった複数の記憶位置を有するア
レイである。図７は、ウインドウ操作が行われる前の、
図３に示される表示２０の表示マップ３８を示す。表示
マップの各エントリは、走査線上に使用されるカバーの
ラン長符号化である。各入力は、以下を含む。 scanlen 走査線におけるランの数。 runs ランを含む記憶装置へのポインタ４４。

【００２３】各ランは、表示マップ記憶領域４６に一対
の値として記憶される。 count ランにおけるピクセルの数。 cover _- index ランにおける全てのピクセルによって
共有されるカバーのインデックス。ランのカバーは、こ
のインデックスを用いてカバー収集にアクセスすること
により見つけられる。 従って、図３の表示２０は１０本の走査線を含み、ピク
セルカウント及び対応するカバーがメモリアドレスロケ
ーションＡ₀ 乃至Ａ₃₄に記憶される３５個のピクセルラ
ンを含む。

【００２４】ウインドウの生成及び削除 前述のように、全てのウインドウ操作はウインドウを追
加及び削除することによって行われる。複雑な操作にお
いて、ウインドウの追加と削除は、表示が復元される前
に何度も行われる。しかしながら、最終的な表示を生成
するため変更される必要のあるピクセルのみが実際、再
ペイントされる。ウインドウがアプリケーションソフト
ウェア３０によって生成又は削除されると、ウインドウ
の積み重ね位置を表す値とウインドウによって占有され
る表示領域は、ウインドウ管理システム３２によって得
られる。ウインドウ生成操作において、ウインドウ管理
システム３２は新たなウインドウ記述子構造４２を生成
し、ウインドウ記述子構造の"above" ポインタ及び "be
low"ポインタ及び上下に隣接するウインドウ記述子構造
の"above" ポインタ及び "below"ポインタを設定するこ
とによって、ウインドウの連係リストへとウインドウを
挿入する。

【００２５】ウインドウ記述子構造の"index" 入力は、
第１ゼロポインタに対するウインドウ記述子アレイ３４
を走査することによって割り当てられる。このアレイ位
置には、新たなウインドウ記述子構造４２に対するポイ
ンタが提供される。次に、ウインドウ記述子構造"inde
x" 値が設定され、ウインドウ記述子アレイにおける位
置を指す。ウインドウ記述子構造"depth" 値は、より上
のウインドウ（又はこれが最上部のウインドウならば
０）とより下のウインドウ（又はこれが最下部のウイン
ドウならば最大の整数）の深さの平均をとることによっ
て割り当てられる。より下のウインドウとより上のウイ
ンドウの深さの差が１ならば、最上部のウインドウから
の深さを、対応するウインドウ記述子構造の"depth" 値
に割り当てることによって、全てのウインドウに新たな
深さが与えられる。

【００２６】ウインドウ記述子構造が直ちに空かない場
合を除いて、ウインドウが破壊されると変換操作が行わ
れる。代わりに、"destroyed" フラグが設定される。次
の表示が発生すると、ウインドウ記述子構造は空き、そ
の"index" 値はNULL（ゼロ）に再設定されて、ウインド
ウ記述子アレイは削除されたウインドウ記述子構造への
ポインタを除去するように変更される。

【００２７】走査線の変更 ウインドウ操作がアプリケーションソフトウェア３０に
よって実行されるため、ウインドウ管理システム３２
は、（新たな表示マップ４０として）表示マップ３８の
走査線を変更して、ウインドウの追加及び削除を反映す
る。表示の選択された領域に含まれる最も下から最も上
の各走査線は、新たなバージョンと置換される。新たな
バージョンを生成するため、ウインドウの領域と交差す
るピクセル・ランは、カバーインデックスと各ランのピ
クセルの数とにおける変化を反映するように変更され
る。各ウインドウの追加又は削除は、新たな表示マップ
を生成させる。第１の新たな表示マップ４０は、古い表
示マップ３８を変更することによって生成される。その
後、続く新たな表示マップがそれ以前の新たな表示マッ
プを変更することによって生成される。大切なことは、
古い表示マップ及び最後の新たな表示マップのみがセー
ブされる必要があることである。以下に述べられるよう
に、それらマップが単独で用いられて表示を復元する。

【００２８】図８乃至図１１は、表示マップ変更手順の
論理的フローを示している。手順はまた擬似コード形式
で示される。この手順は、ウインドウ操作前の表示２０
を示す図３と、ウインドウが図３に示される初期位置か
ら右上方に動かされた操作後の表示２０を示す図１２に
関連して示される。このウインドウ操作は２つの従属操
作で行われる。第１操作においてウインドウＢは初期位
置から削除され、第２操作においてウインドウＢが新た
な位置で追加される。

【００２９】ウインドウ削除操作において、アプリケー
ションソフトウェア３０は、ウインドウ管理システム３
２に対してウインドウＢの初期領域座標及び積み重ね位
置を提供する。図３より、ウインドウＢは最初に走査線
１から５及びピクセル列３から７を含むことが分かる。
ウインドウＢはウインドウ積み重ね順序において２番目
である。初期位置におけるウインドウＢの削除に応じる
と共に、表示マップを変更する前に、ウインドウ管理シ
ステム３２は、ウインドウＢが削除されたことを示すよ
うウインドウ記述子構造４２ｂにおいてウインドウ"des
troyed" フラグを設定する。次に、ウインドウ管理シス
テムは、図８乃至図１１の表示マップ変更手順を用いて
新たな表示マップを生成する。その手順の記述におい
て、以下の略語がデータ構造における項目に使用され
る。 region ウインドウが生成又は削除される操作の選
択された領域。図３において、その領域は表示２０全体
をカバーする。 oldscan 置換中の走査線。 oldcover oldscan における現在のランのカバー。 newscan 作成される走査線の新たなコピー。 newcover newscan における現在のランのカバー。 xposn 走査線を作成している間の現在のｘ位置。 regionrem 新たな表示マップにおける領域ランの未処
理の部分。 scanrem 古い表示マップにおけるoldscan ランの未
処理の部分。 lastcover newscan で生成される最後のラン上に使用
されるカバー。 lastrun newscan で生成される最後のランの長さ。 newrun newscan のため生成される新たなランの長
さ。

【００３０】走査線変更手順の第１ステップはメモリ割
り当てステップ５０であり、ここで表示マップ４０の各
新たな走査線("newscan") のスペースが割り当てられ
る。メモリ割り当てに続いて、以下の変数が初期設定ス
テップ５２において初期設定される。 xposn = 0 regionrem = 0 scanrem = 0 lastcover = カバーなし lastrun = 0

【００３１】ステップ５４から始まって、xposn が表示
幅より狭い間に、古い表示マップ３８において第１走査
線("oldscan") の各ランが処理される。ステップ５６に
おいて、新たな表示マップにおけるランの処理は、変数
regionrem がゼロかどうかをテストすることによって監
視される。regionrem の値がゼロでないならば、処理は
ステップ６４に進む。手順の開始時及び新たな表示マッ
プにおける新たな各ランの作成に続いて起こるように、
regionrem の値がゼロならば、プロセスはステップ５８
に移動して、新たな表示領域の次のランが得られる。こ
れらのランは、古い表示領域からのランを用いて見つけ
られる。ランが追加されるべきウインドウを横切らなけ
れば、各ランはコピーされる。ランがウインドウを横切
る場合は、古いランは、横切る各ウインドウエッジにお
いて２つのランに分割される。ウインドウが削除中なら
ば、古いランは初期のラン長を変更せずに使用できる。
図３において先ずウインドウＢが削除される。図３にお
いて走査線１の処理すべき第１の新たなランは古いラン
と同じ長さで、表示列０から２をスパンする（及ぶ）。
図１２においては図３においてウインドウＢが削除され
たのに続いてウインドウＢが移動した位置に置かれる。
ウインドウＢが追加された後では、走査線１の処理すべ
き第１の新たなランは、表示列０から追加のウインドウ
Ｂのエッジがある列３に延びる。いったん新たなランが
得られると、ステップ６０において、そのラン長はregi
onrem を再設定するために使用される。ステップ６４に
おいて、古い表示マップにおけるランの変数処理は、変
数scanrem がゼロかどうかをテストすることによって監
視される。scanrem がゼロでないならば、プロセスはス
テップ６８に進む。手順の開始時及び古い表示マップに
おける各ランの処理に続いて起こるように、scanrem の
値がゼロならば、プロセスはステップ６６に進んで、古
い表示マップの次のランが得られる。これらのランは、
古い表示マップからの現存するランを用いて見つけられ
る。図３において、走査線１の処理すべき第１の古いラ
ンは、表示列０からウインドウＢのエッジがある列２に
延びる。図１２において、走査線１の処理すべき第１の
古いランは、表示の幅全体にスパンする。処理ステップ
６６において、scanrem は得られるランの長さで再設定
される。ステップ６８において、変数oldcoverには古い
走査線ランのカバーインデックスが割り当てられる。図
３において、表示列０から２をスパンするoldscan ラン
（図７のカバー収集のランＡ１）のカバーはゼロであ
り、ランがウインドウを含まないことを示している。同
様に、図１２において、走査線１の表示列０から９をス
パンするoldscan ランのカバーはゼロであり、ランにウ
インドウがないことを再度示している。前述のステップ
５４乃至６８は、擬似コード形式で以下のように示され
る。

【００３２】

【表１】

【００３３】走査線変更処理における次のステップは、
古い領域のラン及び新たな領域のランの交差点に新たな
ピクセルを生成することである。これは、ステップ７０
において、regionrem 値及びscanrem 値を比較して、ど
ちらの値が最小のピクセル長を有するかを決定すること
によって行われる。ウインドウＢが削除される図３にお
いて、走査線１の開始時に、scanrem によって表される
古いラン長がピクセル３個に等しい。regionrem によっ
て表される新たなラン長もまたピクセル３個に等しい。
新たな表示マップへの追加と考えられるnewrunを示す交
差点は、３個のピクセルのラン長を有する。ウインドウ
Ｂが追加される図１２において、走査線１の開始時に、
scanrem によって表される古いラン長はピクセル１０個
に等しい。regionrem によって表される新たなラン長は
ピクセル４個に等しい。新たな表示マップへの追加と考
えられるnewrunを示す交差点は、４個のピクセルのラン
長を有する。処理ステップ７０は、擬似コード形式で以
下のように示される。

【００３４】

【表２】

【００３５】newrunの値が設定されると、ステップ７２
において、プロセスは、newrunが追加されたウインドウ
又は削除されたウインドウのピクセル領域内にあるかど
うかを確認する。領域内になければ手順はステップ７３
に進み、ウインドウ操作の結果としてカバーが変化しな
いため、newrunのカバーであるnewcoverがoldcoverと等
しいように設定される。図３において、走査線１の開始
時に、newrunが第１の３個の表示列をスパンしており、
ウインドウＢの領域外にある。この場合、newrunはoldc
over値ゼロが割り当てられる。同様に、図１２におい
て、走査線の開始時に、newrunは第１の４個の表示列を
スパンし、それはウインドウＢの領域外にある。従っ
て、この場合のnewrunもまたoldcover値ゼロが割り当て
られる。次に、手順は処理ステップ７４にジャンプす
る。newrunがウインドウ領域内にあるならば、処理ステ
ップ７４が実行されて、後述のカバー生成プロセスを介
して"newcover"と称される新たなカバーインデックスを
生成する。図３において、新たな表示領域の第２newrun
である走査線１は表示列３から７をスパンする。図１２
において、新たな表示領域の第２newrunである走査線１
は表示列４から８をスパンする。これらnewrunはウイン
ドウ領域内にあって、新たなカバーを受信する。処理ス
テップ７２及び７４は、擬似コード形式で以下のように
示される。

【００３６】

【表３】

【００３７】新たなカバーが生成されるならば、走査線
変更プロセスの次の連続ステップが実行される。これら
のステップにおいて、変数oldcoverによって表される古
いカバーと、変数newcoverによって表される新たなカバ
ーに対応する、表示における画素の数を表す変数"refco
unt"が調整される。処理ステップ７６において、oldcov
er refcount は新たな画素ラン"newrun"でピクセルの数
だけ減分される。処理ステップ７８において、oldcover
のrefcount値がゼロかどうかテストされる。refcount値
がゼロならば、ステップ８０においてoldcoverはフリー
カバーリストに配置される。次にプロセスはステップ８
２に進み、newcoverのrefcount値はnewrunにおいて画素
の数だけ増分される。処理ステップ７６乃至８２は、擬
似コード形式で以下のように表される。

【００３８】

【表４】

【００３９】走査線変更プロセスの次の連続ステップ
は、新たな表示マップの中へ新たなランを作成すること
である。しかしながら、新たなランは新たなマップに直
ちに追加されるのではない。新たなランが直ちに追加さ
れたならば、走査線はウインドウ操作が進むにつれて、
各ランがピクセル１個のみを含むようになるまで、より
多くのランへと細分化されることになる。代わりに、ne
wrunが生成されると、そのカバーが処理された最後のラ
ンのカバーと同一かどうかを見るため比較される。カバ
ーが同一ならば、ランは組み合わされる。これによっ
て、走査線が最小の数のランに保たれる。カバーが同一
でなければ、以前に処理されたランが新たな表示マップ
に追加される。従って、処理ステップ８４で始まって、
最初にゼロに設定される変数lastcover は、newcoverと
同一かどうかテストされる。カバーが同一ならば、プロ
セスはステップ９２に進む。lastcover がnewcoverと等
しくなければ、カバーは変更され、以前に処理されたラ
ンが作成される走査線の新たなコピーに追加される。こ
のランは、lastrun のピクセルカウント（初期値ゼロ）
とlastcover に等しいカバーを有する。処理ステップ８
８及び９０において、変数lastcover はnewcoverの値に
割り当てられ、変数lastrun はゼロに設定される。処理
ステップ９０に続いて、即ち、処理ステップ８４がFALS
E （誤った）出力を生じる（即ち、lastcover がnewcov
erと等しい）ならば、変数lastrun はnewrunの長さだけ
増分される。これは、処理ステップ９２で生じる。図３
において、走査線１の第１newrun（表示列０から２をス
パンする）が最後のカバー初期値ゼロに対してテストさ
れる。カバー値は異なることが分かり、新たなランが処
理ステップ８６において新たな表示マップに追加され
る。しかしながら、新たなランはピクセルカウントと初
期値ゼロに等しいカバーを有する。換言すれば、第１ne
wrunは未だ新たな表示マップに追加されていない。第２
newrunが処理され、そのカバーが第１newrunのカバーと
等しいかどうかテストされる後まで、追加されない。し
かしながら、追加する前に、プロセスはステップ９２に
進み、lastrun は第１newrunのラン長だけ増分される。
同様の手順は、図１２の走査線１の第１newrunにおいて
も実行される。前述のステップ８４乃至９０は、擬似コ
ード形式で以下のように示される。

【００４０】

【表５】

【００４１】処理ステップ９４及び９６において、変数
scanrem 及びregionrem はnewrunの値だけ減分される。
処理ステップ９８において、表示位置xposn は次の画素
ランを処理するためnewrunの値だけ増分される。次に、
手順は次のランを処理するためステップ５４に戻る。処
理ステップ９４乃至９８は、擬似コード形式で以下のよ
うに示される。

【００４２】

【表６】

【００４３】残りの走査線が同様に処理される。図３に
おいて、走査線１の第２newrunは表示列３から７をスパ
ンする。newcoverは、ウインドウＢが除去されるためゼ
ロである。処理ステップ８４において、このnewcoverは
走査線１の第１newrunのlastcover に等しいことが分か
る。手順は処理ステップ９２にジャンプし、lastrunは
第２newrunのラン長だけ増分される。従って、lastrun
は表示列０から７をスパンし、lastcover はゼロであ
る。手順の第３パスは、図３の走査線１の第３newrun及
び最後のnewrunを処理するために生成される。このnewr
unは表示列８から９にスパンし、newcover値ゼロを有す
る。処理ステップ８８において、このnewcoverがlastco
ver に等しいことが分かる。従って、処理ステップ９２
が再実行され、lastrun は第３newrunのラン長だけ増分
される。従って、lastrun は表示幅全体に等しい。手順
が第４パスに戻ると、xposn が表示幅に等しいことが分
かる。この点で、手順はステップ１００及びステップ１
０２を開始し、最後のランを処理する。ステップ１００
において、lastrun の値がゼロかどうかテストされる。
lastrun がゼロならば、次の走査線の処理が開始され
る。lastrun がゼロでないならば、ステップ１０２が実
行され、lastrun がlastcover のカバーと共に新たな表
示マップに追加される。処理ステップ１００乃至１０２
は、擬似コード形式で以下のように示される。

【００４４】

【表７】

【００４５】図３の場合において、表示幅全体をスパン
し、カバー値ゼロを有する単一ランが、新たな表示マッ
プに追加される。同様に、図１２の走査線１に対して３
本の新たなランが新たな表示マップに追加されることが
分かる。手順の第１パスにおいて、表示列０から３をス
パンする第１newrunが画定されるが、新たな表示マップ
に追加されるのではない。手順の第２パスにおいて、表
示列４から８をスパンする第２newrunが画定される。処
理ステップ８４において、第２newrunのカバーは第１ne
wrunのカバーと比較される。カバーは異なることが分か
り、処理ステップ８６において第１newrunが新たな表示
マップに追加される。手順の第３パスにおいて、表示列
９をスパンする第３newrunが画定される。処理ステップ
８４において、第３newrunのカバーは第２newrunのカバ
ーと比較される。カバーは異なることが分かり、処理ス
テップ８６において第２newrunが新たな表示マップに追
加される。処理ステップ１０２において第３newrunが新
たな表示マップに追加される。

【００４６】前述の手順において、各ランが生成される
につれて、含まれるカバーの"refcount"フィルードが更
新される。"newcover"ランがランのピクセルを得て、"o
ldcover"ランがランのピクセルを失う。これら"refcoun
t"は最適化だけではない。アルゴリズムのワーカビリテ
ィは、カバー収集におけるカバーの数を低くしておくこ
とに依存する。カバーが空かなければ、ウインドウ操作
が行われるにつれて未使用のカバーがすばやく蓄積し、
全ての入手可能な記憶装置を使い果たす。生成されるカ
バーの可能な数は２^maxwindowsである。

【００４７】走査線変更手順の説明を単純にするため、
処理される領域は表示幅全体をスパンするものとなって
いる。しかしながら、これは余分な作業をもたらす。代
替的方法として、追加されたウインドウもしくは削除さ
れたウインドウのピクセル領域を交差するランのみの処
理がある。ウインドウ領域外に全体が位置する走査線ラ
ンは、新たな表示マップにコピーされるだけである。走
査線の開始時において、領域走査線と交差する第１ラン
に達するまでランはコピーされる。同様に、領域の最後
のランが検出されると、走査線の残りのランが"newsca
n" にコピーされる。しかしながら、ウインドウ領域後
の第１コピーされたランは、領域の最後のランと同一の
カバーを有するかどうか検査されるのが好ましい。さも
なければ、不必要なランが生成されることもありうる。

【００４８】新たなカバーの生成 走査線変更処理のステップ７４において、"newscan" に
追加されるべきランの新たなカバーが生成されなければ
ならない。古いランのカバーインデックスと共に、生成
または削除されようとするウインドウのウインドウ記述
子インデックスが入力となる。古いカバーは、古いラン
のカバーインデックスを用いて、カバー収集３６にアク
セスすることにより発見される。古いカバーのビットマ
ップから、ウインドウインデックスに対応するビットを
オンにすることによって新たなビットマップが生成され
る。次に、このビットマップと共に現存するカバーの検
索は、カバーリストへのハッシュテーブルアクセスを用
いて行われる。ビットマップが見つかれば、"newcover"
は識別されたビットマップのカバーインデックスに割り
当てられる。ビットマップが見つからなければ、新たな
カバーが生成されなければならない。

【００４９】新たなカバーを生成するため、先ず、フリ
ーカバーのリストが対応するビットマップのため検査さ
れる。フリーカバーの中に対応するビットマップが見つ
からなければ、カバー収集３６に新たなスロットが割り
当てられる。新たなカバーのフィールドは以下のように
設定される。 ・cover _- index はカバーリストアレイに配置される位
置である。 ・bitmapは古いビットマップを変更することによって生
成される新たなビットマップである。 ・refcountは最初にゼロであり、処理ステップ８２にお
いて再設定される。 ・topmost は生成されるウインドウの深さと古いカバー
によって示される最上部のウインドウの深さを比較する
ことによって設定される。もし新たな深さがより小さい
ならば、新たなウインドウはtopmost になる。深さが小
さくなければ、古いウインドウがなお最上部ウインドウ
のままである。

【００５０】ウインドウの破壊は、新たなカバーが生成
される方法を除いて、ウインドウの生成と同様である。
ウインドウが生成されると、新たなウインドウに対応す
るビットを設定することによって新たなビットマップが
生成される。ウインドウが破壊されると、ビットマップ
における対応するビットはオフにされる。"topmost"フ
ィールドが生成される方法もまた変更される。ウインド
ウが生成されると、カバーの最上部ウインドウは、前の
最上部ウインドウもしくは新たなウインドウのいずれか
でなければならない。ウインドウを破壊すると、新たな
topmost はカバーにおいていかなるウインドウにもなり
うる。"topmost" と示されるウインドウ以外のいかなる
他のウインドウも破壊されるならば、"topmost" は変更
されない。"topmost" ウインドウが破壊されるならば、
ビットマップは走査されなければならない。"topmost"
は、ビットマップに示されるウインドウの内の最小の深
さのウインドウに設定される。

【００５１】新たなカバーを検索するために使用される
手順は、走査線変更手順の内部ループの重要な部分であ
る。古いカバーのビットマップは変更され、ハッシュキ
ーは生成され、新たなカバーはハッシュテーブルに見つ
けられなければならない。このステップは、プロセスの
間に調べられるランの多くで回避される。新たなカバー
を生成するコストは、ウインドウのピクセルの殆どが実
際同一のカバーを共有するため回避される。ウインドウ
を生成する間、これらピクセルを含む全てのランは別個
に考えられる。各々の場合において、ピクセルが同一の
カバーを有するため、同一の新たなカバーは新たなカバ
ーを見つけるための手順によって検出される。従って、
もし古いカバーと以前のランから決定される新たなカバ
ーの結合を記録するキャッシュが維持されるならば、各
ランにおいて新たなカバーを検索する作業は回避され
る。走査線変更手順において、このキャッシュは検査さ
れ、新たなカバーを見つけるためのサブルートの呼び出
しのみが、現存するカバーがキャッシュに見つからない
ときのみ呼び出される。ハッシュテーブルはこのキャッ
シュに使用される。その入力は古いカバーインデックス
であり、その内容は新たなカバーインデックスである。
このキャッシュは単一のウインドウ生成操作又はウイン
ドウ削除操作のみに有効であり、各後続の操作の前に再
設定される必要があることに注意したい。

【００５２】ウインドウ表示更新 新たな表示マップが、ウインドウ操作に関連して実行さ
れる各ウインドウの追加又は各ウインドウの削除毎に生
成されることが分かる。幾つかの場合において、幾つか
のウインドウ操作が表示更新と次の表示更新の間に行わ
れてもよい。一連の新たな表示マップが生成される。新
たな各表示マップが生成されるにつれて、以前新たに生
成された表示は古い表示マップとしてはたらく。全ての
ウインドウ操作が完了すると、元の古い表示マップと最
終的な新たな表示マップのみが、ラスタ表示を再ペイン
トするため使用される。表示は、新たな上部ウインドウ
を有するピクセルのみが更新される方法で更新される。
ウインドウ操作によって生成されるウインドウ領域（１
ヶ所でも複数ヶ所でもよい）外のピクセルは、更新され
ない。更に、ウインドウ領域に対応する同一の上部ウイ
ンドウを有するウインドウ領域（１ヶ所でも複数ヶ所で
もよい）内のピクセルもまた更新されない。この方法に
よって、表示更新は迅速かつ効率的に行われる。ウイン
ドウ更新手順は、図１３乃至図１４のフローチャートに
図形的に示されている。手順は更に、擬似コード形式に
示される。手順は、以下の変数が初期設定される初期設
定ステップ１１０で開始する。 xposn = 0 - 走査線の現在位置 oldrem = 0 - 古い走査線の未処理の部分 newrem = 0 - 新たな走査線の未処理の部分

【００５３】ウインドウ領域（１ヶ所でも複数ヶ所でも
よい）内のラスタ表示の各走査線において、手順は左か
ら右へ増加するｘ座標位置の方向に移動するシーケンシ
ャルピクセル・ランを調べる。処理ステップ１１２にお
いて、ピクセル位置"xposn"は、表示の右側が達したか
どうかを決定するためテストされる。表示の右側が達し
たならば、プロセスは初期設定ステップ１１０に戻り、
次の走査線が評価される。処理ステップ１１４におい
て、変数"oldrem"がゼロかどうかテストされる。ゼロで
なければ、プロセスはステップ１２２にジャンプす
る。"oldrem"がゼロならば、処理ステップ１１６が実行
されて、次のランが古い表示マップ"oldmap"から得られ
る。処理ステップ１１８において、変数"oldrem"がこの
ランの長さに設定されて、処理ステップ１２０におい
て、変数"oldtop"がoldrunに対応するカバーの最上部ウ
インドウと等しく設定される。ステップ１１８乃至１２
０で決定される値は、古い表示マップ３８及びその表示
マップ記憶装置アレイ４６に情報を求めることによって
決定される。表示マップ記憶装置アレイ４６はラン長と
ランに対応するカバーインデックスを識別する。カバー
インデックスから、最上部のウインドウはカバー収集３
６から見つけられる。次に、処理ステップ１１４から１
２０が新たな表示マップに対して繰り返され、newrem値
及びnewtop値が得られる。前述の処理ステップが、擬似
コード形式で以下のように示される。

【００５４】

【表８】

【００５５】次に、表示更新手順は、古いランと新たな
ランに含まれる画素の交差点を決定する。図３及び図１
２の走査線１から、各マップの第１ランの交差点は、表
示列０から２をスパンする図３のoldrunであることが分
かる。この比較は処理ステップ１２２で行われ、擬似コ
ード形式で以下のように示される。

【００５６】

【表９】

【００５７】表示更新手順は、次に最上部のウインドウ
がステップ１２２において決定される交差ピクセル上で
変更されたかどうかを決定する。従って、処理ステップ
１２４において、変数"oldtop"が変数"newtop"と異なる
かどうかを決定するため、変数"oldtop"がテストされ
る。変数"oldtop"が変数"newtop"と同じで、最上部のウ
インドウが変化しなかったならば、手順はステップ１２
８へジャンプする。図３及び図１２の場合において、走
査線１の第１ランの交差点はゼロの共通カバーを生成す
る。従って、これらのピクセルは復元されず、表示更新
手順の第２パスが作成される。図３の次の古いマップラ
ンである走査線１は、表示列３から７をスパンする。図
１２の第１の新たなマップランの残りの部分は、表示列
３をスパンする。古いマップランとの交差点は、表示列
３をスパンする単一ピクセル・ランである。古いマップ
ランのカバーと新たなマップランのカバーとは異なり、
最上部が変化する。最上部のウインドウが変化したと
き、手順はステップ１２６に移動し、交差ピクセルが、
ウインドウ"newtop"からのデータと共に、"outrun"ピク
セルのxposn として開始する表示に書き込まれる。図３
及び図１２の場合には、表示列３をスパンする交差ラン
はウインドウＢからのデータと共に書き込まれる。次
に、手順はステップ１２８に移動し、ピクセル位置xpos
n は"outrun"によって表される交差ピクセルの数だけ増
分される。走査線の未処理の部分を表す変数"oldrem"
は、両方のoutrunピクセルだけ減分される。ステップ１
３２において、未処理の新たな走査線の部分を表す変
数"newrem"もまた"outrun"の値だけ減分される。処理ス
テップ１２４乃至１３２は擬似コード形式で、以下のよ
うに示される。

【００５８】

【表１０】

【００５９】表示更新手順に続いて、"oldmap"における
走査線の全てが空き、"newmap"における走査線のコピー
と置換される。"destroyed" として示されるウインドウ
記述子もまた空き、それらのインデックス位置はNULLに
設定される。新たなウインドウデータを備えた表示の実
際の更新は幾つかの方法で行われることに注意したい。
ウインドウがメモリのある場所においてピクセルアレイ
として保持されるならば、更新はこれらのアレイから表
示へのバイトの任意の数のコピーである。ウインドウが
ソリッドカラーならば（即ち、ウインドウよりも図形を
管理するためにアルゴリズムが使用されるならば）、単
色のピクセルの行が再書き込みされる。ウインドウがア
プリケーションから描き直しを要求することによって更
新されるならば、走査線の更新された細分化部分がクリ
ッピング領域に追加され、細分化部分はアプリケーショ
ンによって次の更新を行うときに使用される。

【００６０】表示更新ルーチンが、走査線を頂部から底
部へと順に描き直すことに更に注意したい。多くの表示
システム上で、この更新は表示復元と同期して、表示へ
の変化を瞬時に見せることができる。

【００６１】このようにして、ラスタ表示における矩形
でないウインドウを管理するための方法が開示されてき
た。ウインドウの全数よりも、主にウインドウの重なり
に対応する期間において、本発明は矩形でないウインド
ウの管理を可能にする。ウインドウは何度も変更され、
画面のどの領域も再度書き込まれないように組み合わさ
れる。これにより、従来のウインドウ更新システムの性
能及びユーザインタフェースが高められる。

【００６２】本発明は好ましい実施例に関連して示され
かつ述べられたが、いかなる制限も目的とされず、多く
の変更及び応用が当業者に明らかであると理解される。
例えば、走査線は単一ピクセルの高さとして作成される
と示された。実際、ウインドウは矩形の傾向があり、同
一のカバーを備えた大きな矩形である。領域の各走査線
及び表示マップの各走査線には、高さが与えられる。ウ
インドウ管理システムの基本的な性質は高さによって変
更されるのではない。表示マップの更新の手順はより一
層複雑である。表示走査線が高さの異なる領域走査線と
比較されるとき、表示走査線は分割されなければならな
い。分割を回避するため、連続する表示走査線は同一な
らば再結合されなければならない。一般的に、再結合は
ウインドウが破壊された後に起こる。

【００６３】

【発明の効果】本発明は上記より構成され、ラスタ表示
においてウインドウを管理するための方法を提供する。

【図面の簡単な説明】

【図１】従来の方法で配置されるウインドウ操作前のウ
インドウの概略図である。

【図２】再配置された位置で示されるウインドウ操作後
の図１のウインドウの概略図である。

【図３】本発明に従って構成されたウインドウ管理シス
テムの部分的ブロック概略図である。

【図４】図３のウインドウ管理システムの追加の特徴を
示す詳細なブロック図である。

【図５】図３のウインドウ管理システムによって実行さ
れるウインドウ記述子データ構造の詳細な概略図であ
る。

【図６】図３のウインドウ管理システムによって実行さ
れるカバー収集データ構造の詳細な概略図である。

【図７】図３のウインドウ管理システムによって実行さ
れる表示マップデータ構造の詳細な概略図である。

【図８】図３のウインドウ管理システムによって実行さ
れる表示マップ変更手順のフローチャートである。

【図９】図３のウインドウ管理システムによって実行さ
れる表示マップ変更手順のフローチャートである。

【図１０】図３のウインドウ管理システムによって実行
される表示マップ変更手順のフローチャートである。

【図１１】図３のウインドウ管理システムによって実行
される表示マップ変更手順のフローチャートである。

【図１２】ウインドウ操作後の変更された表示の部分的
な概略図である。

【図１３】図３のウインドウ管理システムによって実行
されるラスタ表示更新手順のフローチャートである。

【図１４】図３のウインドウ管理システムによって実行
されるラスタ表示更新手順のフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 昭63−168686（ＪＰ，Ａ) 特開 平４−43394（ＪＰ，Ａ) 特開 昭60−17486（ＪＰ，Ａ) 特開 昭60−211491（ＪＰ，Ａ) 特開 昭63−23191（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06G 5/14

Claims (8)

(57)【特許請求の範囲】
1. 【請求項１】 ラスタ表示においてウインドウを管理す
   るためのコンピュータで実行される方法において、 各走査線上において所属するウインドウを同じくするピ
   クセルの一連のピクセルのラン（以下の請求項において
   「カバー」と称する）をそれぞれ識別するカバーの識別
   子を各走査線においてマップする第１表示マップを記憶
   装置の第１部分に生成するステップと、 表示において再配置されたウインドウに対して、各走査
   線上において所属するウインドウを同じくするピクセル
   の一連のピクセルのランをそれぞれ識別するカバーの識
   別子を各走査線においてマップする第２表示マップを記
   憶装置の第２部分に生成するステップと、 前記第１及び第２表示マップはある期間の間併存し、各
   々各走査線の識別、各走査線における各カバーの識別、
   各カバーに共通するウインドウの識別、及びウインドウ
   の積み重ね順序を表す数値を置数した記憶装置ロケーシ
   ョンを有することと、 ウインドの変更により最上部のウインドウとなるピクセ
   ルを識別するため、前記第１表示マップを前記第２表示
   マップと比較するステップと、 識別されたピクセルの最上部のウインドウからのデータ
   によって変更されたピクセルのみを書き込むことによっ
   て、ラスタ表示を再ペイントするステップと、から成る
   ウインドウ管理方法。
2. 【請求項２】 前記第２表示マップを生成するステップ
   が、ウインドウが再配置されたラスタ表示の領域を識別
   し、前記領域においてウインドウ積み重ね順序の変化を
   反映する新たなカバーを識別することによって、前記第
   １表示マップを変更するステップを含む、請求項１に記
   載のウインドウ管理方法。
3. 【請求項３】 前記第２表示マップを生成するステップ
   が、 ウインドウ再配置が生じたラスタ表示領域を識別するス
   テップと、 完全に前記ウインドウ領域外にあるカバーに対応する第
   １表示マップ値の部分を前記第２表示マップにコピーす
   るステップと、 前記ウインドウ領域内にある各カバー毎に、前記ウイン
   ドウ領域内にあるランの部分を識別するステップと、 前記識別されたランの部分から、前記ランの部分を新た
   なカバーとして識別する第１表示マップ値を生成するス
   テップと、 前記新たなカバーに対して新たなウインドウ積み重ね順
   序を決定するステップと、 前記新たなウインドウ積み重ね順序を、前記第２表示マ
   ップにおける隣接するカバーのウインドウ積み重ね順序
   と比較するステップと、 両者の順序が一致すると、前記新たなカバーと前記隣接
   するカバーとの組み合わせを表す第２値を生成し、前記
   第２値を前記第２表示マップに追加し、両者が不一致の
   場合、前記第１表示マップ値を前記第２表示マップに追
   加するステップと、 を含む請求項１に記載のウインドウ管理方法。
4. 【請求項４】 前記第１表示マップを生成するステップ
   が、 各々が、ラスタ表示におけるウインドウに対応しかつウ
   インドウ積み重ね順序におけるウインドウの位置を指定
   する、ウインドウ記述子のアレイを生成するステップ
   と、 各々が、カバーの識別子、ウインドウ記述子の前記アレ
   イによってウインドウの組み合わせを定義するマップ、
   及び各組み合わせにおける最上部のウインドウを指定す
   る指示子を有する、カバー情報の収集を生成するステッ
   プと、 を含む請求項１に記載のウインドウ管理方法。
5. 【請求項５】 ＣＰＵ、キーボードを備える入力システ
   ム、ラスタ表示デバイスを備える出力システム、データ
   記憶資源、及びラスタ表示デバイスにおいて１以上の表
   示ウインドウを画定するための適切なプログラミングを
   備えるデータ処理デバイスにおいて、ラスタ表示ウイン
   ドウを管理するためのシステムであって、 各走査線上において所属するウインドウを同じくするピ
   クセルの一連のピクセルのランをそれぞれ識別するカバ
   ーの識別子を各走査線においてマップする第１表示マッ
   プを記憶装置の第１部分に生成する手段と、 表示において再配置されたウインドウに対して、各走査
   線上において所属するウインドウを同じくするピクセル
   の一連のピクセルのランをそれぞれ識別するカバーの識
   別子を各走査線においてマップする第２表示マップを記
   憶装置の第２部分に生成する手段と、 前記第１及び第２表示マップはある期間の間併存し、各
   々各走査線の識別、各走査線における各カバーの識別、
   各カバーに共通するウインドウの識別、及びウインドウ
   の積み重ね順序を表す数値を置数した記憶装置ロケーシ
   ョンを有することと、 ウインドの変更により最上部のウインドウとなるピクセ
   ルを識別するため、前記第１表示マップを前記第２表示
   マップと比較する手段と、 識別されたピクセルの最上部のウインドウからのデータ
   によって変更されたピクセルのみを書き込むことによっ
   て、ラスタ表示を再ペイントする手段と、 から成るラスタ表示ウインドウ管理システム。
6. 【請求項６】 前記第２表示マップを生成するための手
   段が、ウインドウ再配置が生じたラスタ表示の領域を識
   別し、前記領域においてウインドウ積み重ね順序におけ
   る変化を反映する新たなカバーを画定することによっ
   て、前記第１表示マップを変更するための手段とを含
   む、請求項５に記載のラスタ表示ウインドウ管理システ
   ム。
7. 【請求項７】 前記第２表示マップを生成するための手
   段が、 ウインドウ再配置が生じたラスタ表示領域を識別するた
   めの手段と、 完全に前記ウインドウ領域外にある前記第１表示マップ
   のカバーの中の部分を前記第２表示マップに定義するた
   めの手段と、 前記ウインドウ領域内にある各第１表示マップのカバー
   毎に、前記ウインドウ領域内にあるランの部分を識別す
   るための手段と、 前記識別されたラン部分から新たなカバーを前記第２表
   示マップに定義するための手段と、 前記新たなカバーに対して新たなウインドウ積み重ね順
   序を決定するための手段と、 前記新たなウインドウ積み重ね順序を、前に定義された
   隣接カバーのウインドウ積み重ね順序と比較するための
   手段と、 両者が一致すると、前記新たなカバーを前記以前に定義
   されたカバーと組み合わせるための手段と、 両者が不一致の場合、前記新たなカバーを新たに定義さ
   れたカバーとして前記第２表示マップに追加するための
   手段と、 を含む請求項５に記載のラスタ表示ウインドウ管理シス
   テム。
8. 【請求項８】 前記第１表示マップを生成するための手
   段が、 各々が、ラスタ表示におけるウインドウに対応しかつウ
   インドウ積み重ね順序におけるウインドウの位置を指定
   する、ウインドウ記述子のアレイを生成する手段と、 各々が、カバーの識別子、ウインドウ記述子の前記アレ
   イによってウインドウの組み合わせを定義するマップ、
   及び各組み合わせにおける最上部のウインドウを指定す
   る指示子を有する、カバー情報の収集を生成する手段
   と、 を含む請求項５に記載のラスタ表示ウインドウ管理シス
   テム。