JP2603759B2

JP2603759B2 - ディスプレイ装置を有するデータ処理装置

Info

Publication number: JP2603759B2
Application number: JP2400085A
Authority: JP
Inventors: 裕司井上
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1990-01-19
Filing date: 1990-12-01
Publication date: 1997-04-23
Anticipated expiration: 2012-04-23
Also published as: EP0438152A2; AU6946691A; KR910014793A; DE69129706D1; CN1053502A; DE69129706T2; CA2034295C; AU652549B2; EP0438152A3; ATE168205T1; EP0438152B1; JPH08320774A; JPH06242907A; CN1045673C; US5146558A; JP2813332B2; CA2034295A1; KR940007813B1

Description

【発明の詳細な説明】

【０００１】

【技術分野】本発明はディスプレイ装置を有するデータ
処理装置に係わり、特にマウスのようなポインティング
デバイスと共に使用されるマルチタスクオペレーション
−マルチウインドゥのデータ処理装置に関するものであ
る。

【０００２】

【背景技術】ＵＮＩＸまたはＯＳ／２のようなマルチタ
スク・オペレーションシステムにおいては、タスクは同
時に非同期的に処理される（ＵＮＩＸ及びＯＳ／２はそ
れぞれ米国ＡＴ＆Ｔベル研究所の登録商標及び米国ＩＢ
ＭＣｏｒｐ．の商標である）。例えば、複数のタスク
をシステムがそのディスプレイの制御に従事している際
にも処理し得る。又、ネットワークを介して相互接続さ
れたいくつかのホストコンピュータのグループにおい
て、タスクは１つのホストから他のホストへと送り実行
され得る。そしてマルチウインドゥシステムでは進行中
の各タスクに関する情報は単一のスクリーン上のそれぞ
れのウインドゥに同時に表示される。Ｘウインドゥはそ
のようなマルチウインドゥシステムの現在の代表的なも
のの１つである（Ｘウインドゥは米国マサチューセッツ
工科大学の登録商標である）。

【０００３】コンピュータ端末ディスプレイ装置として
従来リフレッシュ走査型ＣＲＴ（陰極線管）が一般的に
用いられてきた。そしてメモリ性を有するベクトル走査
型ＣＲＴはＣＡＤ（コンピュータエイデッドデザイン）
に関する大きなサイズの高細度ディスプレイとしてしば
しば用いられている。ベクトル走査型ＣＲＴではイメー
ジが一度表示されると次のスクリーンリフレッシュ（全
画面のリフレッシュ）がなされるまでメモリ機能によっ
てそのイメージを維持している。しかしその動作速度が
比較的低いという理由で移動するカーソル表示、移動す
るマイコン表示、マウスのようなポインティングデバイ
ス又はエディタ表示のようなリアルタイムのマン−マシ
ン・インターレースディスプレイとしては適当ではなか
った。一方、リフレッシュ走査型ＣＲＴはメモリ機能を
有しないから一定のフレーム周波数でのリフレッシュ・
サイクルが必要である。フレーム周波数毎にディスプレ
イに新しい画面が供給され、その周波数はフレーム当た
りの走査線数と各ラインの水平走査時間の積の逆数であ
り、フリッカ防止のためには60Hz以上が望まれる。ノン
・インターフェース走査法は両方のタイプに共通に採用
されており、画面におけるデータの移動表示例えばマイ
コンの移動表示がユーザがそれを観測し追従するのに適
するようにしている。

【０００４】ＣＲＴの両方のタイプで、例えばマルチウ
インドゥを適切に表示するなどの理由で所望の表示解像
度が高くなる程ディスプレイ装置は大型となり消費電力
も大きくなると共に駆動回路も高価となってくる。その
ような大型の高解像度ＣＲＴは種々の不都合な面があ
り、そのため最近はフラットパネル型のディスプレイが
開発されるようになってきた。

【０００５】現在、種々のフラットディスプレイ・パネ
ルがあるが、その１つはスーパツイストネマチック液晶
（ＳＴＮ）を用いた高多重駆動システムを採用するもの
である。又、その変形として白／黒ディスプレイの使用
のもの及びプラズマディスプレイがある。これらの全て
はＣＲＴシステムの画像データ転送方式及びスクリーン
リフレッシュに60Hz又はそれより高い周波数によるノン
・インターレース走査方式を採用しており、それ故一つ
の全画面について400〜480本の走査ライン程度が得られ
るだけである。例えば1000本以上の走査ラインのより大
型のフラットディスプレイパネルは尚実用段階にはな
い。この原因はフリッカを防止するため60Hz以上のフレ
ーム周波数でリフレッシュサイクルをしなければならな
いが、そうすると１ライン当たり10〜50μsec 以下の走
査時間となるため良好なコントラストを得ることができ
ないからである。

【０００６】ＣＲＴであると、蛍光スクリーン上に形成
されたイメージは蛍光特性のためにある時間維持され
る。ＴＮ型ＬＣＤ（ツイストネマチック型液晶）では、
イメージは十分な駆動電圧の印加による光透過率の変化
を用いて形成される。いずれかのタイプであっても、少
なくとも30Hz以上の高いフレーム周波数を用いることが
必要である。

【０００７】例えば走査ライン数1920本でライン当たり
2560画素、即ち一画面で 4,915,200画素数のＣＲＴディ
スプレイ又はＴＮ型ＬＣＤでは約17.5μsec の水平走査
時間となりそして水平ドットクロック周波数は約147MHz
となる。ＣＲＴの場合、147MHzの水平ドットクロック周
波数は現在入手できるピクチャーチューブで用いられて
いるビームガンの最大電子ビーム変調周波数をかなり越
えたものとなる。その結果正確なイメージ形成は達成さ
れない。ＴＮ型ＬＣＤの場合、1920本の走査ラインを駆
動するということは現在可能とされる約1/400 の最小デ
ューティファクタよりかなり低い1/1920のデューティフ
ァクタに該当してしまう。一方、現実的な水平走査速度
での駆動が用いられると、そのフレーム周波数は30Hzよ
り低くなり、フリッカが表示品質を損なってしまう。こ
れらの理由で、ＣＲＴやＴＮ型ＬＣＤで得られる画面の
大型化と高細度化は走査ライン数が十分に増加できない
ため限られてしまっていた。

【０００８】最近になって Clarkと Lagerwall（米国特
許第 4,367,924号）は高速応答性とメモリ性（双安定
性）の両方を有する強誘電体液晶装置（ＦＬＣＤ）を提
案した。ＦＬＣＤはスメチッチＣ相(SmC^*)またはＨ相(S
mH^*)を個有温度で示し、光学的な双安定状態を有する。
ＦＬＣＤは印加電界で高速な状態変化を示し、高速メモ
リ性ディスプレイ装置として広く用いられることが期待
されている。

【０００９】ＦＬＣＤは上述したフラットパネルディス
プレイ装置を著しく凌ぐ大型高細度ディスプレイ装置に
可能性を与えている。比較的低いフレーム周波数での駆
動が必要であるから、適切なマン−マシーンインターフ
ェイスディスプレイであるようそのメモリ機能を利用し
部分書き換え走査を採用している。部分書き込み走査と
は、スクリーン上書き換えられるべき領域のみが走査さ
れそこに新しい描画を行うというものである。そのよう
な部分書き換え走査は米国特許第 4,655,561号に開示さ
れている。ＦＬＣＤの双安定性機能を用いたディスプレ
イとして（走査線数1920）×（ライン当たりの画素256
0）のフラットパネルが実現されている。

【００１０】ＦＬＣＤのライン走査方式では、フレーム
リフレッシュ周波数は走査線が増加するほど低くなる。
例えば50μsec/ラインの速度のＦＬＣＤに関するフレー
ム周波数は、 1920(ライン)×50(μsec/ライン)＝96(msec)＝10(Hz) である。一方、コンピュータの操作性上ポインティング
デバイスの動き及びキーボード入力のリアルタイム応答
性と滑らかさは重要な要素である。ポインティングデバ
イス指標（例えばマウスフォント）とか文字はスクリー
ン上の画面に対し比較的小さいものであるが、それを表
示するのに高速応答性が要求される。例えばマウスフォ
ントは60Hzで、そして文字は30Hzの速さで通常扱われな
ければならない。それ故、10Hzのフレーム周波数はその
ような動作に関し十分ではない。前述の“部分書き換え
走査技術”は、新しい描画をディスプレイの必要な領域
についてのみ書き換えるというもので、描画を更新する
に必要な時間を大幅に減ずることができる。もしマウス
フォントが32×32ビットデータとして画成されるとする
なら、そのデータの表示速度は、 32(ライン)×50(μsec/ライン)＝1.6(msec)＝625(Hz) となる。しかし、この“部分書き換え走査技術”を実際
に用いるには“部分書き換え要求”を認識しそして書き
換えられるべき走査線数をディスプレイに指示すること
が必要である。更に、その他いくつかの要因で部分書き
換えにおける現実の周波数は約 300Hz程度である。従っ
て、大型のディスプレイにおいてマウスフォント等の表
示のリアルタイム化に大きな改善をもたらすものであ
る。

【００１１】しかし、複数のタスクをマルチウインドゥ
で表示するディスプレイにあってはリアルタイム表示に
ついて又別な問題がある。図８Ａを参照するに、１つの
ディスプレイスクリーン上に３つのウインドゥ１、２及
び３がオープンされている。第１のタスクがウインドゥ
１において時々刻々針が動く時計を表示している。第２
のタスクがウインドゥ２において矢印方向に回転する直
線をグラフィック的に表示している。そしてテキストエ
ディタのような第３のタスクがウインドゥ３で文字を表
示している。又ベース（ルート）ウインドゥにおいてシ
ステムのタスクがスクリーン上１つの位置から次の位置
へと移動した矢印のマウスフォントを表示している。図
８Ｂはこのような描画コマンドの発生の時間系列とその
コマンドの実行の時間系列を示している。

【００１２】図示するように最初のマウスフォント表示
コマンド発生から２番目のマウスフォント表示コマンド
の発生との時間間隔にウインドゥ２から直線を描くコマ
ンドが８個発生したものとする。マルチタスクを処理す
るコンピュータであっても、それら複数のタスクからの
描画コマンドを同時並列的に処理するのではなく１つの
系列として順次実行するものであるから、２番目のマウ
スフォント表示コマンドの実行は他のタスクにおいて先
に発生した８個の直線を描くコマンドの実行処理後であ
る。ここでコマンドの実行時間、即ちグラフィックデバ
イスで実際に描画する時間（主にデバイスのハード的属
性に依存する）がコマンド発生の速さに追いつかなくな
ると、コマンド発生とその実行との間に時間的ずれが生
ずる。この結果２番目のマウスフォントはかなりの時間
遅れで表示されることになってしまう。

【００１３】この時間的ずれそのものを少なくするには
グラフィックデバイスのハード的な動作速度の改善のほ
か先に述べた部分書き換え走査技術のようなソフト的な
改善が必要である。しかしここで特に問題としているこ
とは、他のタスクから（または自己のタスクからの場合
もまれにある）発生される描画コマンドによってハード
ウェアイベントの表示のリアルタイム化が著しく遅延さ
れるという点である。このため現実のマウス操作に対し
スクリーン上の表示マウスフォントが追従しなくなると
いう問題がマルチウインドゥシステムでは特に発生する
可能性がある。

【００１４】コンピュータ操作にあってマウスとかキー
ボードからの入力はハードウェア（Ｈ／Ｗ）イベントと
称されるが、Ｈ／Ｗイベントのリアルタイム処理はコン
ピュータシステムにとってできるだけ保証されているこ
とが必要である。何故なら、このようなＨ／Ｗイベント
は操作者の操作と直接関係しておりＨ／Ｗイベントのリ
アルタイム処理は操作性そのものを意味しているからで
ある。

【００１５】

【発明の概要】本発明の目的は、ハードウェアイベント
のリアルタイム表示について改善されたデータ処理装置
を提供することにある。

【００１６】本発明のより固有な目的は、大型高精細Ｆ
ＬＣＤディスプレイ装置におけるハードウェアイベント
のリアルタイム表示を改善することにある。

【００１７】本発明の他のより固有な目的は、マルチウ
インドゥシステムにおけるハードウェアイベントのリア
ルタイム表示を改善することにある。

【００１８】本発明は、ディスプレイ装置に対する描画
要求を備え、ハードウェアイベント入力に基づいて発生
したプロセスを含む複数のプロセスをタイムシェアリン
グにおいて処理するマルチタスク手段及び該マルチタス
ク手段から受信した描画要求がハードウェアイベント入
力に基づいて発生した描画要求の時、該描画要求を他の
描画要求より優先させて登録させ、該登録させた描画要
求に基づいてグラフィックデバイスに対する描画命令を
発生させ、該描画命令をグラフィックデバイスへ転送す
るスケジューリング手段を論理的に構成しているホスト
プロセッサ、並びに該スケジューリング手段から転送さ
れた描画命令を登録し、描画命令に基づいた描画をディ
スプレイ装置で実行させる時、描画命令−実行時間を描
画要求に応じて設定し、該設定させた描画命令−実行時
間内で、ディスプレイ装置での描画を実行させるグラフ
ィックデバイスを有するデータ処理装置であって、前記
スケジューリング手段は、グラフィックデバイスに転送
された描画命令の実行完了状態をモニターし、該実行完
了が所定の段階まで進展するまで、前記マルチタスク手
段からの描画要求の登録を保留するデータ処理装置に特
徴がある。

【００１９】

【実施例の説明】

(1) ハードウェア構成本発明の実施例はＦＬＣＤをディスプレイとするコンピ
ュータシステムである。図１にそのハードウェア構成の
アウトラインを示す。システムはホスト側プロセッサで
制御されている部分とグラフィックデバイス側のプロセ
ッサとで制御されている部分とからなり、ホストとグラ
フィックデバイスのプロセッサは夫々独立した動作をし
ている。尚、ここでグラフィックデバイスとはグラフィ
ックカード、グラフィックコントローラ、ＦＬＣＤパネ
ルを含むデバイス全体を意味する。ホスト即ちコンピュ
ータ本体にはＯＳが実装されプロセスをタイムシェアリ
ング的に走行させており、各プロセスで生成された描画
命令はバスインターフェースを介してグラフィックデバ
イス内のグラフィックカードに与えられる。グラフィッ
クカードは描画命令に応じ描画内容をビデオ（Ｖ）ＲＡ
Ｍに展開する機能と共にその描画内容によってＦＬＣＤ
パネルに対し固有の部分書き込みの管理機能を有し、次
段のグラフィックスコントローラへＶＲＡＭ内容をデジ
タル信号として渡す。グラフィックスコントローラは送
られてきた部分書き込み情報を有するＶＲＡＭ内容のデ
ジタル信号からＦＬＣＤパネル上の所定のアドレス位置
に実際にドライバＩＣを介して図形などを表示する駆動
信号を形成する。

【００２０】グラフィックカードの実施例のブロック構
成は図３に示されている。グラフィックカードは、グラ
フィックプロセッサ20、インターフェース28及びメモリ
34のためのメモリコントローラ22とからなる。メモリ34
は命令を蓄積するRAM34-1、ビデオ出力を蓄積するVRAM3
4-2と34-3；及びグラフィックプロセッサ20のための初
期制御命令を蓄積するROM34-4 からなる。尚、後述する
グラフィックデバイスのグラフィックコマンド・バッフ
ァはRAM34-1 に論理的に構成されるものである。又、こ
れらメモリのいくつかはホスト側の主メモリ上に構成さ
れ得るものである。データはプロセッサ20とメモリ34と
の間でメモリコントローラ22を介して通信される。ビデ
オタイミング・ユニット32はグラフィックプロセッサ20
に同期信号を提供し、クロック30がグラフィックプロセ
ッサ20のタイミング信号として与えられる。VRAM34-1と
34-2の出力は出力インターフェース50へその入力として
与えられる。出力インターフェース50において入力され
たデータはマルチプレクサ36を経て、適当なグレースケ
ール又はカラー信号レベルが与えられる。カラー／グレ
ースケール・パレット38を通ってデジタルインターフェ
ース40に入る。デジタルインターフェース40は、スクリ
ーン上のアドレスデータとイメージデータ（信号線PD0
- PD7 ）、アドレスデータとイメージデータを識別する
信号ＡＨ／ＤＬ及びタイミング信号ＣＬＫを作成して次
段のグラフィックコントローラへと送る。

【００２１】グラフィックプロセッサ20は例えばTexas
Instrumentsの GSP34010プロセッサであり、それはグラ
フィック命令と一般命令の両方を実行することができ
る。インターフェース28はＩＢＭ“ＡＴバス”である。
これらは当業者に知られているものである。GSP34010の
詳細はTexas Instruments Inc.により刊行されているTM
S34010ユーザズガイド(刊行番号 SPVU007)に記述されて
いる。

【００２２】図２はグラフィックカードからの描画デー
タを得てＦＬＣＤパネルを駆動するグラフィックコント
ローラのブロック構成を示す。ＦＬＣＤパネルは1920本
の走査電極と2560本のデータ電極からなるマトリックス
構造である。走査電極は走査電極駆動回路82に、そして
データ電極はデータ電極駆動回路62に接続されている。
走査電極駆動回路62はデコーダ78、ラインアドレス・メ
モリ80及びアドレス検出回路88を含む。データ電極駆動
回路64はシフトレジスタ72、ラインメモリ74及びバッフ
ァ70を含む。

【００２３】描画位置をパネルスクリーン上に指定する
走査電極84をアドレスするための走査電極アドレスデー
タ（A0, A1, A2…A15)とイメージデータ(D0, D1, D2,…
D2559）が同一の信号線PD0 - PD7 を介して送られるか
ら、送信データがアドレスデータかイメージデータかを
識別する信号ＡＨ／ＤＬ信号が同時にプロセッサ89に送
られる。制御回路68ＡＨ／ＤＬ信号がハイレベルのとき
PD0 - PD7 上の信号を走査電極アドレスデータであると
してアドレス検出回路88で取り込ませ、ローレベルのと
きはイメージデータであるとしてラインバッファ70に取
り込ませる。ＡＨ／ＤＬ信号は又データを転送する転送
開始信号でもある。ラインバッファ70に取り込まれたイ
メージデータは一時的に蓄えられ、水平走査期間に合わ
せてシフトレジスタ72、ラインバッファ74を経てデータ
電極駆動装置76に与えられる。アドレス検出回路88で検
出されたアドレスデータはデコーダ78によりアドレスデ
ータに従う走査電極の駆動信号とされラインアドレス・
メモリ80を経て走査電極駆動装置82に印加される。

【００２４】本実施例では、表示パネル60の駆動とグラ
フィックカード内のプロセッサによる走査電極アドレス
データA0 - A15及びイメージデータDO - D2559の発生は
同期していないため、データ転送時に制御回路68とグラ
フィックプロセッサを同期させる必要がある。この目的
のために、同期信号Hsync が各水平走査時に制御回路で
発生される。このHsync 信号はＡＨ／ＤＬ信号と関連を
有している。グラフィックプロセッサ20はHsync をモニ
タしてHsync がHighからLow に遷移したのを検出した後
データ転送の準備に入り、ＡＨ／ＤＬ信号をLow からHi
ghに立ち上げ走査電極アドレスデータを転送し、ＡＨ／
ＤＬを再びHighからLow に立ち下げ画像データを転送す
る。その詳細な信号波形を図１３に示す。

【００２５】本発明は図１のようなグラフィックデバイ
スにあってＨ／Ｗイベントのリアルタイム化処理を改善
するためのもので、本発明の特徴はホスト側におけるグ
ラフィックデバイスへの論理的なインターフェース構成
に係わるものである。

【００２６】(2) ソフトウェア（論理）構成概要本発明の論理構成は、ＵＮＩＸオペレーティングシステ
ム（ＯＳ）で動作するＸウインドゥ・グラフィックユー
ザインターフェース（ＧＵＩ）を用い、図１のハードウ
ェア上に実装される。ＵＮＩＸオペレーティングシステ
ムのＵＮＩＸ固有の本質部分はカーネルと称される。ユ
ーザプログラムはopen(), read()等のシステムコールに
よってカーネルと相互作用をする。ＵＮＩＸのファイル
システム、マルチタスク・メカニズム（タイムシアリン
グ）、プロセス間通信などの機能はこのカーネルによっ
て提供されているものである。ＯＳは複数のモジュール
からなりベンダーがユーザに提供するシステムソフトウ
ェアである。ＯＳ内の１つのモジュールであるところの
デバイスドライバは、入出力ハードウェアデバイスを直
接制御するものであり、デバイス非依存性であるＵＮＩ
Ｘ固有のカーネルに対するインターフェースを提供する
ソフトウェアである。ディスプレイ装置を制御するのは
このデバイスドライバであり、ユーザプログラムはデバ
イスドライバを介してディスプレイ装置に描画を指示す
る。デバイスドライバは次のようなＩ／Ｏシステムコー
ル等によりカーネルの機能とデバイスのハード的属性の
関連においてプログラムされる。

【００２７】 #include <temio.h> int ioctl (fd, cmd, tbuf) /* 端末デバイスの制御 */ int fd; /* オープンされたファイル記述子 */ int cmd; /* 実行する操作を指定するコマンド */ struct termio * tbuf; /* 端末情報のための構造体へのポインタ */

【００２８】例えばコマンドTCGETAはtermio構造体をfd
によって参照される端末の情報で満たすことを命令する
ものである。デバイスドライバはカーネルにリンクさ
れ、１つの新しいカーネルイメージとなり得るが、ＵＮ
ＩＸカーネル固有の部分ではない。

【００２９】Ｘウインドゥは、ＵＮＩＸカーネル上に構
築されたグラフィックデバイス・ドライバ機能を含むＧ
ＵＩとしてユーザにマルチウインドゥのプログラミング
環境を提供するソフトウェアシステムであるが、そのシ
ステム構成の概要を図４に示す。Ｘウインドゥシステム
は１つのスクリーン上にマルチウインドゥを生成するＧ
ＵＩであり、サーバ／クライアント・モデルによって説
明される。サーバプログラムは、Ｘウインドゥの核心
（ベースウインドゥシステム）であり通常スクリーン、
キーボード及びマウスからなるワークステーション（端
末）と相互作用してウインドゥを生成しこれをスクリー
ン上に表示したり、ウインドゥ上に図形を描画したり又
はキーボード又はマウスからのハードウェアＨ／Ｗイベ
ントを検知して処理する役目を行う。クライアントプロ
グラムはユーザプログラム、Ｘライブラリ及びウインド
ゥマネージャーを意味する。即ち、クライアントである
ユーザプロセスはサーバにグラフィック処理を依頼する
ことができる。このときクライアントはグラフィックデ
バイスのハード的属性を考慮することなくマルチウイン
ドゥ機能を記述できる。ハード的属性はサーバが吸収し
ている。クライアントとサーバの交信はＸプロトコルに
よって行われる。ＯＳやハードウェアなどのベンダに依
存した操作はサーバがその処理を担当しているので、ク
ライアントは一般に相手システムがＸプロトコルを理解
すればＯＳやハードウェアに依存せずにプログラムを書
くことができる。そしてホスト１にあるクライアント
が、ホスト０のサーバとネットワーク上でＸプロトコル
によって交信しそのサーバを介してホスト０にあるワー
クステーションを制御することができる。即ち、Ｘウイ
ンドゥシステムはネットワーク透過性である。ここでホ
スト１（ローカル）のクライアントプロセスに対しホス
ト０（リモート）のサーバプロセスがエージェントとな
っている。クライアントがホスト０にある場合はネット
ワークを介さずサーバと交信する。尚、アプリケーショ
ンは直接Ｘプロトコルをハンドリングするのでなく、ラ
イブラリ関数Xlibをコールし、コールされたXlib関数が
Ｘプロトコルを発行している。そしてホスト０のサーバ
はホスト０とホスト１にある２個の複数のプロセスに対
しマルチタスク的にサービスを提供することができる。

【００３０】図５はＸウインドゥシステムのモジュール
構成を示すものである。以下はXlibを用いてスクリーン
上に500×300のウインドゥｗを表示するクライアントの
ユーザアプリケーション・プログラム例である。

【００３１】 #include <XII/Xlib.h> #include <XII/Xutil.h> main() { Display *d; Window w; Unsigned long black, white; d = XOpenDisplay(NULL) w = XCreateSimpleWindow(d, RootWindow(d,0), 100, 100, 500, 300, 2, BlackPixel (d, 0), White- Pixel (d, 0)); XMapWindow(d, w); }

【００３２】XOpenDisplay()はこのプログラムに係わる
ユーザプロセスとネットワークシステム内の指定したサ
ーバとの接続を確立し、XCreateSimpleWindow() はその
サーバの制御するスクリーンに500×300のウインドゥｗ
を生成し、XMapWindow()は生成ウインドゥｗをスクリー
ン上に表示するＸプロトコルを発生してそれをＸサーバ
に与えるXlib関数である。

【００３３】サーバ構造サーバはクライアントとの接続を確保し、複数のクライ
アントからの要求をバランスよく処理し、ディスプレ
イ、マウス、キーボードなど、ハードウェアからのイベ
ントを複数のクライアントに分配するのが主な仕事であ
る。図７に示すようにサーバは、DIX(Device Independe
nt X)、DDX(Device Dependent X)、OS、拡張機能(EXT:
Extension)の４つのレイヤ（層）からなる。本発明の説
明にあってこれらレイヤの理解が重要である。

【００３４】DIX 層：サーバの全ての動作はDIX から
ほかのレイヤの関数を呼び出すことで行われ、その呼び
出された関数によってクライアントからの要求の処理、
入力イベントの読み取りとクライアントへの配分がなさ
れる。DIX はマシン、デバイス、OSに依存しない部分で
あり、Ｘプロトコルによってクライアントと交信を行
う。DIX 層にイベント処理をスケジューリングするルー
チンDispatch()が属する。

【００３５】DDX 層：入出力デバイスを直接制御する
関数を集めた部分であり、デバイスとOSに依存して記述
される。ハードウェアからのイベントの読み取り、マウ
ス移動感度の調整、キーコードのマッピング情報作成な
どの入力デバイス制御を行う入力部分と、描画要求の実
行、GC（Graphic Context ）の作成／変更などを行う出
力部分の両者からなる。それらの関数はデバイス毎にデ
ータ構造体を伴ってDIX からコールされる。

【００３６】OS層：クライアントとの接続、ネットワ
ーク接続およびその通信のための読み書き機能、入力イ
ベントが発生したことを通知する機能（これはDDX との
共同作業の場合もある）、クライアントへのタイムシェ
アリングサービスを円滑に行うための機能、フォントフ
ァイルとのインターフェース・アクセス機能、低レベル
メモリ管理機能を行う。

【００３７】EXT 層：サーバの機能、Ｘプロトコルを
拡張するためのレイヤである。普通のサーバには必要が
なく、特殊機能を持ったディスプレイなどでその機能を
生かすものである。

【００３８】即ち、Ｘウインドゥシステムはネットワー
ク透過性マルチウインドゥ環境をユーザに提供するＵＮ
ＩＸカーネル上に構築されたオペレーティングシステム
と言える。ユーザはＵＮＩＸ固有の前述の機能と共にＸ
プロトコルによりマルチウインドゥ機能にアクセスする
ことができる。本発明の実施例に係わる図１でＸウイン
ドゥシステムはホストコンピュータにおけるもので、そ
してＦＬＣＤグラフィックデバイスのハード的属性はそ
の DDX層及びOS層内に記述される。

【００３９】クライアントユーザプログラムがサーバに
対しマウスのクリック点に文字Ｘを描くプログラムを例
示してシステム動作の理解の助けとする。

【００４０】

【００４１】プログラムはXSelectInputt() のセットに
よりマウスクリックイベントがあったときそれを報告し
てくれるようにサーバに依頼しておく。Ｈ／Ｗイベント
をXNextEvent()で読み込みそのクリック時のマウス位置
座標情報をXButtonEvent構造体ｅのｘ、ｙメンバに記述
する。 XDrawString()はサーバに対しｘ、ｙメンバで指
定するウインドゥスクリーン位置に文字ｘを描くことを
指示する。サーバはクライアントに対しＨ／Ｗイベント
の検出と報告をしそしてクライアントがそのＨ／Ｗイベ
ントに基づいて作成した描画命令を受けてグラフィック
デバイスを制御して描画を行う。即ちクライアントユー
ザプログラムはハードウェアデバイスに依存せず記述さ
れ、サーバがハードウェアデバイスに対しインターフェ
イスをとってサービスをクライアントに提供している。

【００４２】スケジューリングサーバは、１つのワークステーション（端末：スクリー
ン、キーボード、マウス）を制御するのに対応づけられ
た単一のプロセスであるが複数のプロセス即ち複数のク
ライアントへサービスを提供している。尚、ここでプロ
セスとはプログラムが実行される環境である。１つのプ
ロセスは、命令セグメント、ユーザデータ・セグメン
ト、システムデータ・セグメントの３つのセグメントか
ら構成される。プログラムは命令とユーザデータを初期
化するために使用される。１つのプログラムが時間的に
並行した複数のプロセスで実行され得る。マルチタスク
・システムは複数のプロセスをタイムシェアリングで並
行して実行する。この複数のプロセスに対するタイムシ
ェアリング自体はＵＮＩＸカーネルが担当している。一
方サーバにおけるスケジューリングとは発生した描画要
求、Ｈ／Ｗイベント処理などのサービス要求の処理順序
を規定するものである。図１０に複数のクライアントへ
のサービスを処理するための本発明の実施例におけるキ
ュー（待ち行列）システムを示す。クライアントで作成
された描画命令はそのクライアント毎のクライアントキ
ュー101−103に作成順で登録される。

【００４３】登録された命令はサーバのキュー105 にエ
ントリーポイント104 から転送される。即ち、複数クラ
イアントからの命令は単一の１つの系列へと制御されサ
ーバキュー105 に入れられシングルタス的に順次処理さ
れることになる。ホストプロセッサ・サイドのサーバキ
ュー105 内の命令はあるまとまった単位でグラフィック
デバイスのプロセッササイドのグラフィックコマンド・
バッファ106 に渡される。ホストプロセッサは命令群を
グラフィックデバイスのプロセッササイドへ渡すと、そ
の命令群の処理はグラフィックデバイス・プロセッサに
委ね自分は他の処理に移行する。グラフィックコマンド
・バッファ 106において渡された命令群はグラフィック
デバイス・プロセッサ用のコマンドに展開され図１０の
TailからHead−1 の間に納まる。グラフィックデバイス
・プロセッサはTailから順次Headへとコマンドを実行す
る。実行につれてTailはHeadに近づいていきTail＝Head
になったとき渡された命令群の実行が完了したことを意
味する。そうすると次の命令群がサーバキュー105 から
グラフィックコマンドバッファ106 へと渡される。この
次の命令群は以前のHeadよりも先のアドレスへ納められ
る。即ち、次の命令群を展開したコマンドのTailは以前
のHeadとなる。グラフィックコマンド・バッファ106 は
模式的にリング状のものとして説明される。図１０の
(a)ではHead＞Tailであるが(d)ではTail＜Head となっ
ていることに注意されたい。

【００４４】図８Ａ及び図８Ｂに示すようにマウスイベ
ントのようなＨ／Ｗイベントに係わる描画がリアルタイ
ムで実行できなくなるのは、グラフィックデバイス以降
の処理速度が描画命令発生の速さに対し十分でなくその
イベント発生時にサーバキュー105 に未処理命令が多く
残っているからである。サーバシステムはＨ／Ｗイベン
ト自体は優先して処理しクライアントへ報告するにして
も、そのときのＨ／Ｗイベントに係わるクライアントで
生成された描画命令の実行はサーバキュー105に残って
いる命令が済んでからなされる。何故ならサーバキュー
105 内の処理はシングルタスク的に単に順次実行される
ものであるからである。

【００４５】サーバがサービスすべき事象は複数のクラ
イアントプロセスから又ハードウェアデバイスから非同
期的に発生するがその処理のスケジューリングを行いそ
の後の処理の流れを制御するのが、サーバの DIXレイヤ
にあるルーチンDispatch()である。即ち、発生した事象
はDIX レイヤのDisptach()ルーチンでスケジューリング
され、その事象に係わる命令がDIX レイヤから呼ばれた
ルーチンによってサーバの制御するグラフィックデバイ
スで実行されるためにクライアントキューからサーバキ
ューへと転送される。Dispatch()ルーチンはクライアン
トからの描画要求とＨ／Ｗイベント発生が競合したとき
Ｈ／Ｗイベントの処理を優先的にスケジューリングして
そのリアルタイム化を図っている。

【００４６】図６にDispatch()ルーチンによるスケジュ
ーリングのフローを示す。ステップ１：Ｈ／Ｗイベント（キーボード、マウス操
作）があったかのチェック。これはイベントキュー内の
先頭と末尾ポインタを参照して２つのポインタが異なる
ときはイベントキュー内から登録イベントを読み出す。ステップ２：Ｈ／Ｗイベントチェックが Yesの時、そ
のイベントに係わる文字表示やマウスカーソル表示に伴
う処理を行う。このときサーバ／クライアント間のデー
タ送受信はOS層の WriteToClient()関数が呼ばれそれが
行う。処理は、Ｈ／Ｗイベントに応答してＨ／Ｗイベン
トのクライアントへの報告、クライアントで生成された
イベントに係わる描画命令がサーバキューへと登録され
ることで終了し、フローはステップ１に戻る。ステップ３：Ｈ／ＷイベントチェックでNoの場合、OS
層のWaitForSomething()が呼ばれる。WaitForSomething
()の詳細は図１２に示されているが、その名のとうり事
象を待ちモニターする関数である。待ち事象には以下の
ものがある。 *ハードウェア、ユーザからのイベント *サーバへ既に接続されているクライアントからの要求
（描画命令） *接続されていないクライアントを指定サーバへの接続
要求これらの事象が発生したら、イベントタイプ等の必要な
情報を設定してDIX層のDispatch()に返す。ステップ４：発生事象が接続クライアントからの要求
であるとOSレイヤのReadRequestClient()を呼びクライ
アントキュー内の例えば描画命令を読みサーバキューへ
と登録し、ステップ１に戻る。ステップ５：発生事象がサーバへのクライアントへの
接続要求であるとOS層のWriteToClient()を介して接続
確立のデータをクライアントへ書き込み、ステップ１に
戻る。

【００４７】DIX層のDispatch()はサーバへのサービス
要求のスケジューリングを行う関数であり、サービスタ
イプに応じ必要なルーチンプロセスを分岐するものであ
り、分岐プロセス先で実際の描画処理などは行われる。
このスケジューリングは先ずＨ／Ｗイベントを優先的に
処理する、即ちイベントキュー内に登録イベントがある
時、優先的にそれを処理することでリアルタイム化を図
っている。

【００４８】しかし前述したように、イベントキュー内
の登録イベントを優先的に処理するDispatch()スケジュ
ーリングだけでは、あるクライアントにおける２つのＨ
／Ｗイベント発生の間に他のクライアントによる未処理
描画要求がサーバキューに残る場合がありそれを先ずグ
ラフィックデバイス側は処理しないといけないからＨ／
Ｗイベントのリアルタイム化に支障が生ずるおそれがあ
った。これは命令を生成するホスト側サーバと命令を処
理するグラフィックデバイス側とは非同期的に動作して
いることに起因している。本発明はこの２つの非同期的
動作において、サーバ側がグラフィックデバイス側の処
理状態をWaitFor-Something() 内でモニターし、そのモ
ニターに基づいてイベント処理スケジューリングを制御
し上述の問題の改善を図るものである。

【００４９】WaitForSomething() WaitForSomething()ルーチンの詳細の説明の前に、図１
５Ａを参照してグラフィックコマンド・バッファ106 の
Head、Tail及び未使用隣接空間の概念について説明す
る。図１５Ａはグラフィックコマンド・バッファ内に展
開されたコマンドデータの種々の構造を示す。サーバキ
ュー105 から転送されてきたデータはTailアドレスから
Headアドレスへ順次書き込まれ、グラフィックデバイス
・プロセッサによりTailアドレスからHeadアドレスへと
実行される。Headアドレスは、データがグラフィックコ
マンド・バッファ106 に書き込まれる毎に更新され、Ta
ilアドレスは、グラフィックデバイス・プロセッサでデ
ータが実行されるにつれて更新される。図１５Ａの(a)
と(c) はHeadアドレスがTailアドレスより大きい場合を
示し、(b) と(d) はHeadアドレスがTailアドレスに等し
いとき、そして(e) はTailアドレスがHeadアドレスより
大きい場合である。図１５Ｂは、後述の本発明に従うQS
pace()ルーチンを採用した場合のHeadアドレス、Tailア
ドレス及び未使用隣接空間の大きさの実際の例を示す。

【００５０】図１２Ａに示すDIX レイヤーにあるWaitFo
rSome-thing() ルーチンは、本発明に従い先ず関数XQSp
ace() を呼ぶ。尚、関数XQSpace() は図１１に示す関数
QSpace()のＸウインドゥ領域に変換したものである。QS
pace()はグラフィックコマンド・バッファ106 をモニタ
ーして、Tail、Headアドレスを入取し、未使用隣接空間
を計算するものである。グラフィックデバイス内のバッ
ファの状態をモニターするためＯＳに対しデバイスアク
セス許可を求めるチャネルオープンを行い、モニター後
に速やかにクローズする。計算前後でオープン／クロー
ズしているのは、マルチタスクの効率を極力維持するた
めである。このようなデバイスが使用許可されるとこの
デバイスが使用する物理的メモリ空間を他のプログラム
にＯＳが割り当てないようにロックする。このことは事
実上、マルチタスクの仮想記憶システムが１つのプロセ
スに占有された状態になるのでシングル・タスクのシス
テムと同様になってしまう。このため仮にこの'LOCK'状
態がデバイスの処理能力のモニター結果に依存するので
あれば、グラフィックプロセッサ側がビジーであっても
新たな要求の処理は中断状態におかれ、ロック解除まで
続く。これにより実質的に、QSpace()がグラフィックプ
ロセッサ側とＯＳ側とで処理能力に応じた同期を取って
いることになる。このロック状態はＵＮＩＸのようなシ
ステムでは極力避けなければならない状態であるので、
当然本来のマルチタスクの状態にできるだけ速やかに戻
す必要がある。QSpace()が呼ばれ、いよいよ計算に入る
という直前にオープンし、メモリをロックし、処理後直
ちにメモリを解放するためにクローズしている。

【００５１】QSpace()において、チャネルオープンがな
されるとグラフィックコマンド・バッファのHeadとTail
アドレスを入取する。もしHead＞Tailならば未使用隣接
空間はキューサイズ(CMDBUFSIZE)−Headとして計算し、
Head＜Tailならば未使用隣接空間はTail−Headとして計
算される。QSpace()で入取・計算されたデータはWaitFo
rSomething()にリターンされる。

【００５２】図１２ＡのステップS2で、Head≠Tail（即
ち、未処理コマンドがグラフィックコマンド・バッファ
内に存在）且つ未使用隣接空間が所定値PART_QUEより小
さい（即ち、次に来るであろうサーバキューからの命令
群を引き続き格納する空き領域がグラフィックコマンド
・バッファに十分ない）かをチェックする。Yes である
ときは次の命令群を受付処理するに準備されていない場
合であってステップS3において再びQSpace()を呼びグラ
フィックコマンド・キューにアクセスしてTailとHeadア
ドレスを入取する。前回のQSpace()のときからコマンド
実行処理が進んだ結果未処理コマンドがなくなっていれ
ば、ステップS4でのチェックによりHead＝Tailとなって
いるのでステップS5に進むが、まだ未処理コマンドがあ
ってHead＝TailチェックがNoであるとループして再びス
テップS3に戻りHead＝Tailになって未処理コマンドがな
くなる迄ループしている。もし、ステップS2のチェック
でステップS1でのQSpace()で得られたデータにおいてHe
ad＝TailまたはHead≠Ｔａｉｌであっても次に来る命令
群を受け付けるに十分な未使用隣接空間があると（Ｎ
ｏ）直ちにステップS5に進む。

【００５３】ステップS5はサービス要求事象（Ｈ／Ｗイ
ベント、接続クライアントからの描画要求、非接続クラ
イアントのサーバへの接続要求）の発生をＨ／Ｗイベン
トキュー及びクライアントキューにおいてモニターし
（尚、実際はサーバ内のフラグをみる）、キュー内に登
録があればそのイベントタイプを含む情報をDIX レイヤ
にあるDispatch()に渡し図６のフローにおけるステップ
４に進む。

【００５４】即ち、本発明に従うWaitForSomething()で
は、ステップS1〜S4においてグラフィックデバイス・プ
ロセッサが次の描画処理を実行できる状態になる迄はス
テップ５におけるサービス要求事象のモニターを開始さ
せないようにしている。従って、クライアントからの描
画要求があっても、その処理を直ちに行いサーバキュー
へ描画命令を登録するスケジューリングではなくグラフ
ィックデバイスによる描画処理の進行状態に応じてこれ
を保留する。Ｈ／Ｗイベント優先スケジューリングで
は、Ｈ／ＷイベントがＨ／Ｗイベントキューに登録され
ているとそれをクライアントからの描画要求に優先して
処理するというだけであり、Ｈ／Ｗイベントキューに登
録がないとグラフィックプロセッサによる描画処理進行
状態と無関係にクライアント要求が順次処理されるよう
サーバキューに登録されてしまう。本発明はＨ／Ｗイベ
ントキューに登録がなくＨ／Ｗイベントの優先処理が必
要でない間でもクライアントからの描画要求の発生時直
ちに処理するのでなくグラフィックデバイスのプロセッ
サの実行の進行状態をモニターしてそれに応じて処理を
する事にその特徴あるものである。これによって、サー
バキューにはＨ／Ｗイベントのリアルタイム処理を遅ら
せるような多くの命令が登録されることがないので、Ｈ
／Ｗイベントによるリアルタイム処理が改善される。図
１２ＢはWaitForSomething()の別な実施例である。ステ
ップS1でQSpace()によりグラフィックコマンド・バッフ
ァのHeadとTailアドレスを入取し、ステップS2でHead≠
Tailチェックを行いHead＝Tailなら直ちにステップS5で
サービス要求の処理を行い、Head≠TailならHead＝Tail
になる迄ループにより待ってからステップS5に入るフロ
ーである。

【００５５】図１４は、本発明に係わるスケジューリン
グの層構造の概念を示す図である。DispatchはDIX レイ
ヤにあってサーバの外殻をなしクライアント及びＨ／Ｗ
デバイスと直接交信してＨ／Ｗデバイス及びＯＳに依存
しない形態でのスケジューリングの基本フローを行う。
WaitForSomething()はＯＳレイヤにあってDispatch()か
らコールされＯＳに依存した形態でのサービス要求の処
理を行う。QSpace()は最内にあってWaitForSomething()
からコールされグラフィックデバイスを直接アクセスし
てそのモニターを行う。

【００５６】サーバキューからグラフィックコマンドキ
ューへの命令データ転送サーバキュー105 内の命令データはサーバ側（ホスト
側）のHostDispatcherで基本グラフィック関数に展開さ
れてからBeginCommand()関数によってグラフィックデバ
イス側（リモート側）のグラフィックコマンド・バッフ
ァ106 へ転送される。グラフィックコマンド・バッファ
106 内の展開された命令はリモート側のGetCommand()関
数によって読出され、Remote DispatcherでHost Dispat
cherに対応したグラフィック・プロセッサ関数に展開さ
れてVRAMに対し所定の描画処理が実行される。

【００５７】図１６Ａ〜図１６Ｃはホスト側のBeginCom
mand()、図１７Ａ〜図１７Ｃはリモート側のGetCommand
()の概要を表しており、グラフィックコマンド・バッフ
ァ106 に対する通信・管理の様子を中心に示してある。
図１６での変数Ｘ、Ｙや図１７での変数Ｚ、Ｗは任意の
変数を表し、Head、Tailはグラフィックコマンド・バッ
ファ106 の命令データ格納場所の先頭、末尾を表す。ま
たBeginCommand()自体はホスト側サーバキュー105 から
送られるグラフィック命令の転送フローにあたり、GetC
ommand()はリモート側の受信フロー及び命令実行フロー
にあたる。この送・受信間では命令の転送・受信開始及
び終了時に互いに同期を取っている。これはリモート側
がシングルプロセッサであるということと、ディスプレ
イに対しては一度に複数の独立した走査（リフレッシ
ュ）が出来ないことによる。ホスト側サーバキュー105
から送られるグラフィック命令がHost Dispatcher であ
るまとまった単位の基本グラフィック関数群をPutWords
()関数に渡す。PutBlock()関数の詳細は図１６Ｂと図１
６Ｃに示されている。

【００５８】PutBlock()では現時点のコマンドバッファ
106 のHead、Tail値を読みだし、変数Ｘ、Ｙに格納し未
使用隣接空間も計算する。グラフィックコマンド・バッ
ファ106 における特殊処理を施した後、グラフィックコ
マンド・バッファ106 へデータを転送する。そして転送
終了タイミングを見るために、WaitCommand() 関数でリ
モート側からの受信終了確認を待つ。この後、グラフィ
ックコマンド・バッファ106 の新しいHead位置をセット
し、次のデータ転送を待つ。全てのデータを転送し終わ
るとPutBlock()は終了し、PutWords()とBeginCommand()
が終了する。

【００５９】一方、リモート側のGetCommand()では図１
７Ａで示されるように命令の種類によって（monolithic
command（引数を伴わない単一・単純命令）またはchun
kedcommand （複数の引数を伴った命令））、データ領
域のバッファの確保の処理は異なるが、いずれも図１７
Ｃに示すGetBlock()によってホスト側からの命令データ
をコマンドバッファ106 に格納（受信）する。そのの
ち、図１７Ｂに示されるようにコマンドキュー106 から
Head、Tail値を用いて命令データの読みだし及び実行を
行う。図１７ＣにGetBlock()内部動作を示す。初めにHe
adとTailの値が異なるかどうかを確認する。これはリモ
ート側の命令実行の全てが終了後はHead＝Tailとなり、
それに応答してホスト側が新たな命令を転送すると図１
６Ｃで示されたようにHead値を更新し、Head≠Tailとな
っているからである。もう１つの理由はホスト側とリモ
ート側はデータ通信時以外独立・非同期動作のため、デ
ータ受信時のホスト側の状態を確認する必要があるから
である。

【００６０】次に得られたHead、Tailの値からデータサ
イズを算出し、ラップ処理を行いホスト側からデータを
受信し、Tailを更新し、その旨をホスト側へ知らせる。
ちなみにこの情報はホスト側が命令データをリモート側
へ送ろうとする際のリモート側のビジー(BUSY)情報の判
別として扱われ、リモートからの返答を以てアイドル(I
DLE)状態であると判別し、転送を開始するのに用いられ
る。以上のことから、'Head'はホスト側BeginCommandに
よって更新され、'Tail'はリモート側GetCommandによっ
て更新され、ホストとリモート側は互いに基本的には非
同期実行処理を行い、データ通信時に同期を取るように
なっている。

【００６１】図９Ａと図９Ｂは本発明の実施例に従う表
示状態を例示するものである。図９Ａは図８Ａと類似す
るスクリーン上の３つのウインドゥを示す。図９Ｂの左
側はホスト側において発生されたグラフィックコマンド
系列であり、その右側は発生コマンドの実行系列であ
る。マウスカーソルフォントを描くコマンドは発生順序
でなく実行されることに注意されたい。斜線部のコマン
ドは２番目のマウスカーソルフォント描画命令が発生す
る前にクライアントキューに既に存在しているものであ
るが、本発明に従うQSpace()を含むWaitForSomething()
ルーチンによるスケジューリングではその事象のスケジ
ューリング処理がされず２番目のマウスイベント発生前
にはサーバキューへは送られなかったものである。マウ
スイベントはＨ／Ｗイベントとして優先処理されるから
クライアントキューに登録されている他のクライアント
からの要求に先んじてスケジューリングされその描画命
令はサーバキューへと送られ実行されるのである。

【００６２】他の実施例尚、これ迄説明した本実施例ではＨ／Ｗイベント中心に
処理するようサーバキューへのクライアント・スケジュ
ールをした例を示したが、QSpace()を用いて他の方法で
もクライアント・スケジューリングを行うことができ
る。例えば図６中のReadRequestFromClient() 関数の処
理の前後でQSpace()によるリモート側の実行状態をバッ
ファを通してモニターすることで図４のステップ２の処
理の流れに変更を加えることは可能である。図１８にRe
adRequestFromClient() 関数でQSpace()をコールする具
体例を示す。本来この関数は単にあるクライアントから
の要求を受取り、要求内容を読んでそれをリターンする
ものである。そしてリターンされた要求内容に従い図６
のステップ４で処理をしグラフィックデバイス側のコマ
ンドバッファ106 に描画コマンドを格納する。図１８の
ReadRequestFromClient() 関数においては、先ずQSpace
()がコールされグラフィック側のコマンドバッファ106
のコマンド処理状態即ちバッファの空き状態をモニター
し、十分空きがあるときは直ちにクライアントの要求を
読みそれをリターンするが、空きが十分でないときはク
ライアントからの要求を読まずにリターンし、そして次
に再びReadRequestFromClient() が図６で起動されその
時にコマンドバッファ106 が空きならばそこでクライア
ントからの要求が読まれその読まれた内容がリターンさ
れて処理され、描画コマンドがコマンドバッファ106 に
格納される。即ち、グラフィックデバイスの処理が遅い
ときクライアントからの要求をスキップする。これによ
りグラフィックデバイス側の処理速度に同期してクライ
アント要求処理も行われるので、要求に伴う描画コマン
ドが一方的にコマンドバッファ106 にたまることがな
い。さらに同様のことを他のステップにおいても行うこ
とは可能であり、どのステップでQSpace()をコールし、
何の処理を行うかはそのシステムに合った処理を加えれ
ばよい。このような関数でのQSpace()のコールはそれ単
独で用いることもできるが先に説明したWaitForSomethi
ng()でのQSpace()のコールとの組み合わせでも用いるこ
とができ、その場合より適切な描画処理の形態が提供さ
れ得る。

【００６３】また本発明はリモート側のグラフィックコ
マンド・バッファ106 の構成や管理方法に限定されるも
のではなく、グラフィック側の実行状態がモニターでき
る情報が得られる構成であればよい。例えば別の例とし
て、本発明の固定サイズ・バッファとは異なった任意長
のバッファサイズを各命令毎に確保でき、HeadやTailの
管理ではなく命令毎にナンバーを割り振り、このナンバ
ーを各命令の実行状態に応じて管理する方法を示す。図
１９命令の格納先を指し示すポインターを４つ持つバッ
ファを表す。各ポインターroom #1 - #4はある時点で３
つのそれぞれ異なる命令(opcode)とその実行に必要なデ
ータが格納され、 room #1から#3にそれぞれその格納場
所とサイズが収納される。そして実行が進み、現在 roo
m #1の命令が既に実行済みとなった状態となっていて、
room #2 が実行中であるとする。このときのQSpace()で
はこのナンバー数# とサイズをモニターすることにな
り、図２０のようになる。そしてこのQSpace関数（X 用
にはQSpace()）を使ったWaitForSomething()関数は図２
１となる。冒頭のQSpace()関数によるループからのEXIT
条件はHead、Tail値から先のナンバー数とサイズの大小
関係におき代わる。しかし、基本的なアルゴリズムと効
果は先の実施例となんら変わってはいない。

【図面の簡単な説明】

【図１】本発明の実施例の適用されるハードウェア構成
のブロック図である。

【図２】図１のグラフィックコントローラの詳細を示す
ブロック図である。

【図３】図１のグラフィックカードの詳細を示すブロッ
ク図である。

【図４】本発明の実施例の動作する環境であるＸウイン
ドゥシステム構成を示す図である。

【図５】Ｘウインドゥシステムのモジュール構成を示す
図である。

【図６】イベント処理スケジューリングのフローを示す
図である。

【図７】Ｘウインドゥのマルチウインドゥでの描画を示
す図である。

【図８Ａ】Ｘウインドゥのマルチウインドゥでの描画を
示す図である。

【図８Ｂ】図８Ａのマルチウインドゥ描画の従来技術で
の描画コマンドの発生の時間系列とそのコマンドの実行
の時間系列を示す図である。

【図９Ａ】Ｘウインドゥのマルチウインドゥでの描画を
示す図である。

【図９Ｂ】図９Ａのマルチウインドゥ描画の本発明の実
施例に従う描画コマンドの発生の時間系列とそのコマン
ドの実行の時間系列を示す図である。

【図１０】本発明の実施例におけるキューシステムを示
すブロック図である。

【図１１】WaitForSomething()ルーチン中のQSpace()の
フロー図である。

【図１２Ａ】WaitForSomething()ルーチンの第１の例の
フロー図である。

【図１２Ｂ】WaitForSomething()ルーチン中の第２の例
のフロー図である。

【図１３】第２図のグラフィックカードにおける信号波
形を示す図である。

【図１４】本発明に係わるスケジューリングの層構造の
概念を示す図である。

【図１５Ａ】グラフィックコマンド・バッファのHead、
Tail及び未使用隣接空間の様子を示す図である。

【図１５Ｂ】Headアドレス、Tailアドレス及び未使用隣
接空間の大きさの実施例を示す図である。

【図１６Ａ】ホスト側でのコマンドの転送フロー図であ
る。

【図１６Ｂ】図１６Ａの転送フロー中のPutBlock()の前
半部のフロー図である。

【図１６Ｃ】図１６Ａの転送フロー中のPutBlock()の後
半部のフロー図である。

【図１７Ａ】リモート側のコマンド受信と実行の右半分
のフロー図である。

【図１７Ｂ】リモート側のコマンド受信と実行の左半分
のフロー図；

【図１７Ｃ】図１７Ａのフロー中のGetBlock()のフロー
図；

【図１８】QSpace()をReadRequestFromClient()でコー
ルする例のフロー図である。

【図１９】本発明の適用し得るグラフィックコマンドバ
ッファ構成の第２の例を示す図である。

【図２０】図１９のバッファ構成を用いる際のQSpace()
のフロー図である。

【図２１】図２０のQSpace()を用いたときのWaitForSom
ething()のフロー図である。

【符号の説明】

クライアントキュー … 101 〜 103 サーバキュー … 105 グラフィックコマンド・バッファ … 106

Claims

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

【請求項１】ディスプレイ装置に対する描画要求を備
え、ハードウェアイベント入力に基づいて発生したプロ
セスを含む複数のプロセスをタイムシェアリングにおい
て処理するマルチタスク手段及び該マルチタスク手段か
ら受信した描画要求がハードウェアイベント入力に基づ
いて発生した描画要求の時、該描画要求を他の描画要求
より優先させて登録させ、該登録させた描画要求に基づ
いてグラフィックデバイスに対する描画命令を発生さ
せ、該描画命令をグラフィックデバイスへ転送するスケ
ジューリング手段を論理的に構成しているホストプロセ
ッサ、並びに該スケジューリング手段から転送された描画命令を登録
し、描画命令に基づいた描画をディスプレイ装置で実行
させる時、描画命令−実行時間を描画要求に応じて設定
し、該設定させた描画命令−実行時間内で、ディスプレ
イ装置での描画を実行させるグラフィックデバイスを有
するデータ処理装置であって、前記スケジューリング手段は、グラフィックデバイスに
転送された描画命令の実行完了状態をモニターし、該実
行完了が所定の段階まで進展するまで、前記マルチタス
ク手段からの描画要求の登録を保留することを特徴とす
るデータ処理装置。
【請求項２】請求項１に記載のデータ処理装置におい
て、該ハードウェアイベントはキーボード、マウス、ラ
イトペン、タッチスクリーンまたはトラックボールの操
作に応答して発生されるものであるデータ処理装置。
【請求項３】請求項１に記載のデータ処理装置におい
て、該スケジューリング手段は該グラフィックデバイス
の１つのスクリーン上にマルチウインドゥ機能を提供す
るものであるデータ処理装置。
【請求項４】請求項１に記載のデータ処理装置におい
て、該ディスプレイ装置は強誘電体液晶ディスプレイパ
ネルであるデータ処理装置。