以下に、本願の開示する情報処理装置、画像送信プログラムおよび画像表示方法の実施例を図面に基づいて詳細に説明する。なお、本実施例によりこの発明が限定されるものではない。
[システム構成]
図1は、本実施例に係るシンクライアントシステムについて説明する。図1は、実施例に係るシンクライアントに含まれる各装置の構成を示すブロック図である。
図1に示すシンクライアントシステム1は、クライアント端末20が表示する画面をリモートでサーバ装置10に制御させるものである。つまり、シンクライアントシステム1は、実際にはサーバ装置10が実行した処理結果や保持するデータをクライアント端末20に表示させつつも、あたかもクライアント端末20が主体となって処理を実行したり、データを保持したりしているかのように振る舞う。
図1に示すように、シンクライアントシステム1は、サーバ装置10と、クライアント端末20とを有する。なお、図1の例では、1つのサーバ装置10に対し、1つのクライアント端末を接続する場合を図示したが、任意の数のクライアント端末を接続できる。
これらサーバ装置10およびクライアント端末20は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、LAN(Local Area Network)やVPN(Virtual Private Network)などの任意の種類の通信網を採用できる。なお、サーバ装置10およびクライアント端末20間の通信プロトコルには、一例として、VNCにおけるRFB(Remote Frame Buffer)プロトコルを採用する場合を想定する。
サーバ装置10は、クライアント端末20に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置10には、サーバ向けリモート画面制御用のアプリケーションがインストールまたはプレインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションをサーバ側リモート画面制御用アプリと呼ぶ。
このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一例としては、サーバ側リモート画面制御用アプリは、クライアント端末20における操作情報を取得したうえでその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成したうえでその画面をクライアント端末20へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末20で表示させていたビットマップ画像との間で変更のあった部分の画像が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
また、サーバ側リモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末20へ送信する機能も有する。一例としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度が閾値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末20へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をMPEG−2やMPEG−4などのMPEG方式のデータにエンコードしたうえでクライアント端末20へ送信する。なお、ここでは、MPEG(Moving Picture Experts Group)方式のデータ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばMotion−JPEG(Joint Photographic Experts Group)などを採用できる。
クライアント端末20は、サーバ装置10によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末20の一例としては、パーソナルコンピュータなど固定端末のほか、携帯電話機、PHS(Personal Handyphone System)やPDA(Personal Digital Assistant)などの移動体端末を適用することもできる。このクライアント端末20には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションをクライアント側リモート画面制御用アプリと呼ぶ。
このクライアント側リモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置10へ通知する機能を有する。一例としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリックを始め
、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの位置や移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
さらに、クライアント側リモート画面制御用アプリは、サーバ装置10から受信した画像を所定の表示部に表示させる機能を有する。一例としては、クライアント側リモート画面制御用アプリは、サーバ装置10から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一例としては、クライアント側リモート画面制御用アプリは、サーバ装置10から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。そのうえで、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードしたうえでブランク領域に表示する。
[サーバ装置の構成]
次に、本実施例に係るサーバ装置の構成について説明する。図1に示すように、サーバ装置10は、OS実行制御部11aと、アプリ実行制御部11bと、グラフィックドライバ12と、フレームバッファ13と、サーバ側リモート画面制御部14とを有する。なお、図1の例では、図1に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスなどの機能を有するものとする。
OS実行制御部11aは、OS(Operation System)の実行を制御する処理部である。例えば、OS実行制御部11aは、後述の操作情報取得部14aにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。一例としては、OS実行制御部11aは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部11bへ指示する。他の一例としては、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、OS実行制御部11aは、そのコマンドの実行をアプリ実行制御部11bへ指示する。なお、以下では、アプリケーションをアプリと略記する。
アプリ実行制御部11bは、OS実行制御部11aによる指示に基づき、アプリケーションの実行を制御する処理部である。一例としては、アプリ実行制御部11bは、OS実行制御部11aによりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部11bは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ13に描画する要求を後述のグラフィックドライバ12へ行う。このようにグラフィックドライバ12へ描画要求を行う場合には、アプリ実行制御部11bは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ12へ通知する。
なお、アプリ実行制御部11bが実行するアプリは、プリインストールされたものであってもよく、サーバ装置10の出荷後にインストールされたものであってもかまわない。また、JAVA(登録商標)などのネットワーク環境で動作するアプリであってもよい。
グラフィックドライバ12は、フレームバッファ13に対する描画処理を実行する処理部である。一例としては、グラフィックドライバ12は、アプリ実行制御部11bからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ13上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、OS実行制御部11aからの描画要求を受け付けることもできる。一例としては、グラフィックドライバ12は、OS実行制御部11aからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをOSにより指定されたフレームバッファ13上の描画位置ビットマップ形式で描画する。
フレームバッファ13は、グラフィックドライバ12により描画されたビットマップデータを記憶する記憶デバイスである。かかるフレームバッファ13の一態様としては、VRAM(Video Random Access Memory)を始めとするRAM(Random Access Memory)、ROM(Read Only Memory)やフラッシュメモリなどの半導体メモリ素子が挙げられる。なお、フレームバッファ13は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
サーバ側リモート画面制御部14は、サーバ側リモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末20へ提供する処理部である。図1に示すように、サーバ側リモート画面制御部14は、操作情報取得部14aと、画面生成部14bと、変更頻度判別部14cと、高頻度変更領域識別部14dと、エンコーダ14eと、第1の画像送信部14fと、第2の画像送信部14gとを有する。また、サーバ側リモート画面制御部14は、属性情報送信部14hと、コピーイベント制御部14kと、全画面動画化判定部14mとを有する。さらに、サーバ側リモート画面制御部14は、高頻度画面更新領域識別部14nと、画面更新通知部14oとを有する。
操作情報取得部14aは、クライアント端末20から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの位置や移動量などが上げられる。操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。
画面生成部14bは、クライアント端末20の表示部22に表示させる画面の画像を生成する処理部である。一例としては、画面生成部14bは、グラフィックドライバ12によりフレームバッファ13へビットマップデータが格納される度に、次のような処理を起動する。すなわち、画面生成部14bは、前回のフレーム生成時にクライアント端末20で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ13へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部14bは、前回のフレームから変更があった部分の画素をつなぎ合わせたうえで矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。なお、画面生成部14bは、後述するエンコーダ14eよりも画像劣化が低くなるように、フレームバッファ13の画像を圧縮するものとしても良い。
変更頻度判別部14cは、フレームバッファ13に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部14cは、画面生成部14bにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部14cは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、1秒間にわたって更新矩形の画像を蓄積する場合を想定する。
このとき、変更頻度判別部14cは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末20に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。
図2は、デスクトップ画面の分割要領を説明するための図である。図2に示す符号30は、変更頻度判別用のマップを示す。図2に示す符号31は、マップ30に含まれるメッシュを指す。図2に示す符号32は、メッシュ31を形成する画素のブロックに含まれる1画素を指す。図2に示す例では、変更頻度判別部14cがマップ30を占める画素のうち8画素×8画素のブロックを1つのメッシュとして分割する場合を想定している。この場合には、1つのメッシュに64個の画素が含まれることになる。
ここで、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部14cは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部14cは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を1つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と1つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。
図3A〜図3Cは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図3A〜図3Cに示す符号40A、符号40Bおよび符号40Nは変更頻度判別用のマップを示す。図3Aおよび図3Bに示す符号41Aおよび符号41Bは更新矩形を示す。ここで、マップ40Aのメッシュ内に図示した数字は、更新矩形41Aが展開された時点におけるメッシュの変更回数を示す。また、マップ40Bのメッシュ内に図示した数字は、更新矩形41Bが展開された時点におけるメッシュの変更回数を示す。さらに、マップ40Nのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図3A〜図3Cにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。
図3Aに示すように、更新矩形41Aがマップ40Aに展開された場合には、網掛け部分のメッシュが更新矩形41Aと重なり合う。このため、変更頻度判別部14cは、網掛け部分のメッシュの更新回数を1つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は0から1に加算される。さらに、図3Bに示すように、更新矩形41Bがマップ40Bに展開された場合には、網掛け部分のメッシュが更新矩形40Bと重なり合う。このため、変更頻度判別部14cは、網掛け部分のメッシュの更新回数を1つずつ加算する。この場合には、各メッシュの変更回数は1であるため、網掛け部分の変更回数は1から2に加算される。このようにして全ての更新矩形がマップに展開された段階では、図3Cに示すマップ40Nの結果が得られる。
そして、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度が閾値を超えるメッシュを取得する。図3Cの例で言えば、閾値を「4」としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述のエンコーダ14eによりエンコードできる。なお、上記の「閾値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
図1の説明に戻り、高頻度変更領域識別部14dは、クライアント端末20に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。
高頻度変更領域識別部14dは、変更頻度判別部14cにより変更回数が閾値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体に補完する補間領域を導出する。そのうえで、高頻度変更領域識別部14dは、導出した補完領域をメッシュ連結体に足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。
図4は、メッシュ連結体の補正要領を説明するための図である。図4に示す符号51は補正前のメッシュ連結体を示す。図4に示す符号52は補間領域を示す。また、図4に示す符号53は補正後の矩形を示す。図4に示すように、高頻度変更領域識別部14dは、メッシュ連結体51に補間領域52を足し合わせることにより、メッシュ連結体51を矩形53に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形53が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。
高頻度変更領域識別部14dは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部14dは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出する。そのうえで、高頻度変更領域識別部14dは、導出した補間領域を高頻度変更領域の候補に足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。
図5は、高頻度変更領域の候補の合成要領を説明するための説明図である。図5に示す符号61Aおよび符号61Bは、高頻度変更領域の候補を指す。図5に示す符号62は補間領域を指す。図5に示す符号63は、高頻度変更領域の候補61Aおよび高頻度変更領域の候補61Bの合成体を指す。図5に示すように、高頻度変更領域識別部14dは、高頻度変更領域の候補61Aおよび高頻度変更領域の候補61Bの距離dが所定の距離以内である場合に補間領域62を足し合わせる。これにより、高頻度変更領域の候補61Aおよび高頻度変更領域の候補61Bを含む合成体63へ合成する。そして、高頻度変更領域識別部14dは、このようにして得た合成体を高頻度変更領域と識別する。
このようにして高頻度変更領域を識別すると、高頻度変更領域識別部14dは、高頻度変更領域の位置および大きさを特定可能な属性情報を後述の属性情報送信部14hへ出力する。このようにして属性情報送信部14hに高頻度変更領域の属性情報をクライアント端末20へ通知させることにより、クライアント端末20で表示されるデスクトップ画面のビットマップデータのうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部14dは、作業用の内部メモリにマッピングされたメッシュの変更回数を後述の全画面動画化判定用マップに加算したうえでクリアする。なお、高頻度変更領域識別部14dは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。
また、高頻度変更領域識別部14dは、画面生成部14bにより更新矩形が生成される度に、その更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち後述の第2の画像送信部14gにより動画を送信中の領域に含まれるか否かを判定する。このとき、高頻度変更領域識別部14dは、更新矩形が高頻度変更領域に含まれない場合には、更新矩形の画像および属性情報を後述の第1の画像送信部14fに送信させる。一方、高頻度変更領域識別部14dは、更新矩形が高頻度変更領域に含まれる場合には、原則として、後述の第1の画像送信部14fに更新矩形の画像および属性情報を送信させない。なお、更新矩形がOS実行制御部11aにより描画されたマウスのものである場合には、マウスに関する更新矩形の画像および属性情報を例外的に送信させることとしてもよい。
また、高頻度変更領域識別部14dは、フレームバッファ13にビットマップデータが描画される度に、作業用の内部メモリの高頻度変更領域の属性情報が登録されているか否かを判定する。そして、高頻度変更領域識別部14dは、高頻度変更領域の属性情報が登録されている場合に、フレームバッファ13に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出す。そのうえで、高頻度変更領域識別部14dは、後述のエンコーダ14eへ出力する。
エンコーダ14eは、画像をエンコードする処理部である。一例として、高頻度変更領域識別部14dから高頻度変更領域の画像が入力される画像をエンコードする場合が挙げられる。この場合には、エンコーダ14eは、高頻度変更領域識別部14dから入力された高頻度変更領域のビットマップ画像がストリームを形成可能なフレーム数に到達した段階で高頻度変更領域のビットマップ画像をエンコードする。なお、エンコード方式の一態様としては、MPEG−2やMPEG−4などのMPEG方式やMotion−JPEG方式が挙げられる。
第1の画像送信部14fは、画面生成部14bにより生成された更新矩形の画像および属性情報をクライアント端末20へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例として、VNCにおけるRFBプロトコルが採用される。
第2の画像送信部14gは、エンコーダ14eによりエンコードされたエンコード画像および属性情報をクライアント端末20へ送信する処理部である。このエンコード画像を送信する場合の通信プロトコルには、一例として、RTP(Real-time Transport Protocol)を採用できる。
属性情報送信部14hは、画像の属性情報をクライアント端末20へ送信する処理部である。一例としては、高頻度変更領域識別部14dにより高頻度変化領域が識別されると、属性情報送信部14hは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信する。これにより、クライアント端末20で表示されるデスクトップ画面のビットマップデータのうち高頻度変更領域に対応する部分をブランク表示させる。
図6A〜図6Cは、高頻度変更領域の属性情報の通知要領を説明するための図である。図6Aに示す符号70Aは、フレームバッファ13に描画されたデスクトップ画面の一例を示す。図6B〜図6Cに示す符号70Bおよび符号70Cは、変更頻度判別用のマップを示す。図6Aに示す符号71は、ブラウザ画面を指す。図6Aに示す符号72は、動画再生画面を指す。図6Bに示す符号73は、マウスの移動軌跡を示す。図6Bに示す符号74は、アプリによる動画再生領域を示す。
図6Aに示すように、デスクトップ画面70Aには、ブラウザ画面71および動画再生画面72が含まれる。このデスクトップ画面70Aから経時的な変化を追った場合には、図6Bに示すように、静止画であるブラウザ画面71の更新矩形は検出されず、マウスの移動軌跡73および動画再生領域74に関する更新矩形が検出される。このうち、動画再生領域74で変更回数が閾値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部14dにより識別されたものとする。この場合には、属性情報送信部14hは、図6Cに示す網掛け部分の高頻度変更領域の左上の頂点の座標(x、y)と、高頻度変更領域の幅wおよび高さhとを高頻度変更領域の属性情報としてクライアント端末20へ送信する。なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸XYの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。
このように、サーバ装置10では、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別する。さらに、サーバ装置10では、高頻度変更領域以外の領域については変更があった部分の画像を送信しつつ、高頻度変更領域についてはその領域に対応する画像を動画向けの圧縮方式のデータに圧縮する。それゆえ、サーバ装置10では、クライアント端末20へ送信する画像のうち操作レスポンスを悪化させる根本となる画像に重点を置いてデータ量を低減しつつ、圧縮処理を行うエンコーダ、端末装置側で復号化処理を行うデコーダの負荷を最小限にできる。このため、サーバ装置10では、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることが可能になる。
ところが、サーバ装置10では、高頻度変更領域を識別するには一定の時間が必要となる。このため、フレームバッファ13へ描画される画像のフレーム間で動きが激しい変更が描画されたとしても変更が短期間である場合には、その変更が行われた領域を高頻度変更領域として識別することはできない。
例えば、ウィンドウが移動された場合には、ウィンドウの動きを追従することができず、クライアント端末20で動画をスムーズに表示できない場合がある。図7は、ウィンドウが移動する場合にサーバ装置がクライアント端末へ送信する画像の送信方式の一例を示す図である。図7の例では、動画アプリが動画を再生している場合にそのウィンドウのタイトルバーがドラッグ&ドロップされる場合を想定している。
図7に示すように、動画アプリにより動画が再生される時刻T1前までは、ウィンドウは停止しているので、フレーム間の変更部分が更新矩形の画像としてサーバ装置10からクライアント端末20へ送信される。そして、時刻T1となって動画アプリによる動画の再生が開始される。その後、時刻T2となった段階でサーバ装置10によりウィンドウが高頻度変更領域と識別されてウィンドウの画像が動画でクライアント端末20へ送信され始める。
ところが、時刻T3になった段階でウィンドウのタイトルバーをドラッグ&ドロップすることにより移動され始める。そうすると、動きの激しい部分がウィンドウの移動に伴って一緒に移動するので、動画再生中であるにもかかわらず、ウィンドウは高頻度変更領域とは識別されなくなる。その後、時刻T4になってウィンドウの移動が停止されてからも時刻T5になるまで、ウィンドウは高頻度変更領域とは識別されない。そして、ようやく時刻T5になってサーバ装置10によりウィンドウが高頻度変更領域と識別されてウィンドウの画像が動画でクライアント端末20へ送信され始める。
このように、ウィンドウが移動された場合には、網掛け部分の期間にわたって動画アプリにより再生される動画が更新矩形としてクライアント端末20へ送信されるので、操作レスポンスが低下する。
かかるウィンドウの移動に対応するために、本実施例に係るサーバ装置10では、コピーイベントを発生させることにより、ウィンドウの移動を追従することとした。ここで、コピーイベントとは、実際のウィンドウが移動された場合にウィンドウと擬似的にみなしたコピー領域をマウスの移動軌跡にしたがって移動させることにより、ウィンドウの移動にコピー領域を追従させるイベントを指す。
すなわち、本実施例に係るサーバ装置10では、ウィンドウの移動に追従するコピー領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信するとともに、フレームバッファ13上でコピー領域に描画される画像を動画化して送信する。
これによって、大量の更新矩形を発生させずに動きが激しいコピー領域の画像を圧縮してクライアント端末20へ送信できるので、ウィンドウが移動した場合の操作レスポンスが改善される。
しかしながら、ウィンドウの移動がクライアント端末20の画面の大部分に及ぶ場合などには、画面のうちコピー領域の一部だけ動画化してクライアント端末20へ送信した方が全画面を動画化する場合よりもサーバ装置10の負荷が重くなる場合がある。なぜなら、上述の高頻度変更領域を識別するには、所定の時間にわたって蓄積した更新矩形をメモリ上にマッピングする必要があるからである。特に、スマートフォンなどの小型の携帯端末の場合には、画面のサイズ自体が小さいので、全画面を動画化した方が有効である場合がある。
そこで、本実施例に係るサーバ装置10では、フレームバッファ13に描画した画面の更新部分をクライアント端末20へ送信する際に、ウィンドウの移動によって画面内の更新面積や更新頻度が閾値以上になった場合には全画面を動画化して送信する。これによって、本実施例に係るサーバ装置10では、全画面を動画化した方がサーバ装置10の処理負荷が軽くなる場合に全画面を動画化することができる。よって、本実施例に係るサーバ装置10によれば、ウィンドウ移動のレスポンスを向上できる。
ところで、クライアント端末20により動画が再生された画像は、更新矩形が再生された画像と比較して劣化する。このため、サーバ装置10は、動画の送信が終了した際に、動画の領域に対応した更新矩形を送信する場合がある。この場合、サーバ装置10は、仮に全画面を動画化して送信すると、動画の送信が終了した際に、全画面の領域に対応した更新矩形を送信することとなる。すると、動画の送信が終了した際に、送信帯域が増加してしまう。
そこで、さらに、本実施例に係るサーバ装置10では、ウィンドウの移動によって画面内の更新面積や更新頻度が閾値以上になった場合には全画面を動画化して送信しつつ、全画面の中で実際に変化のあった更新領域を送信する。さらに、本実施例に係るサーバ装置10では、画面の更新開始から更新終了までの更新領域を積算しておき、動画の送信が終了した際に、積算した更新領域における更新矩形を送信する。これによって、本実施例に係るサーバ装置10では、動画の送信が終了した際に、動画中に更新した領域に制限して更新矩形を送信することができる。よって、本実施例に係るサーバ装置10によれば、動画の送信が終了した際の送信帯域の増加を軽減できる。
図1の説明に戻り、上記のコピーイベントを実現するコピーイベント制御部14kと、全画面の動画化を実現する全画面動画化判定部14mとについて説明する。このうち、コピーイベント制御部14kは、コピーイベントの発生、実行および終了を制御する処理部である。
かかるコピーイベントを発生させる契機について説明する。コピーイベント制御部14kは、高頻度変更領域識別部14dにより識別された高頻度変更領域が所定のサイズ、例えば50×50ピクセル以上であるか否かを判定する。このとき、高頻度変更領域が所定のサイズ以上である場合には、コピーイベント制御部14kは、特定のマウスイベントが検出されたか否か、例えばドラッグ&ドロップが操作情報取得部14aにより取得されているか否かをさらに判定する。そして、特定のマウスイベントが検出された場合には、コピーイベント制御部14kは、コピーイベントを発生させる。なお、ここでは、マウスイベントによりコピーイベントの発生可否を判定する場合を説明したが、タブレットやキーボードの操作からコピーイベントの発生可否を判定するようにしてもよい。
このように、一定のサイズ以上の高頻度変更領域が存在する場合には、フレームバッファ13に動画を含むウィンドウが描画されている可能性が高まる。かかる状況でウィンドウを移動させる操作が取得された場合には、動画を含むウィンドウを移動させる操作がなされていると推定できる。よって、OSから特段の情報を収集せずとも、コピーイベントを適切なタイミングで発生させることができる。
次に、コピーイベントを終了させる契機について説明する。コピーイベント制御部14kは、特定のマウスイベントが検出されたか否かを判定する。そして、特定のマウスイベントが検出されなくなった場合、すなわちウィンドウの移動操作が終了された場合には、コピーイベント制御部14kは、コピーイベントを終了させる。なお、ウィンドウの移動操作が終了された場合には、ドラッグ操作に含まれる左クリックが解除された旨の操作情報が後述の操作情報取得部14aにより取得される。また、マウスカーソルの更新矩形が所定の期間にわたって通知されなくなった場合もウィンドウの移動操作が終了されたと言える。
次に、コピーイベントで実行される処理内容について説明する。コピーイベント制御部14kは、操作情報取得部14aによりマウスの移動量が取得された場合に、前回にコピーイベントを実行したコピー領域の位置と、今回に取得されたマウスの移動量とから今回のコピー領域の位置を算出する。なお、コピー領域の位置および大きさは、高頻度変更領域と同様に、左上の頂点の座標で位置が規定されるとともに高頻度変更領域の幅wおよび高さhで大きさが規定されるものとする。
図8は、コピー領域の位置を算出する方法を説明するための図である。図8に示す「i=0」の領域は、時刻t0にコピーイベントを実行したコピー領域であり、コピーイベント発生時の高頻度変更領域の属性情報、すなわち左上の座標(x0、y0)と高頻度変更領域の幅wおよび高さhと同じである。図8に示す「i=1」の領域は、時刻t1にコピーイベントを実行したコピー領域である。図8に示す「i=2」の領域は、時刻t2にコピーイベントを実行したコピー領域である。
例えば、図8に示す時刻t1のコピー領域の位置は、時刻t0のコピー領域の座標(x0、y0)に時刻t1に取得したマウスの移動量を加算することにより、左上の頂点の座標が(x1、y1)と算出される。例えば、図8に示す時刻t2のコピー領域の位置は、時刻t1のコピー領域の座標(x1、y1)に時刻t2に取得したマウスの移動量を加算することにより、左上の頂点の座標が(x2、y2)と算出される。なお、コピー領域の幅および高さは、高頻度変更領域の幅wおよび高さhが各更新カウントのコピー領域で引き継がれる。
このようにして、コピー領域の属性情報が算出された後に、コピーイベント制御部14kは、コピー領域の属性情報を属性情報送信部14hへ出力する。この属性情報送信部14hによりコピー領域の属性情報がクライアント端末20へ送信される。
また、コピーイベント制御部14kは、コピー領域の属性情報をエンコーダ14eへ出力する。そして、フレームバッファ13に描画されたビットマップ画像のうち、コピー領域に対応する位置および大きさの画像がエンコーダ14eにより順次エンコードされる。その後、第2の画像送信部14gによりエンコード画像がクライアント端末20へ送信される。
全画面動画化判定部14mは、フレームバッファ13に描画された画面全体を動画化するか否かを判定する処理部である。この全画面動画化判定部14mは、コピーイベントが発生している場合に、作業用の内部メモリにマッピングされた全画面動画化判定用マップを用いて、移動面積Atおよび更新頻度Ctを算出する。ここで、移動面積Atとは、画像のフレーム間における変更が累積して更新された面積を指す。また、更新頻度Ctとは、画像のフレーム間における変更の頻度を指す。なお、コピーイベントが発生していない場合には、ウィンドウが移動しておらず、サーバ装置10の処理負荷が重くなりにくいので、全画面の動画化の要否は判定しない。この場合には、全画面動画化判定用マップをクリアする。
図9は、ウィンドウが移動する一態様を示す図である。図9に示す符号200は、全画面動画化判定用マップを指す。図9に示す符号200Aは、ウィンドウが時刻t0に所在した位置を示す。図9に示す符号200Bは、ウィンドウが時刻t1に所在した位置を示す。図9に示す符号200Cは、ウィンドウが時刻t2に所在した位置を示す。図9に示す符号200Dは、ウィンドウが時刻t3に所在した位置を示す。
図10A〜図10Cは、更新頻度と移動頻度を説明するための図である。図10A、図10Bおよび図10Cに示す符号210B、符号210Cおよび符号210Dは、全画面動画化判定用マップを示す。網掛け部分は、コピーイベントが発生してから更新矩形が1度でも検出されたメッシュを指し、全てのメッシュを足し合わせた数が移動面積Atとなる。全画面動画化判定用マップ210B、210Cおよび210Dのメッシュ内に図示した数字は、メッシュ内の更新頻度を指し、全てのメッシュを足し合わせた数が更新頻度Ctとなる。
図10Aの例では、図9に示したウィンドウが時刻t1にあるときの全画面動画化判定用マップ210Bを表す。図10Aの例で言えば、全画面動画化判定部14mは、網掛け部分のメッシュを足し合わせることにより移動面積Atを「22」と算出するとともに、メッシュ内の数字を足し合わせることにより更新頻度Ctを「49」と算出する。
図10Bの例では、図9に示したウィンドウが時刻t2にあるときの全画面動画化判定用マップ210Cを表す。図10Bの例で言えば、全画面動画化判定部14mは、網掛け部分のメッシュを足し合わせることにより移動面積Atを「36」と算出するとともに、メッシュ内の数字を足し合わせることにより更新頻度Ctを「82」と算出する。
図10Cの例では、図9に示したウィンドウが時刻t3にあるときの全画面動画化判定用マップ210Dを表す。図10Cの例で言えば、全画面動画化判定部14mは、網掛け部分のメッシュを足し合わせることにより移動面積Atを「42」と算出するとともに、メッシュ内の数字を足し合わせることにより更新頻度Ctを「98」と算出する。
このようにして、移動面積Atおよび更新頻度Ctを算出した後に、全画面動画化判定部14mは、更新頻度Ctが閾値C未満であるか否かを判定する。このとき、更新頻度Ctが閾値C未満である場合には、全画面動画化判定部14mは、移動面積Atが閾値A2未満であるか否かをさらに判定する。一方、更新頻度Ctが閾値C以上である場合には、全画面動画化判定部14mは、移動面積Atが閾値A1未満であるか否かをさらに判定する。
このように、更新頻度Ctが閾値C未満である場合には、移動面積Atと比較する閾値A2とし、また、更新頻度Ctが閾値C以上である場合には、閾値A2よりも小さい閾値A1の値に変更するのは、次のような理由である。その理由とは、動画を含むウィンドウはある程度の移動があれば全画面を動画化し、静止画であるウィンドウは多少の移動では動画化しないように判定ロジックとし、サーバ装置10の負荷を最小化するためである。
ここで、更新頻度Ctと比較する閾値Cは、図9に示したウィンドウに動画が含まれるか否かを判定できる値であることが好ましい。また、移動面積Atと比較する閾値A1は、動画が含まれるウィンドウの移動が全画面を動画化した場合におけるサーバ装置10の処理負荷を超える値であることが好ましい。また、移動面積Atと比較する閾値A2は、静止画であるウィンドウの移動が全画面を動画化した場合におけるサーバ装置10の処理負荷を超える値であることが好ましい。なお、閾値A1と閾値A2の関係は、A1<A2であるものとする。
例えば、閾値Cを「50」、閾値A1を「30」、閾値A2を「50」であると仮定する。図10Aの例では、更新頻度Ctが「49」であるので、更新頻度Ct<閾値Cとなり、移動面積Atが「22」であるので、移動面積At<閾値A2となる。このため、図9に示したウィンドウは時刻t1の段階では動画化されない。図10Bの例では、更新頻度Ctが「82」であるので、更新頻度Ct≧閾値Cとなり、移動面積Atが「36」であるので、移動面積At≧閾値A1となる。このため、図9に示したウィンドウは時刻t2の段階で全画面を動画化すると判定する。なお、図9に示したウィンドウは時刻t2の段階で全画面が動画化されるので、実際には時刻t3における更新頻度Ct「98」および移動面積At「42」の算出や全画面動画化の要否が判定されることはない。
そして、全画面動画化判定部14mは、移動面積Atが閾値A1以上である場合または移動面積Atが閾値A2以上である場合に、全画面を動画化すると判定する。この場合に、全画面動画化判定部14mは、フレームバッファ13に描画された画面全体をエンコードの対象とするようにエンコーダ14eへ指示する。そして、フレームバッファ13に描画されたビットマップ画像全体がエンコーダ14eにより順次エンコードされる。その後、第2の画像送信部14gによりエンコード画像がクライアント端末20へ送信される。なお、全画面の動画化は、特定のマウスイベントが検出されなくなった場合、すなわちウィンドウの移動が終了した場合に、元の更新矩形を送信する形態に戻す。
高頻度画面更新領域識別部14nは、全画面動画化の間、全画面動画領域の中から実際に変化した更新領域を識別する処理部である。例えば、高頻度画面変化領域検出部14nは、前回にコピーイベントを実行したコピー領域の位置および大きさと、今回にコピーイベントを実行したコピー領域の位置とから前回から今回までに変化した更新領域の属性情報を算出する。なお、前回から今回までに変化した更新領域は、矩形で表されるものとする。
図11A〜図11Bは、更新領域の属性情報の算出を説明するための図である。図11Aおよび図11Bに示す符号220Bおよび符号220Cは、全画面動画化判定用マップを示す。図11Aの網掛け部分は、時刻t2にコピーイベントを実行したコピー領域と時刻t3にコピーイベントを実行したコピー領域を指す。図11Bの網掛け部分は、時刻t2にコピーイベントを実行したコピー領域、時刻t3にコピーイベントを実行したコピー領域および時刻t4にコピーイベントを実行したコピー領域を指す。
図11Aの例では、ウィンドウが時刻t3にあるときの全画面動画化判定用マップ220Bを表す。図11Aの例で言えば、高頻度画面更新領域識別部14nは、時刻t2にコピーイベントを実行したコピー領域の位置および大きさと時刻t3にコピーイベントを実行したコピー領域の位置とから時刻t2から時刻t3までに変化した更新領域の属性情報を算出する。ここでは、時刻t2のコピー領域は、左上の頂点の座標を(x0、y0)とし、幅をwとし、高さをhとする。また、時刻t3のコピー領域は、左上の頂点の座標を(x1、y1)とする。すると、高頻度画面更新領域識別部14nは、前回の時刻t2から今回の時刻t3までに変化した更新領域を、左上の頂点の座標を(x0、y1)、幅を「w+(x1−x0)」、高さを「h+(y1−y0)」として算出する。
図11Bの例では、ウィンドウが時刻t4にあるときの全画面動画化判定用マップ220Cを表す。図11Bの例で言えば、高頻度画面更新領域識別部14nは、時刻t3にコピーイベントを実行したコピー領域の位置および大きさと時刻t4にコピーイベントを実行したコピー領域の位置とから時刻t3から時刻t4までに変化した更新領域の属性情報を算出する。ここでは、時刻t3のコピー領域は、左上の頂点の座標を(x1、y1)とする。また、時刻t3のコピー領域の大きさは、時刻t2のコピー領域の大きさと同じである。さらに、時刻t4のコピー領域は、左上の頂点の座標を(x2、y2)とする。すると、高頻度画面更新領域識別部14nは、前回の時刻t3から今回の時刻t4までに変化した更新領域を、左上の頂点の座標を(x1、y2)、幅を「w+(x2−x1)」、高さを「h+(y2−y1)」として算出する。
そして、高頻度画面更新領域識別部14nは、全画面動画化の間、更新領域が算出される度に、その更新領域を積算して積算更新領域を算出する。ここで、全画面動画化の間とは、全画面動画化が開始される場合のコピーイベントが発生してから全画面動画化が終了される場合のコピーイベントが発生しなくなるまでをいう。例えば、高頻度画面更新領域識別部14nは、全画面動画化の間、コピーイベントが発生中に、コピーイベントが発生する度に算出される更新領域を積算して積算更新領域の属性情報を算出する。なお、積算更新領域は、矩形で表されるものとする。
図12A〜図12Bは、積算更新領域の属性情報の算出を説明するための図である。図12Aおよび図12Bに示す符号230Bおよび符号230Cは、全画面動画化判定用マップを示す。図12Aの網掛け部分は、時刻t2にコピーイベントを実行したコピー領域と時刻t3にコピーイベントを実行したコピー領域を指す。図12Aに示す符号230B1は、時刻t2から時刻t3までの更新領域を指す。図12Bの網掛け部分は、時刻t2にコピーイベントを実行したコピー領域、時刻t3にコピーイベントを実行したコピー領域および時刻t4にコピーイベントを実行したコピー領域を指す。図12Bに示す符号230C1は、時刻t2から時刻t3までの更新領域を指す。図12Bに示す符号230C2は、時刻t3から時刻t4までの更新領域を指す。なお、ここでは、時刻t2に全画面動画化が開始される場合のコピーイベントが発生したものとする。
図12Aの例では、ウィンドウが時刻t3にあるときの全画面動画化判定用マップ230Bを表す。図12Aの例で言えば、高頻度画面更新領域識別部14nは、全画面動画化が開始される場合のコピーイベントが時刻t2で最初に発生したので、時刻t2の次のコピーイベントが発生した時刻t3で算出される更新領域230B1を積算更新領域とする。ここでは、積算更新領域は、時刻t2から時刻t3までの更新領域と一致し、左上の頂点の座標を(x0、y1)、幅を「w+(x1−x0)」、高さを「h+(y1−y0)」と算出される。
図12Bの例では、ウィンドウが時刻t2にあるときの全画面動画化判定用マップ230Bを表す。図12Bの例で言えば、高頻度画面更新領域識別部14nは、時刻t3で算出される更新領域230C1と時刻t4で算出される更新領域230C2とを積算して積算更新領域とする。ここでは、積算更新領域は、左上の頂点の座標を(x0、y2)、幅を「w+(x2−x0)」、高さを「h+(y2−y0)」と算出される。
画面更新通知部14oは、全画面動画化の間、更新領域の属性情報を第2の画像送信部14gに通知する。その後、第2の画像送信部14gは、エンコーダ14eにより画面全体がエンコードされた動画画像と、画面更新通知部14oにより通知された更新領域の属性情報とをクライアント端末20に送信する。
また、画面更新通知部14oは、全画面動画化の終了時に、積算更新領域の更新矩形の画像および属性情報を第1の画像送信部14fに通知する。例えば、画面更新通知部14oは、コピーイベント制御部14kからコピーイベントの終了が通知されると、全画面動画化の終了を判定し、画面生成部14bにより生成された積算更新領域の更新矩形の画像および属性情報を第1の画像送信部14fに通知する。その後、第1の画像送信部14fは、積算更新領域の更新矩形の画像をクライアント端末20に送信する。
なお、OS実行制御部11a、アプリ実行制御部11b、グラフィックドライバ12、サーバ側リモート画面制御部14には、各種の集積回路や電子回路を採用できる。また、サーバ側リモート画面制御部14に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)が挙げられる。また、電子回路としては、CPU(Central Processing Unit)やMPU(Micro Processing Unit)などが挙げられる。
[クライアント端末の構成]
次に、本実施例に係るクライアント端末の構成について説明する。図1に示すように、クライアント端末20は、入力部21と、表示部22と、クライアント側リモート画面制御部23とを有する。なお、図1の例では、図1に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。
入力部21は、各種の情報、例えば後述のクライアント側リモート画面制御部23に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部22も、マウスと協働して、ポインティングデバイス機能を実現する。
表示部22は、各種の情報、例えばサーバ装置10から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。
クライアント側リモート画面制御部23は、クライアント側リモート画面制御用アプリを通じて、サーバ装置10によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部23は、図1に示すように、操作情報通知部23aと、第1の画像受信部23bと、第1の表示制御部23cと、第2の画像受信部23dと、デコーダ23eと、第2の表示制御部23fとを有する。
操作情報通知部23aは、入力部21による操作情報をサーバ装置10へ通知する処理部である。一例として、操作情報通知部23aは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの位置や移動量などを操作情報として通知する。他の一例としては、操作情報通知部23aは、マウスホールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
第1の画像受信部23bは、サーバ装置10の第1の画像送信部14fにより送信された更新矩形の画像および属性情報を受信する処理部である。また、第1の画像受信部23bは、サーバ装置10の属性情報送信部14hにより送信された高頻度変更領域の属性情報またはコピー領域の属性情報を受信する。
第1の表示制御部23cは、第1の画像受信部23bにより受信された更新矩形の画像を表示部22に表示させる処理部である。一例としては、第1の表示制御部23cは、第1の画像受信部23bにより受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部22の画面領域に更新矩形のビットマップ画像を表示させる。
他の一例としては、第1の表示制御部23cは、第1の画像受信部23bにより高頻度変更領域の属性情報またはコピー領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第1の表示制御部23cは、高頻度変更領域の属性情報またはコピー領域の属性情報に含まれる位置および大きさに対応する表示部22の画面領域をビットマップ画像の表示対象外のブランク領域とする。
更なる一例としては、第1の表示制御部23cは、第1の画像受信部23bにより積算更新領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第1の表示制御部23cは、全画面動画化の終了時に、積算更新領域の属性情報に含まれる位置および大きさに対応する表示部22の画面領域に、更新矩形のビットマップ画像を表示させる。
第2の画像受信部23dは、サーバ装置10の第2の画像送信部14gにより送信された高頻度変更領域またはコピー領域のエンコード画像を受信する処理部である。また、第2の画像受信部23dは、サーバ装置10の第2の画像受信部14gにより送信された全画面のエンコード画像および全画面の中で実際に変化のあった更新領域の属性情報を受信する。
デコーダ23eは、第2の画像受信部23dにより受信された高頻度変更領域、コピー領域または全画面のエンコード画像をデコードする処理部である。なお、デコード23e
には、サーバ装置10に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。
第2の表示制御部23fは、デコーダ23eによりデコードされたデコード画像をそのまま表示部22に表示させる処理部である。
一例としては、デコーダ23eから入力されるデコード画像が高頻度変更領域のデコード画像である場合には、第2の表示制御部23fは、第1の表示制御部23cによりブランク領域とされた表示部22の画面領域にデコード画像を表示させる。
他の一例としては、デコード23eにより入力されるデコード画像がコピー領域のデコード画像である場合には、第2の表示制御部23fは、第1の表示制御部23cによりブランク領域とされた表示部22の画面領域にデコード画像を表示させる。
更なる一例としては、デコーダ23eにより入力されるデコード画像が全画面のデコード画像である場合には、第2の表示制御部23fは、全画面のデコード画像を表示部22に表示させる。
第3の表示制御部23gは、デコーダ23eによりデコードされたデコード画像を属性情報に合わせて表示部22に表示させる処理部である。一例としては、デコーダ23eから入力されるデコード画像が属性情報の大きさと一致しない場合には、第3の表示制御部23gは、全画面動画化中であると判定する。そして、第3の表示制御部23gは、全画面のデコード画像から、実際に変化のあった更新領域に係る属性情報の位置および大きさに対応する部分のデコード画像を切り出したうえで、当該デコード画像を表示部22に表示させる。
[処理の流れ]
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。図13および図14は、実施例に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置10により実行される処理であり、フレームバッファ13にビットマップデータが描画された場合に起動する。
図13に示すように、フレームバッファ13にビットマップデータが描画されると、画面生成部14bは、前回のフレームから変更があった部分の画素をつなげ合わせたうえで矩形に整形した更新矩形の画像を生成する(ステップS101)。そして、画面生成部14bは、先に生成した更新矩形の画像から更新矩形送信用のパケットを生成する(ステップS102)。
続いて、変更頻度判別部14cは、画面生成部14bにより生成された更新矩形を図示しない作業用の内部メモリへ蓄積する(ステップS103)。なお、コピー領域の更新矩形は、高頻度変更領域の識別に関する処理量を削減するために、作業用の内部メモリには蓄積されない。
そして、コピーイベント中の領域に含まれる更新矩形ではない場合(ステップS104否定)には、変更頻度判別部14cは、更新矩形の蓄積を開始してから所定の期間が経過したか否かを判定する(ステップS105)。
このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合(ステップS105否定)には、以降に続く高頻度変更領域の識別に関する処理をとばし、後述のステップS116へ移行する。
一方、更新矩形の蓄積を開始してから所定の期間が経過した場合(ステップS105肯定)には、変更頻度判別部14cは、次のような処理を行う。すなわち、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する(ステップS106)。そして、変更頻度判別部14cは、変更頻度判別用のマップに含まれるメッシュのうち変更頻度が閾値を超えるメッシュを取得する(ステップS107)。
その後、高頻度変更領域識別部14dは、変更頻度判別部14cにより変更頻度が閾値を超えるメッシュが取得されたか否かを判定する(ステップS108)。このとき、変更頻度が閾値を超えるメッシュが存在しない場合(ステップS108否定)には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップS113へ移行する。
一方、変更頻度が閾値を越えるメッシュが存在する場合(ステップS108肯定)には、高頻度変更領域識別部14dは、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する(ステップS109)。
そして、高頻度変更領域識別部14dは、補正後の矩形、すなわち高頻度変更領域の候補が複数存在するか否かを判定する(ステップS110)。このとき、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合(ステップS110肯定)には、高頻度変更領域識別部14dは、次のような処理を行う。すなわち、高頻度変更領域識別部14dは、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する(ステップS111)。なお、高頻度変更領域の候補が複数存在しない場合(ステップS110否定)には、矩形の合成を行わずにステップS112へ移行する。
続いて、高頻度変更領域識別部14dは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信する(ステップS112)。そして、高頻度変更領域識別部14dは、作業用の内部メモリにマッピングされたメッシュの変更回数を全画面動画化判定用マップに加算したうえでクリアする(ステップS113)。
そして、コピーイベント制御部14kによるコピーイベントが発生していない場合(ステップS114否定)には、全画面動画化判定部14mは、全画面動画化判定用マップをクリアする(ステップS115)。
その後、高頻度変更領域識別部14dは、画面生成部14bにより生成された更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち第2の画像送信部14gにより動画を送信中の領域に含まれるか否かを判定する(ステップS116)。
このとき、更新矩形が高頻度変更領域に含まれない場合(ステップS116否定)には、第1の画像送信部14fは、更新矩形の画像および属性情報をクライアント端末20へ送信し(ステップS117)、処理を終了する。
一方、更新矩形が高頻度変更領域に含まれる場合(ステップS116肯定)には、コピーイベント制御部14kは、高頻度変更領域が所定のサイズ以上であるか否かを判定する(ステップS118)。なお、高頻度変更領域が所定のサイズ未満である場合(ステップS118否定)には、コピーイベントを発生させずにステップS121へ移行する。
このとき、高頻度変更領域が所定のサイズ以上である場合(ステップS118肯定)には、コピーイベント制御部14kは、特定のマウスイベントが検出されたか否かをさらに判定する(ステップS119)。なお、特定のマウスイベントが検出されなかった場合(ステップS119否定)には、コピーイベントを発生させずにステップS121へ移行する。
そして、特定のマウスイベントが検出された場合(ステップS119肯定)には、コピーイベント制御部14kは、コピーイベントを発生する(ステップS120)。そして、高頻度変更領域識別部14dは、フレームバッファ13に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出したうえでエンコーダ14eにエンコードさせる(ステップS121)。そして、エンコーダ14eによりエンコードされた高頻度変更領域のエンコード画像をクライアント端末20へ送信し(ステップS122)、処理を終了する。
先のステップS104の判定に戻り、コピーイベント中の領域に含まれる更新矩形である場合(ステップS104肯定)には、コピーイベント制御部14kは、特定のマウスイベントが検出されたか否かを判定する(ステップS123)。
このとき、特定のマウスイベントが検出されなかった場合(ステップS123否定)には、コピーイベント制御部14kは、コピーイベントを終了し(ステップS124)、ステップS105へ移行する。
一方、特定のマウスイベントが検出された場合(ステップS123肯定)には、コピーイベント制御部14kは、次の処理を行う。すなわち、コピーイベント制御部14kは、今回にコピーイベントが実行されるよりも1つ前のコピー領域の位置と、今回に取得したマウスの移動量とから今回にコピーイベントを実行するコピー領域の位置を算出する(ステップS125)。
続いて、属性情報送信部14hは、コピー領域の属性情報をクライアント端末20へ送信する(ステップS126)。そして、第2の画像送信部14gは、エンコーダ14eによりコピー領域がエンコーダされたエンコーダ画像をクライアント端末20へ送信し(ステップS127)、処理を終了する。
先のステップS114の判定に戻り、コピーイベントが発生している場合(ステップS114肯定)に、全画面動画化判定部14mは、全画面動画化判定用マップを用いて、移動面積Atおよび更新頻度Ctを算出する(ステップS128)。そして、全画面動画化判定部14mは、更新頻度Ctが閾値C未満であるか否かを判定する(ステップS129)。
一方、更新頻度Ctが閾値C以上である場合(ステップS129否定)には、全画面動画化判定部14mは、移動面積Atが閾値A1未満であるか否かをさらに判定する(ステップS130)。なお、移動面積Atが閾値A1未満である場合(ステップS130肯定)には、ステップS116へ移行する。
このとき、更新頻度Ctが閾値C未満である場合(ステップS129肯定)には、全画面動画化判定部14mは、移動面積Atが閾値A2未満であるか否かをさらに判定する(ステップS131)。なお、移動面積Atが閾値A2未満である場合(ステップS131肯定)には、ステップS116へ移行する。
ここで、移動面積Atが閾値A1以上である場合または移動面積Atが閾値A2以上である場合(ステップS130否定またはステップS131否定)には、次のような処理を行う。すなわち、全画面動画化判定部14mは、全画面動画化をすべく、フレームバッファ13に描画された画面全体をエンコードの対象とするようにエンコーダ14eへ指示する(ステップS132)。
このとき、高頻度画面更新領域識別部14nは、前回にコピーイベントを実行したコピー領域の属性情報と、今回にコピーイベントを実行したコピー領域の位置とから前回から今回までに変化した更新領域の属性情報を算出する(ステップS133)。
さらに、高頻度画面更新領域識別部14nは、算出した今回の更新領域と前回までの更新領域とを積算して積算更新領域の属性情報を算出する(ステップS134)。そして、第2の画像送信部14gは、エンコーダ14eにより画面全体がエンコードされた動画画像と、画面更新通知部14oにより通知された更新領域の属性情報とをクライアント端末20に送信する(ステップS135)。
その後、コピーイベント制御部14kは、特定のマウスイベントが検出されなかったか否かを判定することによって、マウスイベントの終了の可否を判定する(ステップS136)。そして、マウスイベントが終了しないと判定された場合(ステップS136否定)には、全画面動画化の処理を繰り返すべく、ステップS132に移行する。
一方、マウスイベントが終了すると判定された場合(ステップS136肯定)には、
第1の画像送信部14fは、フレームバッファ13に描画された積算更新領域の更新矩形の画像をクライアント端末20に送信する(ステップ137)。これにより、ステップS132〜ステップS137の全画面の動画化処理は、元の更新矩形を送信する形態に戻すために処理を終了する。
なお、上記のステップS105〜ステップS113までの高頻度更新領域の識別に関する処理は、図13および図14に示したフローとは別処理として動作させることもできる。この場合には、更新矩形の蓄積を開始してから所定の期間が経過する度に処理が起動することになる。
また、上記のステップS116〜ステップS117の処理は、図13および図14に示したフローとは別処理として動作させることもできる。この場合には、画面生成部14bにより更新矩形が生成される度に処理が起動することになる。
また、上記のステップS123〜ステップS124の処理は、図13および図14に示したフローとは別処理として動作させることもできる。この場合には、フレームバッファ13にビットマップデータが描画される度に作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かが判定される。このとき、高頻度変更領域の属性情報が登録されている場合に処理が起動することになる。
図15は、実施例に係る画像表示処理の手順を示すフローチャートである。この画像表示処理は、クライアント端末20により実行される処理である。
図15に示すように、操作情報通知部23aは、マウス操作があったか否かを判定する(ステップS141)。このとき、マウス操作がなかった場合(ステップS141否定)には、マウス操作があるまで、ステップS141へ移行する。一方、マウス操作があった場合(ステップS141肯定)には、操作情報通知部23aは、マウスの操作情報をサーバ装置10に送信する(ステップS142)。
そして、第1の画像受信部23bおよび第2の画像受信部23dは、サーバ装置10からのデータがあるか否かを判定する(ステップS143)。このとき、サーバ装置10からのデータがない場合(ステップS143否定)には、第1の画像受信部23bおよび第2の画像受信部23dは、サーバ装置10からデータがあると判定するまで、ステップS141へ移行する。
一方、サーバ装置10からのデータがある場合(ステップS143肯定)であって全画面動画化でない場合(ステップS144否定)には、第1の画像受信部23bおよび/または第2の画像受信部23dは、それぞれ画像データと属性情報を受信する(ステップS145)。すなわち、第2の画像受信部23dは、高頻度変更領域またはコピー領域の動画(エンコード)データと属性情報とを受信する。また、第1の画像受信部23bは、静止画(更新矩形)データを受信する。
第2の画像受信部23dにより動画データが受信された場合には、第2の表示制御部23fは、デコーダ23eによりデコードされた動画を表示部22に表示する。また、第1の画像受信部23dにより静止画データが受信された場合には、第1の表示制御部23cは、第1の画像受信部23bにより受信された静止画データを表示部22に表示する(ステップS146)。
先のステップS144の判定に戻り、全画面動画化である場合(ステップS144肯定)には、全画面動画化が終了するまで(ステップS147否定)、第2の画像受信部23dが、全画面の動画データと更新領域の属性情報を受信する(ステップS148)。
そして、第3の表示制御部23gは、デコーダ23eによりデコードされた全画面の動画から、更新領域の属性情報に対応する部分の動画を切り出したうえで、表示部22に表示する(ステップS149)。
その後、全画面動画化が終了した場合(ステップS147肯定)には、第1の画像受信部23bは、積算更新領域の静止画(更新矩形)データを受信する(ステップS150)。そして、第1の表示制御部23cは、第1の画像受信部23bにより受信された積算更新領域の静止画データを表示部22に表示する(ステップS151)。
[実施例の効果]
上述してきたように、本実施例に係るサーバ装置10では、ウィンドウの移動によって画面内の更新面積や更新頻度が閾値以上になった場合には、全画面を動画化した動画画像と、実際に変化のあった更新領域とをクライアント端末20へ送信する。さらに、本実施例に係るサーバ装置10では、全画面動画化中の更新領域を積算して積算更新領域を算出しておき、全画面動画化の終了時に、積算更新領域における更新矩形をクライアント端末20へ送信する。これによって、本実施例に係るサーバ装置10では、全画面動画化の終了時に、全画面動画化中に変化のあった領域に制限して更新矩形を送信できるので、全画面領域の更新矩形を送信する場合と比較して、送信帯域の増加を軽減できる。
[適用範囲]
なお、上記の実施例では、更新頻度および移動面積に関する条件を満たした場合に全画面を動画化することとしたが、これ以外の条件であってもよい。例えば、画面内の変更の頻度が閾値を超えた領域、すなわち高頻度変更領域の面積が閾値以上になった場合に、全画面を動画化するようにしてもよい。この場合には、例えば、全画面動画化判定部14mは、コピーイベントが発生していない場合であっても、作業用の内部メモリにマッピングされた全画面動画化判定用マップを用いて、高頻度変更領域の面積Btを算出する。そして、全画面動画化判定部14mは、算出した高頻度変更領域の面積Btが閾値A3以上であるか否かを判定する。ここで、閾値A3は、動画が含まれる領域を動画化した場合におけるサーバ装置10の処理負荷が全画面を動画化した場合におけるサーバ装置10の処理負荷を超える値であることが好ましい。
また、全画面動画化判定部14mは、算出した高頻度変更領域の面積Btが閾値A3以上である場合に、全画面を動画化すると判定する。そして、高頻度画面更新領域識別部14nは、全画面動画化の間、画面生成部14bにより更新矩形が生成される度に更新矩形を更新領域として、更新領域の属性情報を算出する。さらに、高頻度画面更新領域識別部14nは、更新領域が算出される度に、その更新領域を積算して積算更新領域を算出する。なお、積算更新領域は、矩形で表されるものとする。
画面更新通知部14oは、全画面動画化の間、更新領域の属性情報を第2の画像送信部14gに通知する。その後、第2の画像送信部14gは、エンコーダ14eにより画面全体がエンコードされた動画画像と、画面更新通知部14oにより通知された更新領域の属性情報とをクライアント端末20に送信する。
また、画面更新通知部14oは、全画面動画化の終了時に、積算更新領域の更新矩形の画像および属性情報を第1の画像送信部14fに通知する。例えば、画面更新通知部14oは、高頻度変更領域内の更新頻度が所定量以下であるか否かを判定する。ここで、所定量は、高頻度変更領域内に動画が含まれるか否かを判定できる値であることが好ましい。そして、画面更新通知部14oは、高頻度変更領域内の更新頻度が所定量以下である場合に、全画面動画化の終了を判定し、画面生成部14bにより生成された積算更新領域の更新矩形の画像および属性情報を第1の画像送信部14fに通知する。その後、第1の画像送信部14fは、積算更新領域の更新矩形の画像をクライアント端末20に送信する。
ここで、コピーイベントが発生していない場合であっても、全画面を動画化する画像送信処理について、図16を参照して説明する。図16は、実施例に係る画像送信処理の変形例の手順を示すフローチャートである。なお、図16は、図14に示す画像送信処理内におけるS114のコピーイベント中でない場合の処理のみを抜粋している。それ以外の処理は、図13および図14で説明した処理と同様であるので、その説明を省略する。また、図14に示す画像送信処理と同一処理については同一符号を示すものとする。
コピーイベント制御部14kによるコピーイベントが発生していない場合(ステップS114否定)には、全画面動画化判定部14mは、高頻度変更領域の面積Btが閾値A3以上であるか否かを判定する(ステップS161)。ここで、高頻度変更領域の面積Btが閾値A3以上である場合(ステップS161肯定)には、次のような処理を行う。すなわち、全画面動画化判定部14mは、全画面動画化をすべく、フレームバッファ13に描画された画面全体をエンコードの対象とするようにエンコーダ14eへ指示する(ステップS132)。
このとき、高頻度画面更新領域識別部14nは、画面生成部14bにより生成された更新矩形の領域を更新領域として、更新領域の属性情報を算出する(ステップS162)。さらに、高頻度画面更新領域識別部14nは、算出した今回の更新領域と前回までの更新領域とを積算して積算更新領域の属性情報を算出する(ステップS163)。
そして、第2の画像送信部14gは、エンコーダ14eにより画面全体がエンコードされた動画画像と、画面更新通知部14oにより通知された更新領域の属性情報とをクライアント端末20に送信する(ステップS135)。
その後、画面更新通知部14oは、高頻度変更領域内の更新頻度が所定量以下であるか否かを判定する(ステップS164)。そして、高頻度変更領域内の更新頻度が所定量より大きいと判定された場合(ステップS164否定)には、全画面動画化の処理を繰り返すべく、ステップS132に移行する。
一方、高頻度変更領域内の更新頻度が所定量以下であると判定された場合(ステップS61肯定)には、第1の画像送信部14fは、フレームバッファ13に描画された積算更新領域の更新矩形の画像をクライアント端末20に送信する(ステップ137)。これにより、ステップS132〜ステップS137の全画面の動画化処理は、元の更新矩形を送信する形態に戻すために処理を終了する。
[その他]
また、上記実施例では、所定の条件を満たした場合に全画面を動画化することとしたが動画化をする範囲を全画面に限定せず、積算更新領域の範囲より大きい範囲であればよい。これによって、積算更新領域より大きい範囲における動画化終了時に、積算更新領域に制限して更新矩形を送信するので、動画化をした範囲の更新矩形を送信する場合と比較して、送信帯域の増加を軽減できる。
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
例えば、サーバ装置10の第1の画像送信部14fおよび第2の画像送信部14gが実行する画像の送信処理を1つの画像送信部に統合することとしてもよい。また、クライアント端末20の第1の画像受信部23bおよび第2の画像受信部23dが実行する画像の受信処理を1つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末20の第1の表示制御部23cおよび第2の表示制御部23fが実行する表示制御処理を1つの表示制御部に統合することとしてもよい。
また、サーバ装置10が有する操作情報取得部14a、画面生成部14b、変更頻度判別部14c、高頻度変更領域識別部14d、エンコーダ14eまたは第1の画像送信部14fは次のように構成できる。さらに、サーバ装置10が有する第2の画像送信部14g、属性情報送信部14h、コピーイベント制御部14kまたは全画面動画化判定部14m、高頻度画面更新領域識別部14nまたは画面更新通知部14oは次のように構成できる。一例としては、これらの機能部をサーバ装置10の外部装置としてネットワーク経由で接続するようにしてもよい。他の一例としては、これらの機能部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置10の機能を実現するようにしてもよい。
[画像送信プログラム]
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図17を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。図17は、実施例に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。また、ここでは、サーバ装置10と同様の機能を有する画像送信プログラムを実行するコンピュータの例を説明するが、クライアント端末20と同様の機能を有する画像表示プログラムを実行する場合も同様である。
図17に示すように、実施例におけるコンピュータ100は、操作部110aと、マイク110bと、スピーカ110cと、ディスプレイ120と、通信部130とを有する。さらに、このコンピュータ100は、CPU150と、ROM160と、HDD(Hard Disk Drive)170と、RAM(Random Access Memory)180とを有する。これら110〜180の各部はバス140を介して接続される。
ROM160には、上記の実施例で示した操作情報取得部14aと、画面生成部14bと、変更頻度判別部14cと、高頻度変更領域識別部14dと、第1の画像送信部14fと同様の機能を発揮する制御プログラムが予め記憶される。さらに、ROM160には、第2の画像送信部14gと、属性情報送信部14hと、コピーイベント制御部14kと、全画面動画化判定部14mと、高頻度画面更新領域識別部14nと、画面更新通知部14oと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ROM160には、図16に示すように、操作情報取得プログラム160aと、画面生成プログラム160bと、変更頻度判別プログラム160cと、高頻度変更領域識別プログラム160dとが記憶される。さらに、ROM160には、第1の画像送信プログラム160eと、第2の画像送信プログラム160fと、属性情報送信プログラム160gと、コピーイベント制御プログラム160hとが記憶される。さらに、ROM160には、全画面動画化判定プログラム160kと、高頻度画面更新領域識別プログラム160lと、画面更新通知プログラム160mとが記憶される。これらプログラム160a〜160mについては、図1に示したサーバ装置10の各構成要素と同様、適宜統合または分離してもよい。なお、ROM160に格納される各データは、常に全てのデータがROM160に格納される必要はなく、処理に必要なデータのみがROM160に格納されればよい。
そして、CPU150が、これらプログラム160a〜160mをROM160から読み出して実行する。これにより、CPU150は、図17に示すように、各プログラム160a〜160mについては、操作情報取得プロセス150aと、画面生成プロセス150bと、変更頻度判別プロセス150cとして機能するようになる。さらに、CPU150は、各プログラム160a〜160mについては、高頻度変更領域識別プロセス150dと、第1の画像送信プロセス150eと、第2の画像送信プロセス150fと、属性情報送信プロセス150gとして機能するようになる。さらに、CPU150は、各プログラム160a〜160mについては、コピーイベント制御プロセス150hと、全画面動画化判定プロセス150kと、高頻度画面更新領域識別プロセス150lと、画面更新通知プロセス150mとして機能するようになる。これらプロセス150a〜150mは、図1に示したサーバ装置の各部に対応する。そして、CPU150は、RAM180を用いて、画像送信プログラムを実行する。なお、CPU150上で仮想的に実現される各処理部は、常に全ての処理部がCPU150上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されればよい。
なお、上記した画像送信プログラムについては、必ずしも最初からHDD170やROM160に記憶させておく必要はない。例えば、コンピュータ100に挿入されるフレキシブルディスク、いわゆるFD、CD−ROM、DVDディスク、光磁気ディスク、ICカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ100がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、LAN、WANなどを介してコンピュータ100に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ100がこれらから各プログラムを取得して実行するようにしてもよい。