JP2628621B2

JP2628621B2 - データ処理システムおよび文字表示方法

Info

Publication number: JP2628621B2
Application number: JP6307210A
Authority: JP
Inventors: ガリー・ジェイムズ・モールス; ステファン・パトリック・トンプソン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1993-12-30
Filing date: 1994-12-12
Publication date: 1997-07-09
Anticipated expiration: 2012-07-09
Also published as: EP0663659A3; EP0663659A2; JPH07271339A; US5771371A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、概括的に云えば、改良
されたデータ処理システムに関するものであり、詳しく
云えば、データ処理システムにおけるグラフィック・デ
ィスプレイ・システムのための改良された方法及び装置
に関するものである。更に詳しく云えば、本発明は、デ
ータ処理システムにおけるビデオ・ディスプレイ上に文
字を表示するための改良された方法及び装置に関するも
のである。

【０００２】

【従来の技術】ＯＳ／２、Ｗｉｎｄｏｗｓ、及びＡＩＸ
のような今日のオペレーティング・システムは、ユーザ
とコンピュータとの間に改良されたインターフェースを
与えるために、グラフィック・ユーザ・インターフェー
ス（ＧＵＩ）を使用している。（なお、「ＯＳ／２」及
び「ＡＩＸ」はＩＢＭ社の商標であり、「Ｗｉｎｄｏｗ
ｓ」はマイクロソフト社の商標である）。ＧＵＩは、ア
プリケーションが単一のディスプレイ・スクリーン上で
テキストとグラフィックスの両方を利用することを可能
にする。文字は、異なるフォントでディスプレイ・スク
リーン上に表示されてもよい。本願において使用される
用語「文字」は、表現、編成、又は制御データのために
使用される一組のエレメントのメンバを意味する。用語
「フォント」は所与のサイズ及びスタイルを持った文字
のファミリ（例えば、１２ポイントのＨｅｌｖｅｔｉｃ
ａ）を意味する。

【０００３】更に、ＧＵＩは、ウインドウと呼ばれるス
クリーンの矩形部分を各アプリケーションに割り当てる
ことによって、複数のアプリケーションが同じスクリー
ンを共用することを可能にする。ウインドウの外の領域
は、通常、そのアプリケーションにとって利用すること
ができない。ユーザは、必要に応じて、各アプリケーシ
ョン・ウインドウをサイズ変更及び位置変更することが
できる。ＧＵＩは、ワード・プロセッサのようなアプリ
ケーションがＷＹＳＩＷＹＧ（ウィジィウィーグ）モー
ドで動作することも可能にする。たとえＧＵＩ環境がデ
ィスプレイをグラフィックス・モードで動作させても、
テキスト・サポートは依然としてそのＧＵＩの重要な部
分である。ディスプレイ・アダプタがグラフィックス・
モードで動作する時、文字の各画素（ペル）はＧＵＩに
よって描かれなければならない。このような状況は、デ
ィスプレイ・アダプタに１つの文字コードを書き込む代
わりにすべての画素を描くことに関連するソフトウエア
・オーバヘッドのため、深刻な性能上の低下をまねく。
文字を描くことに加えて、ＧＵＩはソース・データ（テ
キスト文字又はイメージ・ビットマップ）と宛先（通常
は、スクリーン）との間の論理的動作をサポートする。
これらの論理的動作は、「ラステロプス（ｒａｓｔｅｒ
ｏｐｓ）」とも呼ばれ、テキスト文字を描くに必要なオ
ーバヘッドを増加させる。データ処理システムにおける
多くの異なるハードウエア及びソフトウエアの構成が使
用可能である。

【０００４】そのデータ処理システムのハードウエア部
分は，ハードウエア及びソフトウエアのタイプによって
は、ＧＵＩにおいてテキストを表示するために使用され
るソフトウエアにより十分に利用されなかったり、或い
は酷使されたりすることがある。従って、データ処理シ
ステムのハードウエア部分とソフトウエア部分とに間に
バランスを与えるための方法及び装置を持つことが望ま
しい。

【０００５】

【発明が解決しようとする課題】従って、本発明の目的
は、改良されたデータ処理システムを提供することにあ
る。

【０００６】本発明のもう１つの目的は、データ処理シ
ステムにおけるグラフィックス・ディスプレイ・システ
ムのための改良された方法及び装置を提供することにあ
る。

【０００７】本発明の更にもう１つの目的は、データ処
理システムにおけるビデオ・ディスプレイ上に文字を表
示するための改良された方法及び装置を提供することに
ある。

【０００８】

【課題を解決するための手段】上記の目的は、以下に述
べるように達成される。本発明は、データ処理システム
においてディスプレイ上に文字を表示する効率を上げる
ための方法及び装置を提供する。データ処理システムに
おけるディスプレイ上に文字を表示するための複数のプ
ロセスが与えられる。それらプロセスの各々は、ディス
プレイ上に文字を表示するために種々の量のプロセッサ
資源を必要とする。それらプロセスの１つは、選択され
たプロセスが他のプロセスよりも効率的な文字表示をデ
ィスプレイにおいて行うように選択される。

【０００９】又、本発明は、データ処理システムのシス
テム・メモリにおいてフォント・データをキャッシュす
ることによって文字を表示するための改良された方法及
び装置を提供する。本発明によれば、ＣＰＵにおいて利
用可能なパラメータ移動命令を利用して、特定の文字に
対する字形ビットマップがキャッシュからグラフィック
ス・アダプタに移動可能である。文字は、その文字の幅
全体又は１行の文字のストリング全体を包含する固定走
査線に基づいてグラフィックス・アダプタへ移動され
る。

【００１０】

【実施例】図面、特に図１を参照すると、システム・ユ
ニット２、ビデオ・ディスプレイ端末４、キーボード
６、及びマウス８を含むデータ処理システム１０が示さ
れる。データ処理システム１０は、ＩＢＭ社の製品であ
るＩＢＭＰＳ／２コンピュータ又はＩＢＭＲＩＳＣ
ＳＹＳＴＥＭ／６０００コンピュータのような任意の
適当なコンピュータを利用して実施可能である。（「Ｐ
Ｓ／２」及び「ＲＩＳＣＳＹＳＴＥＭ／６０００」は
ＩＢＭ社の商標である）。図示の実施例はパーソナル・
コンピュータであるけれども、本発明の好適な実施例
は、例えば、インテリジェント・ワークステーション或
いはミニ・コンピュータのような他のタイプのデータ処
理システムにおいても実施可能である。

【００１１】次に図２を参照すると、本発明の好適な実
施例を利用し得るデータ処理システム１０のブロック図
が示される。システム・バス１２は、データ処理システ
ム１０内の種々のコンポーネント相互間の接続を行う。
中央処理装置（ＣＰＵ）１４はインテル社から入手可能
な８０４８６プロセッサ又はＰｅｎｔｉｕｍプロセッサ
のような１つ又は複数のプロセッサを含むものでもよ
い。（「Ｐｅｎｔｉｕｍ」はインテル社の商標であ
る）。

【００１２】システム・メモリ１６はデータ処理装置１
０のための記憶装置であり、読取り専用メモリ（ＲＯ
Ｍ）及びランダム・アクセス・メモリ（ＲＡＭ）の両方
を含むものでよい。システム・メモリ１６は、典型的に
は、例えば、アプリケーション、グラフィックス・パッ
ケージ、及びオペレーティング・システムのようなＣＰ
Ｕ１４上で実行するプログラム及びデータを保持する。
ダイレクト・アクセス記憶装置（ＤＡＳＤ）１８は、典
型的には、データ処理装置１０のための長期記憶装置で
ある。ＤＡＳＤ１８は、例えば、ハード・ディスク駆動
装置又はフロッピ・ディスク駆動装置を含む。グラフィ
ックス・アダプタ２０は、モニタ２２によってユーザに
ＧＵＩを表示するために使用される。

【００１３】グラフィックス・アダプタ２０はディスプ
レイ・プロセッサ２４、ディスプレイ・プロセッサ・メ
モリ２６、フレーム・バッファ２８、及びビデオ・コン
トローラ３０を含む。ディスプレイ・プロセッサ２０
は、走査変換及びラスタ操作のようなグラフィックス機
能を遂行する。ディスプレイ・プロセッサ・メモリ２６
は、走査変換及びラスタ操作のような機能を遂行するデ
ータ及びプログラムを保持する。フレーム・バッファ２
８は、ＶＲＡＭとも呼ばれるビデオ・メモリを含む。フ
レーム・バッファ２８は、走査変換及びラスタ操作によ
って作成された表示可能なイメージを含む。

【００１４】代替えとして、図３に示されたデータ処理
システム１０はローカル・バス３２を含み得るものであ
り、そのローカル・バスはＣＰＵ１４のラインの直接的
拡張であり、ＣＰＵ１４と同じクロックで動作する。ロ
ーカル・バス３２は、そのローカル・バスに接続された
装置に３２ビット又は６４ビット転送を行う。更に、シ
ステム・メモリ１６は、３２ビット又は６４ビット・パ
スを介してＣＰＵ１４に接続可能である。このようなシ
ステムでは、ＤＡＳＤ１８及びグラフィックス・アダプ
タ２０は、データ処理システム１０に対するパフォーマ
ンスを向上させるためにローカル・バス２０に接続され
る。

【００１５】図１、図２及び図３に示されたデータ処理
システムは、以下に示されるプロセスを組み込んだソフ
トウエアをプログラム可能である。

【００１６】本発明は、フォント処理手順を利用すべき
データ処理システムのパフォーマンスを最適化するよう
にそのフォント処理手順を選択するための方法及び装置
を提供する。本発明によれば、データ処理システムは、
そのデータ処理システムにおける文字の表示が最適化さ
れる場合に使用すべき適当なフォント処理手順を決定す
るために分析され、又はテストされる。

【００１７】ＣＰＵのタイプ及びキャッシュの特性のよ
うなデータ処理システムの種々な特性は、そのデータ処
理システムにおけるディスプレイ上に文字を最適に表示
するに必要なフォント処理手順を決定する場合のファク
タとなり得る。例えば、低速度ＣＰＵを持ったデータ処
理システムでは、グラフィックス・アダプタが最適に動
作させるためのフォーマットでフォント・データを得る
ためにそのＣＰＵによる大量の処理を必要とするフォン
ト処理手順は、ソフトウエアによって遅くされであろ
う。

【００１８】一方、非常に高いパフォーマンスのＣＰＵ
を持ったシステムでは、ＣＰＵの計算能力は、グラフィ
ックス・アダプタがそのタスクを終了する前にそのＣＰ
Ｕが文字の処理に関するタスクを終了するという結果を
生じるフォント処理手順を使うことによって費やされ
る。この状態は「ハードウエア限定」状態と呼ばれ、そ
の状態では、ＣＰＵは、ハードウエアが次のコマンド又
はデータに対して準備できるのをいつも待っている。フ
ォント処理手順がハードウエアに付いて行くことができ
ない時、「ソフトウエア限定」状態が存在する。データ
処理システムのパフォーマンスを最大にするためには、
選択されるフォント処理手順は、ハードウエアを待つ必
要があってはならず、その逆があってもならない。換言
すれば、ハードウエアとソフトウエアとの間のワーク・
ロードはバランスされなければならない。

【００１９】文字を処理するために利用される現在得る
ことができるグラフィックス・アダプタ・ソフトウエア
では、現在使用中のフォント・コピー操作のため及びグ
ラフィックス・アダプタのコントロール・インターフェ
ースのため、ハードウエア及びソフトウエアが完全にオ
ーバラップすることは不可能である。典型的には、ソフ
トウエアはフォント情報をオフ・スクリーン・ビデオ・
メモリにコピーし、しかる後、処理を開始するためにそ
れをグラフィックス・アダプタのコントロール・レジス
タに書き込まなければならない。グラフィックス・アダ
プタが前の文字の処理でビジーにある時にこれが行われ
たとしても、ＣＰＵはビデオ・メモリを拘束して、それ
がグラフィックス・アダプタによって利用されないよう
にする。更に、現在のグラフィクス・アダプタは、その
グラフィックス・アダプタが或オペレーションを遂行し
ている時、ソフトウエアがそのコントロール・レジスタ
に書き込むことを可能にするものではない。

【００２０】図４を参照すると、最適なフォント処理手
順を選択するための選択プロセスのフローチャートが、
本発明の好適な実施例に従って示される。その選択プロ
セスは、データ処理システムにおいて最適なフォント処
理を行うフォント・レンダリング・プロセスを選択す
る。その選択プロセスは、典型的には、データ処理シス
テムが最初に利用される時に使用される。更に、この選
択プロセスは、例えば、新しいグラフィックス・アダプ
タが導入されるというように、データ処理システムにお
ける構成が変更される時にも使用可能である。

【００２１】プロセスはブロック１３０において開始
し、しかる後、ブロック１３２に示されるように、１つ
のタイム・インターバルの間に、各処理に対してテキス
トを書き込む。そのタイム・インターバルは任意の長さ
であるが、種々なフォント・アルゴリズムを行う場合に
ＣＰＵの能力を反復可能に正確に予測することを可能に
するタイム・インターバルとなるように、そのアルゴリ
ズムによって決定される。次に、プロセスは、戻りブロ
ックを示すブロック１３４に進む。しかる後、ブロック
１３６に示されるように、１つのタイム・インターバル
の間に如何に多くの文字が処理されるかの測定が処理さ
れる。次に、ブロック１３８に示されるように、すべて
のフォント・プロセスがテストされてしまったかどうか
の決定が行われる。すべてのフォント・プロセスがテス
トされてしまったのではない場合、その選択プロセスは
ブロック１３４に戻り、次のフォント・プロセスをテス
トする。フォント・プロセスがすべてテストされてしま
った場合、プロセスは、各フォント処理の速度を比較し
て最も速いものを選択することを示すブロック１４０に
続く。

【００２２】どのプロセスが最良の結果を与えたかに従
って、プロセスは、ブロック１４２、１４４、又は１４
６に示されるように終了する。標準フォントが最良のパ
フォーマンスを与えた場合、選択プロセスは、標準フォ
ント・プロセスの選択を持ったブロック１４２において
終了する。文字指向プロセスが最良のパフォーマンスを
与えるという決定の結果、その選択手順はブロック１４
４において終了する。ストリング指向プロセスが最も速
いものである場合、プロセスは、ストリング指向プロセ
スが選択されるブロック１４６において終了する。それ
ら３つのフォントプロセスの各々は、種々の量のＣＰＵ
資源を必要とする。本発明は、スクリーン上に最も速い
文字表示を与えるプロセスを選択する。上記実施例は３
つの異なるフォント・プロセスを利用するけれども、本
発明の好適な実施例に従って、別の数の手順を利用する
ことも可能である。

【００２３】更に詳しく云えば、本発明の好適な実施例
は、マイクロソフト・ウインドウズ（Ｍｉｃｒｏｓｏｆ
ｔＷｉｎｄｏｗｓ：商標）のようなＧＵＩ環境におい
て使用可能である。ラスタ・フォントは、文字が字形ビ
ットマップとして表されるフォントである。これらの字
形ビットマップは、本発明の好適な実施例に従って、マ
イクロソフト・ウインドウズにおいて使用されるＦＯＮ
ＴＩＮＦＯと呼ばれるデータ構造で記憶される。これら
字形ビットマップは、１つの文字の各画素に対して１つ
のビットを有する。そのビットはバックグラウンド・カ
ラー（ゼロに等しい値）又はフォアグラウンド・カラー
（１に等しい値）を表すこともできる。グラフィックス
・アダプタに対するデバイス・ドライバは、典型的に
は、ＦＯＮＴＩＮＦＯ構造から文字幅及び字形情報を検
索する。

【００２４】標準フォント・プロセスは、当業者にはよ
く知られている。標準フォント・プロセスは、Ｗｉｎｄ
ｏｗｓにおいて見られるＦＯＮＴＩＮＦＯ構造に記憶さ
れたフォント情報を利用する。標準フォント・プロセス
は、ＦＯＮＴＩＮＦＯ構造から文字幅及び字形情報を検
索して文字字形ビットマップを作成する。用語「字形」
は、通常は、或フォントにおける文字のイメージを意味
する。「フォント・データ」とも呼ばれる文字字形ビッ
トマップ・データは、本発明の好適な実施例によれば、
８画素の列で記憶されたモノクローム・ビットマップで
ある。

【００２５】今では、テキスト・ストリングは、必要な
文字字形ビットマップのようなフォント・データをフレ
ーム・バッファにおけるメモリのオフ・スクリーン領域
にコピーすることによって、ディスプレイ上でレンダさ
れる。テキスト・ストリングは、表示されるべき１行の
文字である。そこで、文字の高さ全体がレンダされるま
で、グラフィックス・アダプタは、そのグラフィックス
・アダプタにおけるメモリのオフ・スクリーン領域から
宛先（通常は、フレーム・バッファにおけるオン・スク
リーン・メモリの領域）にそれら字形ビットマップをコ
ピーする。字形ビットマップがコピーされる時、グラフ
ィックス・アダプタは、１ビット／画素（ｂｐｐ）パタ
ーンを、そのｂｐｐに対する宛先が必要とする適当なフ
ォアグラウンド・カラー及びバックグラウンド・カラー
にマップする。このプロセスは、「カラー拡張」と呼ば
れる。カラー拡張は、当業者にはよく知られていること
である。

【００２６】図５を参照すると、文字「Ａ」に対する、
字形ビットマップ・データとも呼ばれるフォント・デー
タの図が示される。Ｘ印は文字「Ａ」における画素を表
す。その文字の幅全体が表されるまで、８つのビット・
カラムが連結される。明らかに、文字「Ａ」は８画素よ
りも幅広い。文字「Ａ」に対するバイト・パターンは、
走査０から走査１３まで走査線ごとに８つのビット・セ
クションに記憶される。カラム１における走査０乃至走
査１３が読み取られ、しかる後、カラム２におけるそれ
ら走査線に対するデータが読み取られる。各カラムは、
走査０から走査１３まで走査線ごとに読み取られる。こ
の場合、文字「Ａ」は８によって均等に割り切れもので
はないことに注意してほしい。

【００２７】新しい走査線が処理される時にいつも、ブ
レーク・イン・ページ・モードが生じる。「ページ・モ
ード」は、ランダムに配置されたアドレス又は非隣接ア
ドレスよりも速い隣接アドレスを書き込むダイナミック
ＲＡＭ（ＤＲＡＭ）におけるモードである。パッディン
グ（ｐａｄｄｉｎｇ）０は、余ったビット位置にゼロを
記憶することである。文字の幅が８で割り切れない場
合、パッディング０が余ったビット位置に記憶される。
このタイプの記憶フォーマットは、８画素よりも幅広い
文字に対しては、１つの走査線に対するデータが連続ビ
ットの形で記憶されないことを意味する。例えば、図５
に示された１１＊１４画素の「Ａ」に対するパターン
は、 00 0C 12 21 40 40 40 7F 40 40 40 00 00 00 00 00 00 00 80 80 80 80 80 80 80 00 00 00 となる。

【００２８】図６を参照すると、フォント・データをグ
ラフィックス・アダプタに送るための標準的なフォント
・プロセスの高レベルのフローチャートが、本発明の好
適な実施例に従って示される。そのプロセスは、ブロッ
ク１５０において示されるように開始し、しかる後、ブ
ロック１５２に示されるように、文字変数がゼロに等し
くセットされる。次に、その文字変数に関する判断ブロ
ックのためのリターン・ポイントがブロック１５４にお
いて示される。ブロック１５６では、カラム変数がゼロ
に等しくセットされる。次に、ブロック１５８はカラム
変数に関する判断ブロックのためのリターン・ポイント
である。ブロック１６０に示されるように、走査線変数
がゼロに等しくセットされる。

【００２９】そこで、プロセスはブロック１６２に進
む。ブロック１６２は、走査線変数に関する判断ブロッ
クのためのリターンを示す。次に、プロセスはブロック
１６４に進む。ブロック１６４は、フレーム・バッファ
におけるオフ・スクリーン・ビデオ・メモリから次のｎ
画素幅の字形データを得る。しかる後、ブロック１６８
に示されるように、ページ・ブレーク遅延が生じる。こ
の遅延は、新しい走査線がフレーム・バッファ・メモリ
におけるオフ・スクリーン・ビデオ・メモリから読み取
られた時、メモリにおけるブレーク・イン・ページ・モ
ードによって生じる。ページ・ブレークに対する代表的
な遅延期間は８０ナノ秒である。この例では、画素は４
０ナノ秒／画素の割合で書き込まれる。ブロック１６８
に示されるように、それら画素はグラフィックス・アダ
プタのフレーム・バッファに書き込まれる。そこで、ブ
ロック１７０に示されるように、走査線変数が１だけイ
ンクレメントされる。

【００３０】次に、ブロック１７２に示されるように、
走査線変数が走査線最大値よりも大きいかどうかの決定
が行われる。走査線変数が走査線最大値よりも大きくな
い場合、プロセスはブロック１６２に戻る。そうでない
場合、ブロック１７４に示されるように、カラム変数は
１だけインクレメントされ、走査線変数はゼロにセット
される。次に、ブロック１７６に示されるように、カラ
ム変数がカラム最大値よりも大きくないかどうかの決定
が行われる。カラム変数がカラム最大値よりも大きくな
い場合、プロセスはブロック１５８に戻る。そうでない
場合、ブロック１７８に示されるように、文字変数が１
だけインクレメントされる。次に、ブロック１８０に示
されるように、文字変数が文字最大値よりも大きいかど
うか関する決定が行われる。文字変数が文字最大値より
も大きくない場合、プロセスはブロック１５４に戻る。
そうでない場合、ブロック１８２に示されるように、プ
ロセスは終了する。

【００３１】本発明の好適な実施例によれば、その文字
指向プロセスは、ＣＰＵがコントロール情報及びデータ
情報を混合すること及びそれらをグラフィックス・アダ
プタに直接送ることを可能にするであろう。グラフィッ
クス・アダプタは、必要に応じて、そのコントロール情
報を変換し、データを処理する。グラフィックス・アダ
プタが字形ビットマップを受け取る時、そのグラフィッ
クス・アダプタはカラー拡張し、その字形ビットマップ
を宛先に直接書き込むであろう。その結果、ＣＰＵはフ
ォント情報を収集し、そして前に受け取ったデータをグ
ラフィックス・アダプタが書き込むのと同時に、その情
報をグラフィックス・アダプタに送ることができる。文
字幅及び文字間スペースのようなダイナミック・コント
ロール情報がそのフォント・データと混合される。スト
リング高及び開始アドレスのようなスタティック・コン
トロール情報は、コントロール・レジスタを介してグラ
フィックス・アダプタに送られる。

【００３２】本発明の好適な実施例に従って、文字指向
プロセス及びストリング指向プロセスにおいてフォント
のための字形ビットマップをキャッシュするために、グ
ラフィックス・アダプタにおけるフレーム・バッファ内
のオフ・スクリーン・ビデオ・メモリではなくシステム
・メモリが利用される。その結果、前にフォント・キャ
ッシュ専用であったグラフィックス・アダプタにおける
メモリは、メニュー・バー・プルダウン又はスクリーン
領域のような他のビットマップ・イメージを記憶するた
めに使用可能である。

【００３３】更に詳しく云えば、本発明による文字指向
プロセスは、現在多くのグラフィックス・アダプタにお
いて行われているようにそのグラフィックス・アダプタ
におけるメモリを使う代わりに、ＣＰＵを利用してシス
テム・メモリにおける字形ビットマップを事前処理し、
そしてキャッシュする。字形ビットマップはシステム・
メモリにおけるキャッシュから走査線ごとにコピーさ
れ、一時に１文字づつグラフィックス・アダプタに送ら
れ、グラフィックス・アダプタがメモリ・ページ・モー
ド・オペレーションを利用することを可能にする。新し
い走査線が処理される度に、ブレーク・イン・ページ・
モードが生じる。標準的なフォント処理により使用され
るような一時に２カラムではなく１カラムしかの走査線
が利用されないため、その文字指向処理は速いフォント
の表示を行う。

【００３４】文字指向処理の下では、ＣＰＵは次のよう
なデータ・ストリームを使用してグラフィックス・アダ
プタにデータを送る。即ち、[幅][スペース][字形走査
線１][字形走査線２].....[字形走査線Ｎ][幅]...但
し、[幅]は文字の画素における幅であり、[スペース]は
或文字と次の文字との間の文字間スペースであり、[字
形走査線１−Ｎ]は[幅]により指定されたビットの数を
含んでバイト（ワード又はダブルワード）単位で送られ
る文字に対する字形ビットマップ・データである。[幅]
及び[スペース]は、最初の文字がグラフィックス・アダ
プタに送られる前に送られる必要がある。[幅]及び[ス
ペース]は、文字の幅及び文字間スペースが変化する場
合には再び送られる。この処理は、文字のストリング全
体がユーザに対してディスプレイ上でレンダされるまで
続けられる。

【００３５】字形ビットマップ・データは、長さが同じ
のデータ単位で、走査線ベースでグラフィックス・アダ
プタに送られる。本発明の好適な実施例では、グラフィ
ックス・アダプタは、送られたデータのうちの適当な数
のビットを利用して、当業者には知られたアセンブリ言
語の命令である「ＲＥＰＭＯＶＳＤ」のような効率的
なデータ移動命令を、ＣＰＵが使用することを可能にす
る。８０３８６及び８０４８６のようなインテル（商
標）ＣＰＵは効率的にダブルワードを処理するので、こ
の例では、文字指向プロセスに対する走査線の幅として
３２ビットのダブルワードが使用される。

【００３６】本発明の好適な実施例によれば、１つの走
査線全体を移動するために使用することができるＣＰＵ
の永久的な移動命令に関する如何なるデータ幅も利用可
能である。即ち、それはワードでもよい。字形マップ
は、Ｗｉｎｄｏｗｓで利用されるＦＯＮＴＩＮＦＯ構造
で使われるようなカラム・フォーマットではなく、真の
ビットマップとしてキャッシュ（システム・メモリに設
定される）に記憶可能である。その結果、ＣＰＵは「Ｒ
ＥＰＭＯＶＳＤ」命令を使用して、ダブルワード幅の
走査線で配列された字形ビットマップ・データをグラフ
ィックス・アダプタに効果的にコピーする。

【００３７】図７を参照すると明らかなように、文字
「Ａ」が先ずグラフィックス・アダプタに送られ、しか
る後、文字「Ｂ」がグラフィックス・アダプタに送られ
る。文字「Ｃ」は、本発明に従って表示される第３の文
字である。１つの文字の幅全体が、図５に示されたよう
な複数カラムで送られるのではなく、各走査線において
送られる。単一カラムの走査線の利用は、フォント・デ
ータの速い処理を可能にする。

【００３８】この文字指向プロセスは、グラフィックス
・アダプタが文字の幅全体及び文字間スペースに対して
ページ・モードを維持することを可能にする。（但し、
アドレスされたメモリはページ境界に跨らず、グラフィ
ックス・アダプタは割り込みされないものと仮定す
る）。本発明の好適な実施例によれば、ページ・モード
の使用を増加させることはハードウエア・パフォーマン
スを改善する。

【００３９】図８を参照すると、３つのデータ・セクシ
ョンを含む、システム・メモリにおけるキャッシュ・デ
ータ構造２０６が、本発明の好適な実施例に従って示さ
れる。セクション２０８は、特定の文字がキャッシュさ
れているかどうかを表すフラッグを含む２５６エントリ
の１ビット・アレーである。セクション２１０は、文字
幅、ダブルワードのビットマップ・サイズ、及び特定の
文字のためのビットマップに対するポインタのようなデ
ータを含む２５６エントリの６ビット・アレーである。
セクション２１２は文字に対する字形ビットマップを含
む。セクション２１０におけるエントリ「ｎ」は、セク
ション２１２における字形ビットマップ「ｎ」にマップ
する。本発明の好適な実施例に従って、他のキャッシュ
構成が使用可能であることは、当業者には明らかであろ
う。

【００４０】図９を参照すると、文字指向プロセスのフ
ローチャートが、本発明の好適な実施例に従って示され
る。そのプロセスはブロック２４０で始まり、ブロック
２４１に示されるように、ストリング長を得る。しかる
後、ブロック２４２に示されるように、フォント情報が
得られるかどうかに関する決定が行われる。フォント情
報が得られる場合、プロセスは、ブロック２４３に示さ
れるように、宛先（ｘ，ｙ）、フォント高、及び文字数
を表すデータをグラフィックス・アダプタにおけるレジ
スタにロードする。しかる後、ブロック２４４に示され
るように、文字の字形幅、文字間スペース、及び画素に
関するデータがグラフィックス・アダプタに送られる。
次に、ブロック２４５に示されるように、そのストリン
グが終了したかどうかの決定が行われる。そのストリン
グが終了するまで、プロセスはブロック２４３に反復的
に戻る。ブロック２４６に示されるように、ストリング
の終了時に、そのプロセスは終了する。「ストリング」
とは、本発明の好適な実施例に従ってディスプレイ上に
表示されるべき文字行全体のことである。

【００４１】ブロック２４２を再び参照すると、フォン
ト情報が得られない場合、ブロック２４７に示されるよ
うに、プロセスはシステム・メモリにおけるキャッシュ
にフォント情報をロードし、文字に対する字形ビットマ
ップを配置する。

【００４２】図１０を参照すると、文字を処理するため
のプロセスが本発明の好適な実施例に従って示される。
このプロセスは、本発明によるデータ処理システムにお
けるＣＰＵによって実行される。図示のように、プロセ
スはブロック２２０において始まり、しかる後、字形ビ
ットマップが正しいフォーマットであるかどうかの決定
が行われる。字形ビットマップが正しいフォーマットで
ない場合、ブロック２２４に示されるように、プロセス
は字形ビットマップを１ｂｐｐにフォーマットする。し
かる後、ブロック２２６に示されるように、その文字の
字形ビットマップに対して１カラムの走査線だけしか作
成されないように、字形ビットマップが走査線ベースで
配列される。

【００４３】そこで、ブロック２２８に示されるよう
に、プロセスは字形ビットマップをダブルワード配列し
（３２ビット境界で）、バイト境界における端部に必要
なパッドを加える。図示の実施例では、パッドはゼロの
形で加えられる。しかる後、ブロック２３０に示される
ように、そのフォーマットされた字形ビットマップはシ
ステム・メモリにおけるキャッシュに記憶される。ブロ
ック２２２を再び参照すると、字形ビットマップが既に
正しいフォーマットである場合、ブロック２３４に示さ
れるように、プロセスはその字形ビットマップをシステ
ム・メモリにおけるキャッシュにコピーし、再びブロッ
ク２３２において終了する。

【００４４】図１１を参照すると、図９のブロック２４
４において字形ビットマップをグラフィックス・アダプ
タに送る文字指向プロセスのフローチャートが、本発明
の好適な実施例に従って示される。この図に示されたプ
ロセスは、フレーム・バッファにおけるオフ・スクリー
ン・ビデオ・メモリの代りにシステム・メモリにキャッ
シュされた字形ビットマップをグラフィックス・アダプ
タに送る。そのプロセスはブロック２５０において始ま
り、しかる後、ブロック２５２に示されるように、文字
変数がゼロにセットされる。次に、その文字変数に関す
る判断ブロックのためのリターンがブロック２５４に示
される。ブロック２５６に示されるように、走査線変数
がゼロにセットされる。走査線変数に関する判断ブロッ
クのためのリターンがブロック２５８に示される。

【００４５】次に、ブロック２６０に示されるように、
次の「ｎ」画素幅の字形ビットマップ・データが得られ
る。文字指向プロセスにおいて、「ｎ」は図示の実施例
ではダブルワードであり、「ｎ」は、本発明の好適な実
施例によれば、走査線の幅として選択される。しかる
後、ブロック２６２に示されるように、ページ・ブレー
ク遅延が生じる。この遅延は、図示の例では、８０ナノ
秒である。ブロック２６４に示されるように、各画素が
グラフィックス・アダプタに書き込まれる。図示の実施
例における画素は、４０ナノ秒／画素の割合で書き込ま
れる。しかる後、ブロック２６６に示されるように、走
査線変数が１だけインクレメントされる。次に、ブロッ
ク２６８に示されるように、走査線変数が走査線最大値
よりも大きいかどうかに関する決定が行われる。この決
定の結果が否定である場合、プロセスはブロック２５８
に戻る。しかし、走査線変数が走査線最大値よりも大き
い場合、ブロック２７０に示されるように文字変数がイ
ンクレメントされる。しかる後、ブロック２７２に示さ
れるように、文字変数が文字最大値よりも大きいかどう
かに関する決定が行われる。その結果が否定である場
合、プロセスはブロック２５４に戻る。そうでない場
合、ブロック２７４に示されるように、プロセスは終了
する。

【００４６】本発明の好適な実施例によれば、ストリン
グ指向プロセスも、文字を表示するために使用可能であ
る。本発明のストリング指向プロセスは一時に１つの走
査線ずつ文字ストリングを処理する。ストリング指向プ
ロセスでは、一時に１つの走査線ずつ、文字のストリン
グ全体が処理される。換言すれば、すべての文字の対し
て単一の走査線が、次の走査線が始まる前に表示するた
めに、グラフィックス・アダプタに送られる。このタイ
プのプロセスは、グラフィックス・アダプタがメモリ・
ページ・モードを最大に利用することを可能にする。

【００４７】文字指向プロセスとは異なり、ＣＰＵは、
図１２に示されるように次の走査線に進む前に、そのス
トリングにおける各文字に対する特殊な走査線のための
データを収集する。文字「Ａ」、「Ｂ」、及び「Ｃ」
は、３つの文字すべてがディスプレイ上でレンダされる
まで、走査線０から走査線ｎまで、一時に１走査線ずつ
グループとして表示される。このプロセスは、複雑なプ
ログラミング・シーケンスのために及び収集されるべき
データが散乱しているという性質のために、ＣＰＵにお
ける負荷を増大させる。

【００４８】図１３を参照すると、システム・メモリか
らグラフィックス・アダプタに字形ビットマップ・デー
タを送るためのストリング指向プロセスのフローチャー
トが、本発明の好適な実施例に従って示される。図示の
ように、そのプロセスはブロック３５０で始まり、しか
る後、ブロック３５２に示されるように、走査線変数が
ゼロにセットされる。次に、走査線変数に関連する判断
ブロックのためのリターンがブロック３５４に示され
る。

【００４９】しかる後、ブロック３５６に示されるよう
に、字形ビットマップ・データの次の「ｎ」画素幅が得
られる。ストリング指向プロセスでは、「ｎ」は１つの
走査線全体に対する画素の数である。次に、ブロック３
５８に示されるように、ページ・ブレーク遅延が生じ
る。そこで、ブロック３６０に示されるように、各画素
がシステム・メモリからグラフィックス・アダプタに書
き込まれる。しかる後、ブロック３６２に示されるよう
に、走査線変数が１だけインクレメントされる。次に、
ブロック３６４に示されるように、走査線変数が走査線
最大値よりも大きいかどうかの決定が行われる。その結
果が否定である場合、プロセスはブロック３５４に戻
る。そうでない場合、ブロック３６６に示されるよう
に、プロセスは終了する。

【００５０】文字指向プロセス及びストリング指向プロ
セスによって処理されるデータはＣＰＵによる事前処理
を必要とする。ＣＰＵは、フォントを表すデータを配置
することそしてそれらをシステム・メモリに設定された
キャッシュに記憶することによってそれらフォントを事
前処理するために使用される。そのデータは、文字又は
文字のストリング全体がキャッシュからグラフィックス
・アダプタに走査線ベースでコピーされるように、キャ
ッシュに記憶される。文字又は文字のストリングは、ペ
ージ・ブレークが生じないように、走査線ごとにキャッ
シュに記憶される。

【００５１】ストリング指向プロセスでは、本発明の好
適な実施例によれば、文字ごとのベースに代わって、１
行で表示されるべき文字のストリング全体に対して走査
線ベースに字形ビットマップが配列されることを除け
ば、その事前処理は文字指向プロセスに対する事前処理
のプロセスと同じである。

【００５２】使用されるハードウエアに関して、システ
ム・メモリからフレーム・バッファへのデータのブロッ
ク転送は、今日のグラフィックス・アダプタによってサ
ポートされる１つの機能である。「イメージ転送」又は
「ストライド」と呼ばれるこの機能の特別バージョン
は、数多くのグラフィックス・プロセッサにおいて得る
ことができ、この機能を最適化する助けとなる。現在、
ストライドをサポートするいくつかのグラフィックス・
プロセッサは、米国のウェイテック（Ｗｅｉｔｅｋ）社
からのＰ９１００及びマトロックス（Ｍａｔｒｏｘ社）
からのＭＧＡである。ＩＢＭＲＩＳＣシステム／６０
００コンピュータのようなハイ・エンドＲＩＳＣプロセ
ッサにおいて使用される殆どのグラフィックス・プロセ
ッサは、ストライドとして知られれたその機能を組み込
んでいる。この機能を使用すると、グラフィック・プロ
セッサは、システム・メモリからの単一の「ＲＥＰＭ
ＯＶＳＴ」（インテル・プロセッサにおいて見られるア
センブリ言語命令）を利用して字形ビットマップを移動
させることができ、インテル社８０４８６の２５メガヘ
ルツＣＰＵベースのデータ処理システムにおいて１００
パーセント以上もビットマップ転送のパフォーマンスを
増大させることができる。ストライド機能がない場合、
ビット・ブロック転送時に、グラフィックス・プロセッ
サは、ビット・ブロック転送中にいつ新しい行が生じる
かがわからない。ストライド機能によって、グラフィッ
クス・プロセッサに送られた幅パラメータは、その選択
された幅が転送されてしまった後、グラフィックス・プ
ロセッサに走査線を変えるように伝える。

【００５３】ストリング指向プロセスは、グラフィック
ス・アダプタにおいては如何なる追加の機能も必要とし
ない。ストリング指向プロセスの下では、データをグラ
フィックス・アダプタに送るために、正規のビット・ブ
ロック転送が利用される。一方、文字指向プロセスの最
適な使用は、グラフィックス・アダプタにおいて追加の
機能を必要とする。

【００５４】本発明の好適な実施例によれば、複数のイ
メージが横並び（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）態様で転
送されることを可能にするために、ストライド／イメー
ジ転送機能に対する拡張が与えられる。文字指向プロセ
スの場合、これら複数のイメージは、横並びでレンダさ
れる時、ディスプレイ上に１行のテキストを生じるラス
タ・フォント（字形ビットマップとも呼ばれる）であ
る。

【００５５】本発明のグラフィックス・アダプタはスト
ライドの拡張、即ち、ストライドの特別ケースであり、
それ自身がメモリからスクリーンへのビット・ブロック
転送の特別ケース、即ち、システム・バッファからグラ
フィックス・アダプタにおけるフレーム・バッファに矩
形領域の画素の転送の特別ケースである。システム・メ
モリにおけるモノクローム・ビットマップは、ビット・
ブロック転送を通してスクリーンに移動され、グラフィ
ックス・アダプタは、本発明の好適な実施例に従ってフ
レーム・バッファにその処理されたビットマップを配置
する前に、カラー拡張、クリッピング、及びライン・ブ
レークをパイプライン態様で行う。各文字の終わりに、
本発明の好適な実施例に従って文字ストリングが終了す
るまで、アドレス・レジスタが、文字幅及び文字間スペ
ース・データに基づいて、自動的に次の文字の始めにセ
ットされる。本発明の好適な実施例によれば、各文字に
対するグラフィックス・アダプタのアドレス・レジスタ
の再ローディングは不必要である。

【００５６】本発明の下では、宛先（ｘ，ｙ），文字
高、文字幅及び文字間スペース、並びに文字の数のよう
なデータをグラフィックス・アダプタにおける適当なレ
ジスタにロードすることによって、フォントがレンダさ
れる。そのプロセスは、選択されたオペレーション・コ
ードを送ることによって開始可能であり、或いは、代替
えとして、そのプロセスは本発明の好適な実施例に従っ
て利用される幅レジスタにデータを配置することによっ
て開始可能である。

【００５７】図１４を参照すると、ディスプレイ・スク
リーン上で文字指向プロセスを使用してデータ処理シス
テムのグラフィックス・アダプタにおける字形ビットマ
ップを表示するためのプロセスを説明する図が、本発明
の好適な実施例に従って示される。グラフィックス・ア
ダプタは、「Ａ」から「Ｃ」まで、一時に１文字ずつフ
ォントを表示する。図示の例における文字の数は３であ
る。従って、表示プロセスの開始時に、文字カウンタが
３にセットされ、アドレス・カウンタが、宛先アドレス
とも呼ばれる開始アドレスにセットされる。各文字は、
幅Ｗ（ｎ）及び文字間スペースｉ（ｎ）をそれと関連付
けられる。表示プロセスが完了する時、文字カウンタは
ゼロに等しくなる。

【００５８】本発明の好適な実施例に従って、図１５は
グラフィックス・アダプタにおけるグラフィックス・プ
ロセッサによって使用されるプロセスのフローチャート
を示す。そのプロセスはブロック６００において開始
し、しかる後、ブロック６０２に示されるように、宛先
座標（ｘ，ｙ）、文字高、ストリングにおける文字の
数、及びオペレーション・コードをグラフィックス・ア
ダプタのレジスタにロードする。

【００５９】次に、ブロック６０４に示されるように、
文字幅及び文字間スペースがグラフィックス・アダプタ
の幅レジスタにロードされる。そこで、ブロック６０６
に示されるように、その文字のための字形ビットマップ
をグラフィックス・アダプタのプロセッサにおける入力
レジスタに送るために、その文字の「ＲＥＰＭＯＶＳ
Ｄ」が遂行される。そこで、ブロック６０８に示される
ように、プロセスは各ダブルワードを取得し、それをカ
ラー拡張のための１ビット／画素（ｂｐｐ）として利用
する。グラフィックス・アダプタは、ブロック６１０に
示されるように、第１文字の左上においてアドレス・カ
ウンタをスタートさせ、そしてその高さに等しい第１文
字の終わりまでＹアドレスをインクレメントする。ブロ
ック６１２に示されるように、各走査線はフレーム・バ
ッファにおけるディスプレイ・メモリにカラー拡張され
る。カラー拡張は、当業者にはよく知られているプロセ
スである。

【００６０】更に、ブロック６１４に示されるように、
文字は、走査線ベースで、字形ｘ＋ｉ文字間スペースの
範囲でクリップされる。そこで、ブロック６１６に示さ
れるように、文字カウンタが１だけデクレメントされ
る。しかる後、ブロック６１８に示されるように、文字
カウンタは、それがゼロに等しいかどうかを知るために
テストされる。文字カウンタがゼロよりも大きい場合、
ブロック６２０に示されるように、そしてブロック６２
２に示されるように、ｘアドレスが幅レジスタだけイン
クレメントされ、ｙレジスタが当初のｙ値に変更され
る。

【００６１】そこで、プロセスは反復的にブロック６０
４に戻り、次の文字に対する文字幅及び文字間スペース
が幅レジスタにロードされ、そしてすべての文字が表示
されてしまうまで、このサイクルが繰り返される。ブロ
ック６１８において文字カウンタがテストされそしてそ
れがゼロに等しいことがわかった時、ブロック６２４に
示されるように、プロセスは終了する。

【００６２】次に、図１６を参照すると、文字の処理を
示す図が本発明の好適な実施例に従って示される。ブロ
ック６２６において、文字は走査線ベースでダブルワー
ド境界にパッドされる。ブロック６２８はその文字に対
する字形ｘを表し、ブロック６３０は文字間スペース
「ｉ」である。ｘ＋１がブロック６３２に示され、ブロ
ック６３６に示されるようなビデオ・メモリへのカラー
拡張後の文字「Ａ」を生じる。ブロック６３６は、ユー
ザに表示されるブロックである。

【００６３】図１７を参照すると、文字を処理するため
にグラフィックス・アダプタによって利用されるレジス
タのブロック図が、本発明の好適な実施例に従って示さ
れる。本発明を使用してスクリーン上に文字を表示する
プロセスを開始させるためのオペレーション・コードを
ロードするために、Ｏｐコード・レジスタ６５０が使用
可能である。宛先Ｘレジスタ６５２及び宛先Ｙレジスタ
６５４は、その文字の開始アドレス又は宛先アドレスを
ロードするために利用される。これら２つのレジスタ
は、表示されるべき第１文字の開始アドレスを与える。
文字数レジスタ６５６は、如何に多くの文字が処理され
るかをグラフィックス・アダプタに知らせるために使用
される。字形高レジスタ６５８は画素における文字の高
さをセットするために利用され、字形幅＋文字間スペー
ス・レジスタ６６０は、画素における文字及び文字間ス
ペースが如何に幅広いかをグラフィックス・アダプタに
知らせるために使用される。この情報は、未使用の情報
のクリッピングを可能にするために、文字及び文字間ス
ペースがそのワードが何処で終了するかを、この情報は
グラフィックス・アダプタに知らせる。

【００６４】その代替えでは、Ｏｐコード・レジスタ６
５０をグラフィックス・アダプタに加える必要がない。
その代わり、このタイプの反復的なデータ転送のために
しか利用されないレジスタへのデータのローディング
が、そのプロセスを開始するためのトリガとして使用可
能である。字形幅＋文字間スペース・レジスタ６６０
は、本発明の好適な実施例によれば、データがこの特定
のレジスタにロードされる時、そのプロセスをトリガす
るレジスタとして利用可能である。

【００６５】Ｏｐコード・レジスタ６５０、文字数レジ
スタ６５６、並びに字形幅＋文字間スペース・レジスタ
６６０は、本発明のグラフィックス・アダプタを形成す
るために付加される新しいレジスタである。これらレジ
スタのハードウエアにおける実際の設計及び導入は、当
業者にはよく知られているので、それらラッチの詳細な
説明は行わないことにする。

【００６６】本発明の好適な実施例に従ってスクリーン
上にフォントを（字形ビットマップの形で）表示する場
合の速度を上げるためには、文字指向プロセスはその開
示されたグラフィックス・アダプタなしでも利用可能で
ある。しかし、標準的なグラフィックス・アダプタに文
字が送られ時には、システム・メモリからフレーム・バ
ッファにビット・ブロック転送を行うために、レジスタ
は再ロードされなければならない。一方、文字指向プロ
セス及び開示されたグラフィックス・アダプタが組み合
わされた時、新しい文字が表示されるべき時にいつもレ
ジスタを再ロードする必要なくグラフィックス・アダプ
タが反復的なビット・ブロック転送を行うことができる
ので、処理の速度は増大する。

【００６７】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００６８】（１）データ処理システムにおいてディス
プレイ上に文字を表示する効率を高めるための方法にし
て、前記データ処理システムにおいて前記ディスプレイ
上に文字を表示するための複数のプロセスを実行するス
テップにして、前記複数のステップの各々は前記ディス
プレイ上に文字を表示するために異なる量のプロセッサ
資源を必要とするステップと、前記複数のプロセスのう
ちの特定のプロセスを選択するステップにして、前記複
数のプロセスのうちの前記選択されたプロセスは前記複
数のプロセスのうちの他のプロセスよりも効率的な前記
ディスプレイにおける文字の表示を行うステップと、よ
り成る方法。

【００６９】（２）前記選択するステップは前記データ
処理システムの構成の変化に応答して遂行されることを
特徴とする上記（１）に記載の方法。

【００７０】（３）前記複数のプロセスを実行するステ
ップは文字を表示するためのストリング指向プロセスを
実行することを特徴とする上記（１）に記載の方法。

【００７１】（４）前記複数のプロセスを実行するステ
ップは文字を表示するための標準的なフォント・プロセ
スを実行することを特徴とする上記（３）に記載の方
法。

【００７２】（５）ディスプレイ上に文字を表示するた
めの複数のプロセスにして、前記複数のステップの各々
は前記ディスプレイ上に文字を表示するために異なる量
のプロセッサ資源を必要とするものと、前記複数のプロ
セスのうちの特定のプロセスを選択するための選択手段
にして、前記複数のプロセスのうちの前記選択されたプ
ロセスは前記複数のプロセスのうちの他のプロセスより
も効率的な前記ディスプレイにおける文字の表示を行う
ものと、より成るデータ処理システム。

【００７３】（６）前記選択手段は前記データ処理シス
テムの構成における変化に応答して活動化されることを
特徴とする上記（５）に記載のデータ処理システム。

【００７４】（７）前記複数のプロセスは文字を表示す
るためのストリング指向プロセスを含むことを特徴とす
る上記（５）に記載のデータ処理システム。

【００７５】（８）前記複数のプロセスは文字を表示す
るための標準的なフォント・プロセスを含むことを特徴
とする上記（６）に記載のデータ処理システム。

【００７６】（９）システム・メモリと、前記システム
・メモリに複数の字形ビットマップとして記憶された複
数の文字と、ディスプレイと、グラフィックス・アダプ
タ・メモリを含み、前記ディスプレイに接続されたグラ
フィックス・アダプタと、前記システム・メモリから前
記グラフィックス・アダプタ・メモリに前記複数の字形
ビットマップのうちの選択されたものを移動するための
伝送手段と、より成り、前記複数の字形ビットマップの
うちの前記選択されたものが前記ディスプレイ上に表示
されることを特徴とするデータ処理システム。

【００７７】（１０）前記複数の字形ビットマップは文
字のストリングを含むことを特徴とする上記（９）に記
載のデータ処理システム。

【００７８】（１１）前記システム・メモリはページ・
モードを含むこと、及び前記字形ビットマップが前記シ
ステム・メモリから前記グラフィクス・アダプタ・メモ
リに移動される時、前記ページ・モードにおけるブレー
クの発生を最小にするために各字形ビットマップは前記
システム・メモリに複数の走査線として配列されること
を特徴とする上記（１０）に記載のデータ処理システ
ム。

【００７９】（１２）前記複数の字形ビットマップのう
ちの選択されたものを前記グラフィックス・アダプタに
移動するための伝送手段は前記データ処理システムの中
央処理装置において永久的移動命令を利用することを特
徴とする上記（１１）に記載のデータ処理システム。

【００８０】

【発明の効果】本発明によれば、グラフィックス・ディ
スプレイ上に文字を効率的に表示するための方法及び装
置が得られる。

【図面の簡単な説明】

【図１】本発明の好適な実施例を導入し得るデータ処理
システムの概略図である。

【図２】本発明の１つの好適な実施例に従って構成され
た図１のデータ処理システムのブロック図である。

【図３】本発明の他の好適な実施例に従って構成された
図１のデータ処理システムのブロック図である。

【図４】本発明の好適な実施例に従って、データ処理シ
ステムに対する最適なフォント処理手順を選択するため
のプロセスのフローチャートである。

【図５】本発明の好適な実施例に従って描かれた文字
「Ａ」に対する画素データの図である。

【図６】従来技術で知られた標準的なフォント処理プロ
セスのフローチャートである。

【図７】本発明の好適な実施例に従ってシステム・メモ
リからグラフィックス・アダプタにフォントデータを送
るための文字指向プロセスを表す図である。

【図８】本発明の好適な実施例に従ってシステム・メモ
リに記憶された字形ビットマップのブロック図である。

【図９】本発明の好適な実施例に従ってディスプレイ・
スクリーン上に文字を表示するための文字指向プロセス
のフローチャートである。

【図１０】本発明の好適な実施例に従ってフォントを事
前処理するためのプロセスのフローチャートである。

【図１１】本発明の好適な実施例に従って文字指向プロ
セスにおいてグラフィックス・アダプタに字形ビットマ
ップを送るためのプロセスのフローチャートである。

【図１２】本発明の好適な実施例に従ってシステム・メ
モリからグラフィックス・アダプタに字形ビットマップ
を送るためのストリング指向プロセスを表す図である。

【図１３】本発明の好適な実施例に従ってストリング指
向プロセスにおいてシステム・メモリからグラフィック
ス・アダプタに字形ビットマップを送るためのプロセス
のフローチャートである。

【図１４】本発明の好適な実施例に従ってディスプレイ
・スクリーン上に文字を表示するためのグラフィックス
・アダプタにおけるプロセスを示す図である。

【図１５】本発明の好適な実施例に従ってディスプレイ
・スクリーン上に文字を表示するためのグラフィックス
・アダプタにおけるプロセスのフローチャートである。

【図１６】本発明の好適な実施例に従ってグラフィック
ス・アダプタにより文字を処理する過程を示す図であ
る。

【図１７】本発明の好適な実施例に従って文字を処理す
るためにグラフィックス・アダプタにより利用されるレ
ジスタを示す図である。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献特開平３−65988（ＪＰ，Ａ) 特開平４−348483（ＪＰ，Ａ)

Claims

(57)【特許請求の範囲】

【請求項１】データ処理システムのグラフィックス・ア
ダプタに接続されたビデオ・ディスプレイ上に文字を表
示するための上記データ処理システムにおける方法にお
いて、それぞれが、文字に関するデータを上記グラフィックス
・アダプタに送り上記ビデオ・ディスプレイ上に文字を
表示する複数の別個のプロセスであって、該複数の別個
のプロセスのそれぞれは上記ビデオ・ディスプレイ上に
文字を表示するのに他のプロセスと異なるプロセッサ資
源の量を必要とする上記複数の別個のプロセスを記憶す
るステップと、上記複数の別個のプロセスのうち、どのプロセスが所定
時間の間に最も多くの文字表示を行うことができるかを
調べ、最も多くの文字表示を行うプロセスを選択するス
テップと、上記選択されたプロセスを実行して文字を上記ビデオ・
ディスプレイ上に表示するステップとを含む文字を表示
する方法。
【請求項２】上記選択するステップは、上記データ処理
システムの構成が変更されたことに応答して行われるこ
とを特徴とする請求項１に記載の文字を表示する方法。
【請求項３】上記記憶するステップは、文字を表示する
ためのストリング指向プロセスを含む上記複数の別個の
プロセスを記憶することを特徴とする請求項１又は請求
項２に記載の文字を表示する方法。
【請求項４】上記記憶するステップは、文字を表示する
ための文字指向プロセスを含む上記複数の別個のプロセ
スを記憶することを特徴とする請求項３に記載の文字を
表示する方法。
【請求項５】上記記憶するステップは、文字を表示する
ための標準フォント・プロセスを含む上記複数の別個の
プロセスを記憶することを特徴とする請求項４に記載の
文字を表示する方法。
【請求項６】グラフィックス・アダプタに接続されたビ
デオ・ディスプレイ上に文字を表示するデータ処理シス
テムにおいて、それぞれが、文字に関するデータを上記グラフィックス
・アダプタに送り上記ビデオ・ディスプレイ上に文字を
表示する複数の別個のプロセスであって、該複数の別個
のプロセスのそれぞれは上記ビデオ・ディスプレイ上に
文字を表示するのに他のプロセスと異なるプロセッサ資
源の量を必要とする上記複数の別個のプロセスを記憶す
る手段と、上記複数の別個のプロセスのうち、どのプロセスが所定
時間の間に最も多くの文字表示を行うことができるかを
調べ、最も多くの文字表示を行うプロセスを選択する手
段と、上記選択されたプロセスを実行して文字を上記ビデオ・
ディスプレイ上に表示する手段とを含むデータ処理シス
テム。
【請求項７】上記選択手段は、上記データ処理システム
の構成が変更されたことに応答して付勢されることを特
徴とする請求項６に記載のデータ処理システム。
【請求項８】上記複数の別個のプロセスは、文字を表示
するためのストリング指向プロセスを含むことを特徴と
する請求項６又は請求項７に記載のデータ処理システ
ム。
【請求項９】上記複数の別個のプロセスは、文字を表示
するための文字指向プロセスを含むことを特徴とする請
求項８に記載のデータ処理システム。
【請求項１０】上記複数の別個のプロセスは、文字を表
示するための標準フォント・プロセスを含むことを特徴
とする請求項９に記載のデータ処理システム。
【請求項１１】上記文字に関するデータは文字のビット
・マップであることを特徴とする請求項９に記載のデー
タ処理システム。
【請求項１２】データ処理システムのグラフィックス・
アダプタに接続されたビデオ・ディスプレイ上に文字を
表示するための上記データ処理システムにおける方法に
おいて、それぞれが、文字に関するデータを上記グラフィックス
・アダプタに送り上記ビデオ・ディスプレイ上に文字を
表示する複数の別個のプロセスであって、該複数の別個
のプロセスのそれぞれは上記ビデオ・ディスプレイ上に
文字を表示するのに他のプロセスと異なるプロセッサ資
源の量を必要とし、上記複数の別個のプロセスは少なく
とも文字指向プロセス及びストリング指向プロセスの１
つを含む上記複数の別個のプロセスを記憶するステップ
と、上記複数の別個のプロセスのうち、どのプロセスが所定
時間の間に最も多くの文字表示を行うことができるかを
調べ、最も多くの文字表示を行うプロセスを選択するス
テップと、上記選択されたプロセスを実行して文字を上記ビデオ・
ディスプレイ上に表示するステップとを含む文字を表示
する方法。