JP3002302B2 - データ処理装置 - Google Patents
データ処理装置Info
- Publication number
- JP3002302B2 JP3002302B2 JP3207274A JP20727491A JP3002302B2 JP 3002302 B2 JP3002302 B2 JP 3002302B2 JP 3207274 A JP3207274 A JP 3207274A JP 20727491 A JP20727491 A JP 20727491A JP 3002302 B2 JP3002302 B2 JP 3002302B2
- Authority
- JP
- Japan
- Prior art keywords
- event
- hardware event
- data processing
- graphic
- hardware
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000012545 processing Methods 0.000 title claims abstract description 74
- 238000000034 method Methods 0.000 claims abstract description 86
- 230000008569 process Effects 0.000 claims abstract description 72
- 230000004044 response Effects 0.000 claims description 10
- 238000012546 transfer Methods 0.000 claims description 8
- 238000001514 detection method Methods 0.000 claims description 7
- 239000005262 ferroelectric liquid crystals (FLCs) Substances 0.000 claims description 3
- 239000000725 suspension Substances 0.000 claims 1
- 230000006870 function Effects 0.000 description 37
- 238000010586 diagram Methods 0.000 description 17
- 230000015654 memory Effects 0.000 description 13
- 230000007423 decrease Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 230000002123 temporal effect Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000006386 memory function Effects 0.000 description 3
- 238000009125 cardiac resynchronization therapy Methods 0.000 description 2
- 238000011960 computer-aided design Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 239000004988 Nematic liquid crystal Substances 0.000 description 1
- OAICVXFJPJFONN-UHFFFAOYSA-N Phosphorus Chemical compound [P] OAICVXFJPJFONN-UHFFFAOYSA-N 0.000 description 1
- 239000004990 Smectic liquid crystal Substances 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000005684 electric field Effects 0.000 description 1
- 238000010894 electron beam technology Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000002834 transmittance Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
- G06F9/3879—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/543—Local
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/545—Gui
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Human Computer Interaction (AREA)
- Processing Or Creating Images (AREA)
- Digital Computer Display Output (AREA)
- Programmable Controllers (AREA)
- Multi Processors (AREA)
- Liquid Crystal Display Device Control (AREA)
- Image Processing (AREA)
- Studio Circuits (AREA)
- Controls And Circuits For Display Device (AREA)
Description
【０００１】
【産業上の利用分野】本発明は、ディスプレイ装置を有
するデータ処理装置に関し、特にマウスのようなポイン
ティングデバイスと共に使用されるマルチタスクオペレ
ーション−マルチウィンドウのデータ処理装置に関する
ものである。
するデータ処理装置に関し、特にマウスのようなポイン
ティングデバイスと共に使用されるマルチタスクオペレ
ーション−マルチウィンドウのデータ処理装置に関する
ものである。
【０００２】
（背景技術）ＵＮＩＸまたはＯＳ／２（「ＵＮＩＸ」お
よび「ＯＳ／２」はそれぞれ米国ＡＴ＆Ｔベル研究所の
登録商標および米国ＩＢＭ社の商標である）のようなマ
ルチタスク・オペレーションシステムにおいては、タス
クは同時に非同期的に処理される。例えば、システムが
そのディスプレイの制御に従事している際にも同時に複
数のタスクを処理し得る。また、ネットワークを介して
相互接続されたいくつかのホストコンピュータのグルー
プにおいて、タスクは１つのホストから他のホストへと
送り実行され得る。そして、マルチウィンドウシステム
では進行中の各タスクに関する情報は単一のスクリーン
上のそれぞれのウィンドウに同時に表示される。Ｘウィ
ンドウはそのようなマルチウィンドウシステムの現在の
代表的なものの１つである（「Ｘウィンドウ」は米国マ
サチューセッツ工科大学の登録商標である）。
よび「ＯＳ／２」はそれぞれ米国ＡＴ＆Ｔベル研究所の
登録商標および米国ＩＢＭ社の商標である）のようなマ
ルチタスク・オペレーションシステムにおいては、タス
クは同時に非同期的に処理される。例えば、システムが
そのディスプレイの制御に従事している際にも同時に複
数のタスクを処理し得る。また、ネットワークを介して
相互接続されたいくつかのホストコンピュータのグルー
プにおいて、タスクは１つのホストから他のホストへと
送り実行され得る。そして、マルチウィンドウシステム
では進行中の各タスクに関する情報は単一のスクリーン
上のそれぞれのウィンドウに同時に表示される。Ｘウィ
ンドウはそのようなマルチウィンドウシステムの現在の
代表的なものの１つである（「Ｘウィンドウ」は米国マ
サチューセッツ工科大学の登録商標である）。
【０００３】コンピュータ端末ディスプレイ装置として
従来リフレッシュ走査型ＣＲＴ（陰極線管：Cathode Ra
y Tube）が一般的に用いられてきた。そして、メモリ性
を有するベクトル走査型ＣＲＴはＣＡＤ（コンピュータ
・エイデッド・デザイン）に関する大きなサイズの高細
度ディスプレイとしてしばしば用いられている。
従来リフレッシュ走査型ＣＲＴ（陰極線管：Cathode Ra
y Tube）が一般的に用いられてきた。そして、メモリ性
を有するベクトル走査型ＣＲＴはＣＡＤ（コンピュータ
・エイデッド・デザイン）に関する大きなサイズの高細
度ディスプレイとしてしばしば用いられている。
【０００４】ベクトル走査型ＣＲＴでは、あるイメージ
が一度表示されると次のスクリーンリフレッシュ（全画
面のリフレッシュ）がなされるまでメモリ機能によって
そのイメージを維持している。しかし、その動作速度が
比較的低いという理由から、移動するカーソル表示、移
動するアイコン表示、マウスのようなポインティングデ
バイスまたはエディタ表示のようなリアルタイムのマン
−マシン・インタフェース・ディスプレイとしては適当
ではなかった。
が一度表示されると次のスクリーンリフレッシュ（全画
面のリフレッシュ）がなされるまでメモリ機能によって
そのイメージを維持している。しかし、その動作速度が
比較的低いという理由から、移動するカーソル表示、移
動するアイコン表示、マウスのようなポインティングデ
バイスまたはエディタ表示のようなリアルタイムのマン
−マシン・インタフェース・ディスプレイとしては適当
ではなかった。
【０００５】一方、リフレッシュ走査型ＣＲＴはメモリ
機能を有していないから一定のフレーム周波数でのリフ
レッシュ・サイクルが必要である。このリフレッシュ・
サイクルによりフレーム周波数毎にディスプレイに新し
い画面が供給される。その周波数はフレーム当たりの走
査線数と各ラインの水平走査時間の積の逆数であり、フ
リッカ防止のためには６０Ｈｚ以上が望まれる。
機能を有していないから一定のフレーム周波数でのリフ
レッシュ・サイクルが必要である。このリフレッシュ・
サイクルによりフレーム周波数毎にディスプレイに新し
い画面が供給される。その周波数はフレーム当たりの走
査線数と各ラインの水平走査時間の積の逆数であり、フ
リッカ防止のためには６０Ｈｚ以上が望まれる。
【０００６】ノン・インタレース走査法は両方のタイプ
に共通に採用されており、画面におけるデータの移動表
示例えばアイコンの移動表示がユーザがそれを観測し追
従するのに適するようにしている。
に共通に採用されており、画面におけるデータの移動表
示例えばアイコンの移動表示がユーザがそれを観測し追
従するのに適するようにしている。
【０００７】上述のＣＲＴの両方のタイプのいずれにお
いても、例えばマルチウィンドウを適切に表示するなど
の理由で、所望の表示解像度が高くなる程ディスプレイ
装置は大型となり消費電力も大きくなる。さらに駆動回
路も高価となってくる。そのような大型の高解像度ＣＲ
Ｔは種々の不都合な面があり、そのため最近はフラット
パネル型のディスプレイが開発されるようになってき
た。
いても、例えばマルチウィンドウを適切に表示するなど
の理由で、所望の表示解像度が高くなる程ディスプレイ
装置は大型となり消費電力も大きくなる。さらに駆動回
路も高価となってくる。そのような大型の高解像度ＣＲ
Ｔは種々の不都合な面があり、そのため最近はフラット
パネル型のディスプレイが開発されるようになってき
た。
【０００８】現在、種々のフラットディスプレイ・パネ
ルがあるが、その１つはスーパツイストネマチック液晶
（ＳＴＮ）を用いた高多重駆動システムを採用するもの
である。また、その変形として白／黒ディスプレイとし
たものおよびプラズマディスプレイがある。これらの全
ては、ＣＲＴシステムの画像データ転送方式およびスク
リーンリフレッシュに６０Ｈｚまたはそれより高い周波
数によるノン・インタレース走査方式を採用している。
したがって、一つの全画面について４００〜４８０本の
走査ライン程度が得られるだけである。例えば、１００
０本以上の走査ラインを有するものなど、より大型のフ
ラットディスプレイパネルは尚実用段階にはない。この
原因はフリッカを防止するため、６０Ｈｚ以上のフレー
ム周波数でリフレッシュサイクルをしなければならない
が、そうすると１ライン当たり１０〜５０μsec 以下の
走査時間となるため良好なコントラストを得ることがで
きないからである。
ルがあるが、その１つはスーパツイストネマチック液晶
（ＳＴＮ）を用いた高多重駆動システムを採用するもの
である。また、その変形として白／黒ディスプレイとし
たものおよびプラズマディスプレイがある。これらの全
ては、ＣＲＴシステムの画像データ転送方式およびスク
リーンリフレッシュに６０Ｈｚまたはそれより高い周波
数によるノン・インタレース走査方式を採用している。
したがって、一つの全画面について４００〜４８０本の
走査ライン程度が得られるだけである。例えば、１００
０本以上の走査ラインを有するものなど、より大型のフ
ラットディスプレイパネルは尚実用段階にはない。この
原因はフリッカを防止するため、６０Ｈｚ以上のフレー
ム周波数でリフレッシュサイクルをしなければならない
が、そうすると１ライン当たり１０〜５０μsec 以下の
走査時間となるため良好なコントラストを得ることがで
きないからである。
【０００９】ＣＲＴであると、蛍光スクリーン上に形成
されたイメージは蛍光特性のためにある時間維持され
る。ＴＮ型ＬＣＤ（ツイストネマチック型液晶）では、
イメージは十分な駆動電圧の印加による光透過率の変化
を用いて形成される。いずれのタイプであっても、少な
くとも３０Ｈｚ以上の高いフレーム周波数を用いること
が必要である。
されたイメージは蛍光特性のためにある時間維持され
る。ＴＮ型ＬＣＤ（ツイストネマチック型液晶）では、
イメージは十分な駆動電圧の印加による光透過率の変化
を用いて形成される。いずれのタイプであっても、少な
くとも３０Ｈｚ以上の高いフレーム周波数を用いること
が必要である。
【００１０】例えば走査ライン数が１９２０本でライン
当たり２５６０画素、すなわち一画面で４，９１５，２
００画素数のＣＲＴディスプレイまたはＴＮ型ＬＣＤで
は、約１７．５μsec の水平走査時間となり、そして水
平ドットクロック周波数は約１４７ＭＨｚとなる。ＣＲ
Ｔの場合、１４７ＭＨｚの水平ドットクロック周波数
は、現在入手できるピクチャーチューブで用いられてい
るビームガンの最大電子ビーム変調周波数をかなり越え
たものとなる。その結果、正確なイメージ形成は達成さ
れない。ＴＮ型ＬＣＤの場合、１９２０本の走査ライン
を駆動するということは、現在可能とされる約１／４０
０の最小デューティファクタよりかなり低い１／１９２
０のデューティファクタに該当してしまう。一方、現実
的な水平走査速度での駆動が用いられると、そのフレー
ム周波数は３０Ｈｚより低くなり、フリッカが表示品質
を損なってしまう。これらの理由で、ＣＲＴやＴＮ型Ｌ
ＣＤで得られる画面の大型化と高細度化は、走査ライン
数が十分に増加できないため限られてしまっていた。
当たり２５６０画素、すなわち一画面で４，９１５，２
００画素数のＣＲＴディスプレイまたはＴＮ型ＬＣＤで
は、約１７．５μsec の水平走査時間となり、そして水
平ドットクロック周波数は約１４７ＭＨｚとなる。ＣＲ
Ｔの場合、１４７ＭＨｚの水平ドットクロック周波数
は、現在入手できるピクチャーチューブで用いられてい
るビームガンの最大電子ビーム変調周波数をかなり越え
たものとなる。その結果、正確なイメージ形成は達成さ
れない。ＴＮ型ＬＣＤの場合、１９２０本の走査ライン
を駆動するということは、現在可能とされる約１／４０
０の最小デューティファクタよりかなり低い１／１９２
０のデューティファクタに該当してしまう。一方、現実
的な水平走査速度での駆動が用いられると、そのフレー
ム周波数は３０Ｈｚより低くなり、フリッカが表示品質
を損なってしまう。これらの理由で、ＣＲＴやＴＮ型Ｌ
ＣＤで得られる画面の大型化と高細度化は、走査ライン
数が十分に増加できないため限られてしまっていた。
【００１１】最近になってクラークとラガーウォール
は、高速応答性とメモリ性（双安定性）の両方の特性を
有する強誘電体液晶装置（ＦＬＣＤ）を提案した（米国
特許第４，３６７，９２４号）。ＦＬＣＤは、個有温度
でスメチックＣ相（ＳｍＣ* ）またはＨ相（ＳｍＨ* ）
を示し、光学的な双方安定状態を有する。またＦＬＣＤ
は、印加電界に応じて高速な状態変化を示し、高速メモ
リ性ディスプレイ装置として広く用いられることが期待
されている。
は、高速応答性とメモリ性（双安定性）の両方の特性を
有する強誘電体液晶装置（ＦＬＣＤ）を提案した（米国
特許第４，３６７，９２４号）。ＦＬＣＤは、個有温度
でスメチックＣ相（ＳｍＣ* ）またはＨ相（ＳｍＨ* ）
を示し、光学的な双方安定状態を有する。またＦＬＣＤ
は、印加電界に応じて高速な状態変化を示し、高速メモ
リ性ディスプレイ装置として広く用いられることが期待
されている。
【００１２】ＦＬＣＤは、上述したフラットパネルディ
スプレイ装置を著しく凌ぐ大型高細度ディスプレイ装置
に可能性を与えている。比較的低いフレーム周波数での
駆動が必要であるから、適切なマン−マシーン・インタ
フェース・ディスプレイとするため、そのメモリ機能を
利用し部分書き換え走査を採用している。部分書き込み
走査とは、スクリーン上の書き換えられるべき領域のみ
が走査されそこに新しい描画を行なうというものであ
る。そのような部分書き換え走査は米国特許第４，６５
５，５６１号に開示されている。ＦＬＣＤの双安定性機
能を用いたディスプレイとして（走査線数１９２０）×
（ライン当たりの画素数２５６０）のフラットパネルが
実現されている。
スプレイ装置を著しく凌ぐ大型高細度ディスプレイ装置
に可能性を与えている。比較的低いフレーム周波数での
駆動が必要であるから、適切なマン−マシーン・インタ
フェース・ディスプレイとするため、そのメモリ機能を
利用し部分書き換え走査を採用している。部分書き込み
走査とは、スクリーン上の書き換えられるべき領域のみ
が走査されそこに新しい描画を行なうというものであ
る。そのような部分書き換え走査は米国特許第４，６５
５，５６１号に開示されている。ＦＬＣＤの双安定性機
能を用いたディスプレイとして（走査線数１９２０）×
（ライン当たりの画素数２５６０）のフラットパネルが
実現されている。
【００１３】ＦＬＣＤのライン走査方式では、フレーム
リフレッシュ周波数は走査線が増加するほど低くなる。
例えば、５０μsec ／ラインの速度のＦＬＣＤに関する
フレーム周波数は、 1920 （ライン）×50（μsec/ライン）=96(msec)=10(Hz) である。
リフレッシュ周波数は走査線が増加するほど低くなる。
例えば、５０μsec ／ラインの速度のＦＬＣＤに関する
フレーム周波数は、 1920 （ライン）×50（μsec/ライン）=96(msec)=10(Hz) である。
【００１４】一方、コンピュータの操作性上ポインティ
ングデバイスの動きおよびキーボード入力のリアルタイ
ム応答性と滑らかさは重要な要素である。ポインティン
グデバイス指標（例えば、マウスフォント）とか文字は
スクリーン上の画面に対し比較的小さいものであるが、
それを表示するのに高速応答性が要求される。例えば、
マウスフォントは６０Ｈｚで、そして文字は３０Ｈｚの
速さで通常扱われなければならない。それ故、１０Ｈｚ
のフレーム周波数ではそのような動作に関し十分ではな
い。
ングデバイスの動きおよびキーボード入力のリアルタイ
ム応答性と滑らかさは重要な要素である。ポインティン
グデバイス指標（例えば、マウスフォント）とか文字は
スクリーン上の画面に対し比較的小さいものであるが、
それを表示するのに高速応答性が要求される。例えば、
マウスフォントは６０Ｈｚで、そして文字は３０Ｈｚの
速さで通常扱われなければならない。それ故、１０Ｈｚ
のフレーム周波数ではそのような動作に関し十分ではな
い。
【００１５】前述の「部分書き換え走査技術」は、新し
い描画をディスプレイの必要な領域についてのみ書き換
えるというもので、描画を更新するに必要な時間を大幅
に減ずることができる。もしマウスフォントが３２×３
２ビットデータとして画成されるとするなら、そのデー
タの表示速度は、 32 （ライン）×50（μsec/ライン）=1.6(msec)=625(Hz) となる。しかし、この「部分書き換え走査技術」を実際
に用いるには、「部分書き換え要求」を認識しそして書
き換えられるべき走査線数をディスプレイに指示するこ
とが必要である。さらに、その他いくつかの要因から部
分書き換えにおける現実の周波数は約３００Ｈｚ程度で
ある。この程度の周波数で部分書き換えを行えば、大型
のディスプレイにおいてマウスフォント等の表示のリア
ルタイム化に大きな改善がもたらされる。 （従来の技術）ここで、前述した部分書き換え走査技術
を用いたディスプレイ上にＵＮＩＸ環境でＸウィンドウ
のようなウィンドウシステムを動作させる場合について
考える。ウィンドウシステムにおいて、Ｘサーバはマウ
ス等のポインティングデバイス（以下、「マウス」で代
表させることとする）やキーボードを通してユーザの入
力（ハードウェアイベント）を検出し、それを適切なク
ライアント・プロセスに対してＸプロトコルにもとづい
て通知する。この際、従来のＸサーバはなるべく頻繁に
このハードウェアイベントの有無を調べて、迅速にクラ
イアント・プロセスに対して通知していた。そして、そ
の手法はサーバ内部のループ中で一定のステップにおい
て定期的に行なわれていた。これは、サーバはできるだ
けきめ細かくイベントをクライアントに通知して、その
処理はクライアントに任せるべきであるという考え方に
則った方法であり、従来ＣＲＴディスプレイ用のＸサー
バで一般的に用いられてきた方法をそのまま流用したも
のである。
い描画をディスプレイの必要な領域についてのみ書き換
えるというもので、描画を更新するに必要な時間を大幅
に減ずることができる。もしマウスフォントが３２×３
２ビットデータとして画成されるとするなら、そのデー
タの表示速度は、 32 （ライン）×50（μsec/ライン）=1.6(msec)=625(Hz) となる。しかし、この「部分書き換え走査技術」を実際
に用いるには、「部分書き換え要求」を認識しそして書
き換えられるべき走査線数をディスプレイに指示するこ
とが必要である。さらに、その他いくつかの要因から部
分書き換えにおける現実の周波数は約３００Ｈｚ程度で
ある。この程度の周波数で部分書き換えを行えば、大型
のディスプレイにおいてマウスフォント等の表示のリア
ルタイム化に大きな改善がもたらされる。 （従来の技術）ここで、前述した部分書き換え走査技術
を用いたディスプレイ上にＵＮＩＸ環境でＸウィンドウ
のようなウィンドウシステムを動作させる場合について
考える。ウィンドウシステムにおいて、Ｘサーバはマウ
ス等のポインティングデバイス（以下、「マウス」で代
表させることとする）やキーボードを通してユーザの入
力（ハードウェアイベント）を検出し、それを適切なク
ライアント・プロセスに対してＸプロトコルにもとづい
て通知する。この際、従来のＸサーバはなるべく頻繁に
このハードウェアイベントの有無を調べて、迅速にクラ
イアント・プロセスに対して通知していた。そして、そ
の手法はサーバ内部のループ中で一定のステップにおい
て定期的に行なわれていた。これは、サーバはできるだ
けきめ細かくイベントをクライアントに通知して、その
処理はクライアントに任せるべきであるという考え方に
則った方法であり、従来ＣＲＴディスプレイ用のＸサー
バで一般的に用いられてきた方法をそのまま流用したも
のである。
【００１６】
【発明が解決しようとする課題】しかしながら、従来の
ハードウェアイベント検出および通知手法では、マウス
を活用したグラフィカルユーザインタフェースにおい
て、マウス操作のレスポンス上ある問題が存在する。
ハードウェアイベント検出および通知手法では、マウス
を活用したグラフィカルユーザインタフェースにおい
て、マウス操作のレスポンス上ある問題が存在する。
【００１７】例えば、図１１はスクリーン上の、ある図
形オブジェクトをマウスのドラッギングによって移動し
ている場合を示している。このとき、いわゆる「直接操
作的な」ユーザインタフェースを採用して、マウスの移
動に合わせて常にオブジェクトの表示を新しい位置に更
新していくものとする。
形オブジェクトをマウスのドラッギングによって移動し
ている場合を示している。このとき、いわゆる「直接操
作的な」ユーザインタフェースを採用して、マウスの移
動に合わせて常にオブジェクトの表示を新しい位置に更
新していくものとする。
【００１８】図８は、その一連の動作における、ハード
ウェア（マウス）イベントの発生からディスプレイへの
描画までの時間的な処理の流れを概念的に示したもので
ある。図８において、まず発生したマウスイベントは直
ちにハードウェア（Ｈ／Ｗ）イベントキューに格納され
た後に、しかるべきクライアント・プロセスに通知され
る。イベントの通知を受けたクライアント・プロセスは
Ｈ／Ｗイベントを解析し、描画リクエストを生成する。
これを受けてウィンドウシステムのサーバは、クライア
ント・プロセスからの描画リクエストを処理し、リモー
トプロセッサ（グラフィックデバイスプロセッサ）に対
していくつかの描画コマンドを発行する。一方、リモー
トプロセッサはサーバの発行した描画コマンドを処理
し、実際にディスプレイに描画（フレームバッファへの
描画）を行なう。
ウェア（マウス）イベントの発生からディスプレイへの
描画までの時間的な処理の流れを概念的に示したもので
ある。図８において、まず発生したマウスイベントは直
ちにハードウェア（Ｈ／Ｗ）イベントキューに格納され
た後に、しかるべきクライアント・プロセスに通知され
る。イベントの通知を受けたクライアント・プロセスは
Ｈ／Ｗイベントを解析し、描画リクエストを生成する。
これを受けてウィンドウシステムのサーバは、クライア
ント・プロセスからの描画リクエストを処理し、リモー
トプロセッサ（グラフィックデバイスプロセッサ）に対
していくつかの描画コマンドを発行する。一方、リモー
トプロセッサはサーバの発行した描画コマンドを処理
し、実際にディスプレイに描画（フレームバッファへの
描画）を行なう。
【００１９】ところがここにおいて、イベントの発生か
らディスプレイへの描画に至るまでの過程のうちどこか
のステップで時間的な遅延が生じると、イベントの発生
とディスプレイへの描画の間に時間的なずれが長くなる
ことになる。例えば、最終的な描画コマンドの処理時間
が、主としてハードウェアの特性によってコマンド発行
の速さに追い付かなくなることがありうる。また、マル
チタスクの環境においては何らかの理由で、前述のプロ
セスに与えられるＣＰＵの割当時間が短くなることもあ
りうる。それらの要因により、図８に見られるようにハ
ードウェアイベントの発生時からグラフィックデバイス
プロセッサの描画処理までの間に大きな時間差が生じて
しまう。その結果、マウス操作者にとっては、リアルタ
イム性の低い使いにくいシステムになってしまう。
らディスプレイへの描画に至るまでの過程のうちどこか
のステップで時間的な遅延が生じると、イベントの発生
とディスプレイへの描画の間に時間的なずれが長くなる
ことになる。例えば、最終的な描画コマンドの処理時間
が、主としてハードウェアの特性によってコマンド発行
の速さに追い付かなくなることがありうる。また、マル
チタスクの環境においては何らかの理由で、前述のプロ
セスに与えられるＣＰＵの割当時間が短くなることもあ
りうる。それらの要因により、図８に見られるようにハ
ードウェアイベントの発生時からグラフィックデバイス
プロセッサの描画処理までの間に大きな時間差が生じて
しまう。その結果、マウス操作者にとっては、リアルタ
イム性の低い使いにくいシステムになってしまう。
【００２０】上述したような時間的なずれは、グラフィ
ックデバイスのハードウェア的な動作速度の改善のほ
か、先に述べた部分書き換え走査技術のようなソフトウ
ェアによる改善で補う必要がある。いわゆる「直接操作
的」ユーザインタフェースは、近年のグラフィカルユー
ザインタフェースの重要性の高まりと共に今後多く用い
られると予想される。したがって、上記問題を解決する
ことは必要不可欠と言える。
ックデバイスのハードウェア的な動作速度の改善のほ
か、先に述べた部分書き換え走査技術のようなソフトウ
ェアによる改善で補う必要がある。いわゆる「直接操作
的」ユーザインタフェースは、近年のグラフィカルユー
ザインタフェースの重要性の高まりと共に今後多く用い
られると予想される。したがって、上記問題を解決する
ことは必要不可欠と言える。
【００２１】コンピュータ操作にあたってマウスやキー
ボードからの入力はハードウェア（Ｈ／Ｗ）イベントと
称されるが、Ｈ／Ｗイベントのリアルタイム処理はコン
ピュータシステムにとって、できる限り保証されている
ことが必要である。なぜならば、このようなＨ／Ｗイベ
ントは操作者の操作に直接関係しており、Ｈ／Ｗイベン
トのリアルタイム性は操作性そのものを意味しているか
らである。
ボードからの入力はハードウェア（Ｈ／Ｗ）イベントと
称されるが、Ｈ／Ｗイベントのリアルタイム処理はコン
ピュータシステムにとって、できる限り保証されている
ことが必要である。なぜならば、このようなＨ／Ｗイベ
ントは操作者の操作に直接関係しており、Ｈ／Ｗイベン
トのリアルタイム性は操作性そのものを意味しているか
らである。
【００２２】本発明は、上述の従来形における問題点に
鑑み、マウスやキーボードなどからのＨ／Ｗイベントの
発生時からそのイベントに応じた描画処理までの時間を
短くし、操作者にとって使いやすいリアルタイム性の高
いデータ処理装置を提供することを目的とする。
鑑み、マウスやキーボードなどからのＨ／Ｗイベントの
発生時からそのイベントに応じた描画処理までの時間を
短くし、操作者にとって使いやすいリアルタイム性の高
いデータ処理装置を提供することを目的とする。
【００２３】
【課題を解決するための手段】上述の目的を解決するた
め、本発明に係るデータ処理装置は、複数のプロセスを
タイムシェアリングにおいて実行させるマルチタスク手
段、複数のプロセス中のしかるべきものに対してハード
ウェアイベントの発生を知らせるイベント通知手段、お
よび複数のプロセスからグラフィックデバイスへの描画
要求をスケジューリングして描画要求各々にかかわる単
一の系列を形成するスケジューリング手段を論理的に構
成しているホストプロセッサ、およびスケジューリング
手段の単一の系列から転送された所定単位の描画命令に
従ってグラフィックデバイスを制御して描画を行なうグ
ラフィックデバイス・プロセッサからなり、イベント通
知手段はグラフィックデバイスにおける所定単位の描画
命令の実行状態をモニタし、実行状態が所定の程度を越
えた場合、イベントを圧縮した後にしかるべきプロセス
に通知することを特徴とする。
め、本発明に係るデータ処理装置は、複数のプロセスを
タイムシェアリングにおいて実行させるマルチタスク手
段、複数のプロセス中のしかるべきものに対してハード
ウェアイベントの発生を知らせるイベント通知手段、お
よび複数のプロセスからグラフィックデバイスへの描画
要求をスケジューリングして描画要求各々にかかわる単
一の系列を形成するスケジューリング手段を論理的に構
成しているホストプロセッサ、およびスケジューリング
手段の単一の系列から転送された所定単位の描画命令に
従ってグラフィックデバイスを制御して描画を行なうグ
ラフィックデバイス・プロセッサからなり、イベント通
知手段はグラフィックデバイスにおける所定単位の描画
命令の実行状態をモニタし、実行状態が所定の程度を越
えた場合、イベントを圧縮した後にしかるべきプロセス
に通知することを特徴とする。
【００２４】
【作用】グラフィックデバイスにおける所定単位の描画
命令の実行状態をモニタし、実行状態が所定の程度を越
えた場合には、イベントを圧縮した後にしかるべきプロ
セスに通知するようにしているので、描画までの処理時
間が短縮される。
命令の実行状態をモニタし、実行状態が所定の程度を越
えた場合には、イベントを圧縮した後にしかるべきプロ
セスに通知するようにしているので、描画までの処理時
間が短縮される。
【００２５】
【実施例】以下、図面を用いて本発明の実施例を説明す
る。ここで説明する実施例はＦＬＣＤをディスプレイと
するコンピュータシステムである。 （ハードウェア構成）図１に、本発明の一実施例に係る
データ処理装置のハードウェア構成の概略を示す。シス
テムはホスト側プロセッサ（ＣＰＵ）１で制御されてい
る部分とグラフィックプロセッサで制御されている部分
とからなり、ホスト側とグラフィックデバイス１３とは
それぞれ独立した動作をしている。ここで、グラフィッ
クデバイス１３とは、グラフィックカード８（グラフィ
ックプロセッサ、ＶＲＡＭ等を実装している）、グラフ
ィックコントローラ９、ＦＬＣＤパネル１２を含むデバ
イス全体を意味する。
る。ここで説明する実施例はＦＬＣＤをディスプレイと
するコンピュータシステムである。 （ハードウェア構成）図１に、本発明の一実施例に係る
データ処理装置のハードウェア構成の概略を示す。シス
テムはホスト側プロセッサ（ＣＰＵ）１で制御されてい
る部分とグラフィックプロセッサで制御されている部分
とからなり、ホスト側とグラフィックデバイス１３とは
それぞれ独立した動作をしている。ここで、グラフィッ
クデバイス１３とは、グラフィックカード８（グラフィ
ックプロセッサ、ＶＲＡＭ等を実装している）、グラフ
ィックコントローラ９、ＦＬＣＤパネル１２を含むデバ
イス全体を意味する。
【００２６】ホストすなわちコンピュータ本体にはＯＳ
が実装され、プロセスをタイムシェアリング的に走行さ
せる。プロセスによって生成された描画命令は、ＡＴバ
スインタフェース７を介してグラフィックデバイス１３
内のグラフィックカード８に転送される。グラフィック
カード８は、描画命令に応じて描画内容をビデオＲＡＭ
（ＶＲＡＭ）に展開する機能と共にその描画内容によっ
てＦＬＣＤパネル１２に対して固有の部分書き換えの管
理機能を有している。グラフィックカード８は、次段の
グラフィックスコントローラ９にＶＲＡＭの内容をデジ
タル信号として渡す。グラフィックスコントローラ９
は、部分書き換え情報を有するこのＶＲＡＭ情報内容の
デジタル信号からＦＬＣＤパネル１２上の所定のアドレ
ス位置に実際にドライバＩＣ１０−１１を介して図形な
どを表示する駆動信号を形成する。
が実装され、プロセスをタイムシェアリング的に走行さ
せる。プロセスによって生成された描画命令は、ＡＴバ
スインタフェース７を介してグラフィックデバイス１３
内のグラフィックカード８に転送される。グラフィック
カード８は、描画命令に応じて描画内容をビデオＲＡＭ
（ＶＲＡＭ）に展開する機能と共にその描画内容によっ
てＦＬＣＤパネル１２に対して固有の部分書き換えの管
理機能を有している。グラフィックカード８は、次段の
グラフィックスコントローラ９にＶＲＡＭの内容をデジ
タル信号として渡す。グラフィックスコントローラ９
は、部分書き換え情報を有するこのＶＲＡＭ情報内容の
デジタル信号からＦＬＣＤパネル１２上の所定のアドレ
ス位置に実際にドライバＩＣ１０−１１を介して図形な
どを表示する駆動信号を形成する。
【００２７】図２は、図１のハードウェア上に実装され
る論理モジュールの構成を示す。図２において、Ｘサー
バ１４とＸクライアント１５は図１のＣＰＵ１、ＲＡＭ
２、ディスク３上にソフトウェアによって論理的に形成
されるモジュールである。また、入力デバイス１６はキ
ーボードデバイス４およびマウスデバイス５をまとめて
称している。これらは、入力デバイス１６からのユーザ
入力を検出しながら図１のＦＬＣＤパネル１２上にＸウ
ィンドウシステムによるマルチウィンドウ環境を実現す
るものである。
る論理モジュールの構成を示す。図２において、Ｘサー
バ１４とＸクライアント１５は図１のＣＰＵ１、ＲＡＭ
２、ディスク３上にソフトウェアによって論理的に形成
されるモジュールである。また、入力デバイス１６はキ
ーボードデバイス４およびマウスデバイス５をまとめて
称している。これらは、入力デバイス１６からのユーザ
入力を検出しながら図１のＦＬＣＤパネル１２上にＸウ
ィンドウシステムによるマルチウィンドウ環境を実現す
るものである。
【００２８】図３は、グラフィックカード８のブロック
構成を示す。グラフィックカード８は、グラフィックプ
ロセッサ２０、インタフェース２８、およびメモリ３４
のためのメモリコントローラ２２などからなる。メモリ
３４は、命令を蓄積するＲＡＭ３４−１、ビデオ出力を
蓄積するＶＲＡＭ３４−２，３４−３およびグラフィッ
クプロセッサ２０のための初期制御命令を蓄積するＲＯ
Ｍ３４−４からなる。なお、後述するグラフィックデバ
イス１３のグラフィックコマンドキューはＲＡＭ３４−
１に論理的に構成される。また、これらメモリのいくつ
かはホスト側の主メモリ上に構成されうるものである。
構成を示す。グラフィックカード８は、グラフィックプ
ロセッサ２０、インタフェース２８、およびメモリ３４
のためのメモリコントローラ２２などからなる。メモリ
３４は、命令を蓄積するＲＡＭ３４−１、ビデオ出力を
蓄積するＶＲＡＭ３４−２，３４−３およびグラフィッ
クプロセッサ２０のための初期制御命令を蓄積するＲＯ
Ｍ３４−４からなる。なお、後述するグラフィックデバ
イス１３のグラフィックコマンドキューはＲＡＭ３４−
１に論理的に構成される。また、これらメモリのいくつ
かはホスト側の主メモリ上に構成されうるものである。
【００２９】データはプロセッサ２０とメモリ３４との
間でメモリコントローラ２２を介して通信される。ビデ
オタイミングユニット３２はグラフィックプロセッサ２
０に同期信号を提供し、クロック３０がグラフィックプ
ロセッサ２０のタイミング信号として与えられる。ＶＲ
ＡＭ３４−１と３４−２の出力は出力インタフェース５
０へ入力として与えられる。
間でメモリコントローラ２２を介して通信される。ビデ
オタイミングユニット３２はグラフィックプロセッサ２
０に同期信号を提供し、クロック３０がグラフィックプ
ロセッサ２０のタイミング信号として与えられる。ＶＲ
ＡＭ３４−１と３４−２の出力は出力インタフェース５
０へ入力として与えられる。
【００３０】出力インタフェース５０において、入力さ
れたデータはマルチプレクサ３６を経て適当なグレース
ケールまたはカラー信号レベルが与えられる。さらに、
カラー／グレースケールパレット３８を通ってデジタル
インタフェース４０に入る。デジタルインタフェース４
０は、スクリーン上のアドレスデータとイメージデータ
（信号線ＰＤ０−ＰＤ７）、アドレスデータとイメージ
データを識別する信号ＡＨ／ＤＬおよびタイミング信号
ＣＬＫを作成して、次段のグラフィックコントローラ９
へ送る。
れたデータはマルチプレクサ３６を経て適当なグレース
ケールまたはカラー信号レベルが与えられる。さらに、
カラー／グレースケールパレット３８を通ってデジタル
インタフェース４０に入る。デジタルインタフェース４
０は、スクリーン上のアドレスデータとイメージデータ
（信号線ＰＤ０−ＰＤ７）、アドレスデータとイメージ
データを識別する信号ＡＨ／ＤＬおよびタイミング信号
ＣＬＫを作成して、次段のグラフィックコントローラ９
へ送る。
【００３１】グラフィックプロセッサ２０は、例えばテ
キサスインスツルメント社製のＴＭＳ３４０１０であ
り、これはグラフィック命令と一般命令の両方を実行す
ることができる。インタフェース２８はＩＢＭ「ＡＴバ
ス」である。これはパーソナルコンピュータ業界では広
く知られているものである。ＴＭＳ３４０１０の詳細は
テキサスインスツルメント社により刊行されているＴＭ
Ｓ３４０１０ユーザズガイド（刊行番号ＳＰＶＵ００
７）に記述されている。
キサスインスツルメント社製のＴＭＳ３４０１０であ
り、これはグラフィック命令と一般命令の両方を実行す
ることができる。インタフェース２８はＩＢＭ「ＡＴバ
ス」である。これはパーソナルコンピュータ業界では広
く知られているものである。ＴＭＳ３４０１０の詳細は
テキサスインスツルメント社により刊行されているＴＭ
Ｓ３４０１０ユーザズガイド（刊行番号ＳＰＶＵ００
７）に記述されている。
【００３２】図４は、グラフィックカード８からの描画
データを得てＦＬＣＤパネル１２を駆動するグラフィッ
クコントローラのブロック構成を示す。ＦＬＣＤパネル
１２は１９２０本の走査電極と２５６０本のデータ電極
からなるマトリックス構造である。走査電極は走査電極
駆動回路６２に、そしてデータ電極はデータ電極駆動回
路６４に接続されている。走査電極駆動回路６２はデコ
ーダ７８、ラインアドレスメモリ８０およびアドレス検
出回路８８を含む。データ電極駆動回路６４はシフトレ
ジスタ７２、ラインバッファ（メモリ）７４およびバッ
ファ７０を含む。
データを得てＦＬＣＤパネル１２を駆動するグラフィッ
クコントローラのブロック構成を示す。ＦＬＣＤパネル
１２は１９２０本の走査電極と２５６０本のデータ電極
からなるマトリックス構造である。走査電極は走査電極
駆動回路６２に、そしてデータ電極はデータ電極駆動回
路６４に接続されている。走査電極駆動回路６２はデコ
ーダ７８、ラインアドレスメモリ８０およびアドレス検
出回路８８を含む。データ電極駆動回路６４はシフトレ
ジスタ７２、ラインバッファ（メモリ）７４およびバッ
ファ７０を含む。
【００３３】描画位置をパネルスクリーン上に指定する
走査電極をアドレスするための走査電極アドレスデータ
（Ａ０、Ａ１、Ａ２……Ａ１５）とイメージデータ（Ｄ
０、Ｄ１、Ｄ２……Ｄ２５５９）が同一の信号線ＰＤ０
−ＰＤ７を介して送られるから、送信データがアドレス
データかイメージデータかを識別する信号ＡＨ／ＤＬが
同時にプロセッサ８９に送られる。制御回路６８はＡＨ
／ＤＬ信号がハイレベルの時にはＰＤ０−ＰＤ７上の信
号を走査電極アドレスデータであるとしてアドレス検出
回路８８に取り込ませ、ローレベルの時にはイメージデ
ータであるとしてラインバッファ７０に取り込ませる。
ＡＨ／ＤＬ信号は、またデータを転送する転送開始信号
でもある。
走査電極をアドレスするための走査電極アドレスデータ
（Ａ０、Ａ１、Ａ２……Ａ１５）とイメージデータ（Ｄ
０、Ｄ１、Ｄ２……Ｄ２５５９）が同一の信号線ＰＤ０
−ＰＤ７を介して送られるから、送信データがアドレス
データかイメージデータかを識別する信号ＡＨ／ＤＬが
同時にプロセッサ８９に送られる。制御回路６８はＡＨ
／ＤＬ信号がハイレベルの時にはＰＤ０−ＰＤ７上の信
号を走査電極アドレスデータであるとしてアドレス検出
回路８８に取り込ませ、ローレベルの時にはイメージデ
ータであるとしてラインバッファ７０に取り込ませる。
ＡＨ／ＤＬ信号は、またデータを転送する転送開始信号
でもある。
【００３４】ラインバッファに取り込まれたイメージデ
ータは一時的に蓄えられ、水平走査期間に合わせてシフ
トレジスタ７２、ラインバッファ７４を経てデータ電極
駆動装置７６に与えられる。アドレス検出回路８８で検
出されたアドレスデータは、デコーダ７８によりアドレ
スデータに従う走査電極の駆動信号とされ、ラインアド
レスメモリ８０を経て走査電極駆動装置８２に印加され
る。
ータは一時的に蓄えられ、水平走査期間に合わせてシフ
トレジスタ７２、ラインバッファ７４を経てデータ電極
駆動装置７６に与えられる。アドレス検出回路８８で検
出されたアドレスデータは、デコーダ７８によりアドレ
スデータに従う走査電極の駆動信号とされ、ラインアド
レスメモリ８０を経て走査電極駆動装置８２に印加され
る。
【００３５】本実施例では、表示パネル１２の駆動とグ
ラフィックカード８内のプロセッサによる走査電極アド
レスデータＡ０−Ａ１５およびイメージデータＤ０−Ｄ
２５５９の発生は同期していないため、データ転送時に
制御回路６８とグラフィックプロセッサを同期させる必
要がある。この目的のために、同期信号Hsync が各水平
走査時に制御回路で発生される。このHsync 信号はＡＨ
／ＤＬ信号と関連を有している。グラフィックプロセッ
サ２０はHsync 信号をモニタし、Hsync がHighからLow
に遷移するのを検出した後データ転送の準備に入り、Ａ
Ｈ／ＤＬ信号をLow からHighに立ち上げて走査電極アド
レスデータを転送し、ＡＨ／ＤＬ信号を再びHighからLo
w に立ち下げて画像データを転送する。
ラフィックカード８内のプロセッサによる走査電極アド
レスデータＡ０−Ａ１５およびイメージデータＤ０−Ｄ
２５５９の発生は同期していないため、データ転送時に
制御回路６８とグラフィックプロセッサを同期させる必
要がある。この目的のために、同期信号Hsync が各水平
走査時に制御回路で発生される。このHsync 信号はＡＨ
／ＤＬ信号と関連を有している。グラフィックプロセッ
サ２０はHsync 信号をモニタし、Hsync がHighからLow
に遷移するのを検出した後データ転送の準備に入り、Ａ
Ｈ／ＤＬ信号をLow からHighに立ち上げて走査電極アド
レスデータを転送し、ＡＨ／ＤＬ信号を再びHighからLo
w に立ち下げて画像データを転送する。
【００３６】図５は、その詳細な信号波形を示す。
【００３７】本実施例は図１のようなグラフィックデバ
イス１３にあってＨ／Ｗイベント処理の即時性（リアル
タイム性）を改善するものである。本実施例の特徴はホ
スト側におけるグラフィックデバイス１３への論理的な
インタフェース構成に係わるものである。 （ソフトウェア（論理）構成）本発明の論理構成は、Ｕ
ＮＩＸ（「ＵＮＩＸ」はＡＴ＆Ｔの登録商標）オペレー
ション・システム（ＯＳ）環境で動作するＸウィンドウ
システム（ＸWindow System は、Massachusetts Inst
itute of Technology の登録商標）を用い、図１のハー
ドウェアに実装される。ＵＮＩＸおよびＸウィンドウシ
ステムともそれぞれの領域において既に標準の地位を確
保しているといってよい。
イス１３にあってＨ／Ｗイベント処理の即時性（リアル
タイム性）を改善するものである。本実施例の特徴はホ
スト側におけるグラフィックデバイス１３への論理的な
インタフェース構成に係わるものである。 （ソフトウェア（論理）構成）本発明の論理構成は、Ｕ
ＮＩＸ（「ＵＮＩＸ」はＡＴ＆Ｔの登録商標）オペレー
ション・システム（ＯＳ）環境で動作するＸウィンドウ
システム（ＸWindow System は、Massachusetts Inst
itute of Technology の登録商標）を用い、図１のハー
ドウェアに実装される。ＵＮＩＸおよびＸウィンドウシ
ステムともそれぞれの領域において既に標準の地位を確
保しているといってよい。
【００３８】ＵＮＩＸは、プロセスの管理、ファイルシ
ステムの管理、ハードウェア入出力、およびプロセス間
通信等の機能をカーネルと呼ばれる中核部分によって提
供する、マルチタスク、マルチユーザを特徴としたシス
テムソフトウェアである。実際にハードウェア入出力を
直接に制御するのはデバイスドライバと呼ばれるモジュ
ールである。デバイスドライバによって、ＵＮＩＸは各
アプリケーションソフトウェアに対して共通の論理的な
インタフェースを提供し、それによってアプリケーショ
ンソフトウェアの移植性を維持している。ディスプレイ
の場合も例外でなく、ディスプレイドライバと呼ばれる
モジュールが用意される。ただし、デバイスドライバは
カーネルにリンクされて一つのイメージとなるが、各ハ
ードウェアに依存するためＵＮＩＸ固有の部分ではな
い。
ステムの管理、ハードウェア入出力、およびプロセス間
通信等の機能をカーネルと呼ばれる中核部分によって提
供する、マルチタスク、マルチユーザを特徴としたシス
テムソフトウェアである。実際にハードウェア入出力を
直接に制御するのはデバイスドライバと呼ばれるモジュ
ールである。デバイスドライバによって、ＵＮＩＸは各
アプリケーションソフトウェアに対して共通の論理的な
インタフェースを提供し、それによってアプリケーショ
ンソフトウェアの移植性を維持している。ディスプレイ
の場合も例外でなく、ディスプレイドライバと呼ばれる
モジュールが用意される。ただし、デバイスドライバは
カーネルにリンクされて一つのイメージとなるが、各ハ
ードウェアに依存するためＵＮＩＸ固有の部分ではな
い。
【００３９】Ｘウィンドウシステムは、周知のようにビ
ットマップディスプレイ上にマルチウィンドウ環境を実
現するためのソフトウェアである。その動作概念を図６
に示す。Ｘウィンドウシステム全体は、一つのＸサーバ
１４（以後、単にサーバ１４と略す）と複数のＸクライ
アント１５（以後単にクライアントと呼ぶ。また、図２
では一つだけ図示しあとは省略した）で構成される。サ
ーバ１４は、キーボードデバイス（以後、キーボードと
略す）、マウスデバイス（以後、マウスと略す）等の入
力デバイス１６からのユーザ入力（ハードウェアイベン
ト）の受理、クライアント１５との通信、そしてグラフ
ィックデバイス１３への描画コマンドの発行を行なう。
ットマップディスプレイ上にマルチウィンドウ環境を実
現するためのソフトウェアである。その動作概念を図６
に示す。Ｘウィンドウシステム全体は、一つのＸサーバ
１４（以後、単にサーバ１４と略す）と複数のＸクライ
アント１５（以後単にクライアントと呼ぶ。また、図２
では一つだけ図示しあとは省略した）で構成される。サ
ーバ１４は、キーボードデバイス（以後、キーボードと
略す）、マウスデバイス（以後、マウスと略す）等の入
力デバイス１６からのユーザ入力（ハードウェアイベン
ト）の受理、クライアント１５との通信、そしてグラフ
ィックデバイス１３への描画コマンドの発行を行なう。
【００４０】図７に示したように、サーバ１４はＤＩ
Ｘ、ＯＳ、ＤＤＸ、ＥＸＴの四つの部分で構成されてい
る（ＥＸＴは省略した）。ＤＩＸはデバイスやＯＳに依
存しない部分であり、イベント待ちおよび処理への分岐
のためのループの形成、様々なリソースの管理等を行な
っている。ＯＳは、クライアント１５との通信、ファイ
ルシステムへのアクセスを行なうための、広い意味での
ＯＳとのインタフェースとなる部分である。ＤＤＸは、
キーボード４、マウス５、ディスプレイ等のデバイスに
依存する部分である。ＥＸＴは、後述するＸプロトコル
の拡張をサポートする部分で、特殊な機能を盛り込まな
い限り通常は関与しない。一方、クライアント１５は、
Ｘウィンドウシステム上で動作するアプリケーションで
ある。クライアント１５は図６にもあるように、サーバ
１４が動作しているマシンではなく、ネットワークで接
続された別のマシン上で動作していてもよい。
Ｘ、ＯＳ、ＤＤＸ、ＥＸＴの四つの部分で構成されてい
る（ＥＸＴは省略した）。ＤＩＸはデバイスやＯＳに依
存しない部分であり、イベント待ちおよび処理への分岐
のためのループの形成、様々なリソースの管理等を行な
っている。ＯＳは、クライアント１５との通信、ファイ
ルシステムへのアクセスを行なうための、広い意味での
ＯＳとのインタフェースとなる部分である。ＤＤＸは、
キーボード４、マウス５、ディスプレイ等のデバイスに
依存する部分である。ＥＸＴは、後述するＸプロトコル
の拡張をサポートする部分で、特殊な機能を盛り込まな
い限り通常は関与しない。一方、クライアント１５は、
Ｘウィンドウシステム上で動作するアプリケーションで
ある。クライアント１５は図６にもあるように、サーバ
１４が動作しているマシンではなく、ネットワークで接
続された別のマシン上で動作していてもよい。
【００４１】以下にサーバ１４、クライアント１５を軸
としたＸウィンドウシステムの動作概要を記す。
としたＸウィンドウシステムの動作概要を記す。
【００４２】まず、サーバ１４はハードウェアイベント
を検出しそれをクライアント１５に通知する。クライア
ント１５は受け取ったイベントに応じた処理を行ない、
その中で描画等のリクエストをサーバ１４に対して発行
する。サーバ１４は、クライアント１５からのリクエス
トに応じて処理を行ない、ディスプレイドライバを介し
てグラフィックデバイス１３に対して描画コマンドを発
行するか、あるいはクライアント１５に求められた情報
を渡す。Ｘウィンドウシステムはこのようなサーバ／ク
ライアント間通信を中心として動作している。サーバ１
４とクライアント１５の間の情報の受け渡しはＸプロト
コルと呼ばれる一定の規約にしたがって行なわれる。こ
のＸプロトコルは、特定のハードウェアデバイスやＯＳ
からの独立、ネットワーク透過性等を特徴としており、
Ｘウィンドウシステムを定義づけているものである。な
お、クライアントプログラムのサーバ１４とのインタフ
ェースとして、Ｘライブラリ（Ｘlib ）が用意されてお
り、デバイスに依存しないプログラミングが可能になっ
ている。
を検出しそれをクライアント１５に通知する。クライア
ント１５は受け取ったイベントに応じた処理を行ない、
その中で描画等のリクエストをサーバ１４に対して発行
する。サーバ１４は、クライアント１５からのリクエス
トに応じて処理を行ない、ディスプレイドライバを介し
てグラフィックデバイス１３に対して描画コマンドを発
行するか、あるいはクライアント１５に求められた情報
を渡す。Ｘウィンドウシステムはこのようなサーバ／ク
ライアント間通信を中心として動作している。サーバ１
４とクライアント１５の間の情報の受け渡しはＸプロト
コルと呼ばれる一定の規約にしたがって行なわれる。こ
のＸプロトコルは、特定のハードウェアデバイスやＯＳ
からの独立、ネットワーク透過性等を特徴としており、
Ｘウィンドウシステムを定義づけているものである。な
お、クライアントプログラムのサーバ１４とのインタフ
ェースとして、Ｘライブラリ（Ｘlib ）が用意されてお
り、デバイスに依存しないプログラミングが可能になっ
ている。
【００４３】Ｘウィンドウシステムは、前述したＵＮＩ
Ｘのマルチタスク機能やネットワーク機能を活用してお
り、現在ＵＮＩＸを用いたシステム上の標準ウィンドウ
システムの地位を固めている。本発明の実施例に係わる
図１でＸウィンドウシステムはホストコンピュータにお
けるもので、グラフィックデバイス１３のハードウェア
的属性はそのＤＤＸおよびＯＳ部分に記述される。
Ｘのマルチタスク機能やネットワーク機能を活用してお
り、現在ＵＮＩＸを用いたシステム上の標準ウィンドウ
システムの地位を固めている。本発明の実施例に係わる
図１でＸウィンドウシステムはホストコンピュータにお
けるもので、グラフィックデバイス１３のハードウェア
的属性はそのＤＤＸおよびＯＳ部分に記述される。
【００４４】以下、サーバによるハードウェアイベント
とクライアントリクエストの処理につき説明する。
とクライアントリクエストの処理につき説明する。
【００４５】サーバ１４は、一つのワークステーション
（スクリーン、キーボード４、マウス５）を制御するの
に対応付けられたプロセスであるが、複数のプロセスす
なわち複数のクライアント１５へサービスを提供してい
る。尚、ここでプロセスとはプログラムが実行される環
境である。一つのプロセスとは、命令セグメント、ユー
ザデータセグメント、システムデータセグメントの三つ
のセグメントから構成される。プログラムは命令とユー
ザデータを初期化するために用いられる一つのプログラ
ムが時間的に並行した複数のプロセスで実行されうる。
マルチタスクシステムは複数のプロセスをタイムシェア
リングで並行して実行する。この複数のプロセスに対す
るタイムシェアリング自体はＵＮＩＸカーネルが担当し
ている。一方、サーバ１４におけるスケジューリングと
は発生した描画リクエストの処理、ハードウェア（Ｈ／
Ｗ）イベント処理などの順序を規定するものである。
（スクリーン、キーボード４、マウス５）を制御するの
に対応付けられたプロセスであるが、複数のプロセスす
なわち複数のクライアント１５へサービスを提供してい
る。尚、ここでプロセスとはプログラムが実行される環
境である。一つのプロセスとは、命令セグメント、ユー
ザデータセグメント、システムデータセグメントの三つ
のセグメントから構成される。プログラムは命令とユー
ザデータを初期化するために用いられる一つのプログラ
ムが時間的に並行した複数のプロセスで実行されうる。
マルチタスクシステムは複数のプロセスをタイムシェア
リングで並行して実行する。この複数のプロセスに対す
るタイムシェアリング自体はＵＮＩＸカーネルが担当し
ている。一方、サーバ１４におけるスケジューリングと
は発生した描画リクエストの処理、ハードウェア（Ｈ／
Ｗ）イベント処理などの順序を規定するものである。
【００４６】図１０に、クライアント１５へのサービス
を行なうための本発明の実施例におけるキュー（待ち行
列）システムを示す。
を行なうための本発明の実施例におけるキュー（待ち行
列）システムを示す。
【００４７】一般にクライアント１５は、イベント駆動
型のプログラムとしてなりたっている。すなわち、クラ
イアント１５はユーザのキーボード４やマウス５等の入
力に応じて所定の処理ルーチンを呼び出してディスプレ
イに出力を行なう。そのために、サーバ１４はキーボー
ド４やマウス５等のＨ／Ｗイベントを検出し、それをし
かるべきクライアント１５に対して、サーバ／クライア
ント間のプロトコルで定められた形で通知する。本実施
例においては、サーバ１４は定期的にＨ／Ｗイベントキ
ュー１０２内に蓄積されたＨ／Ｗイベントの有無をチェ
ックし、もしＨ／Ｗイベントがあればそれを順次取り出
してクライアント１５に対して通知している。クライア
ント１５はＨ／Ｗイベントに応じて処理を行ない（必要
に応じて）サーバ１４に対する描画リクエストを生成
し、それを各クライアント１５毎のクライアントキュー
１０１に作成順に登録する。
型のプログラムとしてなりたっている。すなわち、クラ
イアント１５はユーザのキーボード４やマウス５等の入
力に応じて所定の処理ルーチンを呼び出してディスプレ
イに出力を行なう。そのために、サーバ１４はキーボー
ド４やマウス５等のＨ／Ｗイベントを検出し、それをし
かるべきクライアント１５に対して、サーバ／クライア
ント間のプロトコルで定められた形で通知する。本実施
例においては、サーバ１４は定期的にＨ／Ｗイベントキ
ュー１０２内に蓄積されたＨ／Ｗイベントの有無をチェ
ックし、もしＨ／Ｗイベントがあればそれを順次取り出
してクライアント１５に対して通知している。クライア
ント１５はＨ／Ｗイベントに応じて処理を行ない（必要
に応じて）サーバ１４に対する描画リクエストを生成
し、それを各クライアント１５毎のクライアントキュー
１０１に作成順に登録する。
【００４８】複数のクライアント１５によって登録され
た多くの描画リクエストは、サーバ１４によってある方
針に従って順次読み出され処理される。すなわち、サー
バ１４はクライアントキュー１０１に描画リクエストの
入っているクライアント１５について順に最大Ｎmaxreq
個連続して読み出し、これを描画コマンドに変換してグ
ラフィックデバイス１３側のグラフィックコマンドキュ
ー１０３に転送する。これにより複数のクライアント１
５が生成した複数の描画リクエストは、サーバ１４によ
ってシングルタスク的に順次処理されることになる。以
上の処理によって、グラフィックコマンドキュー１０３
に転送されたコマンドは、グラフィックデバイスプロセ
ッサ２０によって、サーバ１４とは基本的には非同期に
処理される。従って、このキューに転送されたコマンド
は、それより以前に転送されたコマンドの処理が全て終
わってから処理されることになる。なお、グラフィック
コマンドキュー１０３へのホストプロセッサ１側による
コマンド書き込み、およびグラフィックデバイスプロセ
ッサ２０による同キューからのコマンド読み出し方法に
ついては後述する。
た多くの描画リクエストは、サーバ１４によってある方
針に従って順次読み出され処理される。すなわち、サー
バ１４はクライアントキュー１０１に描画リクエストの
入っているクライアント１５について順に最大Ｎmaxreq
個連続して読み出し、これを描画コマンドに変換してグ
ラフィックデバイス１３側のグラフィックコマンドキュ
ー１０３に転送する。これにより複数のクライアント１
５が生成した複数の描画リクエストは、サーバ１４によ
ってシングルタスク的に順次処理されることになる。以
上の処理によって、グラフィックコマンドキュー１０３
に転送されたコマンドは、グラフィックデバイスプロセ
ッサ２０によって、サーバ１４とは基本的には非同期に
処理される。従って、このキューに転送されたコマンド
は、それより以前に転送されたコマンドの処理が全て終
わってから処理されることになる。なお、グラフィック
コマンドキュー１０３へのホストプロセッサ１側による
コマンド書き込み、およびグラフィックデバイスプロセ
ッサ２０による同キューからのコマンド読み出し方法に
ついては後述する。
【００４９】ところで、図１１に示すように、マウス５
のイベントのようなＨ／Ｗイベントにかかわる描画がリ
アルタイムに実行できなくなるのは、グラフィックデバ
イス１３以降の処理速度が描画命令発生の速さに対し十
分でなく、そのイベント発生時にグラフィックコマンド
キュー１０３に未処理コマンドが多く残っているからで
ある。そこで、描画のリアルタイム性の向上を図るに
は、サーバ１４がクライアント１５に通知するマウスイ
ベントを減少させることにより実現しうるものと考えら
れる。（一般にマウス移動イベントは、複数の移動変位
をベクトル的に加えることによって、結果的にサンプリ
ングを粗くしたのと同様、イベント発生数を少なくする
ことができる。）なぜならば、発行される描画コマンド
の数は、サーバ１４がクライアント１５に通知するマウ
スイベントの数に依存するからである。つまり、マウス
イベントの数が減ればクライアント１５により生成され
る描画リクエストも減り、それによりサーバ１４が発行
するコマンド数も減り、グラフィックデバイスプロセッ
サ２０の負荷が低減されることになる。その結果、グラ
フィックデバイス１３以降の処理速度が描画命令発生の
速さに十分追いつくことができるようになる。
のイベントのようなＨ／Ｗイベントにかかわる描画がリ
アルタイムに実行できなくなるのは、グラフィックデバ
イス１３以降の処理速度が描画命令発生の速さに対し十
分でなく、そのイベント発生時にグラフィックコマンド
キュー１０３に未処理コマンドが多く残っているからで
ある。そこで、描画のリアルタイム性の向上を図るに
は、サーバ１４がクライアント１５に通知するマウスイ
ベントを減少させることにより実現しうるものと考えら
れる。（一般にマウス移動イベントは、複数の移動変位
をベクトル的に加えることによって、結果的にサンプリ
ングを粗くしたのと同様、イベント発生数を少なくする
ことができる。）なぜならば、発行される描画コマンド
の数は、サーバ１４がクライアント１５に通知するマウ
スイベントの数に依存するからである。つまり、マウス
イベントの数が減ればクライアント１５により生成され
る描画リクエストも減り、それによりサーバ１４が発行
するコマンド数も減り、グラフィックデバイスプロセッ
サ２０の負荷が低減されることになる。その結果、グラ
フィックデバイス１３以降の処理速度が描画命令発生の
速さに十分追いつくことができるようになる。
【００５０】サーバ１４は、前述のようにＨ／Ｗイベン
ト（マウスイベントを含む）をしかるべきクライアント
１５に通知するが、これはサーバ１４のＤＤＸレイヤに
含まれるProcessInputEvents()ルーチンで行なわれる。
このルーチンは、サーバ１４のＤＩＸレイヤに含まれる
Dispatch()ルーチン中のDispatchループと呼ばれるルー
プで定期的に呼び出される。また、このDispatchループ
は一般に複数のクライアント１５で生成されたリクエス
トをあるスケジューリング方針に従ってクライアントキ
ュー１０１から読み出してそれぞれのリクエストの種類
に応じた処理ルーチンを起動する。リクエストが描画リ
クエストの場合は、最終的にはＤＤＸレイヤ中のルーチ
ンが呼ばれ、グラフィックデバイス１３に対してコマン
ドが送られる。
ト（マウスイベントを含む）をしかるべきクライアント
１５に通知するが、これはサーバ１４のＤＤＸレイヤに
含まれるProcessInputEvents()ルーチンで行なわれる。
このルーチンは、サーバ１４のＤＩＸレイヤに含まれる
Dispatch()ルーチン中のDispatchループと呼ばれるルー
プで定期的に呼び出される。また、このDispatchループ
は一般に複数のクライアント１５で生成されたリクエス
トをあるスケジューリング方針に従ってクライアントキ
ュー１０１から読み出してそれぞれのリクエストの種類
に応じた処理ルーチンを起動する。リクエストが描画リ
クエストの場合は、最終的にはＤＤＸレイヤ中のルーチ
ンが呼ばれ、グラフィックデバイス１３に対してコマン
ドが送られる。
【００５１】ここで、図１２のフローチャートを参照し
て、DispatchループにおけるＨ／Ｗイベントおよびクラ
イアントリクエストの処理の各ステップについて説明す
る。Dispatchループでは、まずステップＳ１でＨ／Ｗイ
ベントがＨ／Ｗイベントキュー１０２にあれば、Proces
sInputEvents()関数を呼んでキュー内の全てのイベント
の処理を行なう。すなわち、プロトコルに従ってイベン
トをしかるべきクライアント１５に通知する。次に、ス
テップＳ２で次に挙げる事象のうちのどれかが発生する
まで待つ。 (i) Ｈ／Ｗイベントが発生する。 (ii)サーバ１４にすでに接続されているクライアント１
５からリクエストが来る。 (iii) まだサーバ１４と接続されていない新しいクライ
アント１５が接続を要求する。
て、DispatchループにおけるＨ／Ｗイベントおよびクラ
イアントリクエストの処理の各ステップについて説明す
る。Dispatchループでは、まずステップＳ１でＨ／Ｗイ
ベントがＨ／Ｗイベントキュー１０２にあれば、Proces
sInputEvents()関数を呼んでキュー内の全てのイベント
の処理を行なう。すなわち、プロトコルに従ってイベン
トをしかるべきクライアント１５に通知する。次に、ス
テップＳ２で次に挙げる事象のうちのどれかが発生する
まで待つ。 (i) Ｈ／Ｗイベントが発生する。 (ii)サーバ１４にすでに接続されているクライアント１
５からリクエストが来る。 (iii) まだサーバ１４と接続されていない新しいクライ
アント１５が接続を要求する。
【００５２】これらのうちのいずれかが発生したら必要
な情報を設定してから次のステップＳ３に進む。
な情報を設定してから次のステップＳ３に進む。
【００５３】ステップＳ３では、前のステップで、新し
いクライアント１５の接続要求があった場合に接続処理
を行なう。次に、ステップＳ４で処理待ちのリクエスト
が残っているクライアント１５があるかどうかを調べ
る。リクエストがクライアントキュー１０１に残ってい
るクライアント１５が無ければステップＳ１に戻る。リ
クエストがクライアントキュー１０１に残っているクラ
イアント１５があれば、以後のステップＳ５でリクエス
トを処理する対象となるクライアント１５を設定する。
いクライアント１５の接続要求があった場合に接続処理
を行なう。次に、ステップＳ４で処理待ちのリクエスト
が残っているクライアント１５があるかどうかを調べ
る。リクエストがクライアントキュー１０１に残ってい
るクライアント１５が無ければステップＳ１に戻る。リ
クエストがクライアントキュー１０１に残っているクラ
イアント１５があれば、以後のステップＳ５でリクエス
トを処理する対象となるクライアント１５を設定する。
【００５４】ステップＳ５ののち、ステップＳ６で別の
クライアント１５のリクエストの処理に移るべきかどう
か判断する。移る場合は、ステップＳ４に戻る。移らな
い場合は、ステップＳ７に進みProcessInputEvents()関
数をコールする。次に、ステップＳ８で現在のリクエス
ト処理対象のクライアント１５のクライアントキュー１
０１に処理待ちのリクエストがまだ残っているかどうか
を調べる。残っていない場合はステップＳ４に戻り、残
っている場合はステップＳ９に進む。ステップＳ９でRe
adRequestFromClient() 関数を呼び出して、リクエスト
をクライアントキュー１０１から読み出す。次に、ステ
ップＳ１０でリクエストが正しく読み出されたかどうか
を判断する。正しく読み出されなかった場合はステップ
Ｓ６に戻り、正しく読み出された場合はステップＳ１１
でリクエストの種類に応じた処理ルーチンを起動する。
その後、再びステップＳ８に戻る。
クライアント１５のリクエストの処理に移るべきかどう
か判断する。移る場合は、ステップＳ４に戻る。移らな
い場合は、ステップＳ７に進みProcessInputEvents()関
数をコールする。次に、ステップＳ８で現在のリクエス
ト処理対象のクライアント１５のクライアントキュー１
０１に処理待ちのリクエストがまだ残っているかどうか
を調べる。残っていない場合はステップＳ４に戻り、残
っている場合はステップＳ９に進む。ステップＳ９でRe
adRequestFromClient() 関数を呼び出して、リクエスト
をクライアントキュー１０１から読み出す。次に、ステ
ップＳ１０でリクエストが正しく読み出されたかどうか
を判断する。正しく読み出されなかった場合はステップ
Ｓ６に戻り、正しく読み出された場合はステップＳ１１
でリクエストの種類に応じた処理ルーチンを起動する。
その後、再びステップＳ８に戻る。
【００５５】このアルゴリズムでは、ある時点でサーバ
１４の処理を待っているリクエストを持ったクライアン
ト１５を調べ、各クライアント１５ごとに順番にリクエ
ストを処理していく。そのとき、サーバ１４はあるクラ
イアント１５のリクエスト処理を続けて最大Nmaxreq 個
処理したら、そのクライアント１５のリクエストの処理
を中断して他のクライアント１５のリクエストの処理に
移るようにしている。
１４の処理を待っているリクエストを持ったクライアン
ト１５を調べ、各クライアント１５ごとに順番にリクエ
ストを処理していく。そのとき、サーバ１４はあるクラ
イアント１５のリクエスト処理を続けて最大Nmaxreq 個
処理したら、そのクライアント１５のリクエストの処理
を中断して他のクライアント１５のリクエストの処理に
移るようにしている。
【００５６】図１２から分かるようにＨ／Ｗイベントの
処理は、各リクエスト処理の前で毎回行なわれる。これ
は、サーバ１４は発生したＨ／Ｗイベントをなるべく迅
速にかつ頻繁にクライアント１５に通知するべきである
という考え方に基づいている。しかしながら、サーバ１
４がグラフィックデバイス１３におけるコマンド処理状
態にかかわらずＨ／Ｗイベントを次つぎにクライアント
１５に通知してしまうと、図８に示されるような問題、
すなわちＨ／Ｗイベントの発生と描画との間の時間的な
ずれが生じてしまうことは明らかである。よって、何ら
かの手段によってグラフィックデバイス１３におけるコ
マンド処理状態に応じたＨ／Ｗイベントの処理が必要に
なる。本発明はこの点に着目し ReadRequestFromClien
t() 関数によりグラフィックデバイス側のグラフィック
コマンドキュー１０３の未処理コマンド数をモニタする
ことによってそのコマンド処理状態を調べ、それに応じ
てProcessInputEvents()関数においてＨ／Ｗイベントの
クライアント１５への通知を制御することにより、前述
の問題の改善を図るものである。
処理は、各リクエスト処理の前で毎回行なわれる。これ
は、サーバ１４は発生したＨ／Ｗイベントをなるべく迅
速にかつ頻繁にクライアント１５に通知するべきである
という考え方に基づいている。しかしながら、サーバ１
４がグラフィックデバイス１３におけるコマンド処理状
態にかかわらずＨ／Ｗイベントを次つぎにクライアント
１５に通知してしまうと、図８に示されるような問題、
すなわちＨ／Ｗイベントの発生と描画との間の時間的な
ずれが生じてしまうことは明らかである。よって、何ら
かの手段によってグラフィックデバイス１３におけるコ
マンド処理状態に応じたＨ／Ｗイベントの処理が必要に
なる。本発明はこの点に着目し ReadRequestFromClien
t() 関数によりグラフィックデバイス側のグラフィック
コマンドキュー１０３の未処理コマンド数をモニタする
ことによってそのコマンド処理状態を調べ、それに応じ
てProcessInputEvents()関数においてＨ／Ｗイベントの
クライアント１５への通知を制御することにより、前述
の問題の改善を図るものである。
【００５７】次に、グラフィックコマンドキューの構造
と扱いを説明する。
と扱いを説明する。
【００５８】ここで、ReadRequestFromClient() 関数お
よび ProcessInputEvents() 関数の説明に入る前にグラ
フィックコマンドキュー１０３の構造とその扱い方につ
いて説明する。
よび ProcessInputEvents() 関数の説明に入る前にグラ
フィックコマンドキュー１０３の構造とその扱い方につ
いて説明する。
【００５９】図１３は、グラフィックコマンドキュー１
０３の構造を示す。キューはＮbufsiz 個のセルから成
っており、それぞれセル番号「０」〜セル番号「Ｎbufs
iz−１」で参照される。各セルはグラフィックコマンド
のヘッダ部のみを格納しており、コマンドの引数および
データは他のメモリ領域に存在し、ヘッダ部はそのアド
レスを持っている。
０３の構造を示す。キューはＮbufsiz 個のセルから成
っており、それぞれセル番号「０」〜セル番号「Ｎbufs
iz−１」で参照される。各セルはグラフィックコマンド
のヘッダ部のみを格納しており、コマンドの引数および
データは他のメモリ領域に存在し、ヘッダ部はそのアド
レスを持っている。
【００６０】ホストプロセッサ１は、図１４に示すよう
にグラフィックコマンド（正確にはそのヘッダ部である
が、以後簡単のためグラフィックコマンドと称すること
にする）を、０番目のセルからセル番号が増加する方向
に次々に書き込んでゆく。このとき、図１５に示すよう
に最終のセルに到達したら再び０番目のセルに戻る。一
方、グラフィックデバイスプロセッサ２０は、図１６，
１７に示すようにホストプロセッサ１が格納した順序で
ホストプロセッサ１の書き込んだ後を追うようにしてコ
マンドを読み出して処理を行なってゆく。
にグラフィックコマンド（正確にはそのヘッダ部である
が、以後簡単のためグラフィックコマンドと称すること
にする）を、０番目のセルからセル番号が増加する方向
に次々に書き込んでゆく。このとき、図１５に示すよう
に最終のセルに到達したら再び０番目のセルに戻る。一
方、グラフィックデバイスプロセッサ２０は、図１６，
１７に示すようにホストプロセッサ１が格納した順序で
ホストプロセッサ１の書き込んだ後を追うようにしてコ
マンドを読み出して処理を行なってゆく。
【００６１】ここで、ホストプロセッサ１による書き込
みとグラフィックデバイスプロセッサ２０による読み出
し位置を制御するために変数headおよび変数tailを用意
する。図１３のように、変数headはホストプロセッサ１
が最も新しく書き込んだセルの次のセル番号を記憶し、
変数tailはグラフィックデバイスプロセッサ２０が次に
読み出すセルのセル番号を記憶する。すなわち、ホスト
プロセッサ１はグラフィックコマンドを一つ書き込むご
とに変数headを１インクリメントし、一方グラフィック
デバイスプロセッサ２０は一つ読み出すごとに変数tail
を１インクリメントする。ただし、図１５，１７に示し
たように、キューの最終セルに達した次は再び先頭に戻
るためいずれも０にクリアする。書き込み時も読み出し
時も、head≠tailであればそのまま動作を行なってよ
い。しかし、head＝tailの時には特別な配慮が必要であ
る。すなわち、図１８，１９に示すようにキューが一杯
の状態と空の状態ではともにhead＝tailとなるため、書
き込み時にはオーバーライトを避けるために、グラフィ
ックデバイスプロセッサ２０がアイドル状態であること
を確認した上で書き込みを行なわなければならない。
みとグラフィックデバイスプロセッサ２０による読み出
し位置を制御するために変数headおよび変数tailを用意
する。図１３のように、変数headはホストプロセッサ１
が最も新しく書き込んだセルの次のセル番号を記憶し、
変数tailはグラフィックデバイスプロセッサ２０が次に
読み出すセルのセル番号を記憶する。すなわち、ホスト
プロセッサ１はグラフィックコマンドを一つ書き込むご
とに変数headを１インクリメントし、一方グラフィック
デバイスプロセッサ２０は一つ読み出すごとに変数tail
を１インクリメントする。ただし、図１５，１７に示し
たように、キューの最終セルに達した次は再び先頭に戻
るためいずれも０にクリアする。書き込み時も読み出し
時も、head≠tailであればそのまま動作を行なってよ
い。しかし、head＝tailの時には特別な配慮が必要であ
る。すなわち、図１８，１９に示すようにキューが一杯
の状態と空の状態ではともにhead＝tailとなるため、書
き込み時にはオーバーライトを避けるために、グラフィ
ックデバイスプロセッサ２０がアイドル状態であること
を確認した上で書き込みを行なわなければならない。
【００６２】アイドル状態を確認するためには、例えば
グラフィックデバイスプロセッサ２０が、自分がアイド
ル状態にある時には常にある二つのフラグを等しい値に
セットするようにすればよい。そうすれば、ホストプロ
セッサ１がこの二つのフラグに異なった値をセットした
後、このフラグの値を調べた時、それらがグラフィック
デバイスプロセッサ２０によって等しい値にセットされ
ていればアイドル状態にあることが確認できる。逆に、
ある期間をおいてもフラグの値が異なったままであれ
ば、アイドル状態ではないと判断できる。
グラフィックデバイスプロセッサ２０が、自分がアイド
ル状態にある時には常にある二つのフラグを等しい値に
セットするようにすればよい。そうすれば、ホストプロ
セッサ１がこの二つのフラグに異なった値をセットした
後、このフラグの値を調べた時、それらがグラフィック
デバイスプロセッサ２０によって等しい値にセットされ
ていればアイドル状態にあることが確認できる。逆に、
ある期間をおいてもフラグの値が異なったままであれ
ば、アイドル状態ではないと判断できる。
【００６３】一方、グラフィックデバイスプロセッサ２
０側はhead≠tailの場合はそのまま読み出しを行なって
よいが、head＝tailの場合は次のようにして判断すれば
よい。すなわち、グラフィックデバイスプロセッサ２０
はグラフィックコマンドを読み出して変数tailをインク
リメントする直前で、head＝tail＋１となる場合はある
フラグをセットする。そうしておいて、グラフィックデ
バイスプロセッサ２０がコマンドを読み出そうとした時
にhead＝tailであった場合、このフラグを参照し、セッ
トされていればキューは空であり読み出してはいけな
い。また、フラグがセットされていなければキューは一
杯であるので、読み出しを行なう。このフラグを用いる
場合にはhead≠tailの場合、フラグの値にかかわらず必
ずクリアしなければならない。
０側はhead≠tailの場合はそのまま読み出しを行なって
よいが、head＝tailの場合は次のようにして判断すれば
よい。すなわち、グラフィックデバイスプロセッサ２０
はグラフィックコマンドを読み出して変数tailをインク
リメントする直前で、head＝tail＋１となる場合はある
フラグをセットする。そうしておいて、グラフィックデ
バイスプロセッサ２０がコマンドを読み出そうとした時
にhead＝tailであった場合、このフラグを参照し、セッ
トされていればキューは空であり読み出してはいけな
い。また、フラグがセットされていなければキューは一
杯であるので、読み出しを行なう。このフラグを用いる
場合にはhead≠tailの場合、フラグの値にかかわらず必
ずクリアしなければならない。
【００６４】次に図１２で示されたDispatchループから
呼ばれるProcessInputEvents()関数およびReadRequestF
romClient() 関数について説明する。
呼ばれるProcessInputEvents()関数およびReadRequestF
romClient() 関数について説明する。
【００６５】図２０にReadRequestFromClient() 関数の
実施例を示す。図２０において、ReadRequestFromClien
t() 関数は、まずステップＳ２１でPeekDevQueue()関数
を呼ぶ。PeekDevQueue()関数は後に図２１で説明するよ
うに、グラフィックデバイス１３のための仮想デバイス
をオープンして前述の変数head、tailの値を得、これら
の値をもとにして現在グラフィックコマンドキュー１０
３中の未処理のまま残っているグラフィックコマンドの
数を算出してリターンする。ステップＳ２１では、Peek
DevQueue()関数からリターンされた値が既定の値Ｎ１よ
りも大きいか否か判別し、大きかった場合には、再びス
テップＳ２２でPeekDevQueue()関数を呼ぶ。そのリター
ン値が既定の値Ｎ２よりも小さくなるまで繰り返しステ
ップＳ２２を実行し待ってから、ステップＳ２３でフラ
グGDevbusyを真（TRUE）にセットし、リターンする。一
方ステップＳ２１で最初のPeekDevQueue()関数のリター
ン値がＮ１以下であれば、ステップＳ２４でクライアン
トキューからリクエストを読み出してからリターンす
る。
実施例を示す。図２０において、ReadRequestFromClien
t() 関数は、まずステップＳ２１でPeekDevQueue()関数
を呼ぶ。PeekDevQueue()関数は後に図２１で説明するよ
うに、グラフィックデバイス１３のための仮想デバイス
をオープンして前述の変数head、tailの値を得、これら
の値をもとにして現在グラフィックコマンドキュー１０
３中の未処理のまま残っているグラフィックコマンドの
数を算出してリターンする。ステップＳ２１では、Peek
DevQueue()関数からリターンされた値が既定の値Ｎ１よ
りも大きいか否か判別し、大きかった場合には、再びス
テップＳ２２でPeekDevQueue()関数を呼ぶ。そのリター
ン値が既定の値Ｎ２よりも小さくなるまで繰り返しステ
ップＳ２２を実行し待ってから、ステップＳ２３でフラ
グGDevbusyを真（TRUE）にセットし、リターンする。一
方ステップＳ２１で最初のPeekDevQueue()関数のリター
ン値がＮ１以下であれば、ステップＳ２４でクライアン
トキューからリクエストを読み出してからリターンす
る。
【００６６】上記で説明したReadRequestFromClient()
関数の意味するところは、グラフィックコマンドキュー
１０３中にある既定の数より多くのコマンドが未処理の
まま残っているとき、すなわちグラフィックデバイス１
３における処理速度がコマンド発行速度に追いつかなく
なっているときに、フラグGDevbusyを真にセットすると
いうことである。また同時に、未処理コマンド数が別の
ある既定の数より少なくなるまで待つことにより、グラ
フィックデバイス１３へのコマンドの発行速度を押さえ
ている。
関数の意味するところは、グラフィックコマンドキュー
１０３中にある既定の数より多くのコマンドが未処理の
まま残っているとき、すなわちグラフィックデバイス１
３における処理速度がコマンド発行速度に追いつかなく
なっているときに、フラグGDevbusyを真にセットすると
いうことである。また同時に、未処理コマンド数が別の
ある既定の数より少なくなるまで待つことにより、グラ
フィックデバイス１３へのコマンドの発行速度を押さえ
ている。
【００６７】図２１を参照して、PeekDevQueue()関数を
説明する。PeekDevQueue()関数では、まずステップＳ３
１でグラフィックデバイス１３のための仮想デバイスを
オープンする。次に、ステップＳ３２でオープンに成功
したか否か判別し、成功した場合はステップＳ３３に進
み、失敗した場合はステップＳ４０で「０」をリターン
値としてリターンする。
説明する。PeekDevQueue()関数では、まずステップＳ３
１でグラフィックデバイス１３のための仮想デバイスを
オープンする。次に、ステップＳ３２でオープンに成功
したか否か判別し、成功した場合はステップＳ３３に進
み、失敗した場合はステップＳ４０で「０」をリターン
値としてリターンする。
【００６８】ステップＳ３３で前述の変数headを得、ス
テップＳ３４で変数tailの値を得、ステップＳ３５でデ
バイスをクローズする。ステップＳ３６で変数headが変
数tailより大きいか否かを判別し、大きい場合はステッ
プＳ３７で変数numUnproc にhead−tailを格納する。ス
テップＳ３６で変数headが変数tailより大きくない場合
は、ステップＳ３８で変数numUnproc にＮbufsiz−（he
ad−tail）を格納する。すなわち、ステップＳ３６〜Ｓ
３８では変数headおよび変数tailの値をもとにして現在
グラフィックコマンドキュー１０３中の未処理のまま残
っているグラフィックコマンドの数を算出している。ス
テップＳ３７の後、およびステップＳ３８の後、ステッ
プＳ３９で変数numUnproc をリターン値としてリターン
する。
テップＳ３４で変数tailの値を得、ステップＳ３５でデ
バイスをクローズする。ステップＳ３６で変数headが変
数tailより大きいか否かを判別し、大きい場合はステッ
プＳ３７で変数numUnproc にhead−tailを格納する。ス
テップＳ３６で変数headが変数tailより大きくない場合
は、ステップＳ３８で変数numUnproc にＮbufsiz−（he
ad−tail）を格納する。すなわち、ステップＳ３６〜Ｓ
３８では変数headおよび変数tailの値をもとにして現在
グラフィックコマンドキュー１０３中の未処理のまま残
っているグラフィックコマンドの数を算出している。ス
テップＳ３７の後、およびステップＳ３８の後、ステッ
プＳ３９で変数numUnproc をリターン値としてリターン
する。
【００６９】一方のProcessInputEvents()関数では、図
２２に示されるように、まずステップＳ５１で図２０の
ReadRequestFromClient() 関数でTRUEがセットされてい
るかも知れないフラグGDevBusyを参照する。TRUEがセッ
トされていればステップＳ５２に、セットされていなけ
ればステップＳ５５に、それぞれ進む。ステップＳ５２
で変数NSKIP の値が０より大きいか否か判別する。NSKI
P ＞０ならばステップＳ５４に分岐する。ステップＳ５
２でNSKIP ＞０でないときは、ステップＳ５３で、変数
NSKIP にある定数値NADDを加算し、ステップＳ５４でGD
evBusyをクリア（FALSE の設定）する。次に、ステップ
Ｓ５５で変数NSKIP の値が０より大きいか否か判別す
る。最初でGDevBusyがセットされていなかった場合も含
めて、NSKIP ＞０ならば、ステップＳ５６で変数NSKIP
を１デクリメントしてからリターンする。もし、ステッ
プＳ５５でNSKIP ＝０であれば、ステップＳ５７でHand
leEvents()関数を呼んでからリターンする。HandleEven
ts()関数では、図２３に示されるように、まずステップ
Ｓ６１でバッファにＨ／Ｗイベントがあるか否か判別す
る。Ｈ／Ｗイベントがある場合は、ステップＳ６２でＨ
／Ｗイベントキュー１０２に溜まっているＨ／Ｗイベン
トを一つずつ読み出し、WriteToClient() 関数によって
しかるべきクライアント１５に通知している。すなわ
ち、ステップＳ６２でＨ／Ｗイベントを読み出したの
ち、ステップＳ６３でキーボードイベントか否か判別す
る。キーボードイベントである場合は、ステップＳ６６
でキーボードイベントの処理を行い、ステップＳ６１に
戻る。ステップＳ６３でキーボードイベントでない場合
は、ステップＳ６４でマウスボタンイベントか否か判別
する。マウスボタンイベントである場合は、ステップＳ
６７でマウスボタンイベントの処理を行い、ステップＳ
６１に戻る。ステップＳ６４でマウスボタンイベントで
ない場合は、ステップＳ６５でマウス移動量を累積加算
し、ステップＳ６１に戻る。ステップＳ６１でバッファ
にＨ／Ｗイベントがない場合は、ステップＳ６８でマウ
ス移動イベントの処理を行った後、リターンする。
２２に示されるように、まずステップＳ５１で図２０の
ReadRequestFromClient() 関数でTRUEがセットされてい
るかも知れないフラグGDevBusyを参照する。TRUEがセッ
トされていればステップＳ５２に、セットされていなけ
ればステップＳ５５に、それぞれ進む。ステップＳ５２
で変数NSKIP の値が０より大きいか否か判別する。NSKI
P ＞０ならばステップＳ５４に分岐する。ステップＳ５
２でNSKIP ＞０でないときは、ステップＳ５３で、変数
NSKIP にある定数値NADDを加算し、ステップＳ５４でGD
evBusyをクリア（FALSE の設定）する。次に、ステップ
Ｓ５５で変数NSKIP の値が０より大きいか否か判別す
る。最初でGDevBusyがセットされていなかった場合も含
めて、NSKIP ＞０ならば、ステップＳ５６で変数NSKIP
を１デクリメントしてからリターンする。もし、ステッ
プＳ５５でNSKIP ＝０であれば、ステップＳ５７でHand
leEvents()関数を呼んでからリターンする。HandleEven
ts()関数では、図２３に示されるように、まずステップ
Ｓ６１でバッファにＨ／Ｗイベントがあるか否か判別す
る。Ｈ／Ｗイベントがある場合は、ステップＳ６２でＨ
／Ｗイベントキュー１０２に溜まっているＨ／Ｗイベン
トを一つずつ読み出し、WriteToClient() 関数によって
しかるべきクライアント１５に通知している。すなわ
ち、ステップＳ６２でＨ／Ｗイベントを読み出したの
ち、ステップＳ６３でキーボードイベントか否か判別す
る。キーボードイベントである場合は、ステップＳ６６
でキーボードイベントの処理を行い、ステップＳ６１に
戻る。ステップＳ６３でキーボードイベントでない場合
は、ステップＳ６４でマウスボタンイベントか否か判別
する。マウスボタンイベントである場合は、ステップＳ
６７でマウスボタンイベントの処理を行い、ステップＳ
６１に戻る。ステップＳ６４でマウスボタンイベントで
ない場合は、ステップＳ６５でマウス移動量を累積加算
し、ステップＳ６１に戻る。ステップＳ６１でバッファ
にＨ／Ｗイベントがない場合は、ステップＳ６８でマウ
ス移動イベントの処理を行った後、リターンする。
【００７０】図２２のProcessInputEvents()関数では、
もしNSKIP ＞０であればHandleEvents()関数を呼ばずに
リターンしてしまう。すなわち、ハードウェアイベント
キューからのイベントの読み出しおよびクライアントへ
の通知を行なわない。HandleEvents()関数で注目すべき
は、キーイベントとマウスボタンイベントは読み出され
た直後にクライアント１５に通知されるが、マウス移動
イベントは複数のイベントの移動量をベクトル的に加算
していき、Ｈ／Ｗイベントキュー１０２に溜まった全て
のイベントが読みだされてから一つのマウス移動イベン
トとしてクライアント１５に通知されている点である。
これにより、複数のマウス移動イベントは一つのマウス
移動イベントになり、クライアントに通知されるマウス
移動イベントの数が減少する。
もしNSKIP ＞０であればHandleEvents()関数を呼ばずに
リターンしてしまう。すなわち、ハードウェアイベント
キューからのイベントの読み出しおよびクライアントへ
の通知を行なわない。HandleEvents()関数で注目すべき
は、キーイベントとマウスボタンイベントは読み出され
た直後にクライアント１５に通知されるが、マウス移動
イベントは複数のイベントの移動量をベクトル的に加算
していき、Ｈ／Ｗイベントキュー１０２に溜まった全て
のイベントが読みだされてから一つのマウス移動イベン
トとしてクライアント１５に通知されている点である。
これにより、複数のマウス移動イベントは一つのマウス
移動イベントになり、クライアントに通知されるマウス
移動イベントの数が減少する。
【００７１】本発明の新規性は、グラフィックデバイス
におけるコマンド処理状態に応じてハードウェアイベン
トの読み出しおよびクライアントの通知を所定の期間ス
キップし続けることである。すなわち、ReadRequestFro
mClient() 関数中においてグラフィックデバイス１３の
処理速度が相対的に下がったと判断された場合、それは
フラグGDevBusyを通してProcessInputEvents()関数に伝
えられる。するとProcessInputEvents()関数内ではいっ
たんGDevBusyがセットされると、以降ProcessInputEven
ts()関数が呼ばれるごとにＨ／Ｗイベントの処理関数Ha
ndleEvents()が連続NADD回（NADDは適当な大きさの値を
用いる）だけスキップされる。Ｈ／Ｗイベントの処理が
スキップされることによって、Ｈ／Ｗイベントキュー１
０２にさらに多くのイベントが溜まるようになり、次に
Ｈ／Ｗイベントの処理が行なわれる時に読み出されるイ
ベントの数が増す。図２３に示されるように、一回のHa
ndleEvents()関数で読み出されるイベントの数が増える
ほど、マウス移動イベントの数の減少程度は大きくな
る。それにより、クライアント１５に対して通知される
マウス移動イベントが減少し、クライアント１５により
生成されるリクエストが減少し、最終的にグラフィック
デバイス１３が処理すべき描画コマンドも減少する。そ
れ故グラフィックコマンドキュー１０３にコマンドが格
納されたときに、未処理のまま残っているコマンドの数
が減少するため、格納されてから処理されるまでの時間
が短縮する。例えば図１１のような例では、Ｈ／Ｗイベ
ントの検出から描画までの時間的な処理の流れが図８の
ような状況から図９のような状況に変わる。それによっ
て、図９では検出されたイベントに係わる描画とイベン
ト検出の間の時間が図８より短縮されていることが分か
る。
におけるコマンド処理状態に応じてハードウェアイベン
トの読み出しおよびクライアントの通知を所定の期間ス
キップし続けることである。すなわち、ReadRequestFro
mClient() 関数中においてグラフィックデバイス１３の
処理速度が相対的に下がったと判断された場合、それは
フラグGDevBusyを通してProcessInputEvents()関数に伝
えられる。するとProcessInputEvents()関数内ではいっ
たんGDevBusyがセットされると、以降ProcessInputEven
ts()関数が呼ばれるごとにＨ／Ｗイベントの処理関数Ha
ndleEvents()が連続NADD回（NADDは適当な大きさの値を
用いる）だけスキップされる。Ｈ／Ｗイベントの処理が
スキップされることによって、Ｈ／Ｗイベントキュー１
０２にさらに多くのイベントが溜まるようになり、次に
Ｈ／Ｗイベントの処理が行なわれる時に読み出されるイ
ベントの数が増す。図２３に示されるように、一回のHa
ndleEvents()関数で読み出されるイベントの数が増える
ほど、マウス移動イベントの数の減少程度は大きくな
る。それにより、クライアント１５に対して通知される
マウス移動イベントが減少し、クライアント１５により
生成されるリクエストが減少し、最終的にグラフィック
デバイス１３が処理すべき描画コマンドも減少する。そ
れ故グラフィックコマンドキュー１０３にコマンドが格
納されたときに、未処理のまま残っているコマンドの数
が減少するため、格納されてから処理されるまでの時間
が短縮する。例えば図１１のような例では、Ｈ／Ｗイベ
ントの検出から描画までの時間的な処理の流れが図８の
ような状況から図９のような状況に変わる。それによっ
て、図９では検出されたイベントに係わる描画とイベン
ト検出の間の時間が図８より短縮されていることが分か
る。
【００７２】
【発明の効果】以上説明したように、本発明によれば、
描画命令の実行状態をモニタし、その実行状態が所定の
程度を越えた場合に、以後のハードウェアイベントの通
知処理を所定期間の間スキップするようにしているの
で、ハードウェアイベントの発生から描画までの時間が
短縮されレスポンスがよくリアルタイム性の高いシステ
ムが実現される。
描画命令の実行状態をモニタし、その実行状態が所定の
程度を越えた場合に、以後のハードウェアイベントの通
知処理を所定期間の間スキップするようにしているの
で、ハードウェアイベントの発生から描画までの時間が
短縮されレスポンスがよくリアルタイム性の高いシステ
ムが実現される。
【図１】 本発明の一実施例に係るデータ処理装置のハ
ードウェア構成を示すブロック図、
ードウェア構成を示すブロック図、
【図２】 図１のハードウェア上に実装される論理構成
のブロック図、
のブロック図、
【図３】 図１のグラフィックカードの詳細を示すブロ
ック図、
ック図、
【図４】 図１のグラフィックコントローラの詳細を示
すブロック図、
すブロック図、
【図５】 図３のグラフィックカードにおける信号波形
を示す図、
を示す図、
【図６】 本実施例の動作する環境であるＸウィンドウ
システムの構成を示す図、
システムの構成を示す図、
【図７】 Ｘウィンドウシステムのモジュール構成を示
す図、
す図、
【図８】 従来例における、ハードウェアイベント発生
から実際の描画までの各モジュールの時間的な動作状態
変化を示す図、
から実際の描画までの各モジュールの時間的な動作状態
変化を示す図、
【図９】 図８の従来例と比較した、本実施例によるハ
ードウェアイベント発生から実際の描画までの各モジュ
ールの時間的な動作状態変化を示す図、
ードウェアイベント発生から実際の描画までの各モジュ
ールの時間的な動作状態変化を示す図、
【図１０】 本実施例におけるキューシステムを示すブ
ロック図、
ロック図、
【図１１】 マウスを用いた「直接操作的な」ユーザイ
ンタフェースを説明するための図、
ンタフェースを説明するための図、
【図１２】 ＸサーバにおけるDispatchループのフロー
チャート図、
チャート図、
【図１３】 グラフィックデバイスのおけるグラフィッ
クコマンドキューの構造を示す図、
クコマンドキューの構造を示す図、
【図１４】 グラフィックコマンドキューへのアクセス
方法を示す図、
方法を示す図、
【図１５】 グラフィックコマンドキューへのアクセス
方法を示す図、
方法を示す図、
【図１６】 グラフィックコマンドキューへのアクセス
方法を示す図、
方法を示す図、
【図１７】 グラフィックコマンドキューへのアクセス
方法を示す図、
方法を示す図、
【図１８】 グラフィックコマンドキューの状態を示す
図、
図、
【図１９】 グラフィックコマンドキューの状態を示す
図、
図、
【図２０】 図１２におけるReadRequestFromClient()
ルーチンのフローチャート図、
ルーチンのフローチャート図、
【図２１】 図２０におけるPeekDevQueue()ルーチンの
フローチャート図、
フローチャート図、
【図２２】 図１２におけるProcessInputEvents()ルー
チンのフローチャート図、
チンのフローチャート図、
【図２３】 図２２におけるHandleEvents処理のフロー
チャート図。
チャート図。
１４：Ｘサーバ、１５：Ｘクライアント、１０１：クラ
イアントキュー、１０２：Ｈ／Ｗイベントキュー、１０
３：グラフィックコマンドキュー。
イアントキュー、１０２：Ｈ／Ｗイベントキュー、１０
３：グラフィックコマンドキュー。
Claims (17)
- 【請求項１】 複数のアプリケーションプログラムプロ
セスをタイムシェアリングにおいて実行させるマルチタ
スク手段と、ハードウェアイベントの発生を検知するハ
ードウェアイベント検知手段と、発生したハードウェア
イベントを複数のクライアントプログラムプロセス中の
所定のものに対して通知するハードウェアイベント通知
手段と、該複数のアプリケーションプログラムプロセス
からグラフィックデバイスへの描画要求をスケジューリ
ングして該描画要求各々を単一の系列に形成するスケジ
ューリング手段とを論理的に構成しているホストプロセ
ッサ手段、および該スケジューリング手段の単一の系列
から転送された所定単位の描画命令に従ってディスプレ
イ装置を制御して描画を行なうグラフィックデバイスを
有するデータ処理装置において、該イベント通知手段
は、該グラフィックデバイスにおける所定単位の描画命
令の実行状態をモニタし、該実行状態が所定の程度を越
えた場合、以後該ハードウェアイベントの通知処理を所
定期間の間スキップし続けることを特徴とするデータ処
理装置。 - 【請求項２】 前記イベント検知手段が、ハードウェア
イベントが発生したとき他の処理に優先して処理する、
すなわち該ハードウェアイベントをハードウェアイベン
トキューに順次蓄積しているものである請求項１に記載
のデータ処理装置。 - 【請求項３】 前記ハードウェアイベントが、キーボー
ド等のキー入力装置と、マウス、ライトペン、スタイラ
ス、タッチスクリーンまたはトラックボール等の指示装
置の操作に応じて発生されるものである請求項２に記載
のデータ処理装置。 - 【請求項４】 前記ハードウェアイベント通知手段が、
該ハードウェアイベントキューに蓄積された該ハードウ
ェアイベントを読みだして、それに関する情報を複数の
該アプリケーションプログラムプロセス中のしかるべき
ものに通知するものである請求項１に記載のデータ処理
装置。 - 【請求項５】 前記スケジューリング手段が、該グラフ
ィックデバイスの一つのスクリーン上にマルチウィンド
ウを構成する請求項１に記載のデータ処理装置。 - 【請求項６】 前記グラフィックデバイス手段が、描画
コマンドに従いスクリーン上の表示を行なっている請求
項１に記載のデータ処理装置。 - 【請求項７】 前記ホストプロセッサが、該スケジュー
リング手段を一つのプロセスとして走行させている請求
項１に記載のデータ処理装置。 - 【請求項８】 前記スケジューリング手段が複数の該ア
プリケーションプログラムプロセスから描画要求を読み
取って、これに応じてコマンドを作成し、該グラフィッ
クデバイスへと転送している請求項１に記載のデータ処
理装置。 - 【請求項９】 前記スケジューリング手段が一つのアプ
リケーションプログラムプロセスからの複数の該描画要
求を、所定の回数を最大数として連続的に処理し、これ
を複数のプロセスについて順次行なっている請求項８に
記載のデータ処理装置。 - 【請求項１０】 前記ハードウェアイベント通知手段
が、該グラフィックデバイス手段に転送された描画コマ
ンドの処理状態をモニタし、該処理状態に応じてハード
ウェアイベントキュー中のハードウェアイベントの読み
出しおよび該走行プロセスへの通知処理を制御している
請求項２ないし９に記載のデータ処理装置。 - 【請求項１１】 前記ハードウェアイベント通知手段
が、ハードウェアイベントキュー中に複数の指示装置移
動イベントが含まれている場合、それらが保持している
マウス移動量をベクトル的に加算して一つの移動イベン
トに変換する機能を有している請求項１０に記載のデー
タ処理装置。 - 【請求項１２】 前記ハードウェアイベント通知手段
が、該グラフィックデバイス手段に転送された描画コマ
ンドが所定の数以上未処理であった場合、所定の期間ハ
ードウェアイベントキューからのハードウェアイベント
の読み出しを保留している請求項１０に記載のデータ装
置。 - 【請求項１３】 前記ハードウェアイベント通知手段
が、ハードウェアイベントの読み出しを保留している期
間において、ハードウェアイベントの読み出しの保留期
間の設定を再度重ねて行なわない機能を有している請求
項１２に記載のデータ処理装置。 - 【請求項１４】 前記グラフィックデバイス手段が、強
誘電体液晶ディスプレイパネル装置を含むものである請
求項１０ないし１３に記載のデータ処理装置。 - 【請求項１５】 ディスプレイパネルと該ディスプレイ
パネルを描画コマンドに従って駆動してディスプレイ上
に描画を行なうローカルプロセッサとからなるグラフィ
ックデバイスハードウェアイベントを発生させるオペレ
ータ操作デバイス、描画プロセスを走行させるクライア
ント実行手段、および該プロセスからの描画要求と該ハ
ードウェアイベントを読み出し該描画要求をスケジュー
リングし、その結果発行される描画コマンドを該ローカ
ルプロセッサに転送し、一方該ハードウェアイベントを
該クライアントのプロセスに通知するサーバ手段とを論
理的に構成しているホストコンピュータプロセッサを備
えたデータ処理装置であって、該サーバ手段は該ローカ
ルプロセッサの描画コマンド処理状態を調べ、未処理コ
マンド数が値を上回っているとき、該ハードウェアイベ
ントの読み出しおよび該クライアントのプロセスへの通
知を所定の期間行なわず、その後にハードウェアイベン
トキューに蓄積された複数の指示装置移動イベントを一
つの指示装置移動イベントに変換して該クライアントの
プロセスに通知していることを特徴とするデータ処理装
置。 - 【請求項１６】 前記ディスプレイが強誘電体液晶パネ
ルディスプレイである請求項１５に記載のデータ処理装
置。 - 【請求項１７】 前記サーバが、該ディスプレイ上にマ
ルチウィンドウを形成する描画コマンドを該ローカルプ
ロセッサに提供しているものである請求項１５に記載の
データ処理装置。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP3207274A JP3002302B2 (ja) | 1991-07-25 | 1991-07-25 | データ処理装置 |
| EP92306722A EP0526098B1 (en) | 1991-07-25 | 1992-07-23 | Picture draw command scheduling in multitasking data processing apparatus |
| DE69228152T DE69228152T2 (de) | 1991-07-25 | 1992-07-23 | Ablauffolgeplanung von Zeichenbefehlen in einem multitasking Datenverarbeitungssystem |
| AT92306722T ATE175791T1 (de) | 1991-07-25 | 1992-07-23 | Ablauffolgeplanung von zeichenbefehlen in einem multitasking datenverarbeitungssystem |
| US08/434,983 US5642509A (en) | 1991-07-25 | 1995-05-04 | Data processing apparatus with event notification and picture drawing scheduling |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP3207274A JP3002302B2 (ja) | 1991-07-25 | 1991-07-25 | データ処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH0535835A JPH0535835A (ja) | 1993-02-12 |
| JP3002302B2 true JP3002302B2 (ja) | 2000-01-24 |
Family
ID=16537083
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP3207274A Expired - Fee Related JP3002302B2 (ja) | 1991-07-25 | 1991-07-25 | データ処理装置 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5642509A (ja) |
| EP (1) | EP0526098B1 (ja) |
| JP (1) | JP3002302B2 (ja) |
| AT (1) | ATE175791T1 (ja) |
| DE (1) | DE69228152T2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102557297B (zh) * | 2011-12-31 | 2013-10-02 | 重庆重冶铜业有限公司 | 一种印刷电路板铜镀层清洗后的废液的处理方法 |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5848418A (en) * | 1997-02-19 | 1998-12-08 | Watchsoft, Inc. | Electronic file analyzer and selector |
| US6633313B1 (en) * | 1997-05-08 | 2003-10-14 | Apple Computer, Inc. | Event routing mechanism in a computer system |
| US6185639B1 (en) * | 1998-06-05 | 2001-02-06 | International Business Machines Corporation | System and method to reduce a computer system's interrupt processing overhead |
| US6823523B1 (en) * | 1999-07-29 | 2004-11-23 | International Business Machines Corporations | Process and system for blocking unnecessary callbacks to empty paint methods of graphical user interface components |
| US7234144B2 (en) * | 2002-01-04 | 2007-06-19 | Microsoft Corporation | Methods and system for managing computational resources of a coprocessor in a computing system |
| US7962552B2 (en) * | 2005-11-14 | 2011-06-14 | Red Hat, Inc. | Borrow and give back of windows |
| US9049176B2 (en) | 2011-06-22 | 2015-06-02 | Dropbox, Inc. | File sharing via link generation |
| WO2013084728A1 (ja) * | 2011-12-07 | 2013-06-13 | 三菱電機株式会社 | 制御装置及びリモコン装置 |
| DE112013001051T5 (de) * | 2012-02-20 | 2014-12-11 | Mitsubishi Electric Corp. | Grafikdatenverarbeitungsgerät und Grafikdatenverarbeitungssystem |
| TWI516982B (zh) * | 2014-04-22 | 2016-01-11 | 晨星半導體股份有限公司 | 計算裝置及計算裝置之處理安全服務之方法 |
| CN114153364A (zh) * | 2021-11-30 | 2022-03-08 | 联想(北京)有限公司 | 一种数据处理方法、装置及电子设备 |
| CN114359025B (zh) * | 2022-01-10 | 2023-05-02 | 成都智元汇信息技术股份有限公司 | 一种图片分流调度到中心的方法、边缘识图盒子及*** |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4367924A (en) * | 1980-01-08 | 1983-01-11 | Clark Noel A | Chiral smectic C or H liquid crystal electro-optical device |
| US4655561A (en) * | 1983-04-19 | 1987-04-07 | Canon Kabushiki Kaisha | Method of driving optical modulation device using ferroelectric liquid crystal |
| GB2226432B (en) * | 1988-12-22 | 1993-02-03 | Sun Microsystems Inc | Memory mapped mouse. |
| JPH02242418A (ja) * | 1989-03-16 | 1990-09-26 | Fuji Xerox Co Ltd | カーソルの移動量変更装置 |
| US5146558A (en) * | 1990-01-19 | 1992-09-08 | Canon Kabushiki Kaisha | Data processing system and apparatus |
| US5253340A (en) * | 1990-01-19 | 1993-10-12 | Canon Kabushiki Kaisha | Data processing apparatus having a graphics device with priority scheduling of drawing requests |
| US5305454A (en) * | 1991-08-12 | 1994-04-19 | International Business Machines Corporation | Notification of event handlers in broadcast or propagation mode by event management services in a computer system |
| US5438659A (en) * | 1992-10-08 | 1995-08-01 | Hewlett-Packard Company | Object-action user interface management system |
-
1991
- 1991-07-25 JP JP3207274A patent/JP3002302B2/ja not_active Expired - Fee Related
-
1992
- 1992-07-23 DE DE69228152T patent/DE69228152T2/de not_active Expired - Fee Related
- 1992-07-23 EP EP92306722A patent/EP0526098B1/en not_active Expired - Lifetime
- 1992-07-23 AT AT92306722T patent/ATE175791T1/de active
-
1995
- 1995-05-04 US US08/434,983 patent/US5642509A/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102557297B (zh) * | 2011-12-31 | 2013-10-02 | 重庆重冶铜业有限公司 | 一种印刷电路板铜镀层清洗后的废液的处理方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH0535835A (ja) | 1993-02-12 |
| EP0526098A2 (en) | 1993-02-03 |
| EP0526098A3 (en) | 1993-07-14 |
| DE69228152D1 (de) | 1999-02-25 |
| EP0526098B1 (en) | 1999-01-13 |
| US5642509A (en) | 1997-06-24 |
| ATE175791T1 (de) | 1999-01-15 |
| DE69228152T2 (de) | 1999-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3002302B2 (ja) | データ処理装置 | |
| EP0438152B1 (en) | Data processing apparatus with display device | |
| US5481274A (en) | Display control device | |
| US5253340A (en) | Data processing apparatus having a graphics device with priority scheduling of drawing requests | |
| JPS6329290B2 (ja) | ||
| KR940001109B1 (ko) | 정보처리장치 및 디스플레이 시스템 | |
| EP0312720A2 (en) | Double buffered graphics design system | |
| US5446840A (en) | System and methods for optimized screen writing | |
| JP3245229B2 (ja) | 表示制御装置および表示制御方法 | |
| US5812150A (en) | Device synchronization on a graphics accelerator | |
| JP3245230B2 (ja) | 表示制御装置および表示制御方法 | |
| JPH09179713A (ja) | ウィンドウ表示方式及びデータ処理システム | |
| JPH07199889A (ja) | 表示制御装置 | |
| JP3227200B2 (ja) | 表示制御装置及び方法 | |
| JP2633032B2 (ja) | 情報処理システム及び装置 | |
| JP3264520B2 (ja) | 表示制御装置 | |
| JP2729049B2 (ja) | 表示装置 | |
| JP2770961B2 (ja) | 情報処理装置 | |
| JP3109892B2 (ja) | 表示制御装置及び方法 | |
| JP3140803B2 (ja) | 表示制御装置および表示制御方法 | |
| JP2801218B2 (ja) | 表示装置 | |
| JP3229341B2 (ja) | 表示制御装置および表示制御方法 | |
| JPH08123651A (ja) | マルチウィンドウディスプレイ装置 | |
| JP3262361B2 (ja) | 表示制御装置及び方法 | |
| JPH03189723A (ja) | Ｃｒｔコントローラ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |