JPS60222890A - ビツトマツプデイスプレイにおけるマルチウインドウ制御方式 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 〔発明の利用分野〕 本発明は、ビットマツプディスプレイを用いるマルチウ
ィンドウ表示に係り、特に、ディスプレイの画面を編集
するための作業用メモリの必要容量を増加させることの
ない、マルチウィンドウ制御方式に関する。

〔発明の背景〕

近年、計算機の処理対象は、文字から、図形や画像をも
含むように、多種多様化している。これに伴ない、従来
のキャラクタディスプレイより表示に自由度の多いビッ
トマツプディスプレイが多用されるようになっている。

キャラクタディスプレイの場合、文字フォント展開はデ
ィスプレイの制御装置が実行するので、ディスプレイに
供給するデータは文字コードのみであった。これと異な
り、ビットマツプディスプレイの場合、ディスプレイに
転送するデータは、展開後のビットマツプデータである
。このため、文字２図形９画像等の表示内容を予めビッ
トマツプ展開する処理、および画面を編集する処理が必
要となり、これらの処理用にワークメモリが必要となる
。

一方、ディスプレイサイズの物理的制約から必要なデー
タが全てディスプレイ上に表示されているとは限らない
。この場合、必要データを得るには、画面をスクロール
、ズーム、移動などの処理（以後、スクロール等と記す
）をすることとなる。

このスクロール等を円滑に実行するには、全データを予
めビット展開し、ワークメモリ（ピッ１〜マツプメモリ
と呼ぶ）上に保持する方法がある。

ところが、この方法では、ビットマツプメモリの必要容
量が増大する欠点がある。特にマルチウィンドウ表示（
画面とに、複数種類のデータを同時表示する表示方式）
の場合には、上記のビットマツプメモリの容量は、数メ
ガバイト必要になる場合もあり、現実的ではない。

〔発明の目的〕

従って、本発明の目的は、ビットマツプメモリの必要容
量を増大させずに、スクロール等に円滑に実現できる。

マルチウィンドウ制御方式を提供することにある。

〔発明の概要〕

この目的を達成するために、本発明においては、表示内
容更新など現在処理中のウィンドウ（アクティブウィン
ドウと呼ぶ）については全データを、他のウィンドウ（
インアクティブウィンドウと呼ぶ）については、現在表
示中のウィンドウ部分のみのデータを、各々ビットマツ
プメモリに保持する方式を採る。これによって、アクテ
ィブウィンドウは円滑にスクロールでき、かつ、インア
クティブウィンドウについては、現在の開示と関係のな
いデータは保持しないので、ビットマツプメモリの容量
を増大することがない。

〔発明の実施例〕

以下１本発明の実施例を、第１図により説明する。この
実施例では、文字２図形、および画像を含む文書情報を
取扱うものとする。

第１図中、データファイル１０には、文書情報がコード
形式で格納されている。ここでコード形式とは、文字コ
ード、座標列、帯域圧縮画像などを示す。２０は、ウィ
ンドウ管理テーブルである。

ここには、データファイル１０内の文書情報中、ディス
プレイ画面に表示する領域（ウィンドウと呼ぶ）の位置
、大きさを示している。３０は、上記コード形式データ
のビットマツプ展開結果を保持するビットマツプメモリ
である。４０はディスプレイ画像をリフレッシュするた
めのフレームメモリであり、５０は、ビットマツプディ
スプレイである。６０は、ウィンドウの状態を管理する
テーブルであり、その詳細は後述する。

１１０は、コード形式のデータをビットマツプ展開する
処理である。具体的には、文字コードをフォントに、座
標列を線または面図形に、帯域圧縮画像は、ラスク画像
に、それぞれ変換する。

１２０は、ビットマツプデータを、画像フォーマットに
編集する処理であり、】３０は、フレームメモリ４０の
内容を、ディスプレイ５０に表示する処理を示す。以上
の各ファイルテーブル類、および処理のうち、１０，２
０，４０，５０、および１３０は全て公知である。

本発明の特徴は、ビットマツプメモリ３０の構成にある
。すなわち、ビットマツプメモリ３０には、現在表示中
の全文書情報のビットマツプデータを保持するのではな
く、アクティブなウィンドウのみについて、それが属す
る文書情報の全ビットマツプデータを保持し、インアク
ティブなウィンドウについては、当該ウィンドウのみの
ビットマツプデータを保持する。従って、ビットマツプ
展開処理１１０は、アクティブウィンドウについては、
それが属する文書情報全体をビットマツプ展開するが、
それ以外のインアクティブウィンドウについては、当該
ウィンドウ部分のみについて、ビット展開する。この処
理で、どのウィンドウがアクティブであるかを示すのが
、ウィンドウ状態テーブル６０である。

第２図に、ビットマツプメモリ３０の構成を示す。ビッ
トマツプメモリ３０は、１つの全体領域３０１と、複数
個の部分領域３０２とから成る。

全体領域３０１とは、アクティブウィンドウが属する文
書情報全体のビットマツプデータを保持する領域である
。一方、部分領域とは、インアクティブウィンドウに対
応するビットマツプデータを保持する領域である。

第３図に、ウィンドウ状態テーブル６０の内容を示す。

ウィンドウ状態テーブル６０には、各ウィンドウＷ１〜
Ｗ１ごとに、ウィンドウ識別子６０１、当該ウィンドウ
に対するビットマツプデータが格納されているビットマ
ツプメモリ３０上のアドレス６０２、そのデータ長６０
３、およびアクティブフラグ６０４が保持されている。

アクティブウィンドウについては、アクティブフラグ６
０４がセットされており、インアクティブウィンドウに
ついては、アクティブフラグ６０４はセットされていな
い。

ビットマツプ展開処理１１０は、ビットマツプ展開に際
し、ウィンドウ状態テーブル６０中のアクティブフラグ
６０４を参照し、文書情報全体を展開するか、ウィンド
ウに対応する部分のみを展開するかを決定する。（第４
図参照） また１画面編集処理１２０も、上記アクティブフラグ６
０４を参照して、アクティブウィンドウについては、ビ
ットマツプメモリ３０の全体領域３０１からウィンドウ
部分のビットマツプデータを切出して、フレームメモリ
４０上に合成する。

一方、インアクティブウィンドウについては、ビットマ
ツプメモリ３０の部分領域３０２のデータを、そのまま
フレームメモリ４０上に合成する。

（第５図参照） アクティブウィンドウが変更になった時は、旧アクティ
ブウィンドウに対しては、ビットマツプメモリ３０上の
全体領域３０１上のビットマツプデータからウィンドウ
対応部分を切出し、ビットマツプメモリ３０−ヒの部分
領域３０２にコピーする。続いて、新アクティブウィン
ドウが属する文書情報全体を新たにビットマツプ展開し
、ビットマツプメモリ３０の全体領域３０１に格納する
。

更に、上記変更に対応して、ウィンドウ状態テーブル６
０の内容を更新する。（第６図参照）〔発明の効果〕 以上の通り、本発明によれば、スクロール等の処理が発
生するアクティブウィンドウについては、それが属する
データ全てを、予めビットマツプ展開し保持しているの
で、スクロール等の処理は円滑に実行できる。一方、ス
クロール等の処理が発生しないインアクティブウィンド
ウについては、表示中のウィンドウに対応した部分のみ
のデータを保持するので、ビットマツプメモリの必要容
量を増大させることはない。

【図面の簡単な説明】

第１図は本発明の一実施例におけるデータフロー、第２
図はビットマツプメモリの構成、第３図はウィンドウ状
態テーブルの構成、第４図はビットマツプ展開の処理フ
ロー、第５図は画面編集の処理フロー、第６図はアクテ
ィブウィンドウ切替の処理フローである。 １０・・・データファイル、２０・・・ウィンドウ管理
テーブル、３０・・・ビットマツプメモリ、４０・・・
フレームメモリ、５０・・・ディスプレイ、６０・・・
ウィンドウ状態テーブル、１１０・・・ビットマツプ展
開処理、１２０・・・画面編集処理、１３０・・・画面
表示処■１図 Ｙｚ図 ３ρ 第　３　ロ ■　４　図 第　５　国 ″ｆＪ／；

Claims (1)

【特許請求の範囲】
1. データファイルと、その内容をビットマツプ展開したビ
   ットマツプデータを格納するビットマツプメモリと、フ
   レームメモリと、ビットマツプディスプレイとから成る
   表示装置において、ウィンドウがアクティブかインアク
   ティブかを示すウィンドウ状態テーブルを設け、アクテ
   ィブウィンドウについては、それが属する原データの全
   てを、インアクティブウィンドウについては、該ウィン
   ドウ部分のみのデータを、それぞれビットマツプメモリ
   上に保持することを特徴とするビットマツプディスプレ
   イのマルチウィンドウ制御方式。