次に、この発明の実施の形態を実施例に基づいて以下の順序で説明する。
A.第1実施例:
B.第2実施例:
C.第3実施例:
D.第4実施例:
E.第5実施例:
F.変形例:
A.第1実施例:
図1は本発明の一実施例として画像表示システムの構成を示す説明図である。本実施例の画像表示システム10は、画像供給装置としてのパーソナルコンピュータ100(以下「PC100」とも呼ぶ)と、画像表示装置としてのプロジェクタ200と、コンピュータ100とプロジェクタ200とをつなぐUSBケーブル300と、を備えている。コンピュータ100は、USBケーブル300を介して画像をプロジェクタ200供給して、プロジェクタ200に画像を投写させて投写表示画面70に表示させる機能を有している。
図2は、コンピュータ100とプロジェクタ200の内部構成を示すブロック図である。コンピュータ100は、CPU102と、ROM104と、汎用メモリ(「システムメモリ」とも呼ぶ)としてのRAM106と、ハードディスクドライブ108と、キーボードやポインティングデバイスなどで構成される入力部110と、USBインターフェース部112と、フレームメモリとしてのVRAM114と、グラフィックコントローラ116と、液晶ディスプレイなどの表示デバイス118と、これら各要素を接続するバス120と、を備えている。
RAM106には、アプリケーションプログラム122と、グラフィカルデバイスインターフェース(GDI:Graphics Device Interface)124と、ディスプレイドライバ126と、ファイルシステムモジュール130と、SCSIドライバ132と、マスストレージドライバ134と、USBモジュール136と、画像転送プログラム500と、を含む各種コンピュータプログラムが格納されている。なお、GDI124と、ディスプレイドライバ126と、ファイルシステムモジュール130と、SCSIドライバ132と、マスストレージドライバ134と、USBモジュール136は、オペレーティングシステム(OS)の一部として機能する。なお、本実施例においては、オペレーティングシステムとして、マイクロソフト社によって提供されるWindows(登録商標)を想定している。このような各種コンピュータプログラムは、フレキシブルディスクやCD−ROM等の、コンピュータ読み取り可能な記録媒体に記録された形態で提供される。
GDI124は、表示装置(例えば、コンピュータ100の表示デバイス118)や印刷装置(図示せず)などへの描画を統一的に管理しているコンピュータプログラムである。良く知られているように、GDI124は、「GDI関数」と呼ばれる描画に関するアプリケーションプログラムインタフェース(API:Application Program Interface)を各種のアプリケーションプログラムに対して提供している。なお、APIとは、一般に、アプリケーションプログラムがオペレーティングシステムの持つ様々な機能を利用するための手続きの集まりを言う。
アプリケーションプログラム122は、GDI124に対して、例えばプレゼンテーションファイルに含まれているプレゼンテーションシートの画像の描画要求を発行する。通常は、描画要求には、画像の出力先に関する情報(即ち、画像を表示装置に出力するか、印刷装置に出力するかを指定する情報)も含まれている。GDI124は、アプリケーションプログラム122から出された描画要求を受け取り、その描画要求に基づいて画像の出力先をチェックし、その出力先が表示装置であれば、ディスプレイドライバ126に対して描画要求を渡す。ディスプレイドライバ126は、受け取った描画要求に従ってVRAM114内に画像データを描画する。
コンピュータ100の他の構成要素については、後述する。
一方、プロジェクタ200は、CPU202と、ROM204と、RAM206と、各種の操作ボタンを含む入力部210と、USBインターフェース部212と、画像処理部214と、光源ランプと液晶パネルと投写光学系を含む投写部216と、これら各要素を接続するバス218と、を備えている。ROM204には、画像表示モジュール240と、ディスクイメージ224と、コマンドディスパッチャモジュール226(以下、単に「ディスパッチャ226」とも呼ぶ)と、データ管理モジュール230と、SCSIドライバ232と、マスストレージドライバ234と、USBモジュール236と、を含む各種コンピュータプログラムが格納されている。
図3は、第1実施例におけるソフトウェア構成の詳細を示す説明図である。図3では、各構成要素が、データ通信の階層と同じ順番に並んで配置されている。USBモジュール136、236は、それぞれ、USBインターフェース部112、212(図2)を制御し、USBプロトコルを解釈することによってデータ通信を行う。USBモジュール136、236の上位層に設けられたマスストレージドライバ134、234は、マスストレージクラスの通信プロトコルに従ってデータ通信を行う。マスストレージドライバ134、234の上位層に設けられたSCSIドライバ132、232は、SCSIコマンドセットを利用してデータ通信を行う。コンピュータ100のファイルシステムモジュール130は、SCSIドライバ132にデータアクセス要求を発行することによって、ファイルシステムの管理を行う。一方、プロジェクタ200のデータ管理モジュール230は、ディスパッチャ226、SCSIドライバ232を介してコンピュータ100からのアクセス要求を受信し、この要求に応じて、ディスクイメージ224に対するアクセスを中継する。
また、図3には、画像転送プログラム500と画像表示モジュール240との詳細な構成も示されている。画像転送プログラム500は、キャプチャモジュール510と、データ生成モジュール520と、SCSIラッパモジュール530と、を含んでいる。画像表示モジュール240は、画像展開モジュール242とデータ取得モジュール244とを含んでいる。これらの詳細については後述する。
図4は、プロジェクタ200をコンピュータ100に接続したときに実行される接続処理の手順を示すフローチャートである。まず、プロジェクタ200は、SCSIドライバ232(図3)と、マスストレージドライバ234と、USBモジュール236とによって、CD−ROMドライブとして動作する(ステップS100)。
次に、コンピュータ100のUSBモジュール136は、USBケーブル300を介してプロジェクタ200がコンピュータ100に接続されたことを検出し(ステップS104)、この検出に応じてプロジェクタ200に装置構成情報を要求する(ステップS108)。
プロジェクタ200のUSBモジュール236は、この要求に応じて、装置構成情報をコンピュータ100に送信する(ステップS112)。送信される装置構成情報には、プロジェクタ200がUSB規格に準じたデータ記憶装置として動作することを表す情報が含まれている。具体的には、装置構成情報には、USBデバイスのデバイスクラス(インターフェースクラス)が「マスストレージクラス」であることを示す情報が含まれている。また、よく知られているように、「マスストレージクラス」で利用可能なコマンドセットは、インターフェースサブクラスによって特定される。第1実施例のプロジェクタ200は、「SCSIコマンドセット」に対応していることとしている。そこで、装置構成情報には、サブクラスが「SCSIコマンドセット」であることを示す情報も含まれる。なお、サブクラスとしては、他の種々のクラス(例えば、「ATAPI」)を採用可能である。また、装置構成情報には、他の種々のUSBディスクリプタも含まれている。
コンピュータ100(図3)のUSBモジュール136は、この装置構成情報を受信したことに応じて、プロジェクタ200をマスストレージクラスに分類される装置であると識別し、OSに標準的に備えられている汎用のマスストレージドライバ134をロードする(ステップS116)。マスストレージドライバ134は、動作中のOSプロセス内に組み込まれる。これにより、コンピュータ100は、マスストレージドライバ134を利用することによって、プロジェクタ200とデータ通信を行うことが可能となる。
なお、マスストレージドライバ134は、USBのクラスドライバに相当する。クラスドライバは、USBバスのドライバ(図3の例では、USBモジュール136)の上位層に位置し、USBデバイスの種類に応じた通信プロトコルに従ってUSBデバイスとの通信を行う通信制御モジュールである。USB規格では、USBデバイスの種類が複数のクラスに分類されている。そして、クラス毎(すなわち、デバイス種類毎)に異なる通信プロトコルが利用されている。ここで、種々の機能を有するUSBデバイスを利用可能とするために、ベンダ独自のクラス(Vendor Specific Class)を定義することも可能である。この場合には、専用の通信プロトコル(すなわち、専用のクラスドライバ)が利用される。
一方、いくつかの代表的なクラスについては、装置間のデータ通信を容易に行うために、通信プロトコルが標準化されている。「マスストレージクラス」は、このようなクラスの一つである。マスストレージドライバ134は、マスストレージクラス用の通信プロトコルに従ってデータ通信を行う。このようなマスストレージドライバ134は、特定の製造者のデータ記憶装置に限らず、種々の製造者のデータ記憶装置(例えば、CD−ROMドライブやDVD−ROMドライブ、ハードディスクドライブ、半導体メモリ)に共用される。同様に、標準化された通信プロトコルを利用する汎用のデータ記憶装置(例えば、CD−ROMドライブ)は、特定の製造者のコンピュータに限らず、種々の製造者のコンピュータ(例えば、パーソナルコンピュータや情報携帯端末)に対して共通に利用可能である。
また、本実施例では、マスストレージドライバ134(図3)とともに、SCSIドライバ132もロードされる。この際、SCSIドライバ132は、プロジェクタ200のSCSIドライバ232から、プロジェクタ200がCD−ROMドライブであることを示す情報を取得する。これにより、ファイルシステムモジュール130は、SCSIドライバ132を介してSCSIコマンドをプロジェクタ200に送信することにより、プロジェクタ200(ディスクイメージ224)をCD−ROMドライブとして利用可能である。なお、プロジェクタ200は、CD−ROMドライブに限らず、種々のデータ記憶装置(例えば、DVD−ROMドライブや、ハードディスクドライブ)として識別されてもよい。いずれの場合も、ディスクイメージ224からのデータ読み出しは、ファイルシステムモジュール130とSCSIドライバ132とによって行われる。このように、ファイルシステムモジュール130とSCSIドライバ132との全体は、本発明における「データ読み出しモジュール」に相当する。
次のステップS120では、コンピュータ100は、CD−ROMドライブとして認識したプロジェクタ200に記憶されているオートランプログラムを実行する。これにより、ディスクイメージ224(図3)に記録された画像転送プログラム500が、プロジェクタ200からコンピュータ100へ送信され(ステップS124)、そして、画像転送プログラム500が起動する(ステップS128)。Windowsオペレーティングシステムは、CD−ROMのルートフォルダに、「Autorun.inf」というファイルが記録されていると、このファイルによって指定された任意のプログラムの実行を行う。そこで、本実施例ではこの機能を利用して、ディスクイメージ224に記録された画像転送プログラム500を実行することとしている。
なお、オペレーティングシステムの設定によっては、オートランプログラムの自動実行機能が無効になっている場合がある。また、オペレーティングシステムの中には、自動実行機能を利用できないものもある。このような場合には、ユーザの指示に応じて、コンピュータ100が、画像転送プログラム500をプロジェクタ200(ディスクイメージ224)から取得してもよい。また、プロジェクタ200に格納された画像転送プログラム500の代わりに、別のCD−ROM等の記録媒体に記録された画像転送プログラム500や、インターネットからダウンロードした画像転送プログラム500を利用してもよい。
起動した画像転送プログラム500は、プロジェクタ200を利用した画像表示処理を開始する。図5は、画像表示処理の手順を示すフローチャートである。最初のステップS200では、キャプチャモジュール510(図3)は、表示デバイス118(図2)によって表示されている画像をキャプチャする。画像のキャプチャ方法としては、任意の方法を採用可能である。例えば、画像をキャプチャするためのGDI関数を呼び出してもよく、他の描画用APIを利用してもよい。また、キャプチャモジュール510が、直接に、VRAM114から画像データを取得することとしてもよい。なお、第1実施例では、表示デバイス118によって表示されている表示画面の全体がキャプチャされる。
次のステップS204では、データ生成モジュール520は、キャプチャによって取得されたキャプチャ画像データを用いて、表示用データを生成する。第1実施例では、キャプチャ画像データを圧縮することによって、表示用データが生成される。圧縮のアルゴリズムとしては、任意のものを採用可能である。ただし、圧縮せずに、表示用データを生成してもよい。これは、後述する他の実施例についても同じである。
次に、データ生成モジュール520は、SCSIラッパモジュール530に対して、表示用データを送信する命令を発行する。SCSIラッパモジュール530は、この命令に応じて、表示用データを送信するための特別なSCSIコマンド(以下「D9コマンド」とも呼ぶ)を生成する。図6は、D9コマンドの一例を示す説明図である。このD9コマンドは、SCSIの規定で定められているコマンドデスクリプターブロック(CDB:Command Descriptor Block)の構造に準じている。この理由は、SCSIドライバ132(図3)と同様に、マスストレージドライバ134を利用することによってプロジェクタ200とデータ通信を行うためである。
0バイト目は、オペレーションコード(以下「OPコード」とも呼ぶ)を表している。OPコードはコマンドを識別するコードであり、「リード」や「ライト」といったコマンド毎に所定のコードが予め割り当てられている。第1実施例では、画像転送プログラム500によって発行されたSCSIコマンドには、「D9h(hは16進表記を意味する。以下同様)」が割り当てられる。これにより、OPコードが「D9h」である場合には、そのコマンドが画像転送プログラム500によって発行されたものであると判定できる。OPコードが「D9h」以外の場合には、そのコマンドがSCSIドライバ132によって発行されたものであると判定できる。
なお、画像転送プログラム500によって発行されたSCSIコマンドを識別するOPコードとしては、「D9h」に限らず任意のコードを採用可能である。ただし、ディスクイメージ224のデータリードのためのSCSIコマンドのコードとは異なるコードを採用することが好ましい。こうすれば、画像データの転送と、ディスクイメージ224のリードと、を両立させることができる。なお、データリードのためのコマンドとは、データ記憶装置をインターフェースに接続してから、通信を確立し、データリードを完了するまでの一連の処理に利用されるコマンドを意味している。このようなコマンドには、例えば、インクワイアリ(inquiry)コマンドやリード(READ)コマンドが含まれる。
2バイト目は、UDコマンドコードを表している。UDコマンドコードは、画像転送プログラム500が発行するコマンドの具体的な内容を識別するコードである。画像転送プログラム500が複数種類のコマンドを発行する場合には、これらのコマンドがUDコマンドコードによって識別される。従って、OPコードとUDコマンドコードとの組み合わせによって、画像転送プログラム500によって発行されたコマンドを識別することができる。だたし、画像転送プログラム500によって発行されるコマンドが、画像データ送信コマンドのみである場合には、UDコマンドコードを省略してもよい。
3バイト目から6バイト目は、送信されるデータサイズを表している。このデータサイズは、このSCSIコマンドに続けて送信されるデータのサイズを意味している。後述するように、このD9コマンドに続けて表示用データが送信されるので、データサイズは、表示用データのサイズに設定される。
7バイト目は、CEフラグを表している。CEフラグは、送信されるデータの続きの有無を示すフラグである。データを複数の部分データに分割して送信する場合がある。この場合、最後の部分データを送信するためのD9コマンドでは、CEフラグが「E(終了)」に設定され、他の部分データを送信するためのD9コマンドでは、CEフラグが「C(継続)」に設定される。データを分割せずに送信する場合には、CEフラグは「E」に設定される。
D9コマンドの他の部分は、所定の値に設定される。これらの値は、SCSIの規定に従ったデータ通信に利用される(詳細は省略)。
D9コマンドが生成されたら、SCSIラッパモジュール530は、このD9コマンド(CDB)と表示用データとを送信する命令をマスストレージドライバ134に対して発行する。すると、マスストレージドライバ134は、D9コマンドを送信するためのコマンドブロックラッパ(CBW:Command Block Wrapper)を生成する。CBWは、マスストレージクラスを利用してSCSIコマンドを送信するためのデータであり、CDBを格納している。そして、マスストレージドライバ134は、USBモジュール136を制御することによって、CBWと表示用データとをこの順番に送信する。
図5には、送信されるCBWと表示用データTDとが示されている。表示用データTDは、ヘッダImgHと、圧縮された画像データImgDとを含んでいる。ヘッダImgHは、圧縮形式(アルゴリズム)と、画像の高さ(ドット数)及び幅(ドット数)と、画面内における画像の位置と、を表す情報を含んでいる。画面内の位置は、例えば、画像データImgDによって表される画像の基準点(通常は左上の角のドット)の画面内の位置によって表される。なお、第1実施例では、表示用データTDは、分割されずに送信される。
コンピュータ100は、以上説明した画像のキャプチャと(S200)、CBW(D9コマンド)と表示用データTDとの送信と(S204)、を繰り返し実行する。
一方、プロジェクタ200では、USBモジュール236、マスストレージドライバ234によってCBW(D9コマンド)と表示用データTDとが受信される(ステップS220)。次のステップS224では、ディスパッチャ226は、CBWに格納されたSCSIコマンドのOPコードが「D9h」であるか否かを判断する。OPコードが「D9h」である場合には、次のステップS230で、ディスパッチャ226は、受信されたデータをデータ取得モジュール244に供給する。供給されるデータには、SCSIコマンドと、そのコマンドと共に送信されたデータ(すなわち、CBWと表示用データTD)が含まれる。次のステップS234では、データ取得モジュール244は、表示用データTDを抽出して画像展開モジュール242に供給する。画像展開モジュール242は、ヘッダImgHで指定された圧縮形式に従って画像データImgDを伸長する。そして、画像展開モジュール242は、ヘッダImgHの情報(高さ、幅、位置)と伸長された画像データとに従って画像処理部214(図2)を制御し、画像処理部214によって画像処理部214内の表示メモリ(図示せず)に画像データを展開させる。この際、画像展開モジュール242は、投写部216の解像度(画素数)と、ヘッダImgHの情報と、に応じた解像度変換処理を実行してもよい。
以上の結果、プロジェクタ200は、図1に示すように、投写表示画面70に画像を表示することができる。このように、画像表示モジュール240は、プロジェクタ200が画像データを受信したことに応じて、画像を表示する。従って、コンピュータ100が画像データの送信を繰り返し実行することによって、プロジェクタ200によって表示される画像も繰り返し更新される。
次のステップS238では、データ取得モジュール244は、正常に表示用データTDを受信したことを表す応答を送信する命令をマスストレージドライバ234に対して発行する。すると、マスストレージドライバ234は、応答を送信するためのコマンドステイタスラッパ(CSW:Command Status Wrapper)を生成する。CSWは、マスストレージクラスを利用してSCSIのステータス応答を送信するためのデータである。そして、マスストレージドライバ234は、USBモジュール236を制御することによって、CSWを送信する。
一方、OPコードが「D9h」とは異なる場合には(S224:No)、次のステップS290で、ディスパッチャ226は、受信されたデータをSCSIドライバ232に供給する。供給されるデータには、SCSIコマンドと、そのコマンドと共に送信されたデータが含まれる。ただし、SCSIコマンドのみが受信される場合には、SCSIコマンドのみが供給される(例えば、READコマンドが発行される場合)。次のステップS294では、データ管理モジュール230は、SCSIドライバ232を介して受け取ったSCSIコマンドに従って、ディスクイメージ224に対するアクセスを中継する(例えば、ディスクイメージ224に格納されたデータがコンピュータ100に送信される)。なお、SCSIドライバ232とデータ管理モジュール230とディスクイメージ224との全体は、本発明における「データ記憶部」に相当する。
次のステップS298では、データ管理モジュール230は、コマンドの実行結果を表すステータス応答をコンピュータ100に送信する。この処理は、ステップS238と同様に行われる。なお、画像転送プログラム500がコンピュータ100に送信される場合には、これらのステップS290〜S298の処理が実行される。
以上のように、第1実施例は、以下のような種々の特徴と利点を有している。第1の特徴点は、プロジェクタ200が、プロジェクタとは異なる汎用デバイス(マスストレージクラス)として識別される点である。プロジェクタ200のUSBモジュール236は、このような汎用デバイスを示す識別情報(デバイスクラス(インターフェースクラス))をコンピュータ100に送信する。これにより、プロジェクタ200のための専用のデバイスドライバをコンピュータ100にインストールせずに、汎用のマスストレージドライバ134を利用して、USBインターフェース部112、212を介したデータ通信(画像データの転送)が可能となるという利点がある。なお、プロジェクタ200におけるUSBモジュール236とマスストレージドライバ234とディスパッチャ226との全体は、本発明における「画像表示装置の通信制御部」に相当する。一方、コンピュータ100におけるUSBモジュール136とマスストレージドライバ134との全体は、本発明における「画像供給装置の通信制御部」に相当する。
第2の特徴点は、プロジェクタ200が、データ記憶装置(マスストレージクラス)として識別される点である。マスストレージクラスの通信プロトコルは、データ記憶装置へのデータ転送速度が過剰に遅くならないように設計されている。従って、画像データの転送速度を高め、プロジェクタ200による表示画像の更新頻度を高めることが可能となる。
第3の特徴点は、プロジェクタ200のデータ記憶部(ディスクイメージ224)に、画像転送プログラム500が格納されている点である。これにより、画像転送プログラム500を、容易に、コンピュータ100に提供することができる。その結果、画像転送プログラム500の準備が容易となるので、プロジェクタ200の利用に関する利便性をさらに向上させることができる。
B.第2実施例:
図7は、第2実施例における画像表示処理の手順を示すフローチャートである。この図7には、プロジェクタ200が実行する処理が示されている。第2実施例では、図5に示す第1実施例とは異なり、データ生成モジュール520は、キャプチャされた画像データを複数の部分データに分割して、1つずつ順番にプロジェクタ200に送信する。装置の構成は、図1〜図3に示す第1実施例と同じである。
ステップS220、S224の処理は、図5のステップS220、S224の処理と、それぞれ同じである。D9コマンドを受け取ったデータ取得モジュール244は、CEフラグ(図6)の値を確認する(S228)。CEフラグが「C」に設定されている場合には、データ取得モジュール244は、受信した部分データをRAM206(図2)に格納し(S240)、正常応答を発行する(S244)。このステップS244は、図5のステップS238と同様である。そして、処理はステップS220に戻り、データ取得モジュール244は、残りの部分データを待つ。
複数の部分データの内の最後の部分データが送られてきた場合には、CEフラグが「E」に設定されている。この場合には、次のステップS250で、データ取得モジュール244は、受信した複数の部分データを結合することによって表示用データを再構成し、この表示用データを画像展開モジュール242に供給する。すると、画像展開モジュール242は、図5のステップS234と同様に、ヘッダと画像データに従って画像処理部214(図2)を制御する。この結果、プロジェクタ200は、図1に示すように、投写表示画面70に画像を表示する。次のステップS254は、図5のステップS238と同様である。このステップS254の後、処理はステップS220に戻る。そして、上述した一連の処理が繰り返し実行される。
図8は、第2実施例における画像表示処理の一例の具体的な手順を示すフローチャートである。この例は、画像データが2つの部分データに分割して送られる場合を示している。
最初のステップS200は、図5のステップS200と同じである。次のステップS208aでは、データ生成モジュール520(図3)は、キャプチャされた画像データを圧縮することによって送信用画像データImgDを生成し、この画像データImgDを用いて第1表示用データTD1を生成する。ここで、データ生成モジュール520は、画像データImgDを、第1部分データImgD1と第2部分データImgD2とに分割する。そして、データ生成モジュール520は、ヘッダImgHと第1部分データImgD1とから構成される第1表示用データTD1を生成する。
次に、データ生成モジュール520は、CEフラグを「C」に設定して第1表示用データTD1を送信する命令をSCSIラッパモジュール530に対して発行する。SCSIラッパモジュール530によって生成されるD9コマンド(CDB1)では、OPコードが「D9h」に設定され、CEフラグが「C」に設定されている。
生成されたD9コマンド(CDB1)を格納するコマンドブロックラッパCBW1と、第1表示用データTD1とは、マスストレージドライバ134によって、プロジェクタ200に送信される。
一方、データを受信したプロジェクタ200では、受信されたD9コマンドのCEフラグが「C」に設定されているので、図7のステップS228、S240、S244と同様の一連の処理が実行される。
コンピュータ100では、ステップS244で発行された正常応答(CSW)を受信したことに応じて、データ生成モジュール520(図3)が、残りの第2部分データImgD2を送信する命令をSCSIラッパモジュール530に対して発行する(S208b)。この際、CEフラグを「E」に設定する指示が発行される。SCSIラッパモジュール530によって生成されたD9コマンド(CDB2)では、OPコードが「D9h」に設定され、CEフラグが「E」に設定されている。
生成されたD9コマンド(CDB2)を格納するコマンドブロックラッパCBW2と、第2表示用データTD2(第2部分データImgD2)とは、マスストレージドライバ134によって、プロジェクタ200に送信される。
一方、データを受信したプロジェクタ200では、受信されたD9コマンドのCEフラグが「E」に設定されているので、図7のステップS228、S250、S254と同様の一連の処理が実行される。
以上、画像データが2つの部分データに分割して送信される場合について説明したが、画像データが3つ以上の部分データに分割して送信される場合についても、同様の手順に従って、部分データが逐次送信され、全ての部分データが転送された後に画像が表示される。
このように、第2実施例の画像表示処理では、画像データが分割して送信される。従って、画像データのサイズが大きい場合であっても、適切にプロジェクタ200に画像データの全体を送信することができる。特に、通信用のインターフェースによっては、1回のコマンド発行で送信可能なデータサイズに上限が設けられている場合が多い。このような場合であっても、サイズに拘わらずに、画像データの全体を転送することができる。
なお、図8の例では、送信用画像データImgDを分割して送信していたが、画像データを分割して送信する方法としては、他の種々の方法を採用可能である。例えば、表示画面を複数の部分画面に分割し、各部分画面毎にキャプチャ画像データを送信してもよい。例えば、表示デバイス118の表示画面を左半分と右半分との2つの部分画面に区分してもよい。ここで、左部分画面の画像データをプロジェクタ200へ送信して、プロジェクタ200に左半分を更新させ、その後、右部分画面の画像データを送信して、プロジェクタ200に右半分を更新させる一連の処理を、繰り返し実行してもよい。ここで、表示画面全体のキャプチャ画像データの転送が完了した後に、プロジェクタ200が表示を更新してもよい。なお、画面の区分としては、左半分と右半分への区分に限らず任意の区分を採用可能である。また、3以上の領域に区分してもよい。
C.第3実施例:
図9は、第3実施例におけるソフトウェア構成の詳細を示す説明図である。図3に示す第1実施例との差違は3点ある。第1の差違は、画像転送プログラム500aが、判断モジュール540を有している点である。第2の差違は、コンピュータ100a上で、フック処理モジュール400と、プロジェクタドライバ128と、が動作している点である。第3の差違は、プロジェクタ200a上で、状態チェックモジュール250が動作している点である。他の構成は、図3に示す第1実施例と同じである。第3実施例では、これらの構成要素によって、画面の変化領域のみが、コンピュータ100aからプロジェクタ200aに転送される。なお、コンピュータ100a上で動作するプログラム500a、400、128は、ディスクイメージ224に格納されている。そして、図4に示す接続処理におけるオートランプログラム、あるいは、ユーザの指示に応じて、プロジェクタ200aからコンピュータ100aに転送される。また、ハードウェア構成は、図1、図2に示す第1実施例と同じである。
図10は、第3実施例における接続処理の手順を示すフローチャートである。図10の処理は、図4に示す接続処理の後に実行される。この接続処理は、コンピュータ100aが、プロジェクタ200aによる画像データ受信準備の完了を待つために、実行される。プロジェクタ200aの受信準備完了を待つ理由は以下の通りである。第3実施例では、後述するように、最初に画面全体の画像データが送信された後は、画像の変化した部分の画像データのみが送信される。従って、最初の画面全体の画像データを確実にプロジェクタ200aに受信させるために、コンピュータ100aは、プロジェクタ200aの受信準備完了を待つ。
最初のステップS300では、判断モジュール540(図9)は、プロジェクタ200aに、状態問い合わせを送信する命令を、SCSIラッパモジュール530に対して発行する。SCSIラッパモジュール530は、画像データを送信する場合と同様に、状態問い合わせを送信するためのD9コマンドを生成する。ここで、UDコマンドコード(図6)は、画像データ送信コマンドのUDコマンドコードとは異なるコードに設定される。例えば、第3実施例では、画像データ送信コマンドに対しては「80h」が採用され、状態問い合わせを送信するコマンドに対しては「C1h」が採用されることとしている。生成されたD9コマンドは、マスストレージドライバ134によってプロジェクタ200aに送信される。なお、受信状態に加えて他の種々の状態を、この状態問い合わせ用のD9コマンド(UDコマンドコード=C1h)を用いて問い合わせる場合には、このD9コマンドに続けて、問い合わせの内容を識別するデータを送信してもよい。
一方、プロジェクタ200aのディスパッチャ226は、SCSIコマンドを受信したら(S350)、そのコマンドがD9コマンドか否かを判断する(S354)。そのコマンドがD9コマンドである場合には、さらに、UDコマンドコードを確認する(S358)。UDコマンドコードが「C1h」である場合には、受信したデータを状態チェックモジュール250に供給する。なお、図10では図示を省略しているが、UDコマンドコードが「80h」である場合には、ディスパッチャ226は、受信したデータ(画像データ送信用D9コマンドと表示用データ)をデータ取得モジュール244に供給する。
UDコマンドコードがC1hに設定されたD9コマンド(すなわち、状態問い合わせ)を受信した状態チェックモジュール250は、プロジェクタ200aの状態が、画像データ受信が可能な状態か否かを判断する(S360)。受信可能と判断するための条件としては、受信した画像データを消失させずに保持できることを示す任意の条件を採用可能である。例えば、画像表示モジュール240(図9)の起動が完了していることを条件として採用してもよい。また、画像処理部214(図2)の起動が完了していることを条件として採用してもよい。状態チェックモジュール250は、判断結果を表す状態データを、コンピュータ100aに送信すべきデータとして、RAM206(図2)に格納する。本実施例では、状態データは、「REDY(受信可能)」あるいは「BUSY(受信不可)」のいずれかの文字列である。
次に、状態チェックモジュール250は、状態問い合わせを正常に受信したことを示す応答をコンピュータ100aに送信する(S364)。この応答送信は、図5のステップS238と同様に行われる。なお、この段階では、状態データはコンピュータ100aに送信されない。この理由は、プロジェクタ200aは、SCSIのターゲットに相当するので、自発的にデータを送信することができないからである。
コンピュータ100aの判断モジュール540は、正常応答(CSW)を受信したことに応じて(S304)、リクエスト問い合わせを送信する命令を、SCSIラッパモジュール530に対して発行する(S310)。このリクエスト問い合わせは、プロジェクタ200aに種々のデータを送信させるためのコマンドである。SCSIラッパモジュール530は、画像データを送信する場合と同様に、D9コマンドを生成する。ここで、UDコマンドコード(図6)は、画像データ送信コマンドと、状態問い合わせ送信コマンドと、のいずれのコードとも異なるコードに設定される。例えば、第3実施例では、リクエスト問い合わせ送信コマンドに対しては「00h」が採用されることとしている。生成されたD9コマンドは、マスストレージドライバ134によってプロジェクタ200aに送信される。
一方、プロジェクタ200aのディスパッチャ226は、受信したSCSIコマンドがD9コマンドであり(S354:Yes)、UDコマンドコードが「00h」である場合には、受信したデータを状態チェックモジュール250に供給する。
UDコマンドコードが00hに設定されたD9コマンド(すなわち、リクエスト問い合わせ)を受信した状態チェックモジュール250は、先ほどのステップS360でメモリに格納した状態データを送信する命令を、マスストレージドライバ234に対して発行する(S370)。マスストレージドライバ234は、命令に従って、状態データをコンピュータ100aに送信する。次のステップS374では、状態チェックモジュール250は、リクエスト問い合わせに応じたデータ送信を正常に行ったことを示す応答をコンピュータ100aに送信する。この応答は、ステップS364と同様に行われる。
コンピュータ100aによって受信された状態データと応答とは、判断モジュール540に供給される(S314、S318)。状態データが「BUSY」である場合には、判断モジュール540は、「REDY」に設定された状態データを受信するまで、ステップS300〜S320の一連の処理を繰り返し実行する。
状態データが「REDY」である場合には、判断モジュール540は、次のステップS330で、画像表示処理を開始する指示を、各モジュール510、520、530に対して発行する。
図11は、第3実施例における画像表示処理の手順を示すフローチャートである。最初のステップS400、S404、S408、S412の処理は、図5のステップS200、S204、S234、S238と、それぞれ同じである。特に、ステップS400では、表示デバイス118によって表示されている表示画面の全体がキャプチャされる。これにより、プロジェクタ200aは、図1に示すように、投写表示画面70に画像を表示することができる。なお、図11のフローチャートでは、OPコードとUDコマンドコードとを確認する処理は、図示が省略されている。
次のステップS420では、キャプチャモジュール510は、画面内の変化した領域のみのキャプチャを実行する。この変化領域のみのキャプチャの詳細については後述する。次のステップS424では、ステップS404と同様に、キャプチャされた画像データがコンピュータ100aからプロジェクタ200aへ送信される。この際、ヘッダにおけるサイズ(高さ、幅)と位置とは、変化領域を表す値に設定される。
次のステップS428では、画像展開モジュール242は、ステップS408と同様に、ヘッダと画像データに従って画像処理部214(図2)を制御する。この際、変化領域を表す部分の画像データのみが更新される。他の部分については更新されずに維持される。その結果、プロジェクタ200aは、変化領域が更新された画像を表示することができる。次のステップS432は、ステップS412と同じである。このステップS432の後、処理は、ステップS420に戻る。そして、上述したステップS420〜S432の一連の処理が繰り返し実行される。
以上のように、第3実施例では、表示画面の全体が送信された後は、変化した領域のみが送信される。また、画像展開モジュール242は、変化した領域のみを受信した場合には、変化した領域のみを更新する。これらにより、送信されるデータ量を低減することができる。その結果、プロジェクタ200aによって表示される画像の更新頻度を速めることが可能となる。
なお、図11の例では、画面全体の画像データ送信が接続直後の1回だけであったが(S400、S404)、接続後、複数回に渡って画面全体の画像データが送信されてもよい。こうすれば、プロジェクタ200aによって表示される画像が乱れることを抑制できる。例えば、画像転送プログラム500aが、定期的に画面全体の画像データを送信してもよい。また、画像転送プログラム500aが、ユーザの指示を受けたことに応じて画面全体の画像データを送信してもよい。
次に、変化領域のみのキャプチャ(図11:S420)について説明する。図12は、画面内の変化部分をキャプチャするためのコンピュータのソフトウェアとハードウェアの階層構造を示す説明図である。アプリケーションプログラム122と画像転送プログラム500aは、アプリケーションプログラム層(「ユーザアプリケーションプログラム層」とも呼ぶ)に属する。GDI124とディスプレイドライバ126とプロジェクタドライバ128は、カーネル層に属する。また、汎用メモリとしてのRAM106と、USBインターフェース部112と、VRAM114と、グラフィックコントローラ116と、表示デバイス118は、ハードウェア層に属する。
また、アプリケーションプログラム122とGDI124との間には、フック処理モジュール400が設けられている。フック処理モジュール400は、アプリケーションプログラム122が発行する特定の描画命令をフックして先取りし、後述する処理を実行する。他の描画命令は通常通りGDI124によって処理される。なお、フック処理モジュール400は、アプリケーションプログラム122に応じた適切な特定の描画命令のみをフックするように、各アプリケーションプログラム専用に構成されることが好ましい。
第3実施例では、アプリケーションプログラム122としてプレゼンテーションプログラム(例えばマイクロソフト社のPowerPoint)を使用した場合について説明する。まず、描画命令がフック処理モジュール400を介さずに直接にGDI124に渡される場合について説明し、次に、描画命令がフック処理モジュール400によって先取りされる場合について説明する。
アプリケーションプログラム122は、GDI124に対して、例えばプレゼンテーションファイルに含まれているプレゼンテーションシートの画像の描画要求を発行する。通常は、描画要求には、画像の出力先に関する情報(即ち、画像を表示装置に出力するか、印刷装置に出力するかを指定する情報)も含まれている。
なお、GDI124の代わりに、他の汎用の描画用APIを使用することも可能である。「汎用の描画用API」とは、多数のアプリケーションプログラムに対して共通に使用されるAPIを意味している。
GDI124と、ディスプレイドライバ126と、プロジェクタドライバ128の全体は、描画命令に従って描画処理を実行する描画モジュールとして機能する。具体的には、GDI124は、アプリケーションプログラム122から出された描画要求を受け取り、その描画要求に基づいて画像の出力先をチェックし、その出力先が表示装置であれば、ディスプレイドライバ126とプロジェクタドライバ128のそれぞれに対して描画要求を渡す。
ディスプレイドライバ126は、受け取った描画要求に従ってVRAM114内に画像データを描画する。なお、よく知られているように、描画要求としては、画面の全体を描画するものに限らず、画面の一部を描画するものも多用される。画面の一部を描画する描画命令を受けた場合には、ディスプレイドライバ126は、VRAM114内で描画対象となっている領域(「変化領域」とも呼ぶ)の画像部分のみを描画する。グラフィックコントローラ116は、VRAM114内に描画された画像データ(即ち、ビットマップデータ)に基づいて、表示デバイス118に画像を表示する。一方、プロジェクタドライバ128は、GDI124から受け取った描画要求に従って、VRAM114内の描画対象領域(すなわち変化領域)の位置及びサイズを表す変化領域情報106aをRAM106内に書き込む。以下、プロジェクタドライバ128によって書き込まれる変化領域情報を、第2変化領域情報106a2(変化領域情報A2)とも呼ぶ。
図13(A),(B)は、RAM106内の変化領域情報106a2と画像データ格納領域106bの例を示す説明図である。ここでは、プロジェクタで投写表示されるべき画像が図13(A)から図13(B)のように変化する例を想定する。後述するように、画像データ格納領域106bには、キャプチャモジュール510によってVRAM114から転送された画像データが格納される。画像データ格納領域106bは、VRAM114(フレームメモリ)と同じデータ容量を有することが好ましい。
変化領域Raは、図4(A)から図4(B)に画像を変更する際の描画命令によって描画される画像部分の領域である。この変化領域Raに関する変化領域情報106a2は、変化領域Raの基準点(通常は左上点)のx座標Xa及びy座標Yaと、変化領域Raの幅Wa及び高さHaとを含んでいる。なお、基準点の座標(Xa,Ya)は、変化領域Raの位置を示すデータであり、幅Waと高さHaは変化領域Raのサイズを示すデータである。
キャプチャモジュール510は、RAM106内の変化領域情報106a2を参照して、変化領域Raの画像データを、VRAM114からRAM106内の画像データ格納領域106bに転送する。この画像データ格納領域106bは、例えばコンピュータ100又はプロジェクタ200の表示解像度に等しいサイズのメモリ領域である。キャプチャモジュール510は、さらに、画像データ格納領域106bから変化領域Raの画像データを読み出して、読み出した画像データと変化領域情報106a2とをデータ生成モジュール520に供給する。データ生成モジュール520は、受け取ったデータを用いて、表示用データ(ヘッダと画像データ)を生成する。生成された表示用データは、マスストレージドライバ134によってプロジェクタ200aに送信される。
このように、描画命令がフック処理モジュール400を介さずに直接にGDI124に渡される場合には、一旦VRAM114に格納された画像データを汎用メモリであるRAM106に転送した後で、RAM106内にある画像データをプロジェクタ200aに転送している。このため、VRAM114からRAM106に転送するためにかなりの時間を要してしまい、十分な転送速度が得られない場合があった。
次に、描画命令がフック処理モジュール400によって先取りされる場合について説明する。なお、フック処理モジュール400も一種の描画用APIと考えることも可能であるが、GDI124のような汎用の描画用APIとは区別される。すなわち、フック処理モジュール400は、典型的には特定の描画命令のみを処理するように構成されているのに対して、GDI124はすべての描画命令を処理するように構成されている点で相違する。
フック処理モジュール400は、例えばDLL(ダイナミックリンクライブラリ)としてアプリケーションプログラム122にロード(インストール)される。一般に、アプリケーションプログラムは「プロセス」という単位で動作している。また、アプリケーションプログラムの実行中は、そのプロセス内に複数のモジュール(GDI32.DLLやKernel32.DLLなど)がロードされており、アプリケーションプログラムはそれらのモジュール内の関数を利用することによって各種の動作を行っている。フック処理モジュール400の「ロード」とは、アプリケーションプログラム122のプロセス内に、フックプロシージャが実装されているモジュール400を組み込むことを意味している。
フック処理モジュール400がロードされる際には、アプリケーションプログラム122から発行される特定の描画命令の関数アドレスが、フック処理モジュール400内に実装されている独自機能を実行するための別の関数のアドレスに差し替えられる。この独自機能の関数内では、変化情報と画像データのRAMへの書き込み処理(後述する)が実行され、その後、通常のGDI関数が実行される。フック処理モジュール400をアンロードする際には、ロード時に差し替えられていた関数アドレスを元に戻した後に、プロセス内にロードされていたフック処理モジュール400がアンロードされる。
なお、フック処理モジュール400は、必要に応じていつでもアプリケーションプログラム122にロードしたり、アンロードしたりすることが可能である。但し、画像転送プログラム500aが起動する際に、動作中の特定のアプリケーションプログラム122(本実施例ではプレゼンテーションプログラム)にフック処理モジュール400をロードし、また、画像転送プログラム500aを終了するときにフック処理モジュール400をアンロードするように、画像転送プログラム500aを構成することが好ましい。こうすれば、画像転送プログラム500aが実行中の期間にのみフック処理モジュール400を動作させることができるので、コンピュータ100上で画像転送プログラム500aが実行されていない(起動していない)ときに描画命令をフックしてしまい、望ましくない結果が生じることを回避することができる。なお、本明細書において、「コンピュータ100上で画像転送プログラム500aが実行されている」という文言は、画像転送プログラム500aのプロセスが起動されていることを意味している。
図14は、第3実施例におけるフック処理モジュール400と画像転送プログラム500aの動作を示すフローチャートである。ステップS10〜S16はフック処理モジュール400によって実行され、ステップS20〜S26は画像転送プログラム500aによって定期的に実行される。
フック処理モジュール400は、アプリケーションプログラム122から特定の描画命令が発行されたときに、ステップS10においてその描画命令をフックして、GDI124の代わりにその描画命令を取得する。なお、フック処理モジュール400がフックする描画命令は、すべての描画命令ではなく、限られた特定の描画命令のみに限定することが好ましい。この理由は、アプリケーションプログラム122が発行する描画命令には多数のものがあるので、そのすべてをフックするようにすると、却って処理速度を低下させたり、所望の描画を行えなかったりする可能性があるからである。
ステップS12では、取得した描画命令に応じて変化領域情報を登録する処理が実行される。具体的には、フック処理モジュール400が、描画命令に従って描画が行われる領域(図13(B)の変化領域Ra)の位置とサイズを取得し、その変化領域を表す変化領域情報106a1(以下「変化領域情報A1」とも呼ぶ)をRAM106に直接書き込む処理を実行する。
ステップS14では、変化領域Raの画像データの書込処理が実行される。具体的には、フック処理モジュール400が、描画命令に従って変化領域Ra内の画像データを展開して、その画像データをRAM106内の画像データ格納領域106bに直接書き込む処理を実行する。
ステップS16では、フック処理モジュール400が、ステップS10で取得した描画命令に従って通常のGDI関数を呼び出して描画処理を実行させる。なお、ディスプレイドライバ126とプロジェクタドライバ128(図12)は、描画命令がフック処理モジュール400を介さずに直接にGDI124に渡される場合と同様に、GDI124から受け取った描画命令に従ってそれぞれの処理を実行する。すなわち、ディスプレイドライバ126がVRAM114内に画像を描画し、プロジェクタドライバ128がその描画領域を示す変化領域情報A2をRAM106内に書き込む。
一方、キャプチャモジュール510は、ステップS20において、プロジェクタ200に転送すべき画像データの領域(「画面更新領域」と呼ぶ)を決定する。図15は、ステップS20の詳細手順を示すフローチャートである。ステップS30,S32では、第1と第2の変化領域情報A1,A2が取得される。前述したように、第1の変化領域情報A1は、フック処理モジュール400によってRAM106内の画像データ格納領域106bに描画された領域を表す情報であり、フック処理モジュール400によってRAM106内に書き込まれたものである。一方、第2の変化領域情報A2は、ディスプレイドライバ126によってVRAM114内に描画された領域を表している情報であり、プロジェクタドライバ128によってRAM106内に書き込まれたものである。
図16(A)は、2つの変化領域情報A1,A2で表される2つの変化領域RA1,RA2の一例を示している。ここでは、2つの変化領域RA1,RA2を、同一の画面領域SCA内に配置している。ここで、「画面領域SCA」とは、VRAM114に格納される画像の全体の領域を意味しており、これは、画像データ格納領域106b全体の領域と等しい。厳密に言えば、第1の変化領域RA1は画像データ格納領域106b内のアドレスで定義された領域であり、第2の変化領域RA2はVRAM114内のアドレスで定義された領域であるが、これらは同じ画面領域SCAで表現することができる。
なお、図16(A)の例では、2つの変化領域RA1,RA2は部分的に重なっているが、2つの変化領域RA1,RA2はこれ以外の種々の関係を取る場合がある。例えば、2つの変化領域RA1,RA2が全く重なり合わない場合も存在し、両者が完全に重なり合う場合も存在する。例えば、フック処理モジュール400が特定の描画命令に従って描画を行い、その後、通常の描画モジュール124,126,128が同じ描画命令に従って同じ領域の描画を行った場合には、2つの変化領域RA1,RA2は同一となる。但し、同じ描画命令を実行したときにも、各モジュールの設定によっては、2つの変化領域RA1,RA2に若干の差異が生じる場合もあり得る。
図16(B)は、キャプチャモジュール510がキャプチャ時にRAM106から画像を直接取得する領域TG1を示しており、図16(C)はVRAM114から画像を取得する領域TG2を示している。これらの領域TG1,TG2を「転送領域」とも呼ぶ。この例から理解できるように、第1の変化領域RA1(=TG1)の画像は、RAM106内から直接取得される。一方、第2の変化領域RA2のうちで第1の変化領域RA1に含まれない部分の領域TG2の画像は、VRAM114から取得される。このように区別する理由は、VRAM114から取得する画像を可能な限り少なくして、その取得に要する時間を少なくするためである。例えば、2つの変化領域RA1,RA2が完全に重なる場合には、VRAM114から画像を取得する必要が無くなるので、転送処理を高速に行うことができる。図16(D)は、キャプチャモジュール510によって取得される領域全体(画面更新領域TTG)を示している。この画面更新領域TTGは、第1と第2の変化領域RA1,RA2の和領域に相当する。
なお、第1の変化領域情報A1に複数の描画命令に対応する複数の情報が含まれている場合がある。この場合には、これらの複数の描画命令の描画領域の和領域が第1の変化領域RA1となる。第2の変化領域RA2についても同様である。
図15のステップS34では、キャプチャモジュール510が、2種類の変化領域情報A1,A2で表される変化領域RA1,RA2の差分を計算する。具体的には、第2の変化領域RA2の中で、第1の変化領域RA1に含まれない領域TG2(図16(C))が算出される。ステップS36では、キャプチャモジュール510によって、画面更新領域TTG(図16(D))の最適化処理が実行される。
図17は、画面更新領域の最適化処理の内容を示す説明図である。図17(A)は、図16(D)と同じ画面更新領域TTGを示している。最適化処理では、図17(B)に示すように、画面更新領域TTGを互いに重ならない隣接する矩形領域R11〜R13に分割する。そして、これらの矩形領域R11〜R13が、最適化後の画面更新領域として採用される。個々の画面更新領域R11〜R13は矩形なので、最適化前の画面更新領域TTGを包含するような矩形形状の画像を転送する場合に比べて、転送される画像データ量を削減することが可能である。
図14のステップS22では、キャプチャモジュール510によって、画面更新領域に相当する画像部分の画像データが取得される。図18は、ステップS22の詳細手順を示すフローチャートである。ステップS40では、第2の転送領域TG2(図16(C))が空である否かが調べられる。第2の変化領域情報A2が存在しない場合、及び、第2の変化領域A2が第1の変化領域A1に完全に包含されている場合には、第2の転送領域TG2は空である。第2の転送領域TG2が空である場合には、後述するステップS44に移行する。一方、第2の転送領域TG2が空でない場合には、ステップS42が実行される。ステップS42では、キャプチャモジュール510が第2の転送領域TG2の画像データをVRAM114から取得してRAM106内の画像データ格納領域106bに書き込む。この結果、画像データ格納領域106bには、図16(D)に示す画面更新領域TTG内の画像がすべて格納された状態になる。ステップS44では、キャプチャモジュール510が画面更新領域TTGの画像データをRAM106の画像データ格納領域106bから取得する。なお、実際に取得されるのは、最適化処理後の個々の画面更新領域R11〜R13(図10(B))の画像データである。
図14のステップS24では、キャプチャモジュール510は、変化領域情報と画像データとをデータ生成モジュール520に供給する。データ生成モジュール520は、受信したデータを用いて、表示用データを生成する。ステップS26では、こうして生成された表示用データが、USBインターフェース部112を介してプロジェクタ200aに転送される。なお、最適化処理によって画面更新領域が複数の部分領域に分割された場合には、各部分領域毎に表示用データが生成される。なお、各表示用データは、1つのD9コマンドでまとめて転送されてもよく、別々のD9コマンドで転送されてもよい。
一方、プロジェクタ200a(図9)の画像展開モジュール242は、受信した表示用データ(ヘッダと画像データ)に従って画像処理部214を制御し、プロジェクタ200aによって表示される画像を更新する。
このように、第3実施例では、フック処理モジュール400が、特定の描画命令をフックして先取りし、変化領域の画像データをRAM106に直接書き込む処理を実行するようにしている。この結果、VRAM114からRAM106への画像データの転送に要していた時間を節約することができる。この結果、プロジェクタ200aに画像データを転送する場合の転送速度を十分に速くすることができるという利点がある。
なお、一般に使用されているパーソナルコンピュータでは、RAM106からVRAM114へのデータ転送は非常に高速に実行できるのに対して、VRAM114からRAM106へのデータ転送はその数倍低速でしか実行できないアーキテクチャとなっていることが多い。第3実施例では、低速なVRAMからRAMへのデータ転送を削減できるので、プロジェクタ200に画像データを転送するために要する時間を大幅に削減することが可能である。
また、上記第3実施例では、フック処理モジュール400によって描画されていない領域TG2(図16(C))の画像部分に関しては、VRAM114から取得してプロジェクタ200aに転送している。この結果、通常の描画モジュール124,126,128で描画された画像についても欠落無しにプロジェクタ200に転送することが可能である。
D.第4実施例:
図19は、第4実施例における変化領域と画面更新領域との関係を示す説明図であり、第3実施例の図16に対応するものである。第4実施例は、装置構成や処理フローの全体は第3実施例と同じであるが、転送対象となる領域が第3実施例と異なっている。具体的には、第4実施例では、RAM106から画像が直接取得される第1の転送領域TG1(図19(B))は、第1と第2の変化領域RA1,RA2が重なり合っている部分に設定される。換言すれば、第1の転送領域TG1は、第2の変化領域RA2のうちで第1の変化領域RA1にも含まれている領域に設定される。一方、VRAM114から画像が取得される第2の転送領域TG2(図19(C))は、第3実施例と同様に、第2の変化領域RA2のうちで第1の変化領域RA1に含まれていない部分に設定される。従って、転送対象となる領域の全体である画面更新領域TTG(図19(D))は、第2の変化領域RA2と同一である。
このように、第4実施例では、GDI124及びディスプレイドライバ126によってVRAM114内に描画される領域である第2の変化領域RA2内の画像が画像転送プログラム500aによって転送されることになる。このように処理を行う理由は、以下の通りである。すなわち、フック処理モジュール400によってフック処理された描画命令も、その後、GDI124及びディスプレイドライバ126によって再度実行されるので、基本的にすべての描画命令がGDI124及びディスプレイドライバ126によって実行される。従って、第2の変化領域RA2の画像を転送すれば、プロジェクタ200aに正しい画像を表示させることが可能である。但し、この際にすべての画像データをVRAM114から取得すると、データ転送にかなりの時間を要するという問題を生じてしまう。そこで、第4実施例では、第2の変化領域RA2の中で、第1の変化領域RA1に含まれている部分についてはRAM106から画像データを直接取得することによって、データ取得に要する時間を短縮している。また、第4実施例では、転送される画像データ量が第1実施例よりも更に少ない点で第1実施例よりも好ましい。
なお、多くの場合には、フック処理モジュール400によって描画される領域(第1の変化領域RA1)と、GDI124及びディスプレイドライバ126で描画される領域(第2の変化領域RA2)とは一致している。従って、第4実施例のように、第1の変化領域RA1のうちで第2の変化領域RA2に含まれない部分の画像転送を省略しても、プロジェクタ200aに表示される画像に違和感が生じる可能性は無視できる程度である。これに対して、上述した第3実施例では、第1の変化領域RA1のうちで第2の変化領域RA2に重ならない部分も画像を転送するので、仮に、第1と第2の変化領域RA1,RA2がかなり大幅に異なっている場合にも、より完全な画像を転送できるという利点がある。
なお、画像転送プログラム500aは、第3実施例の転送処理(「第1の転送モード」とも呼ぶ)と第4実施例の転送処理(「第2の転送モード」とも呼ぶ)を含む複数の転送モードの中から1つを選択して実行できるように構成されていても良い。転送モードの選択は、ユーザが行うようにしてもよく、あるいは、コンピュータ100a(一般には画像供給装置)の処理能力(CPUの処理速度やバスの転送速度など)に応じて画像転送プログラム500aが自動的に転送モードの選択を行うようにしてもよい。こうすれば、適切な転送速度で好ましい画像を転送できる転送モードを選択することが可能である。
E.第5実施例:
上述の第3実施例および第4実施例において、プロジェクタ200aがコンピュータ100aに、画面全体の画像データを要求できることとしてもよい。図20は、このような要求に応じる処理の手順を示すフローチャートである。
最初のステップS500では、判断モジュール540(図9)が、リクエスト問い合わせを発行する。この処理は、図10のステップS310と同じである。
プロジェクタ200aのディスパッチャ226(図9)は、受信したSCSIコマンドのOPコードが「D9h」でありUDコマンドコードが「00h」であるので(S504:Yes、S508:Yes)、受信したデータを状態チェックモジュール250に供給する。なお、UDコマンドコードが「00h」とは異なる場合には、UDコマンドコードに応じた処理が実行される(例えば、UDコマンドコードが「80h」である場合には、画像表示処理が実行される)。また、OPコードが「D9h」とは異なる場合には、OPコードに応じた処理が実行される(例えば、ディスクイメージ224に対するアクセス中継処理が実行される)。
状態チェックモジュール250は、リクエスト問い合わせを受信したことに応じて、コンピュータ100aに送信すべきデータをRAM206(図2)から検索する(S512)。第5実施例では、状態チェックモジュール250は、入力部210(図2)を介してユーザから全画面取得指示を受けた場合には、全画面送信コマンドを表すコマンドデータを、送信すべきデータとしてRAM206(図2)に格納することとしている。このような全画面取得指示は、プロジェクタ200aによる表示画面に乱れが生じた場合に、ユーザによって発行され得る。
このようなコマンドデータがRAM206から検出された場合には、状態チェックモジュール250は、検出されたコマンドデータをコンピュータ100aに送信し、そして、正常応答をコンピュータ100aに送信する(S520、S524)。一方、送信すべきデータが検出されなかった場合には、状態チェックモジュール250は、要求の無いことを表すデータをコンピュータ100aに送信し、そして、正常応答をコンピュータ100aに送信する(S530、S534)。ステップS520、S530の処理は、図10のステップS370と同様に行われ、ステップS524、S534の処理は、図10のステップS374と同様に行われる。
コンピュータ100aによって受信されたデータは、判断モジュール540に供給される。判断モジュール540は、全画面送信コマンドを受信した場合には(S540:Yes)、次のステップS550で、全画面の画像データを送信する指示を、各モジュール510、520、530に対して発行する。その結果、全画面の画像データがプロジェクタ200aに送信され(S550)、プロジェクタ200aは、正しい全画面を表示する(S554)。一方、全画面送信コマンドが受信されなかった場合には(S540:No)、判断モジュール540は、処理を終了する。
判断モジュール540は、上述したステップS500〜S550の一連の処理を定期的に実行する。なお、これらの一連の処理は、コンピュータ100aが表示用データ送信処理完了の応答を受信した後から(例えば、図5のS238)、次の表示用データの送信が開始されるまで(例えば、図5のS204)の間に実行される。
このように、第5実施例では、画像転送プログラム500aが、プロジェクタ200aからの要求に応じて全画面の画像データを送信するので、ユーザの利便性を向上させることができる。
なお、プロジェクタ200aからコンピュータ100aへ送信される要求としては、画面全体の画像データの送信要求に限らず任意の要求を採用可能である。例えば、画像転送プログラム500aの動作設定(例えば、画像データの送信頻度)を変更する要求を採用してもよい。ここで、状態チェックモジュール250が、複数種類の要求を発行することとしてもよい。この場合には、要求を識別する情報をコンピュータ100aに送信すればよい。判断モジュール540は、この要求識別情報に応じて、要求された処理を実行すればよい。一般には、判断モジュール540は、プロジェクタ200aからの要求に応じて、要求された所定の処理を実行すればよい。ここで、プロジェクタ200aによる自発的なデータ送信が可能な場合には、判断モジュール540による要求問い合わせを省略してもよい。また、状態チェックモジュール250は、ユーザの指示が無い場合であっても、自動的に要求を発行してもよい。例えば、状態チェックモジュール250は、定期的に全画面送信要求を発行してもよい。また、ユーザの指示を受け取る入力部210(図2)としては、操作ボタンを含む装置に限らず、ユーザによって操作されるリモコンを介して指示を受け取る装置を採用してもよい。
F.変形例:
なお、上記各実施例における構成要素の中の、独立クレームでクレームされた要素以外の要素は、付加的な要素であり、適宜省略可能である。また、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
変形例1:
上述の各実施例において、コンピュータ100、100aによって識別されるプロジェクタ200、200aのデバイス種類としては、「マスストレージクラス」に限らず、汎用デバイスのための種々の種類(クラス)を採用可能である。このような汎用デバイスのためのクラスでは、通信プロトコルが標準化されているので、画像供給装置と画像表示装置との間のデータ通信を容易に行うことができる。また、このようなクラスのドライバは、広く普及している場合が多く、しばしば、USBインターフェースを有する種々の装置に予め組み込まれている。従って、専用のドライバをインストールせずに、画像供給装置と画像表示装置とのデータ通信を行うことができる。また、専用ドライバの開発を省略することもできる。これらの結果、画像表示装置を利用するための労力を軽減することが可能となる。
ここで、コンピュータ100、100aからプロジェクタ200、200aへのデータ転送速度が過剰に遅くならないように設計されたクラスを採用することが好ましい。例えば、「オーディオ(Audio)」と、「マスストレージ(Mass Storage)」と、「コミュニケーションデバイス(Communication Device)」と、の中から任意に選択されたものを採用可能である。
なお、本発明は、USBの将来のバージョンにも適用可能である。また、インターフェースとしては、USBに限らず、複数種類の汎用デバイスに任意に接続可能な種々の汎用インターフェースを採用可能である。いずれの場合も、プロジェクタ200、200a2が汎用デバイスとして識別されることが好ましい。ここで、汎用デバイスとは、インターフェースの標準のプロトコルを利用してデータ通信を行うデバイスを意味している。標準のプロトコルとしては、そのインターフェースの規格団体によって標準化されたものを採用してもよく、また、業界の実質的な標準のものを採用してもよい。
変形例2:
上記各実施例において、ディスクイメージ224(図3、図9)を省略してもよい。この場合には、コンピュータ100、100aで実行されるプログラムを、インターネットや他の記録媒体から取得すればよい。ただし、上記各実施例のようにプロジェクタ200、200aに、コンピュータ100、100aからアクセス可能なデータ記憶部(例えば、ディスクイメージ224)を設ければ、データ記憶部に格納された種々のデータをコンピュータ100、100aに提供することができる。この際、表示用データの送信に利用される通信コマンドは、データ記憶装置のための通信プロトコルで利用されるコマンドの内の、データ記憶部のデータリードのためのコマンドとは異なる所定のコマンドであることが好ましい。こうすれば、表示用データの転送と、データ記憶部のリードとを、両立させることができる。
なお、データ記憶装置のための通信プロトコルで利用されるコマンドの内の、データリードのためのコマンドと、画像転送プログラム500によって発行されるコマンド(特に、表示用データの送信コマンド)と、のいずれとも異なるコマンド(例えば、ライト(WRITE)コマンド)が発行された場合にプロジェクタ200、200aによって実行される処理としては、任意の処理を採用可能である。例えば、ディスパッチャ226が、エラー応答をコンピュータ100、100aに送信してもよい。また、ディスパッチャ226が、受信データをSCSIドライバ232に供給することによって、データ管理モジュール230に応答させてもよい。
また、記憶領域に予め格納しておくデータとしては、プロジェクタ200、200aの取扱説明書等の任意のデータを採用可能である。ただし、上記各実施例のように、プロジェクタ200、200aに対して画像データ(表示用データ)を送信する機能をコンピュータ100、100aに実現させるためのプログラムを採用することが好ましい。こうすれば、画像データを送信するためのプログラムを、容易にコンピュータ100、100aに提供することができるので、プロジェクタ200、200aを利用するための労力を軽減することができる。ここで、画像データの送信に利用されるプログラム(モジュール)の内の、記憶領域に格納しておくものとしては、任意に選択されたものを採用可能である。例えば、標準的にコンピュータ100、100aに組み込まれているモジュールについては、省略してもよい。図9、図12の例で、プロジェクタドライバ128が標準的にコンピュータ100aに組み込まれている場合には、ディスクイメージ224のプロジェクタドライバ128を省略してもよい。
変形例3:
上記各実施例において、変化領域のみをキャプチャする方法としては、図12〜図18に示した第3実施例の方法や、図19に示した第4実施例の方法に限らず、任意の方法を採用可能である。例えば、キャプチャモジュール510が、VRAM114を監視し続けることによって、変化した領域を検出してもよい。この場合には、キャプチャモジュール510は、VRAM114から変化領域の画像データを取得すればよい。また、図17で説明したような最適化処理を省略してもよい。この場合には、キャプチャモジュール510は、最適化前の画面更新領域TTGを包含するような矩形形状の画像をキャプチャすればよい。このように、キャプチャされる画像は、変化した領域よりも大きくてもよい。ただし、画面全体の内の変化した領域を含む一部の画像であることが好ましい。
また、コンピュータ100、100aからプロジェクタ200、200aへ供給される表示用データとしては、上記実施例で使用したもの以外の種々のものを使用することが可能である。例えば、表示用データとして、少なくとも画像データを含むものを使用することができる。具体的には、例えば、画面全体の画像データを転送する場合には、ヘッダ(変化領域情報)を転送する必要は無い。
また、表示用データとしては、変化領域(画面更新領域)の位置及びサイズを示す情報と、変化領域内の画像データとを少なくとも含むことが好ましい。この理由は、変化領域に関するデータ(変化領域情報及びその画像データ)のみを転送すれば、転送すべきデータ量が少なくなるからである。
変形例4:
上記各実施例において、プロジェクタ200、200aによって表示される画面としては、表示デバイス118によって表示されている画面に限らず、任意の画面を採用可能である。例えば、コンピュータ100、100a上で動作している特定のアプリケーションによって描画される画像のみをプロジェクタ200、200aで表示することとしてもよい。この場合には、キャプチャモジュール510が、そのアプリケーションによって描画される画像をキャプチャすればよい。
変形例5:
上記各実施例では、SCSIコマンドセットを利用している。従って、プロジェクタ200、200aからコンピュータ100、100aへ種々のデータ(例えば、図10:S370の状態データや、図20:S520のコマンドデータ)を送信する場合であっても、データサイズは、SCSIのイニシエータに相当するコンピュータ100、100aによって決められる(上記各実施例では所定のサイズに設定されている)。ここで、送信すべきデータのサイズが大きい場合には、データの一部がプロジェクタ200、200aに残る場合がある。このような場合には、コンピュータ100、100aに転送されるデータ内に残存データのサイズを書き込んでおき、コンピュータ100、100aは、残存データの全てを受信するまで、プロジェクタ200、200aにデータを送信させる処理を繰り返し実行すればよい。
変形例6:
表示用データや状態データ、コマンドデータを転送する通信手順としては、上記各実施例の手順に限らず、種々の手順を採用可能である。例えば、図14のステップS26で、図8の例と同様に、表示用データを分割して送信してもよい。また、上記各実施例では、データ通信にSCSIコマンドセットが利用されていたが、データ通信に利用されるコマンドセットとしては、任意のものを採用可能である。また、データ通信の手順としても、採用されたコマンドセットに適した手順を採用すればよい。
変形例7:
上記実施例では、第2の転送領域TG2(図16(C),図19(C))の画像部分をVRAM114から取得して一旦RAM106内の画像データ格納領域106b内に書き込んだ後で、RAM106から画面更新領域TTGの画像を取得してインターフェースを介して転送することとしていたが、画像データ格納領域106bに書き込む処理を省略することも可能である。但し、上記実施例の手順によれば、インターフェースを介して最終的に画像を転送する際に、画像を1つの画像データ格納領域106bから取得できるので、処理が単純になるという利点がある。
変形例8:
上記実施例では、描画モジュールがGDI124とディスプレイドライバ126とプロジェクタドライバ128の3つのモジュールに分かれていたが、モジュールの区分は任意であり、これらの機能を1つのモジュールにまとめることも可能である。また、ディスプレイドライバ126とプロジェクタドライバ128の機能を1つのモジュールにまとめることも可能である。
変形例9:
上記実施例においては、画像供給装置としてパーソナルコンピュータを用いていたが、この代わりに、他の種類のコンピュータ(モバイルコンピュータ、ハンドヘルドコンピュータ、ワークステーションなど)を用いるようにしても良い。また、これらコンピュータの他に、インターフェースを有するとともに、コンピュータと同様な機能を有する機器を用いるようにしても良い。そのような機器には、例えば、情報携帯端末や、携帯電話機や、メール端末や、ゲーム機や、セットトップボックスなどが含まれる。また、画像表示装置としては、プロジェクタ以外の種々の表示装置を使用することが可能である。
変形例10:
上記実施例においてソフトウェアで実現されている機能の一部をハードウェアで実現してもよく、あるいは、ハードウェアで実現されている機能の一部をソフトウェアで実現してもよい。