(57)【特許請求の範囲】
【請求項１】
所定の描画命令に基づく画像データを送信する送信装置と、前記送信装置から受信した画像データをパネル上に表示する受信側モニタと、を含む画像表示システムであって、
前記送信装置は、
前記描画命令によって画面上に変化が発生した領域を検出する領域検出手段と、
前記領域検出手段により検出された領域に基づいて送信すべき送信領域を算出する送信領域算出手段と、
前記送信領域算出手段により算出された前記送信領域をフレームメモリの表示エリアに、当該送信領域の制御情報を当該フレームメモリの非表示エリアにそれぞれ格納し、当該表示エリアから当該送信領域を、当該非表示エリアから当該制御情報をそれぞれ読み出してこれらをパケットに含めて送信するパケット送信手段と、を備え、
前記受信側モニタは、
前記送信装置から送信されたパケットから前記制御情報を解析する解析手段と、
前記解析手段により解析された制御情報に基づいて画像データを展開するフレームメモリと、
前記フレームメモリに展開された画像データを前記パネル上に表示する表示手段と、
を含むことを特徴とする画像表示システム。
【請求項２】
前記パケット送信手段は、前記制御情報からなるヘッダ情報を前記送信領域に付加して前記パケットとして前記受信側モニタに送信することを特徴とする請求項１記載の画像表示システム。
【請求項３】
前記パケット送信手段は、画面上に変化が発生したこととは別に、同一画面情報を含むパケットを繰り返し送信することを特徴とする請求項１記載の画像表示システム。
【請求項４】
ＯＳ(Operating Systems)またはアプリケーションからの描画命令を解析して描画が発生した領域を検出する描画領域検出手段と、
前記描画領域検出手段により検出された領域に基づいてモニタに対して送信すべき矩形領域を算出する矩形領域算出手段と、
前記矩形領域算出手段により算出された前記矩形領域を含めてパケットとして送信すると共に、当該矩形領域の制御情報をヘッダ情報として当該パケットに含めて送信するパケット送信手段と、
を備え、
前記パケット送信手段は、フレームメモリに描画された画像データを読み出して送信するグラフィックスカードの備えるハードウェアパンニング機能において、マウスカーソルのある場所を基準とした領域を切り出すのに代えて、前記矩形領域算出手段により算出された前記矩形領域を切り出すことにより、当該矩形領域だけを送信することを特徴とする画像データ送信装置。
【請求項５】
前記矩形領域算出手段により算出される矩形領域は、複数の領域が変化した際にそれらを包含する領域であることを特徴とする請求項４記載の画像データ送信装置。
【請求項６】
ＯＳまたはアプリケーションからの描画命令を解析して描画が発生した領域を検出する描画領域検出手段と、
前記描画領域検出手段により検出された領域に基づいてモニタに対して送信すべき矩形領域を算出する矩形領域算出手段と、
前記矩形領域算出手段により算出された前記矩形領域を含めてパケットとして送信すると共に、当該矩形領域の制御情報をヘッダ情報として当該パケットに含めて送信するパケット送信手段と、
を備え、
前記パケット送信手段は、フレームメモリに描画された画像データを読み出して送信するグラフィックスカードの備えるハードウェアカーソル機能において、当該フレームメモリの非表示エリアにカーソルデータを保存するのに代えて、前記制御情報を保存することにより、当該制御情報と前記矩形領域とをパケットに含めて送信することを特徴とする画像データ送信装置。
【請求項７】
前記矩形領域算出手段により算出される矩形領域は、複数の領域が変化した際にそれらを包含する領域であることを特徴とする請求項６記載の画像データ送信装置。
【請求項８】
ＯＳまたはアプリケーションからの描画命令を解析して描画が発生した領域を検出する描画命令解析装置と、
前記描画命令解析装置から出力される描画命令および制御命令を受けて受信側モニタに対して画像データを送信するグラフィックスカードと、を備え、
前記描画命令解析装置は、
ＯＳまたはアプリケーションからの前記描画命令によって画面上に変化があったか否かを判断し、画面上に変化があった場合に描画情報を出力する描画命令解析部と、
前記描画命令解析部により出力される描画情報に基づいて送信すべきエリア情報を出力する送信領域制御部と、
前記送信領域制御部からの前記エリア情報と前記描画命令とに基づいて、前記グラフィックスカードに対して描画命令および制御情報を出力するグラフィックスドライバと、を備え、
前記グラフィックスカードは、
フレームメモリと、
前記フレームメモリに対して画像を展開する描画エンジンと、
前記フレームメモリに展開された画像情報と当該フレームメモリの非表示エリアに展開された制御情報とを合成して前記受信側モニタに対して送信するコントローラと、を備えたことを特徴とする画像データ送信装置。
【請求項９】
所定の描画命令に基づいて、受信側モニタに対して画像データを送信する画像データ送信装置であって、
前記描画命令によって変化領域があるか否かを判断すると共に、解析された当該変化領域を含む送信すべき送信領域を算出し、算出された当該送信領域に対するエリア情報制御コントローラの制御情報と描画命令とを出力する描画命令解析装置と、
前記描画命令解析装置から出力される描画命令に基づいてフレームメモリに対して描画すると共に、前記エリア情報制御コントローラの制御情報に基づいて前記受信側モニタに対して送出すべき領域を前記フレームメモリから読み出して出力するグラフィックスカードと、を備え、
前記グラフィックスカードは、送信すべき前記領域に関するヘッダ情報を前記フレームメモリの画像データを格納しない非表示エリアに格納し、当該領域に含まれる画像データの出力に際して、当該非表示エリアから当該ヘッダ情報を読み出し、当該領域に含まれる画像データに当該ヘッダ情報を付加して出力することを特徴とする画像データ送信装置。
【請求項１０】
前記描画命令解析装置は、所定の割り込み信号の入力に基づいて前記エリア情報制御コントローラの制御情報を出力することを特徴とする請求項９記載の画像データ送信装置。
【請求項１１】
前記所定の割り込み信号は、垂直同期信号であることを特徴とする請求項１０記載の画像データ送信装置。
【請求項１２】
ＯＳまたはアプリケーションにて描画が発生した変化領域を検出し、
検出された当該変化領域に対応した送信領域を算出し、
算出された前記送信領域に含まれる画像データをフレームメモリの表示エリアに格納すると共に当該送信領域の制御情報を当該フレームメモリの非表示エリアに格納し、
前記画像データを前記表示エリアから読み出すと共に前記制御情報を前記非表示エリアから読み出し、
前記表示エリアから読み出された前記画像データと共に前記非表示エリアから読み出された前記制御情報を含めたパケットを生成し、
生成された前記パケットをモニタ側に送信することを特徴とする表示画像データ送信方法。
【請求項１３】
前記パケットに含まれる前記制御情報は、前記送信領域の位置および大きさを示す情報を含み、前記非表示エリアに対してヘッダデータとして格納されることを特徴とする請求項１２記載の表示画像データ送信方法。
【請求項１４】
算出される送信領域に対して前記変化領域の特徴をもとに表示優先度を決定し、
決定された前記表示優先度に基づいて、生成された前記パケットを前記モニタ側に送信することを特徴とする請求項１２記載の表示画像データ送信方法。
【請求項１５】
ＯＳまたはアプリケーションにて描画が発生した変化領域を検出し、
検出された当該変化領域に対応した送信領域を算出し、
算出された前記送信領域に含まれる画像データと共に当該送信領域の制御情報を含めたパケットを生成し、
算出された送信領域に対して前記変化領域の特徴をもとに表示優先度を決定し、
決定された前記表示優先度に基づいて、生成された前記パケットをモニタ側に送信し、
表示優先度の低い送信領域に対しては、全画面更新で行われる全画面更新モードによって送信を行うことを特徴とする表示画像データ送信方法。
【請求項１６】
ＯＳまたはアプリケーションからの描画命令に基づいてフレームメモリに対して描画をさせ、
描画が発生した変化領域を前記描画命令に基づいて検出し、
モニタ側に送信すべき矩形領域を前記変化領域に応じて算出し、
グラフィックスカードのハードウェアパンニング機能によって領域を切り出すためのエリア情報として、マウスカーソルのある場所を基準としたエリア情報に代えて、前記モニタ側に送信する描画データを読み出すエリア情報を、所定の割り込み信号にあわせて出力することを特徴とする差分転送方法。
【請求項１７】
描画により変更された領域を含む矩形領域の画像データをフレームメモリの表示エリアから読み出し、
前記フレームメモリの非表示エリアから前記矩形領域の位置情報を含むヘッダデータを読み出し、
前記表示エリアから読み出された前記画像データと、前記非表示エリアから読み出された前記ヘッダデータとを合成して出力することを特徴とする差分転送方法。
【請求項１８】
コンピュータに、
ＯＳまたはアプリケーションからの描画命令を受けて描画が発生した領域を検出させる描画命令解析機能と、
前記描画命令解析機能により検出された領域に基づいて送信領域を算出する送信領域算出機能と、
前記描画命令解析機能により検出された領域の優先度に基づく表示優先度に基づいて、前記送信領域算出機能により算出された前記送信領域の送信順序を決定する送信順序決定機能と、
フレームメモリから画像データを読み出して送信するためのコントローラに与える制御情報を前記送信順序決定機能により決定された送信順序に基づいて出力する送信領域制御機能と、
前記送信順序が後の方の送信領域に対しては、全画面更新で行われる全画面更新モードによって送信を行う全画面更新モード送信機能と
を実現させるためのプログラム。
【請求項１９】
前記送信領域算出機能は、前記描画命令解析機能により検出された複数の領域をまとめて１つの送信領域を算出することを特徴とする請求項１８記載のプログラム。
【請求項２０】
コンピュータに、
描画により変更された領域を含む矩形領域の画像データをフレームメモリの表示エリアから読み出す機能と、
前記フレームメモリの非表示エリアから前記矩形領域の位置情報を含むヘッダデータを読み出す機能と、
前記表示エリアから読み出された前記画像データと、前記非表示エリアから読み出された前記ヘッダデータとを合成して出力する機能と、
を実現させるためのプログラム。
【請求項２１】
コンピュータに実行させるプログラムを当該コンピュータが読み取り可能に記憶した記憶媒体であって、
前記プログラムは、
ＯＳまたはアプリケーションからの描画命令を受けて描画が発生した領域を検出させる処理と、
検出された領域に基づいて送信領域を算出する処理と、
検出された領域の優先度に基づく表示優先度に基づいて、算出された前記送信領域の送信順序を決定する処理と、
フレームメモリから画像データを読み出して送信するためのコントローラに与える制御情報を前記送信順序に基づいて出力する処理と、
前記送信順序が後の方の送信領域に対しては、全画面更新で行われる全画面更新モードによって送信を行う処理と、を前記コンピュータに実行させることを特徴とする記憶媒体。
【請求項２２】
コンピュータに実行させるプログラムを当該コンピュータが読み取り可能に記憶した記憶媒体であって、
前記プログラムは、
描画により変更された領域を含む矩形領域の画像データをフレームメモリの表示エリアから読み出す処理と、
前記フレームメモリの非表示エリアから前記矩形領域の位置情報を含むヘッダデータを読み出す処理と、
前記表示エリアから読み出された前記画像データと、前記非表示エリアから読み出された前記ヘッダデータとを合成して出力する処理と、を前記コンピュータに実行させることを特徴とする記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ディスプレイパネルに画像を表示する際の画像転送システム等に係り、より詳しくは、小規模な変更により、高精細化、高画質化されたディスプレイパネルに対する画像表示を可能とする画像転送システム等に関する。
【０００２】
【従来の技術】
画像を表示するための画像データは、パーソナルコンピュータ(ＰＣ)等からなるホスト装置のグラフィックスコントローラにより処理されて表示装置に送られるのが一般的である。これまでのモニタ(パネル)の主流であるＣＲＴでは、実現可能な画面サイズは高性能なものでＵＸＧＡ(Ultra Extended Graphics Array)(1600×1200ドット)程度であった。この画面サイズであれば、既存のラスタ形式で構成される画像を出力するグラフィックスコントローラでも容易に表示が可能であり、画像データの転送に必要となるモニタケーブルも１本で十分であった。
【０００３】
一方、近年の液晶表示ディスプレイ(ＬＣＤ)に代表される表示装置の進歩により、ホスト装置と表示装置との処理能力に大きな差が出てきている。例えば、ＬＣＤにおいては、パネル自身の高精細化が進み、ＱＸＧＡ(Quad Extended Graphics Array)(2048×1536ドット)を超える大型高精細モニタ(パネル)、例えば、ＱＳＸＧＡ(Quad Super Extended Graphics Array)(2560×2048ドット)、ＱＵＸＧＡ(Quad Ultra Extended Graphics Array)(3200×2400ドット)などの解像度が非常に大きな高精細(超高精細)モニタが実用化されつつある。しかし、モニタの進歩に対してシステムパワーやグラフィックスコントローラのパワーが追従できなくなってきており、超高精細モニタでの充分な表示ができないのが現状である。即ち、現在、入手可能で今後も採用されるであろうラスタ転送方式のグラフィックスカードとモニタケーブル１組からなる既存のグラフィックスシステムでは、これらのモニタを駆動することは困難である。
【０００４】
【発明が解決しようとする課題】
ここで、大型高精細モニタを駆動する方法として、グラフィックスカードとケーブルを複数組用意し、モニタ自体のみならず、ＯＳまたはドライバにも変更を施して、もともと１枚のラスタ入力パネルを複数枚のラスタ入力パネルとして扱う方式が考えられる。しかしながら、このような方式では、ＰＣに搭載可能なグラフィックスカードの枚数に物理的な制約が生じてしまい、また、個々のグラフィックスカードに搭載された描画エンジン同士を同期させて動作させることが難しい。その結果、動画に対する全画面表示はもとより、ＤＴＰ(Desk Top Publishing)等の限られた利用用途であっても、十分な画像品質を実現することは困難である。また、画像品質の問題もさることながら、システム構築のためにＯＳベンダーを始め、グラフィックスメーカやモニタメーカ、ユーザに対して高額の投資を要求することとなる。
【０００５】
一方で、高精細パネル自身に、または、高精細パネルとホスト装置との間に置かられるモニタ接続装置に、フレームメモリを置く方法が検討されている。このフレームメモリをモニタ側に置くことによって、一部の描画コマンドはホスト側では処理せずに、画像展開前の画像データをモニタ側に転送し、モニタ側にて解釈して描画が実行されることで、データ転送量を削減することが可能となる。例えば、ネットワーク上にて、ＰＣと同様な中央演算処理、通信装置、描画装置を備えるクライアントモニタを接続し、サーバ上で実行したアプリケーションの実行結果をこのクライアントモニタに出力するシステムが検討されている。このシステムでは、ネットワークである通信路上を流れるデータ量を大幅に削減することができることから、通信路にイーサネットを選択することが可能となる。
【０００６】
このように、モニタ側にフレームメモリを持つことで、ホスト側における機能を大幅に向上させない場合でも高精細パネルへの表示が可能となるが、現在、考えられている技術では、モニタ側に通常のＰＣと同水準の機能が要求されている。そのために、モニタ側に要求される高機能(ＰＣと同水準の機能)を低減することができれば、コストを大幅に削減することが可能となる。特に、現状採用されているラスタ方式のモニタとの互換性を保ち、既存のラスタ転送方式のグラフィックスシステムを利用できれば、高額の追加投資を行うことなく、簡単に高精細パネルを駆動でき、大型高精細パネルを広く普及させることも期待できる。
【０００７】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、既存のシステムに対して極めて小規模の変更を加えるだけで、大型高精細モニタ(パネル)を駆動することにある。
また他の目的は、限られた転送バンド幅の範囲で、これまでにサポートできなかった大型高精細モニタを駆動することにある。
【０００８】
【課題を解決するための手段】
かかる目的を達成するために、本発明は、画像受信側である受信側モニタにフレームメモリを内蔵し、送信側(ＰＣ側)では差分情報のみを送るという差分転送方式を応用している。即ち、本発明が適用される画像表示システムは、ＯＳやアプリケーション等の所定の描画命令に基づく画像データを送信する送信装置と、受信した画像データを高精細パネル上に表示する受信側モニタとを含み、この送信装置は、描画命令によって画面上に変化が発生した領域を領域検出手段にて検出し、検出された領域に基づいて送信すべき送信領域を送信領域算出手段によって算出し、パケット送信手段によって、算出された送信領域を含めてパケットとして送信すると共に、例えば、ヘッダ情報(ヘッダデータ)の形で送信領域の制御情報をこのパケットに含めて送信している。また、受信側モニタは、送信されたパケットから制御情報を解析する解析手段と、解析された制御情報に基づいて画像データを展開するフレームメモリと、このフレームメモリに展開された画像データを高精細パネル上に表示する表示手段を備えている。
【０００９】
ここで、このパケット送信手段は、画面上に変化が発生したこととは別に、同一画面情報を含むパケットを繰り返し送信するように構成することができる。例えば、描画命令の有無に関わらず、定期的に画面を送出するように構成すれば、転送エラーに対する回復が可能となる点で好ましい。
【００１０】
また、本発明が適用される画像データ送信装置は、ＯＳまたはアプリケーションからの描画命令を解析して描画が発生した領域を検出する描画領域検出手段と、検出された領域に基づいてモニタに対して送信すべき矩形領域を算出する矩形領域算出手段と、算出された矩形領域を含めてパケットとして送信すると共に、この矩形領域の制御情報をヘッダ情報としてパケットに含めて送信するパケット送信手段とを備えたことを特徴としている。
【００１１】
この矩形領域算出手段により算出される矩形領域は、複数の領域が変化した際にそれらを包含する領域であることを特徴とすれば、送信領域変更時のオーバーヘッドを軽減することができる点で優れている。また、表示優先度を決定し、優先度の高いものを先に送信し、優先度の低いものを、例えば全画面更新を行う全画面更新モード時だけに送信することもできる。
【００１２】
ここで、このパケット送信手段は、フレームメモリに描画された画像データを読み出して送信するグラフィックスカードの備えるハードウェアパンニング機能を流用し、矩形領域算出手段により算出された矩形領域だけを送信することができる。このハードウェアパンニング機能では、フレームメモリの特定の位置からデータを読み出すためのコントローラ(ＣＲＴコントローラ)の設定を変更することができる。
【００１３】
また、グラフィックスカードの備えるハードウェアカーソル機能を流用し、制御情報と矩形領域とをパケットに含めて送信することができる。このハードウェアカーソル機能は、フレームメモリ上の非表示エリアにカーソルデータを保存し、画像データを読み出す際に読み出されて合成する機能であり、本発明では、このカーソルデータの代わりに、ヘッダデータ等の制御情報を記述するように構成している。
【００１４】
他の観点から把えると、本発明が適用される画像データ送信装置は、描画命令を解析して描画が発生した領域を検出する描画命令解析装置と、受信側モニタに対して画像データを送信するグラフィックスカードとを備えている。この描画命令解析装置では、描画命令解析部からは、描画命令によって画面上に変化があったか否かが判断されて描画情報が出力され、この出力を受けた送信領域制御部からは、送信すべきエリア情報が出力され、グラフィックスドライバからグラフィックスカードに対して、これらの情報に基づく、描画命令および制御情報が出力される。
【００１５】
一方、グラフィックスカードは、フレームメモリと、このフレームメモリに対して画像を展開する描画エンジンと、フレームメモリに展開された画像情報を受信側モニタに対して送信するコントローラとを備え、このコントローラからは、グラフィックスドライバから出力された制御情報に基づいてフレームメモリから画像データを読み出し、エリア情報に対応する領域にある画像データを受信側モニタに対して送信している。
【００１６】
本発明が適用される画像表示装置は、受信したパケットからヘッダデータを取り出すパケット解析部と、取り出されたヘッダデータに基づいて、フレームメモリに画像データが書き込まれる位置を認識するヘッダ解析部と、解析された位置に対して画像データが書き込まれたフレームメモリから画像データを読み出してパネルに表示させるパネルコントローラとを備えたことを特徴としている。
ここで、このパネルは、ラスタ形式の画像データを表示する際に、送信装置からパケットが伝送されるケーブルのデータ転送量を超えてしまい表示品質を低下させなければならなくなる高精細パネルであること(例えば、ＤＶＩ(Digital Visual Interface)ケーブルに対してＱＸＧＡ(Quad Extended Graphics Array)(2048×1536ドット)サイズを超えるパネルであること)を特徴とすることができる。
【００１７】
一方、本発明は、コンピュータに所定の機能を実現させるためのプログラムとして把握することができる。この機能としては、例えば、描画命令を受けて描画が発生した領域を検出させる描画命令解析機能、送信領域を算出する送信領域算出機能、
フレームメモリから画像データを読み出して送信するためのコントローラに与える制御情報を算出された送信領域に基づいて出力する送信領域制御機能が挙げられる。
また、描画により変更された領域を含む矩形領域の画像データをフレームメモリの表示エリアから読み出す機能、フレームメモリの非表示エリアから矩形領域の位置情報を含むヘッダデータを読み出す機能、表示エリアから読み出された画像データと、非表示エリアから読み出されたヘッダデータとを合成して出力する機能とを実現させるためのプログラムとして把握することもできる。
【００１８】
これらのコンピュータプログラムは、例えば、プログラム伝送装置からネットワークを介して、画像データ送信装置であるＰＣ等に対して提供することができる。このプログラム伝送装置としては、上記したようなプログラムを記憶させたＣＤ−ＲＯＭ、ＤＶＤ、メモリ、ハードディスク等の記憶手段と、これらの記憶手段からプログラムを読み出し、プログラムを実行する装置側に、コネクタ、インターネットやＬＡＮ等のネットワークを介して伝送する伝送手段とを備える構成とすれば良い。
また、上述したようなコンピュータプログラムは、例えば、ＣＤ−ＲＯＭ、ＤＶＤ等の記憶媒体を介して、直接、ＰＣ等に対して提供するように構成することができる。この記憶媒体には、コンピュータに実行させるこれらのプログラムをコンピュータが読み取り可能に記憶されていれば良い。
【００１９】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
図１は、本実施の形態が適用される画像表示システムの全体構成を説明するための図である。本実施の形態における画像表示システムは、ＰＣ等からなるホスト側(送信側)として画像データの送信装置１０と、画像表示装置である受信側モニタ４０とを備え、この送信装置１０と受信側モニタ４０とは、ＤＶＩ(Digital Visual Interface)ケーブル等のデジタルモニタケーブルである既存のモニタケーブル３９によって接続されている。尚、この送信装置１０と受信側モニタ４０とは、別々の筐体で構成されて外部に出るモニタケーブル３９によって接続される場合の他、１つの筐体の中に含まれてコンピュータ装置や画像表示装置を構成する場合もある。
【００２０】
送信装置１０は、一般的なＰＣとして、図示しない中央処理装置、メモリ、ＨＤＤ等を備えている。また、一般的なＰＣにて用いられているＯＳ(Operating Systems)またはアプリケーションであるＯＳ/アプリケーション１１と、一般的なハード構成であるグラフィックスカード１２、及び、本実施の形態における特徴的な構成である描画命令解析装置２０を備えている。本実施の形態における送信装置１０は、変化した領域を抽出する機能と、変化した領域に該当する部分のデータと画像制御情報を含むヘッダ情報を送信する機能とを備えている。
【００２１】
このＯＳ/アプリケーション１１から描画命令解析装置２０に対して、割り込み信号と共に、描画用ＡＰＩ(Application Program Interface)からなる描画命令が出力され、描画命令解析装置２０では、受け取った描画命令の解析がなされる。また、グラフィックスカード１２から描画命令解析装置２０に対して、例えば、垂直同期信号(VSYNC)に基づく割り込み信号が出力される。更に、描画命令解析装置２０からグラフィックスカード１２に対しては、描画命令と共に、所定の制御情報からなる制御命令が出力され、グラフィックスカード１２は、これらの命令を受けて、受信側モニタ４０に対して画像データを送信している。
【００２２】
このグラフィックスカード１２は、描画がなされるフレームメモリ１３、ハードウェアパンニング機能１４、ハードウェアカーソル機能１５を備えている。このハードウェアパンニング機能１４は、本来、モニタの表示可能サイズよりも大きな画面を仮想的に表示するために利用されており、マウスカーソルのある場所に対して、その場所をスタートとして切り出す機能である。本実施の形態では、かかる機能を流用している。即ち、ハードウェアパンニング機能１４では、フレームメモリ１３からどの領域を出力するかを決定しており、描画命令解析装置２０からの指示に基づいて、例えば、送出されるエリア情報(開始位置、サイズ等)を制御するＣＲＴＣの設定を垂直同期に合わせて毎回、変更し、送信したい矩形領域のみを出力している。尚、この変更するタイミングは、必ずしも垂直同期に合わせる必要はなく、例えば水平同期や他の割り込み信号等によることが可能である。
【００２３】
また、ハードウェアカーソル機能１５は、フレームメモリ１３上の非表示エリアにカーソルデータを保存しておき、ＣＲＴＣ(ＣＲＴコントローラ)がフレームメモリ１３から画像を読み出す際に画像データとカーソルデータとを合成して出力する機能である。本実施の形態では、描画命令解析装置２０からの指示に基づいて、このカーソルデータの代わりに、ヘッダ情報を記述するように構成した。この結果、受信側モニタ４０が受け取る画像には、ヘッダが付加されているが、そのために、フレームメモリ１３内のデータを改変する必要がない。尚、カーソルの表示は、ソフトウェアにて実現される。
【００２４】
一方、受信側モニタ４０は、例えば、ＱＵＸＧＡ等の大型高精細パネルであるパネル４１と、送信装置１０からモニタケーブル３９を介して画像データを受信するパケット受信装置５０を備えている。このパケット受信装置５０からパネル４１に対しては、ラスタ形式に変換された画像データが出力される。本実施の形態が適用される受信側モニタ４０は、大型高精細パネルを搭載したモニタとして、受信データに付加された制御情報を解析する機能と、画像をパネルに表示する機能とを備えたものである。
【００２５】
図２は、本実施の形態の理解を容易にするために、本実施の形態が適用される画像表示システムの主要な処理を示したフローチャートである。まず、画像を送信する側である送信装置１０で描画が発生した領域の検出がなされる(ステップ１０１)。次に、送信装置１０にて、検出された領域をもとに、送信すべき矩形が算出される(ステップ１０２)。その後、送信装置１０では、矩形を示す制御情報(位置・サイズ等)が、例えば、パケットのヘッダとして、パケットに付与されて送信される(ステップ１０３)。一方、受信側モニタ４０では、パケットを受信し、付与されている制御情報を抽出する(ステップ１０４)。そして、抽出された制御情報をもとに、送信側モニタ４０内のフレームメモリ上のデータを更新する(ステップ１０５)。その後、パネル４１上に画像が表示される(ステップ１０６)。このような一連の処理を実行するに際し、本実施の形態にて採用された構成を、以下に説明する。
【００２６】
図３は、本実施の形態における描画命令解析装置２０を説明するための図である。この描画命令解析装置２０は、例えば、ソフトウェアモジュールとして送信装置１０にインストールされ、送信装置１０のハードウェア資源等を用いて実行される。本実施の形態における描画命令解析装置２０は、ＯＳ/アプリケーション１１から送られてきた描画命令(描画用ＡＰＩ)を解析し、描画の結果、フレームメモリ１３のどの位置に描画するかを算出する描画命令解析部２１を備え、描画命令解析部２１から送られる描画情報を格納する描画情報ＤＢ(データベース)２２を備えている。また、割り込み信号が入力された際に、描画情報ＤＢ２２から描画情報を取得し、ＣＲＴＣ(ＣＲＴコントロール)の制御情報を算出する送信領域制御部２３を備えている。この送信領域制御部２３にて算出された制御情報はグラフィックスドライバ２４に送出される。また、所定の情報が描画情報ＤＢ２２にフィードバックされる。グラフィックスドライバ２４は、受け取った各種の情報をもとに、描画命令と制御情報とをグラフィックスカード１２に送信している。
【００２７】
グラフィックスカード１２は、グラフィックスドライバ２４からの描画命令を受けてフレームメモリ１３に描画を実行する描画エンジン１７、フレームメモリ１３に描画された描画データを読み出し、受信側モニタ４０に対して送信されるエリア情報を制御するＣＲＴＣ１８を備えている。グラフィックスカード１２では、これらの各構成にて、グラフィックスドライバ２４からの描画命令および制御情報を受けて、前述したハードウェアパンニング機能１４およびハードウェアカーソル機能１５を実現している。
【００２８】
図４は、図３にて説明した描画命令解析部２１における処理を示したフローチャートである。描画命令である描画用ＡＰＩを受信した後(ステップ２０１)、描画命令解析部２１では、描画命令の種類の分類が実行される(ステップ２０２)。ここで、この描画命令が、初期化命令など、描画に直接関連する命令以外の命令である場合には、ここでの処理は行う必要がなく、処理が終了する(ステップ２０６)。描画に直接関連する命令である場合には、描画により画面上に変化が生じるか否かが判断される(ステップ２０３)。画面上に変化がなければ、新たな描画情報を算出する必要がなく、処理は終了する(ステップ２０６)。画面上に変化があった場合には、変更領域の算出がなされる(ステップ２０４)。その後、描画情報を描画情報ＤＢ２２へ送信して(ステップ２０５)、描画命令解析部２１における処理が終了する(ステップ２０６)。尚、ステップ２０５にて描画情報ＤＢ２２に送信される描画情報は、例えば、描画図形を含む矩形の左上の座標と描画図形の大きさの情報とすることができ、また、矩形の左上の座標情報と他の情報とによって描画情報とすることも可能である。更に、一度に描画不可能なサイズである場合には、送信/未送信領域の情報とすることが可能である。
【００２９】
図５は、図３にて説明した送信領域制御部２３における処理を示したフローチャートである。送信領域制御部２３では、割り込み信号を受信することで処理が開始される(ステップ３０１)。この割り込み信号は、例えば、ＯＳ/アプリケーション１１からのタイマ割り込み・入力割り込みや、グラフィックスカード１２からの水平同期信号(HSYNC)、垂直同期信号(VSYNC)などを使った割り込み信号である。そして、送信領域制御部２３は、描画情報ＤＢ２２より描画情報を取得した後(ステップ３０２)、送信矩形領域の算出処理が実行される(ステップ３０３)。この算出処理は、例えば、複数の未送信領域を包含する矩形の算出である。ここで、一度で送信不可能か否かが判断され(ステップ３０４)、一度で送信不可能である場合には、エリア分割がなされて(ステップ３０５)、ステップ３０３の送信矩形領域の算出に戻る。即ち、本実施の形態では、送りたい矩形の大きさがＣＲＴＣ１８で実現可能なサイズまたはモニタケーブル３９のバンド幅等の要因により送信可能サイズを超えている場合には、一度に送りきらない矩形の分割処理を行うように構成されている。
【００３０】
ステップ３０４にて、一度に送信できる場合には、ＣＲＴＣ制御情報の生成と、グラフィックスドライバ２４への送信が実行される(ステップ３０６)。このとき、ＣＲＴＣ制御情報には、ハードウェアカーソルの制御情報を含む場合もある。そして、送信済/未送信情報のなど、ＣＲＴＣ制御情報を計算した結果として得られた送信領域に関する情報が描画情報ＤＢ２２にフィードバックされ(ステップ３０７)、送信領域制御部２３における処理が終了する(ステップ３０８)。
【００３１】
図６は、受信側モニタ４０におけるパケット受信装置５０の構成を示したブロック図である。図６に示すように、パケット受信装置５０は、送信装置１０からモニタケーブル３９を介して受信したパケットをヘッダデータとそれ以外に分離するパケット解析部５１、パケット解析部５１により分離されたヘッダデータを受け取り、フレームメモリ５３のどの位置に画像データ部分を書き込めばよいかを計算(認識)するヘッダ解析部５２、ヘッダ解析部５２からのアドレス(位置)情報に基づき、画像データが書き込まれるフレームメモリ５３、およびフレームメモリ５３から画像データを読み出し、ラスタ形式の画像データとしてパネル４１に送信するパネルコントローラ５４を備えている。
【００３２】
次に、本実施の形態における送受信パケットに関して、パケットデータとその生成方法について説明する。
図７(ａ)〜(ｃ)は、パケットデータの生成方法を説明するための図である。図７(ａ)は、送信装置１０のグラフィックスカード１２におけるフレームメモリ１３の構成を示しており、フレームメモリ１３は、表示エリア１３-１と、非表示エリア１３-２とを備えている。例えば、フレームメモリ全体を６４Ｍバイトとし、画面データが格納される表示エリア１３-１を３６Ｍバイトとした場合に、残りの非表示エリア１３-２は２８Ｍバイトとなる。この表示エリア１３-１には、描画命令解析装置２０により算出された描画により変更された領域を含む矩形が描かれる。また、非表示エリア１３-２には、ヘッダ情報が書き込まれる。図７(ｂ)では、フレームメモリ１３上のスキャン開始位置が１行分前にセットされ、ハードウェアカーソルが元の矩形の左上にセットされた状態を示している。また、図７(ｃ)では、フレームメモリ１３上のイメージとヘッダが合成された送信パケットを示している。
【００３３】
図８(ａ),(ｂ)は、パケットデータを生成する処理を示したフローチャートであり、図８(ａ)は初期設定時の流れを、図８(ｂ)はパケット生成時の流れを示している。
初期設定時では、図８(ａ)に示すように、まず、最初にフレームメモリ１３に対して、領域を１行分、多く確保しておく(ステップ４０１)。そして、ハードウェアカーソル機能１５に関して、グラフィックスカード１２に関しては「有効」、ＯＳ/アプリケーション１１に対しては「無効」であるように初期設定が行われる(ステップ４０２)。即ち、ＯＳ/アプリケーション１１に対しては使えないと報告し、実際には、グラフィックスカード１２にてハードウェアカーソル機能１５を利用するように構成されている。
【００３４】
パケット生成時では、図８(ｂ)に示すように、まず、描画により変化した領域の左上の座標と、変化領域の幅と高さを含む情報とを１行のヘッダデータとして生成する(ステップ４１１、図７の▲１▼参照)。次に、フレームメモリ１３上のハードウェアカーソルのデータを格納する領域にヘッダデータを書き込む(ステップ４１２、図７の▲２▼参照)。そして、ハードウェアカーソルの位置を領域の先頭にあたる場所(0，1)にセットする制御命令をグラフィックスカード１２に送信する(ステップ４１３、図７の▲３▼参照)。また、変化領域よりも１行分前からスキャンを開始するようにＣＲＴＣ１８をプログラムする(ステップ４１４、図７の▲４▼参照)。その後、ＣＲＴＣ１８のスキャンを開始する(ステップ４１５)。そして、ハードウェアカーソル機能１５を利用して、ヘッダとフレームメモリ１３上の画像データを合成する(ステップ４１６、図７の▲５▼参照)。
【００３５】
図９は、パケットのヘッダフォーマットの例を示した図である。本実施の形態におけるパケットヘッダでは、例えば、ヘッダ長を６４ビット(bit)とし、これを６４ピクセル(pixel)の白黒データに変換し、ハードウェアカーソル機能１５を利用して、画像に付加・送信している。例えば、１ピクセルは表示モードにより何ビットか異なり、例えば、フルカラー(３２ビットＲＧＢ)なら１ピクセル＝３２ビットとなる。ここでは、ヘッダビット“０”は黒(１６ビットＲＧＢであれば、"0000000000000000b")に対応し、ヘッダビット”１”は白(１６ビットＲＧＢなら"1111111111111111b")に対応している。このように送信されるヘッダ情報は冗長であることから、受信側モニタ４０で多数決処理などを行うことで、他の画像部分に比べて非常に高いエラー耐性を実現できる。またこの方法は、１ピクセルを表現するためのビット長は変化するものの、表示モードを変更しても常に６４ピクセル分の所定のデータであることには変化がないため、複数の表示モードに対して矛盾なく対応することができる。
【００３６】
図９に示すように、パケットのヘッダ部を構成する要素としては、プロトコルＩＤ、送信矩形の位置(左端の点の座標)、送信矩形の幅、送信矩形の高さ、などの要素がある。図９に示す例では、先頭が０、データ部は６４以降であり、例えば７ビットでプロトコルタイプとバージョンを表すProtocol Type(ProType)、１ビットでビデオデータパケットかコマンドパケットかを示すPacket Type(Pac Type)が格納されている。また、送信矩形の位置としては、例えば、矩形原点(画像開始点)のＸ座標、Ｙ座標がそれぞれ１５ビットであるXPOS,YPOSに格納される。更に、矩形原点ＸＹ座標のフィールドでの単位を示す１ビットであるXY-resolutionに、矩形の幅、高さがそれぞれ８ビットであるWIDTH,HEIGHTに、矩形の幅・高さのフィールドでの単位が１ビットのWH-resolutionに格納されている。また、数ビット(８ビット)で構成されるReservedが確保されている。このようにして、送信パケットのヘッダ部にハードウェアカーソルデータを格納する領域が書き込まれる。
【００３７】
次に、本実施の形態における送信領域の決定方法について説明する。
図３にて説明した描画命令解析装置２０における送信領域制御部２３では、描画情報ＤＢ２２に格納された変化領域のリストから送信領域を決定している。しかしながら、この送信領域の決定は、パネル４１に表示される画像の品質に大きく影響する。本実施の形態では、大きく、「描画結果のまとめ送り」と、「表示優先度に基づく送信順序の変更」の２つの考え方をもとに、送信領域の決定を行っている。
【００３８】
図１０(ａ),(ｂ)は、送信領域の決定方法を説明するための図であり、図１０(ａ)はまとめ送りについて説明し、図１０(ｂ)は表示優先度に基づく送信順序変更を説明している。「描画結果のまとめ送り」では、図１０(ａ)に示すように、第１のＣＲＴＣ設定変更可能期間６１と第２のＣＲＴＣ設定変更可能期間６２との間に、描画命令により変更された複数の領域(６４〜６６)が、１つの送信予定領域６３として送信される。このＣＲＴＣ設定変更可能期間６１,６２は、ＣＲＴＣ１８の設定変更が反映され、ＣＲＴＣ１８のスキャンエリアが変更される期間である。一般に、送信領域を決定するＣＲＴＣプログラミングは、垂直同期の合間などの限られたタイミングでしか行うことができない。そのため、描画コマンドごとに送信するのではなく、ＣＲＴＣプログラミングの回数を最小化するように「描画結果のまとめ送り」を行うことで、システム全体のパフォーマンスの向上を図ることができる。図１０(ａ)に示す例では、領域６４や領域６５だけで送らず、１フレーム表示中に変化した領域６６を含めてまとめ送りが行われる。
【００３９】
また、「表示優先度に基づく送信順序の変更」では、例えば、変化領域の特徴をもとに表示優先度を決定し(例えば、図１０(ｂ)に示すような表示優先度の高い領域７１や表示優先度の低い領域７２)、送信順序を決定している。例えば動画等からなる領域７３は、変更頻度の極めて高い領域であり、利用者が注視していると考えられる。一方で、その変更頻度の高い領域から離れた、例えば時計情報等が表示される領域７６では、意味的に重要でない場合が多い。このように、現在の描画状況やアプリケーションの特徴等から、それぞれの変化領域に対して表示重要度を持たせることが可能である。図１０(ｂ)に示す例では、パネル４１上の表示エリア７０に対する変化領域の特徴をもとに、領域７３〜７５を含む領域を表示優先度の高い領域７１とし、領域７６を含む領域を表示優先度の低い領域７２としている。そのために、図１０(ｂ)では、２(領域７６)よりも後に来た、３(領域７４)、４(領域７５)を先に送信している。この表示重要度をもとに送信順序を変更する処理により、ＣＲＴＣ１８の更新に関するオーバーヘッドを削減することが可能となる。
【００４０】
尚、表示の優先度としては、例えば、
・未描画で残された矩形の中で、古い矩形の優先度を大に、
・最も描画の集中している領域の優先度を大に、
・マウスカーソルのある位置を中心とする領域の優先度を大に、
・アクティブになっているウィンドウがある領域を優先度大に、
といったものが挙げられる。これらの優先度は、利用者が注視していると考えられる領域を高くすることで、意味のある描画に対する適切な表示が可能となる。
【００４１】
更に、本実施の形態では、「表示優先度に基づく送信順序の変更」に伴い、スローリフレッシュ(Slow Reflesh)モードを利用する処理を行っている。この全画面更新モードは、描画命令の実行により描画された領域を動的に検出してＣＲＴＣ１８を設定する通常の方法(通常モードと呼ぶ)とは別に、描画命令の有無に関わらず、定期的に全画面を複数回に分割して送信するようにＣＲＴＣ１８を設定する方法である。例えば、描画命令が発行されず画面上に変化領域がない場合や、変化領域があっても予め設定された適当な時間間隔(例えば１０秒ごと)にて、一時的に通常モードから全画面更新モードに切り換えて全画面を転送するものである。
【００４２】
一般に、通信エラーが発生した場合に、その情報が送信装置１０側に伝わるのはかなりの時間の経過後であり、誤った情報が長時間、表示されることとなる。一方で、モニタケーブル３９の特徴上、受信側モニタ４０から送信装置１０側への通信バンド幅は極めて小さく、速度も極めて遅い。その結果、受信側モニタ４０からの転送結果のフィードバックを常時待つことは現実的ではない。そのために、受信側モニタ４０からのフィードバックがなくともエラーを修正できる仕組みが必要となる。特に、送られた画像がどれくらいの期間、表示されているかは、送信時には不明であることが多く、短期間しか表示されない画像の転送エラーは許容することができても、長時間表示されている画像に対しては、転送エラーを回復する仕組みが必要となる。
【００４３】
本実施の形態では、この全画面更新モードによる処理によって、絶えず変化していて短期間しか表示されていない画像に対しては、多少の転送エラーが生じるが、長時間表示されている画像に関しては、発生したエラーのほとんどを解消することが可能となる。また、ノイズが多い環境下など、エラー率が一定量を超えた場合であっても、この全画面更新モードに切り換えることで、通信エラーに対する対処が可能となる。
【００４４】
次に、変化領域リストから送信領域を決定する方法について更に詳述する。
送信領域を決定する方法には、例えば、以下のようなものがあり、これらは、単独または組み合わせて用いることができる。
１．その時点で未送信な描画領域の全てを包含する１つの矩形領域を次に送信すべき領域とする。その領域が一度に送れるサイズより大きい場合には、分割して複数回に分けて送信する。
２．描画された時間が最も古い領域を含むように(例えば、中心に配置、左上に配置、右上に配置等)送信領域を決定する。一度送信する度に、未送信領域のリストを更新する。
３．描画された時間が最も新しい領域を含むように送信領域を決定する。一度送信する度に、未送信領域のリストを更新する。但し、描画されてから一定時間が経過しても未送信である領域があれば、その領域の送信を優先する。
４．全画面更新モードを持つ実装方式の場合、表示優先度の低い領域に関しては通常モードの送信を行わず、全画面更新モードの実行により自動的に行われる全画面更新処理をもって変化領域の送信完了とする。
５．最も描画領域が集中している領域を送信する。
６．マウスカーソルのある位置を中心とする領域を優先的に送信する。
７．アクティブなウィンドウが配置されている領域を優先的に送信する(Window managerとの連携が必要)。
８．描画領域に関わらず、常に全画面を分割して送信する。
【００４５】
尚、全画面更新モードを備える実装方式では、モード切り換えが発生する時間間隔に関して、所定の検討を必要とする。
一般に、モード切り換えが発生する時間間隔は、
・転送路のエラー発生率
・パネル４１のサイズ
・ＣＲＴＣ１８が一度にスキャン可能な画面サイズ
・動作しているアプリケーションの特徴(描画サイズ、画像更新の頻度)
等の項目を、動的または静的に決定されるものである。例えば動画で、ＣＲＴＣ１８を動かすことなく表示できるサイズであれば、この時間間隔は長くなる。しかし、例えばフォトレタッチ処理など、静止画が主で全画面表示がそれに近い表示を行うような場合には、この時間間隔は極めて短くなる。また、他の構成部分における実装方式により、この時間間隔の補正を行う場合もある。例えば、送信優先度の低い変化領域の更新のために、全画面更新モードを利用する場合には、モード切り換えが発生する時間間隔を通常のものより短く設定するとよい。
【００４６】
以上のように構成することで、本実施の形態では、発生する様々な問題に対して検討を加えている。
まず、第１の問題として、ヘッダ付き矩形画像の送信に関して、特定の矩形情報やコマンドのみを送信装置１０から受信側モニタ４０に送る必要がある。この機能を既存のグラフィックスカード１２に変更を加えることなく実現しなければならない。本実施の形態では、ハードウェアパンニング機能１４を流用することで、該当する矩形領域のみを出力することが可能となる。
【００４７】
また、第２の問題として、ヘッダと画像との同期に関し、画像制御情報をヘッダという形で画像に埋め込む必要がある。このとき、システムのオーバーヘッドを無くし、画像品質を落とすことなく、更には、大規模な追加投資を不要とすることが望ましい。
ソフトウェアによる一般的な解法として、フレームメモリ１３上にある送信予定領域の内部または近辺などにヘッダ情報を予め展開しておき、それを含む形で送信する方法が考えられる。例えば、送信予定領域の１行分前にヘッダ情報を書き込み、送信する矩形を１行だけ余分に送るという方法がある。この方法においては、ヘッダを書き込む前に元画像を保存し、画像送信完了後に再び戻すという処理が必要となる。この処理においては、フレームメモリ１３の使用に関して、ヘッダ情報の書き込みと、描画エンジン１７の書き込みおよび転送とを排他的に行う必要が生じるため、大きなオーバーヘッドとなる。そのため、本方式を採用した場合には、描画時間もしくはデータ送出時間を大幅に低くする必要が生じ、モニタに表示される画像の品質は大幅に悪化してしまう。
【００４８】
また、ヘッダ・画像同期処理をＯＳまたはドライバから容易に行える機能を有する専用ハードウェアを用意することにより、同期の問題を解決する方法が考えられる。しかしながら、この解決法は、グラフィックスカードベンダに対して大幅修正を要求する結果となり、現実的な解決法とは言い得ない。
本実施の形態では、ハードウェアカーソル機能１５を本来の目的とは別に利用することで、フレームメモリ１３内のデータ改変が不要となり、また専用ハードウェアを用意する必要もなく、ヘッダと画像の同期の問題を解決している。
【００４９】
次に、第３の問題として、送信領域変更時に発生するオーバーヘッドの問題がある。例えば、描画コマンドの発生した順に単純に描画された画像ごとに送信領域変更(ＣＲＴＣプログラミング)を行う方法があるが、この方法によると、却って時間がかかってしまい、十分なフレームレートを出すことが出来なくなる。
そこで、本実施の形態では、その解決法として、個々の描画命令を受けた際に、グラフィックスドライバ２４が受ける描画命令をフックし、画面上で影響を受ける領域を算出し、その情報を蓄積するように構成した。例えば、各描画コマンドの描画領域における外接矩形の論理和、もしくはその外接矩形などを蓄積しておく。一方、垂直同期信号による割り込みやタイマなどをトリガとする定期的なタイミングで、蓄積していた情報に基づき最適なＣＲＴＣ１８の位置を決定し、関連するレジスタを設定している。
この結果、いくつかの描画結果は個々に送らずとも1つの矩形で送信できるようになり、ＣＲＴＣ１８をプログラムする際に発生するオーバーヘッドを削減することが可能となる。
【００５０】
また、第４の問題として、描画エンジン１７の描画処理とＣＲＴＣプログラミングによる送信処理との同期を取る必要性が挙げられる。描画命令解析装置２０は、ＯＳ/アプリケーション１１が発行する描画命令を検出し、変化領域を特定する。描画命令はその後グラフィックスカード１２の描画エンジン１７に送られ、フレームメモリ１３上に描画される。その際、通常は描画エンジン１７がどの時点で描画を完了したか知るすべがないため、描画エンジン１７が描画を完了する前にシステムがＣＲＴＣプログラミングを行い、特定領域の画像を送信してしまうことが起こり得る。この場合、送信される画像はなんら意味のないものとなってしまう。
この解決策として、本実施の形態では、描画命令解析装置２０は、描画コマンドを検出すると同時に、一定量ごと(例えば描画コマンド１０個ごと)にフレームメモリ１３上に用意した非表示エリアに描画エンジン１７を使ってシーケンス番号を書き込む。その後、該当エリアのシーケンス番号をフレームメモリ１３から読み込むことによって、発行した描画コマンド列がどこまで終了したかを確認することができる。この結果、描画が完了した範囲のみを送信することを可能としている。
【００５１】
以上、詳述したように、本実施の形態では、変化した領域の抽出を行いこの部分のデータと画像制御情報を含むヘッダ情報を送信できる送信装置１０と、フレームメモリ５３を持ち受信画像を解析・表示することができる受信側モニタ４０からなり、差分転送を基本とする画像表示システムを提供している。これにより、限られた転送バンド幅の範囲で、既存のＰＣ等からなる送信装置１０に対して、例えば、グラフィックスカード１２の追加等の投資を行わなくても、極めて小規模の変更を加えるだけで、大型高精細モニタであるパネル４１を駆動することができる。
【００５２】
また、本実施の形態では、既存のグラフィックスカード１２で採用されているハードウェアパンニング機能１４を利用した送信領域選択手法を採用し、ヘッダ情報の埋め込みにハードウェアカーソル機能１５を利用している。更に、パケットの送信順序制御と共に、パンニングエリアの変更にかかわるオーバーヘッド削減のために、複数の変化領域に対する一括送信も採用している。また更には、送信装置１０側のフレームメモリ１３上にある非表示エリアに書き込んだ署名を利用した、描画中データと送信したい領域内データの同期を取るように構成した。これらによって、転送効率と表示品質を飛躍的に高めることが可能となる。
【００５３】
また、本実施の形態では、描画が発生した矩形部分のみを送信する通常モードに加えて、同じ画面を繰り返し送信するリフレッシュモードを用意し、一定時間利用されていな場合など特定の条件時に通常モードからリフレッシュモードに切り換えることで、送信装置１０と受信側モニタ４０との間での通信エラー制御を実現している。このような通信エラー制御を導入することで、これまでに差分転送に基づくシステムで問題となっていた画像品質の問題を解決している。その結果、限られた通信路(例えば、モニタケーブル３９を１本のみ)で高品位のＱＸＧＡサイズ以上の画像を表示することが可能となる。
【００５４】
更に、本実施の形態によれば、受信側モニタ４０の消費電力に関しても、既存の表示方式と比較して少なくすることが可能となり、モバイル端末への用途や、例えばマルチディスプレイ等、多数のパネルを同時に利用する際にも利点がある。尚、送信エラーが発生していない場合や描画が行われていない場合には、モニタケーブル３９関連の回路等における通信関連部分の電源を切るように構成すれば、更に省電力を図ることも可能となる。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、既存のシステムに対して極めて小規模の変更を加えるだけで、大型高精細モニタ(パネル)を駆動することができる。
【図面の簡単な説明】
【図１】  本実施の形態が適用される画像表示システムの全体構成を説明するための図である。
【図２】  本実施の形態が適用される画像表示システムの主要な処理を示したフローチャートである。
【図３】  本実施の形態における描画命令解析装置を説明するための図である。
【図４】  描画命令解析部における処理を示したフローチャートである。
【図５】  送信領域制御部における処理を示したフローチャートである。
【図６】  受信側モニタにおけるパケット受信装置の構成を示したブロック図である。
【図７】  (ａ)〜(ｃ)は、パケットデータの生成方法を説明するための図である。
【図８】  (ａ),(ｂ)は、パケットデータを生成する処理を示したフローチャートである。
【図９】  パケットのヘッダフォーマットの例を示した図である。
【図１０】  (ａ),(ｂ)は、送信領域の決定方法を説明するための図である。
【符号の説明】
１０…送信装置(ＰＣ)、１１…ＯＳ/アプリケーション、１２…グラフィックスカード、１３…フレームメモリ、１４…ハードウェアパンニング機能、１５…ハードウェアカーソル機能、１７…描画エンジン、１８…ＣＲＴＣ、２０…描画命令解析装置、２１…描画命令解析部、２２…描画情報ＤＢ、２３…送信領域制御部、２４…グラフィックスドライバ、３９…モニタケーブル、４０…受信側モニタ、４１…パネル、５０…パケット受信装置、５１…パケット解析部、５２…ヘッダ解析部、５３…フレームメモリ、５４…パネルコントローラ
【図１】
0003833483.tif 000002
【図２】
0003833483.tif 000003
【図３】
0003833483.tif 000004
【図４】
0003833483.tif 000005
【図５】
0003833483.tif 000006
【図６】
0003833483.tif 000007
【図７】
0003833483.tif 000008
【図８】
0003833483.tif 000009
【図９】
0003833483.tif 000010
【図１０】
0003833483.tif 000011