JP2007328488A - 表示装置および表示処理方法 - Google Patents

Abstract

【課題】表示装置のＧＵＩ画面に対して、ＧＵＩライブラリを変更することなく、柔軟性の高い重ね合わせ表現を行えるようにする。
【解決手段】ＧＵＩ描画は一旦、フック先バッファ５２０に対して行い、この所定位置の所定サイズの矩形領域の内容を重ね合わせスクリーンバッファ５０１〜５０４にコピーするとともに、これらのスクリーンバッファ５０１〜５０４上に重ね合わせ対象の画像をレンダリングする。スクリーンバッファ５０１〜５０４の内容はそれぞれ、オンスクリーンバッファ５１０の該当する位置にコピーされる。
【選択図】図１０

Description

本発明は、ＧＵＩ（Graphical User Interface）ライブラリを用いる表示装置および表示処理方法に関する。

ＧＵＩライブラリは、表示画面上でユーザの操作を受け付けたり案内したりするためのボタンやラベル等のＧＵＩコンポーネントを含むリソースを有し、アプリケーションからＡＰＩ（Application Program Interface）を介して利用することができるようになっている。ＧＵＩライブラリは、プラットフォーム（ＯＳやミドルウェア）が異なっても同様のＧＵＩリソース（表示部品等）が用意されていることが多いが、その呼び出し方はプラットフォームによって異なる。

ＡＰＩとは、特定のプラットフォーム（ＯＳやミドルウェア）向けのソフトウェアを開発する際に使用できる命令や関数の集合のことをいう。通常、アプリケーションから利用できる、ＯＳやプログラミング言語で用意されたライブラリなどの機能の入口となるものであり、主として、ファイル制御、ウィンドウ制御、画像処理、文字制御などのための関数として提供される。

特許文献１には、表示スクリーン上に複数のウィンドウと呼ばれる表示領域を表示し、複数のウィンドウのそれぞれにおいて、異なる処理を行うことができるようにするウィンドウシステムが開示されている。
特開２００５−３４６６１９号公報

従来の携帯端末装置などの組み込み環境におけるアプリケーションに関して、ＡＰＩとＧＵＩライブラリとは相互の依存度が高く、プラットフォームが変わるとＧＵＩライブラリに合わせてＡＰＩが変わり、これに伴ってアプリケーションも書き直す必要があった。

特に、ＧＵＩ画面に対して、柔軟性の高い重ね合わせ表現を行おうとする場合にも、ＧＵＩライブラリを変更する必要が生じる。

本発明はこのような背景において、表示装置のＧＵＩ画面に対して、ＧＵＩライブラリを変更することなく、柔軟性の高い重ね合わせ表現を行えるようにするものである。

本発明は、また、ＡＰＩとＧＵＩライブラリの相互の独立性を高め、アプリケーションの移植性およびＧＵＩリソースの再利用性を向上させようとするものである。

本発明による表示装置は、表示デバイスの表示画面上に画像を表示する表示手段と、前記表示画面の全体に対応する第１のスクリーンの内容を記憶する第１のスクリーンバッファと、ＧＵＩリソースを有するＧＵＩライブラリと、前記ＧＵＩリソースを利用したＧＵＩ画像の描画の展開先となるフック先バッファと、前記第１のスクリーンバッファにコピーされるべき第２のスクリーンに対応する画像を記憶する第２のスクリーンバッファと、前記第２のスクリーンバッファに前記フック先バッファの内容をコピーするとともに任意の画像を重ね合わせて書き込む重ね合わせ手段とを備えたことを特徴とする。

ＧＵＩ画像の描画自体はフック先バッファに対して行われ、重ね合わせ手段によるＧＵＩ画像に対する任意の画像の重ね合わせは第２のスクリーンバッファに対して行われるので、重ね合わせ対象の画像を変化させる場合でもＧＵＩ画像への影響はなく、ＧＵＩ画像の描画自体をやり直す必要はない。表示デバイスの表示画面には第１のスクリーンバッファの内容が反映されるのに対して、第２のスクリーンバッファ上で重ね合わせが行われ、その結果が第１のスクリーンバッファに転送されるので、重ね合わせ処理が完了した後に当該転送を行うことにより、重ね合わせ後の画像を表示に反映させることができる。

前記重ね合わせ手段は、例えば、前記第２のスクリーンバッファにおいて、前記フック先バッファに描画されたＧＵＩ画像に任意の画像を重ね合わせて描画するためにアプリケーションに提供される重ね合わせＡＰＩと、異なるＧＵＩライブラリをアプリケーションが利用する場合にも、前記重ね合わせＡＰＩを共通のインターフェイスで前記ＧＵＩライブラリに仲介するＧＵＩ依存モジュールインターフェイスとを備え、特定のＧＵＩライブラリに対して、前記ＧＵＩ依存モジュールインターフェイスのルールに基づいて当該ＧＵＩライブラリに対する入出力を定めるＧＵＩ依存モジュールが個別に用意される。ＧＵＩ依存モジュールは、アプリケーションに対してＧＵＩライブラリが異なっても、その違いを吸収し、ＡＰＩがＧＵＩライブラリに依存しないように作用する。

本発明によれば、第１および第２のスクリーンバッファおよびフック先バッファを組み合わせ、ＧＵＩ画面に影響なく、任意の画像を重ね合わせ可能とすることにより、ＧＵＩライブラリを変更することなく、柔軟性の高い重ね合わせ表現を行えるようになる。

また、ＡＰＩがＧＵＩライブラリに依存しないため、アプリケーションの汎用性が高くなり、異なるＧＵＩ環境への移植が容易となる。また、ＧＵＩリソースの再利用性が向上する。

以下、本発明の好適な実施の形態について図面を参照しながら詳細に説明する。

図１は、本発明が適用される携帯端末装置の概略のハードウェア構成を示すブロック図である。携帯端末装置としては、携帯電話端末、ＰＤＡ、ゲーム装置等、組み込み環境におけるＧＵＩ画面を有する任意の装置でありうる。ＧＵＩ画面には、ＧＵＩ画面と独立に１以上の描画スクリーンを重ね合わせることができるようにする。

制御部４１０は、ＣＰＵ等のプロセッサを有し、本装置全体の制御を司る部位であり、各種のデータ処理を実行するデータ処理部を兼ねている。記憶部４２０は、プロセッサにより実行されるプログラムや各種のデータを記憶する部位であり、ＲＯＭ、フラッシュメモリ、ＲＡＭ、ＨＤＤ等を含みうる。表示部４３０は、ＬＣＤや有機ＥＬ等の表示デバイスを有し、表示画面上にテキスト、画像、動画等の情報を表示する部位である。入力部４４０は、ユーザが装置に対して指示や情報を入力するための部位であり、キーボード、マウス、タッチパネル、ジョグダイヤル等の任意の操作手段を含みうる。通信部４５０は、無線インターフェイスまたは有線インターフェイスによりネットワークと通信を行うための部位である。ネットワークとしては、携帯電話網、インターネット、ＬＡＮ等を含みうる。但し、通信部４５０は本発明の端末に必須の要素ではない。

図２は、本実施の形態におけるＧＵＩ画面への描画スクリーンの重ね合わせの概念を示す図である。これは重ね合わせの標準モードを示している。選択ボタン１１〜１４やラジオボタン１５，１６が配置されたＧＵＩ画面１０に対して、任意の描画スクリーン２０を重ね合わせて得られた表示画面２５の状態を示している。描画スクリーン２０として位置・サイズ固定の１スクリーンのみをサポートする標準的なモードである。ＧＵＩ画面に重ね合わせる描画スクリーン２０の位置はＧＵＩ画面１０の所定の位置（ここでは左上の原点座標（０，０）の位置）に固定され、サイズはそのＧＵＩ環境のスクリーンサイズを越えないこととしている。また、作成し重ね合わせた描画スクリーンのＧＵＩ画面１０に対する移動は許可しないものとする。ＧＵＩ画面１０と描画スクリーン２０とは互いに独立となっている。ここに「互いに独立」とは一方を変更するために他方を変更する必要がなく、一方のみを他方に影響なく制御できることをいう。次に説明する拡張モードに比べて、処理速度、メモリ消費量に関しては高いパフォーマンスが得られる。

図３は本実施の形態における拡張モードでの重ね合わせの概念を示している。図２に示した要素と同様の要素には同じ参照番号を付して、重複した説明は省略する。このモードは、位置・サイズ可変の複数枚の描画スクリーン３１〜３４をサポートするモードである。図の例では４個の描画スクリーン３１〜３４を用いており、ＧＵＩ画面１０上の任意の位置に重ね合わせて表示画面２６が形成される。描画スクリーン３１〜３４の各々の位置およびサイズはそのＧＵＩ環境のスクリーン（ＧＵＩ画面）内であれば任意に指定でき、描画スクリーン同士で重なっても問題ない。作成し重ね合わせた描画スクリーンは、ユーザがタッチペンなどで動的に移動可能とする。

図４は、本実施の形態におけるソフトウェアの概略の構成を示している。アプリケーション１００が、特定のＯＳ等のプラットフォーム上に用意されたＧＵＩライブラリ３２０ａ，３２０ｂ，３２０ｃにより構成される異なるＧＵＩ環境に対して、これらのＧＵＩ環境とは独立に任意の描画スクリーンを重ね合わせて利用するために、重ね合わせライブラリ２００を設けている。（ＧＵＩライブラリ３２０ａ，３２０ｂ，３２０ｃを特に区別しないときは単にＧＵＩライブラリ３２０という。他の参照符号についても同様である。）前述したように、ＧＵＩライブラリは、表示画面上でユーザの操作を受け付けたり案内したりするためのボタンやラベル等のＧＵＩコンポーネントを含むリソースを有し、アプリケーションからＡＰＩを介して利用することができるようになっている。

重ね合わせライブラリ２００は、重ね合わせＡＰＩ２１０とＧＵＩ依存モジュールインターフェイス２２０を有する。

重ね合わせＡＰＩ２１０は、任意の（１以上の）描画スクリーン（ウィンドウ）をＧＵＩ画面に重ね合わせて表示させ、その描画やイベントなどを簡単に制御するための手段である。この重ね合わせＡＰＩ２１０自体はＧＵＩライブラリ３２０に依存しないため、どのようなＧＵＩ開発環境においてもアプリケーションからの使用方法は同一にすることができる。

重ね合わせＡＰＩの具体的な関数としては、重ね合わせシステムの構築・初期化、終了・開放、重ね合わせシステムが出力先とするスクリーンの幅，高さ，ビット深さの取得、アイドリング処理間隔指定、イベントやアイドリング処理の有効化、新たな描画スクリーンの作成・追加、描画スクリーンの除去・破棄、描画スクリーンのオフスクリーンバッファの取得、タッチパネル等のイベントの有効化／無効化、描画スクリーンの座標の変更、描画スクリーンに対するアイドラの登録、ハンドラの登録、等を含む。

ＧＵＩ依存モジュールインターフェイス２２０は、異なるＧＵＩライブラリをアプリケーションが利用する場合にも、共通の重ね合わせＡＰＩ２１０を共通のインターフェイスでＧＵＩライブラリセットに仲介する手段であり、個々のＧＵＩライブラリには依存しない。

一方、各ＧＵＩライブラリ３２０ａ，３２０ｂ，３２０ｃには、それぞれ、ＧＵＩ依存モジュール３１０ａ，３１０ｂ，３１０ｃが個別に設けられ、それぞれ、ＧＵＩライブラリセットＡ，Ｂ，Ｃ（３００ａ，３００ｂ，３００ｃ）を構成している。これらの各ＧＵＩ依存モジュールは、個々のＧＵＩライブラリに対して個別に用意され、共通のＧＵＩ依存モジュールインターフェイスのルールに基づいて当該ＧＵＩライブラリに対する入出力を定める。すなわち、ＧＵＩ依存モジュール３１０が、個々のＧＵＩ環境の違いを吸収する役割を担っている。

以下、本実施の形態における重ね合わせ表現を実現するために行う処理を説明する。

本実施の形態における重ね合わせ手法は、ＧＵＩ環境に依存しない。すなわち、ＧＵＩ環境の情報をアプリケーションが共通のインターフェイスで得ることができる様にしている。ＧＵＩ環境情報としては以下のような情報があり、アプリケーションは、重ね合わせＡＰＩ２１０を介して、ＧＵＩ環境情報を問い合わせて確認する。
（ａ）ＧＵＩ環境が出力先とするスクリーンのサイズ（幅および高さ）
（ｂ）ＧＵＩ環境のスクリーンピクセルのビット深度
（ｃ）拡張モードの適用の可否

＜重ね合わせシステム全体の構築＞
本手法では、任意の描画スクリーンを登録する前に、重ね合わせシステム全体の構築を行う。重ね合わせシステムの構築としては、上述した「標準モード」および「拡張モード」の２種類のシステム構成を用意しており、それを構築の際に選択して使い分ける。

＜描画スクリーンの登録＞
図５に模式的に示すように、描画スクリーン（重ね合わせスクリーン）の管理はリスト構造によって実現している。アプリケーション１００から重ね合わせＡＰＩ２１０に対して描画スクリーンの作成を指定すると、重ね合わせＡＰＩ２１０は、ＧＵＩ依存モジュール３１０に対して描画スクリーンの作成を依頼する。個々の描画スクリーンが登録されると、ＧＵＩ環境に互換性のある描画スクリーンが作成され、リストに追加して管理される。本手法では、その作成作業をＧＵＩ依存モジュール３１０において行うことで、アプリケーション１００が直接ＧＵＩライブラリに依存することを回避している。また、図１０に示すように、登録されたスクリーンに関連付けられたアイドラおよびハンドラ（これらについては後述する）などもここでまとめて管理できるようにしている。

図７に、各重ね合わせスクリーン（描画スクリーン）を定義するための重ね合わせスクリーン定義情報５５０を例示する。重ね合わせスクリーン定義情報５５０は、「フック先バッファヘのポインタ」「座標（位置情報）」「サイズ」「アイドラ関数ポインタ」「入力イベントハンドラの関数ポインタ」「入力イベントが有効か無効かのフラグ」「リストコネクション」等を含む。

「座標（位置情報）」は重ね合わせスクリーンの原点（例えば左上点が位置するＧＵＩ画面上の座標である。「サイズ」は重ね合わせスクリーンの幅および高さである。「アイドラ関数ポインタ」はアイドラ関数を指し示すポインタである。「入力イベントハンドラ関数ポインタ」は入力イベントハンドラ関数を指し示すポインタである。「入力イベントが有効か無効かのフラグ」は入力イベントを有効に設定されているか無効に設定されているかを示すフラグである。「リストコネクション」は、リスト同士のつながりを示す情報である。なお、アイドラ関数およびハンドラ関数は重ね合わせライブラリ２００内に記憶されている。

図８に示すように、ＧＵＩ環境がＧＵＩコンポーネント５３０を出力するもともとの出力先であるスクリーンバッファ５１０（オンスクリーンバッファと呼ぶ）を本明細書では第１のスクリーンバッファという。「フック先バッファヘのポインタ」は、図８に示すように、スクリーンバッファ５１０ではなく、その前段に設けられ、重ね合わせシステムが内部的に確保した、ＧＵＩコンポーネントを展開して保持するためのフック先バッファ５２０を指し示すポインタである。フック先バッファ５２０に展開された画像データは所定のタイミングでスクリーンバッファ５１０にコピーされる。

図９に示すように、標準モードでは、ＧＵＩ画像の描画のフック先バッファ５２０の描画データは、一旦、唯一の重ね合わせスクリーンバッファ５００（第２のスクリーンバッファ）にコピーされ、かつ、この重ね合わせスクリーンバッファ５００に対して、重ね合わせシステムによる任意のレンダリング（描画）が行われる。ここでは、ＧＵＩ画面にキャラクタ２１を重ね合わせる例を示している。この重ね合わせスクリーンバッファ５００の画像データは、完成後に所定のタイミング（例えば毎秒６０フレームの一定周期）でスクリーンバッファ５１０にコピーされる。重ね合わせスクリーンバッファ５００は、オンスクリーンバッファに対してオフスクリーンバッファという。

図１０は、拡張モードにおける複数の重ね合わせスクリーンバッファ５０１〜５０４の作用を示している。ＧＵＩ描画のフック先バッファ５２０上に設定された指定サイズの複数のウィンドウ５２１〜５２４の矩形領域の画像をそれぞれ重ね合わせスクリーンバッファ５０１〜５０４にコピーするとともに、任意の画像（ここではキャラクタ３１〜３４）を重ねてレンダリングする。その後、所定のタイミングでそれぞれの重ね合わせスクリーンバッファ（第２のスクリーンバッファ）５０１〜５０４の内容をオンスクリーンバッファであるスクリーンバッファ５１０の当該位置へコピーする。重ね合わせスクリーンバッファ５０１〜５０４もオフスクリーンバッファである。複数のウィンドウ５２１〜５２４の矩形領域の位置は手動または自動で移動可能に制御される。

＜描画管理＞
図５で説明したように、アプリケーションによって登録された１つあるいは複数の重ね合わせスクリーンは、リスト構造として管理される。

前述したように、本手法では、本来のＧＵＩ画面と完全に独立して、かつ一貫性を持った更新を行えるように、ＧＵＩ描画を重ね合わせシステムによってＧＵＩ画面を一旦フック先バッファ５２０に描画し、このフック先バッファでの管理下に置く処理を行っている。

ＧＵＩ描画をフック先バッファに描画する理由は次のとおりである。

ＧＵＩコンポーネントの描画をＧＵＩ環境に任せた状態では、重ね合わせスクリーンを更新および描画する際に、期待する結果が得られない場合がある。それは、ＧＵＩ描画スクリーンのクリアを重ね合わせシステムで制御できないと、一定の間隔で更新が必要な場合にＧＵＩコンポーネントと重ね合わせ対象の画像とをうまく合成できないからである。そのため、本手法では内部的にＧＵＩ描画のフック先バッファを用意し、そちらへＧＵＩ環境がコンポーネントを描画するように設定する。このフック先バッファには重ね合わせ対象の画像は何ら書かれないので、ＧＵＩ画面の描画内容自体が重ね合わせによる影響を受けることはない。

（標準モード）
標準モードでは、重ね合わせスクリーンの位置およびサイズが固定であるため、拡張モードに比べてシンプルな方法で描画を行う。そのため、バッファ間の複写等も少なく、処理速度は速い。

（拡張モード）
拡張モードでは、基本的には標準モードと同じ方法で描画を行うが、前述のように、複数のスクリーンに対して個別にコピーおよびレンダリングが実施されるので、標準モードに比べて処理速度は低下する。

＜イベント管理＞
本手法でのイベント処理は、アイドリング処理（一定時間間隔で周期的に実行される処理）と、マウスやタッチペンなどによる入力に対してのイベント処理の二つを制御する。また、どちらの処理に関しても、本手法は複数（あるいは唯一）の描画スクリーンに対して一括的に制御を行っている。

＜アイドリング処理＞
図６に示したように、本手法では、重ね合わせの対象となる描画スクリーンごと１枚につき、１つのアイドラ関数を登録できる。それぞれのアイドラ関数は、全て重ね合わせシステムに唯一のアイドリング間隔に基づいて連続でコールされる。なお、本手法では基本的にこのアイドラ関数内でそれぞれに関連付けられた描画スクリーンヘの更新が行われる。この更新は、具体的には、ＧＵＩ描画のフック先バッファ５２０から重ね合わせスクリーンバッファ５００へのコピーおよび任意の画像のレンダリングを含む。つまり、この一定時間間隔でコールされる関数によって、アニメーションなど動的な変化をもつレンダリングを可能とする。

＜入力イベント処理＞
本手法では、表示スクリーンに対して行われた入力イベントは全て一度重ね合わせシステムによって受け取られる。そしてシステムは登録済みの描画スクリーンの中から入力されたポイントと対応する矩形のスクリーンを検索し、イベント処理が許可されたもののみに対して処理を振り分けている。ただし、各入力イベントに対するイベントハンドラが設定されていなければ処理は何も行われない。

図１１（ａ）に示すように、複数の重ね合わせスクリーンでＧＵＩ画面内の指定された矩形領域の画像に重ね合わされているスクリーンバッファ５１０に対応する表示画面上で、図示のように矢印で示されたポイントへユーザによる指示（例：タッチペンＤｏｗｎ）がなされたとき、図１１（ｂ）に示すように、このポイント５３１が属するウィンドウ５２３に対応する重ね合わせスクリーン５０３に登録された入力イベントハンドラ（例：PenDownHandler）が実行される。

図１１（ｃ）に示すように、矢印で示された別のポイントがユーザにより指示されたとき、このポイント５３２が重ね合わせスクリーンの矩形領域に属さず、かつ、ＧＵＩ部品の領域に属する場合、この指示はＧＵＩ部品に対するＧＵＩイベントとして処理される。図の例では選択ボタン１３が押されたと判断する。

また、図示しないが、複数の描画スクリーンが互いに重なっているポイントに入力がなされた場合は、後に登録されたもの（上層と把握される）を優先してイベントを描画スクリーンに振り分ける。

図１２は、本実施の形態における処理のフローチャートを示している。これはアプリケーションの処理であり、制御部４１０により実行される。まず、「標準モード」または「拡張モード」のいずれかの重ね合わせシステムを構築する（Ｓ１１）。そこで、任意の個数の重ね合わせスクリーンについて、描画スクリーン登録処理Ｓ１３を繰り返して実行する（Ｓ１２ａ〜Ｓ１２ｂ）。描画スクリーン登録処理Ｓ１３の詳細については後述する。

ついで、重ね合わせシステムを実行開始する（Ｓ１４）。その後、当該アプリケーションのメインループの処理が実行される（Ｓ１５）。メインループでは、アイドリング処理、およびユーザ操作に基づくイベント処理が実行される。

メインループの処理が終了したら、描画スクリーンを破棄し（Ｓ１６）。重ね合わせシステム（に利用したメモリ等の資源）を開放する（Ｓ１７）。

描画スクリーン登録処理では、重ね合わせスクリーンとしての描画スクリーンを作成し（Ｓ２１）、これに対応するアイドラ（アイドラ関数）の登録を行う。ついで、この描画スクリーンに対応するタッチペン入力などに対するハンドラ（ハンドラ関数）の登録を行う（Ｓ２３）。最後に、ユーザの指示に応じて入力イベントを有効（または無効）に設定する（Ｓ２４）。

図１３は、ＧＵＩ環境Ａで動作するアプリケーションを他のＧＵＩ環境Ｂに移植する場合の説明図である。ＧＵＩ環境ＡとＧＵＩ環境Ｂとはそれぞれ異なるＧＵＩライブラリＡ（３２０ａ）およびＢ（３２０ｂ）を有する。アプリケーション１００をＧＵＩ環境ＡからＧＵＩ環境Ｂへ移植する場合、その前後でアプリケーション１００および重ね合わせライブラリ２００は共通であり、なんら変更は不要である。必要なことは、ＧＵＩ依存モジュール３１０ａに代えて、ＧＵＩ環境Ｂに対応するＧＵＩ依存モジュール３１０ｂを実装することである。このように、ＧＵＩ依存モジュールを交換するだけで、アプリケーションは何ら変更することなく、異なるＧＵＩ環境への移植を行うことができる。

図１４は、描画スクリーンに対して入力イベントの有効化（ＯＮ）が行われている場合と、無効化（ＯＦＦ）が行われている場合の動作の違いの説明図である。図１４（ａ）に示すようにＧＵＩ画面に描画スクリーン３１が重ね合わせ表示されている場合、入力イベントの有効化（ＯＮ）が行われていれば、図１４（ｂ）に示すように、ユーザは描画スクリーン３１のキャラクタをタッチペン等の操作で移動させることができる。これに対して、入力イベントが無効化（ＯＦＦ）されていれば、図１４（ｃ）に示すように、ユーザによる描画スクリーン３１のキャラクタの操作はできなくなる。

図１５は本実施の形態における重ね合わせシステムで実現可能な表示画面６００の表現例を示している。

図１５（ａ）のアプリケーションはＧＵＩ画面のボタン６１１〜６１５に対して例えばエージェントを表す２次元または３次元のキャラクタ６２０（図の例ではにわとり）を重ね合わせ、タイマー設定によりアラーム表示６２１（および音声出力）のようなユーザへのアクションを行わせる表示画面６００の例を示している。これはキャラクタ６２０を描画する重ね合わせスクリーンを用いるとともに、アイドリング処理により特定の時刻でのアラーム表示６２１の追加を行うことにより実現される。

図１５（ｂ）は、図１５（ａ）と同じＧＵＩ画面上に、メモ用紙６４０をＧＵＩ画面上の任意の位置へピン留めした表示例を示している。これはユーザ操作による入力イベントに応じてメモ用紙６４０に対応する重ね合わせスクリーンを用いることにより実現される。また、この画面ではユーザが任意の文字列６５０をタッチペン６３０で画面上に記入することを許容する例を示している。これはユーザ操作による入力イベントに応じて特定の重ね合わせスクリーン上に描画を行うことにより実現される。

図１５（ｃ）は図１５（ｂ）の画面でユーザがタッチペン６３０を用いてメモ用紙６４０を画面上でドラッグ（移動）することを許容する表示例を示している。この場合、入力イベント（ドラッグ動作）に応じて当該重ね合わせスクリーンの重ね合わせスクリーン定義情報５５０（図７）内の「座標（位置情報）」が動的に更新されることになる。

図１５（ｄ）の表示例では、図１５（ｃ）のドラッグ後の画面上の一つのボタン６１３に対するユーザによるタッチペン６３０でのプッシュを入力イベントとして受け付けることができることを示している。なお、このボタン６１３の指示に応じて起動されるＧＵＩイベント処理自体は、重ね合わせシステムとは別の既存システムにより実行される。この処理は従来のＧＵＩ環境により実現される動作である。

このほか、重ね合わせスクリーンとしてＧＵＩ画面上に時計などのアクセサリの表示を行わせることも可能である。

以上説明したように、本実施の形態によれば、従来の手法と比べて次のような効果が得られる。

１．ＡＰＩがＧＵＩライブラリに非依存
ＧＵＩ依存モジュール３１０がＧＵＩライブラリ３２０の違いを吸収する構成になっており、アプリケーションの改変を必要とせずに異なるＧＵＩ環境に対して重ね合わせ表現を適用させることができる。すなわち、重ね合わせシステムのインターフェイスはその下位に存在するＧＵＩライブラリに依存しないため、アプリケーション側からはどのようなＧＵＩライブラリ環境下でも共通のＡＰＩを使用することができ、ＧＵＩライブラリが変更になった場合でもアプリケーションに対しての修正の必要がない。これはアプリケーションの移植性が高いことを意味する。例えば、あるＧＵＩ環境で本手法を用いてアプリケーションを開発し、それを他のＧＵＩ環境へ移植する必要が生じた場合、アプリケーション自体を改変せず、ＧＵＩ依存モジュールをその新しいＧＵＩ環境に合わせて実装し直すだけでよい。

２．ＧＵＩリソースの再利用性
ＧＵＩリソース（ＲＡＤツールなどで作成されたものを含む）を直接変更せず、アプリケーション側で描画およびイベントを完全に管理しているため、重ね合わせを意識してＧＵＩリソースを作成する必要がなく、ＧＵＩリソースを再利用性の高いものとして保持することができる。例えば、ＧＵＩコンポーネント（ボタンやラベルなど）に何らかの仕掛けを持ちたい場合にでも、ＧＵＩコンポーネントに対して変更や拡張を施す必要が無く、重ね合わせシステムによりアプリケーションの一機能としてＧＵＩコンポーネントを拡張することができ、ＧＵＩリソースそのものの再利用性を高めることができる。

３．描画処理の独立
任意の描画スクリーン（重ね合わせスクリーン）ヘの描画は、ＧＵＩコンポーネントの描画と完全に独立しているため、ＧＵＩ画面上にペイントしたり、他の付加情報（メモ書きなど）を配置したりした場合でも、それがＧＵＩ自体に与える影響は無く（従来のＧＵＩに対する操作性を損なうこともなく）、視覚的にダイナミックな表現もソフトウェア処理だけで比較的簡易に実現することができる。

４．イベント処理の独立
描画更新やタッチペンなどによる入力イベントがあったとしても、ＧＵＩコンポーネントの処理とは独立しているため、従来のただ表示するだけのものと違い、対話型のキャラクタや仕掛けをアプリケーションで実現することが容易となり、またＧＵＩ自体への入力を停止させる必要がない。また、描画スクリーン毎にイベントの有効化／無効化を行えるので、特定の描画スクリーンへの入力イベントを、任意に有効または無効化することができる。

５．重ね合わせシステムの高自由度
本実施の形態の重ね合わせシステムは、比較的低レベルのＡＰＩだけで構成することができるため、自由度が高く、アプリケーションにおいて本システムを使用することで、ハードウェアに依ることなくユーザの工夫次第で様々な表現を可能にすることができる。また、この重ね合わせ表現は、機能的にもＧＵＩから完全に独立しているため、ソフトウェア処理のみによって使用者に対しあらゆるカスタマイズを許可し、自由度が高く、工夫次第で様々な面白さを提供することができる。

以上、本発明の好適な実施の形態について説明したが、上記で言及した以外にも種々の変形、変更を行うことが可能である。

本発明が適用される携帯端末装置の概略のハードウェア構成を示すブロック図である。 本発明の実施の形態におけるＧＵＩ画面への描画スクリーンの重ね合わせの概念を示す図である。 本発明の実施の形態における拡張モードでの重ね合わせの概念を示す図である。 本発明の実施の形態におけるソフトウェアの概略の構成を示す図である。 本発明の実施の形態における描画スクリーン（重ね合わせスクリーン）のリスト構造による管理を示す図である。 本発明の実施の形態において、重ね合わせの対象となる描画スクリーンごと１枚につき、１つのアイドラ関数を登録できることを示す図である。 本発明の実施の形態において、各重ね合わせスクリーン（描画スクリーン）を定義するための重ね合わせスクリーン定義情報を例示する図である。 本発明の実施の形態において、ＧＵＩコンポーネントを展開して保持するフック先バッファの説明図である。 本発明の実施の形態における標準モードでの唯一の重ね合わせスクリーンの利用の仕方の説明図である。 本発明の実施の形態での拡張モードにおける複数の重ね合わせスクリーンの作用を示す図である。 本発明の実施の形態におけるユーザ指示によるイベント処理の例を説明するための図である。 本発明の実施の形態における、アプリケーション処理のフローチャートを示す図である。 本発明の実施の形態において、ＧＵＩ環境Ａで動作するアプリケーションを他のＧＵＩ環境Ｂに移植する場合の説明図である。 本発明の実施の形態において、描画スクリーンに対して入力イベントの有効化（ＯＮ）が行われている場合と、無効化（ＯＦＦ）が行われている場合の動作の違いの説明図である。 本発明の実施の形態における重ね合わせシステムで実現可能な表現例を示す図である。

符号の説明

１０…ＧＵＩ画面、１３…選択ボタン、１５，１６…ラジオボタン、２０…描画スクリーン、２１…キャラクタ、２５，２６…表示画面、３１…描画スクリーン、１００…アプリケーション、２００…重ね合わせライブラリ、２２０…ＧＵＩ依存モジュールインターフェイス、３１０，３１０ａ，３１０ｂ，３１０ｃ…ＧＵＩ依存モジュール、３２０，３２０ａ，３２０ｂ，３２０ｃ…ＧＵＩライブラリ、４１０…制御部、４２０…記憶部、４３０…表示部、４４０…入力部、４５０…通信部、５００，５０１〜５０４…スクリーンバッファ（オフスクリーンバッファ）、５１０…スクリーンバッファ（オンスクリーンバッファ）、５２０…フック先バッファ、５２３…ウィンドウ、５３０…ＧＵＩコンポーネント、５３１…ポイント、５３２…ポイント、５５０…スクリーン定義情報、６００…表示画面、６１３…ボタン、６２０…キャラクタ、６２１…アラーム表示、６３０…タッチペン、６４０…メモ用紙、６５０…文字列

Claims (12)

1. 表示デバイスの表示画面上に画像を表示する表示手段と、
   前記表示画面の全体に対応する第１のスクリーンの内容を記憶する第１のスクリーンバッファと、
   ＧＵＩリソースを有するＧＵＩライブラリと、
   前記ＧＵＩリソースを利用したＧＵＩ画像の描画の展開先となるフック先バッファと、
   前記第１のスクリーンバッファにコピーされるべき第２のスクリーンに対応する画像を記憶する第２のスクリーンバッファと、
   前記第２のスクリーンバッファに前記フック先バッファの内容をコピーするとともに任意の画像を重ね合わせて書き込む重ね合わせ手段と
   を備えたことを特徴とする表示装置。
2. 前記重ね合わせ手段は、
   前記第２のスクリーンバッファにおいて、前記フック先バッファに描画されたＧＵＩ画像に任意の画像を重ね合わせて描画するためにアプリケーションに提供される重ね合わせＡＰＩと、
   異なるＧＵＩライブラリをアプリケーションが利用する場合にも、前記重ね合わせＡＰＩを共通のインターフェイスで前記ＧＵＩライブラリに仲介するＧＵＩ依存モジュールインターフェイスとを備え、
   特定のＧＵＩライブラリに対して、前記ＧＵＩ依存モジュールインターフェイスのルールに基づいて当該ＧＵＩライブラリに対する入出力を定めるＧＵＩ依存モジュールが個別に用意されたことを特徴とする請求項１記載の表示装置。
3. 前記第２のスクリーンバッファに対応して周期的に実行する処理を定める手段を備えたことを特徴とする請求項１記載の表示装置。
4. 前記第２のスクリーンとして、前記第１のスクリーンと同サイズのスクリーンを単一個用いることを特徴とする請求項１記載の表示装置。
5. 前記第２のスクリーンとして、前記第１のスクリーンより小さい任意のサイズおよび個数のスクリーンを用いることを特徴とする請求項１記載の表示装置。
6. 前記第２のスクリーンとして、前記第１のスクリーンと同サイズのスクリーンを単一個用いる第１の動作モードと、前記第２のスクリーンとして、前記第１のスクリーンより小さい任意のサイズおよび個数のスクリーンを用いる第２の動作モードとを選択可能に設定する手段を備えたことを特徴とする請求項１記載の表示装置。
7. 前記第２のスクリーンの少なくとも一つに対して所定の入力イベント処理を登録し、ユーザ操作により指示された表示画面上のポイントと対応する前記第２のスクリーンを検索し、対応する第２のスクリーンが存在する場合、当該イベント処理を実行する請求項５または６記載の表示装置。
8. 前記入力イベントを有効化／無効化する手段を備え、無効化されている場合には前記対応する第２のスクリーンが存在しても前記入力イベント処理を抑止する請求項７記載の表示装置。
9. 表示デバイスの表示画面上に画像を表示する表示装置における表示処理方法であって、
   前記表示画面の全体に対応する第１のスクリーンの内容を記憶する第１のスクリーンバッファと、ＧＵＩリソースを有するＧＵＩライブラリと、前記ＧＵＩリソースを利用したＧＵＩ画像の描画の展開先となるフック先バッファと、前記第１のスクリーンバッファにコピーされるべき第２のスクリーンに対応する画像を記憶する第２のスクリーンバッファとを設けるステップと、
   前記フック先バッファに前記ＧＵＩリソースを利用してＧＵＩ画像の描画を行うステップと、
   前記第２のスクリーンバッファに前記フック先バッファの内容をコピーするステップと、
   前記第２のスクリーンバッファの内容に任意の画像を重ね合わせて書き込むステップと、
   前記第２のスクリーンバッファの内容を前記第１のスクリーンバッファにコピーするステップと
   を備えたことを特徴とする表示処理方法。
10. 前記第２のスクリーンバッファとして、サイズおよび前記第１のスクリーン上の位置を指定して、少なくとも１個のスクリーンバッファを確保するステップを備えた請求項９記載の表示処理方法。
11. 特定の前記第２のスクリーンバッファに対応して周期的に所定の処理を実行するためのアイドラを登録するステップと、
    前記アイドラが登録された前記第２のスクリーンに対応して前記所定の処理を周期的に実行するステップと
    を備えた請求項９記載の表示処理方法。
12. 特定の前記第２のスクリーンバッファに対応して入力イベント処理を登録するステップと、
    前記第１のスクリーンバッファの内容に対応する表示画面に対してユーザ操作によりあるポイントが指示されたとき、その指示されたポイントが前記入力イベント処理を登録された前記第２のスクリーンに対応するか否かをチェックするステップと、
    対応する場合、前記入力イベント処理を実行するステップと
    を備えた請求項９記載の表示処理方法。

Images