JP2006171274A - アプリケーション描画端末、アプリケーション描画の表示方法およびアプリケーション描画プログラム - Google Patents

Abstract

【課題】Ｘウインドウシステムを搭載し、かつＪａｖａ（登録商標）仮想マシンを搭載した携帯電話をはじめとする組込み機器において、Ｊａｖａ（登録商標）アプリケーションの描画結果をＬＣＤなどの表示画面に高速に表示することができなかった。
【解決手段】Ｊａｖａ（登録商標）仮想マシンを搭載し、かつＸウインドウまたはそのサブセットと、描画ライブラリと、表示ドライバと、アプリケーション画像記憶部を具備するシステムにおいて、Ｊａｖａ（登録商標）仮想マシンが描画ライブラリを用いてアプリケーション画像を描画し、アプリケーション画像バッファに格納したのち、Ｘウインドウを経由して生成した主画像と合成してスクリーンに表示する際において、アプリケーション画像バッファに格納したアプリケーション画像は、Ｘウインドウを経由することなく、直接表示ドライバからアクセスを行い、表示ドライバ内にて主画像と合成する。
【選択図】図１

Description

本発明はＪａｖａ（登録商標）仮想マシンおよびＸウインドウシステムまたはそのサブセットを搭載した端末において、Ｊａｖａ（登録商標）アプリケーションの描画結果を、ＬＣＤ等の表示画面に高速表示する技術に関する。

携帯電話装置やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）を始めとする近年の組込み系端末においては、機能の高度化とアプリケーション開発を行いやすくするために、ＬｉｎｕｘなどのＯＳ（Ｏｐａｒａｔｉｎｇ Ｓｙｓｔｅｍ）に加えて、グラフィカルユーザーインターフェース環境であるＸウインドウシステムまたはそのサブセット（以下、ＸウインドウシステムまたはそのサブセットをＸウインドウと略す）が搭載されるものが出現している。また特に携帯電話装置においては、Ｊａｖａ（登録商標）仮想マシンが搭載されて、ゲームを始めとする高速なグラフィック処理が必要なＪａｖａ（登録商標）アプリケーション（以下、アプリケーションと略す）が多数、市場に流通している。

Ｘウインドウシステムとは、マサチューセッツ工科大学において開発されたウインドウシステムであって、ネットワーク環境を前提としたクライアントサーバモデルを採用している点が特徴である。現在ではＵＮＩＸ（登録商標）やＬｉｎｕｘ上での標準のウインドウシステムとなっている。このようなＸウインドウシステムに関する技術としては、例えば、特許文献１に記載されたようなものがある。

一方、現状の組込み端末のハードウエア性能では、部品コストの問題や消費電力の問題などが原因で、ＣＰＵ周波数やメモリのアクセス速度がＰＣよりも低いものが使用されている。そのため、Ｘウインドウのようにソフトウエアを開発する上では便利であるが、処理負荷の重いミドルウエアを介してグラフィック処理の多いＪａｖａ（登録商標）アプリケーションを表示しようとすると、動画を表示するときに表示の更新速度が遅く、ゲームなどのＪａｖａ（登録商標）アプリケーションが想定している表示が行えないという問題が発生する。

図１３および図１４は、従来の携帯電話装置においてＸウインドウを介してＪａｖａ（登録商標）アプリケーションの描画結果を表示する場合の概略構成図である。

図１３において、Ｊａｖａ（登録商標）仮想マシン９１が管理するヒープ領域９９内に第１画像記憶部であるアプリケーション画像バッファ９５を配置し、Ｊａｖａ（登録商標）仮想マシン９１がアプリケーション画像バッファ９５の先頭ポインタを描画ライブラリ９３に渡して描画を行うと、描画された結果のアプリケーション画像がポインタで示されたアプリケーション画像バッファ９５内に描き込まれる。描き込まれたアプリケーション画像はＪａｖａ（登録商標）仮想マシン９１がＸＰｕｔＩｍａｇｅ関数等を用いてＸウインドウ９２内のウインドウバッファ９６に転送する。

図１４の例は、第1画像記憶部であるアプリケーション画像バッファ１０５が、描画ライブラリ１０３の側近に配置されているケースである。描画ライブラリ１０３がＯｐｅｎＧＬ ＥＳ規格準拠の場合などの事例である。この場合、Ｊａｖａ（登録商標）仮想マシン１０１は描画命令を描画ライブラリ１０３に発行し、描画ライブラリ１０３は描画したアプリケーション画像を直接、アプリケーション画像バッファ１０５内に格納する。このとき格納されたアプリケーション画像はＪａｖａ（登録商標）仮想マシン１０１からは直接ポインタ伝いでの読み書き等はできなく、読み書きをするにはメモリコピーが必要である。アプリケーション画像の表示を行う際には、Ｊａｖａ（登録商標）仮想マシン１０１はウインドウ抽象化インターフェース１０９を経由して、アプリケーション画像をＸウインドウ１０２内のＸウインドウバッファ１０６に転送する。この転送はＯｐｅｎＧＬ ＥＳ規格準拠の場合はｅｇｌＳｗａｐＢｕｆｆｅｒｓ関数等を用いることによって行うことが可能である。また、ウインドウ抽象化インターフェース１０９は、ＯｐｅｎＧＬ ＥＳ規格準拠の場合はＥＧＬ(Ｏｐｅｎ ＧＬ ＥＳ Ｎａｔｉｖｅ Ｐｌａｔｆｏｒｍ Ｇｒａｐｈｉｃｓ Ｉｎｔｅｒｆａｃｅ)に相当する。

携帯電話装置においては、アプリケーション画像をＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）に表示するための最終画像を構成するために、アプリケーション画像以外に、アンテナバーや電池残量を示すインジケータや、ユーザにＪａｖａ（登録商標）アプリケーションの制御ボタンを提示するソフトキーなどの表示部品を配置して合成する必要がある。このインジケータやソフトキーなどの表示部品で構成される、Ｊａｖａ（登録商標）アプリケーション以外が生成する画像を主画像と呼ぶ。画像合成を行う際に、上記のＸウインドウを経由する従来の例では、図１３や図１４に示すとおり、アプリケーション画像をＸウインドウ９２、１０２内に一旦メモリコピーする必要がある。すなわちアプリケーション画像バッファのポインタ渡しはできない。これはＸウインドウがネットワークを意識したソケット通信によってサーバ・クライアント型でデータを授受する構造になっていることに起因している。Ｘウインドウ内にコピーされたアプリケーション画像は、Ｘウインドウの仕組みに基づいてインジケータやソフトキーなどの表示部品と合成されて最終表示画像が構成され、表示ドライバ９４、１０４に転送されてＬＣＤ等に表示される。
特開平５−９４２７２号公報

しかしながら、前記従来の構成では、Ｘウインドウを介してアプリケーション画像と、インジケータやソフトキー等の表示部品との合成を行うため、アプリケーション画像バッファからＸウインドウへのメモリコピーに伴う転送オーバーヘッドが発生し、表示処理が遅延する。また、Ｘウインドウはアルゴリズム的・構造的には美しいが、そのため、Ｘウインドウの動作は負荷が重いため、Ｘウインドウ上で行う処理に時間が掛かる。そのため、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）に比べて、携帯電話装置等は非力なハードウエア性能であるため、アプリケーション画像の表示速度が十分上がらない。すなわちＪａｖａ（登録商標）アプリケーションのゲーム等の見栄えが悪くなり、ユーザがゲームを楽しめなくなるという問題が発生する。

本発明はかかる問題を鑑み、Ｘウインドウシステムまたはそのサブセットを搭載し、かつＪａｖａ（登録商標）仮想マシンを搭載した携帯電話装置をはじめとする組込み機器のアプリケーション描画端末において、Ｘウインドウシステムまたはそのサブセットに手を加えることなく、アプリケーションの描画結果をＬＣＤなどの表示画像に高速表示する手段を提供する事を目的とする。

本発明のアプリケーション描画端末は、アプリケーション描画端末の情報を示す主画像を生成するＸウインドウシステムまたはそのサブセットと、描画ライブラリを用いてアプリケーション画像を描画するＪａｖａ（登録商標）仮想マシンと、前記描画ライブラリが前記アプリケーション画像を記憶する第１画像記憶部と、前記第１画像記憶部から直接前記アプリケーション画像を取得し、前記主画像と前記アプリケーション画像とを合成して表示する表示ドライバとを備える。この構成により、アプリケーション画像をＸウインドウシステムまたはそのサブセットを経由せずに合成・表示するので、高速なＪａｖａ（登録商標）アプリケーションのグラフィック表示が可能である。

また、本発明のアプリケーション描画端末は、前記主画像は、前記アプリケーション画像を配置する矩形領域の位置とサイズが保持し、前記アプリケーション画像と前記主画像を表示装置に合成して表示する際に前記矩形領域に透明を意味する特定の色を塗り、前記表示ドライバが前記アプリケーション画像の上に、前記主画像をクロマキー合成にて重ね合わせ、表示する構成をとる。この構成により、矩形領域のアプリケーション画像と主画像を合成して、高速なグラフィック表示を行うことが可能である
また、本発明のアプリケーション描画端末は、前記主画像が１または複数の矩形領域であり、前記アプリケーション画像と前記主画像を表示装置に合成して表示する際に、前記表示ドライバは前記第１画像記憶部から直接前記アプリケーション画像を取得し、前記の前記主画像の矩形領域と、アプリケーション画像をつなぎ合わせて表示する構成をとる。この構成により、１または複数の矩形領域に分かれた主画像とアプリケーション画像をつなぎ合わせた画像を高速に表示することが可能である。

また、本発明のアプリケーション描画の表示方法はＸウインドウシステムまたはそのサブセットがシステムの情報を示す主画像を生成する工程と、Ｊａｖａ（登録商標）仮想マシンが描画ライブラリを用いてアプリケーション画像を描画する工程と、描画ライブラリが描画した前記アプリケーション画像を第１画像記憶部に格納する工程と、表示ドライバが前記第１画像記憶部から直接前記アプリケーション画像を取得する工程と、前記表示ドライバが前記アプリケーション画像と前記主画像とを合成して表示する工程とからなる。この構成により、アプリケーション画像をＸウインドウシステムまたはそのサブセットとウインドウシステムを経由せずに合成し、表示するので、高速なＪａｖａ（登録商標）アプリケーションのグラフィック表示が可能である。

また、本発明のアプリケーション描画の表示方法は、前記主画像は、前記アプリケーション画像を配置する矩形領域の位置とサイズを保持し、前記アプリケーション画像と前記主画像を表示装置に合成して表示する工程において、前記矩形領域に透明を意味する特定の色を塗る工程と、前記表示ドライバが前記アプリケーション画像の上に、前記主画像をクロマキー合成にて重ね合わせる工程とからなる。この構成により、矩形領域のアプリケーション画像と主画像を合成して、高速なグラフィック表示を行うことが可能である
また、本発明のアプリケーション描画の表示方法は、前記主画像は１または複数の矩形領域であり、前記アプリケーション画像と前記主画像を表示装置に合成して表示する工程において、前記表示ドライバは前記第１画像記憶部から直接前記アプリケーション画像を取得し、前記の前記主画像の矩形領域と、アプリケーション画像をつなぎ合わせる工程とからなる。この構成により、１または複数の矩形領域に分かれた主画像とアプリケーション画像をつなぎ合わせた画像を高速に表示することが可能である。

また、本発明のアプリケーション描画のプログラムはＸウインドウシステムまたはそのサブセットがシステムの情報を示す主画像を生成するステップと、Ｊａｖａ（登録商標）仮想マシンが描画ライブラリを用いてアプリケーション画像を描画するステップと、描画ライブラリが描画した前記アプリケーション画像を第１画像記憶部に格納するステップと、表示ドライバが前記第１画像記憶部から直接前記アプリケーション画像を取得するステップと、前記表示ドライバが前記アプリケーション画像と前記主画像とを合成して表示するものである。上記プログラムによれば、アプリケーション画像をＸウインドウシステムまたはそのサブセットを経由せずに合成し、表示するので、高速なＪａｖａ（登録商標）アプリケーションのグラフィック表示が可能なプログラムを提供できる。

また、本発明のアプリケーション描画のプログラムは、前記主画像は、前記アプリケーション画像を配置する矩形領域の位置とサイズを保持し、前記アプリケーション画像と前記主画像を表示装置に合成して表示するステップにおいて、前記矩形領域に透明を意味する特定の色を塗るステップと、前記表示ドライバが前記アプリケーション画像の上に、前記主画像をクロマキー合成にて重ね合わせるステップとからなるものである。上記プログラムによれば、矩形領域のアプリケーション画像と主画像を合成して、高速なグラフィック表示を行うことが可能なプログラムを提供できる。

また、本発明のアプリケーション描画のプログラムは、前記主画像は１または複数の矩形領域であり、前記アプリケーション画像と前記主画像を表示装置に合成して表示するステップにおいて、前記表示ドライバは前記第１画像記憶部から直接前記アプリケーション画像を取得し、前記の前記主画像の矩形領域と、アプリケーション画像をつなぎ合わせるステップとからなるものである。上記プログラムによれば。１または複数の矩形領域に分かれた主画像とアプリケーション画像をつなぎ合わせた画像を高速に表示することが可能なプログラムを提供できる。

アプリケーション描画端末において、Ｊａｖａ（登録商標）アプリケーションが起動しているときの主画像は、主にアプリケーション描画端末の状態を表すインジケータやソフトキーであるため、時間が経過しても表示内容の変化はほとんど無い。従って、アプリケーション画像を、Ｘウインドウを経由せずに主画像とドライバ層で合成し、表示することで、Ｘウインドウ内へのメモリコピーや、Ｘウインドウ固有の処理のオーバーヘッドを省略し、表示ドライバ内でアプリケーション描画結果がＸウインドウを経由することなく主画像と直接合成され表示されることにより、携帯電話装置を始めとする組込み機器において、Ｊａｖａ（登録商標）アプリケーション起動中の画像表示処理の負荷が軽減される。そのため、高速なＪａｖａ（登録商標）アプリケーションのグラフィック表示ができる。

以下、本発明を実施するための最良の形態について、図面を参照しながら説明する。

（実施の形態１）
以下本発明を実施するための最良の形態について、図面を参照しながら説明する。なお、実施の形態を説明するための全図において、同一の構成要素には同一符号を付与し、重複する説明は省略する。

図１は本発明の実施の形態１におけるアプリケーション描画端末である携帯電話装置の概略ブロック図である。アプリケーション描画端末はＪａｖａ（登録商標）仮想マシン１と、Ｘウインドウ２と、描画ライブラリ３と、表示ドライバ４と第１画像記憶部であるアプリケーション画像記憶部５と、主画像記憶部６と、表示画像記憶部７と、ＬＣＤ８と、ウインドウ抽象化インターフェース９とで構成される。

Ｊａｖａ（登録商標）仮想マシン１はＪａｖａ（登録商標）アプリケーションを動作させ、描画ライブラリ３を用いてＪａｖａ（登録商標）アプリケーションのアプリケーション画像５１を描画する。描画ライブラリ３は、アプリケーション画像５１を描画し、アプリケーション画像記憶部５に格納する。アプリケーション画像記憶部５はＪａｖａ（登録商標）仮想マシン１が描画ライブラリを使って生成したビットマップ状態のデータであるアプリケーション画像５１を格納している。

Ｘウインドウ２はアプリケーション描画端末の電池や通信状況などに応じたインジケータや携帯電話装置の状態に応じたソフトキーを合成し、主画像６１の生成を行う。そして、Ｘウインドウ２は生成した主画像をＸウインドウ２の管理化にあるウインドウバッファなどで構成される主画像記憶部６に格納する。

表示ドライバ４はアプリケーション画像記憶部５から直接アプリケーション画像５１を参照する機能を具備し、主画像記憶部６に保持した主画像と合成し、表示画像７１を生成する。また、表示バッファは表示画像７１を表示画像記憶部７に格納し、ＬＣＤ８に出力する。ＬＣＤ８は表示画像記憶部７に記憶された表示画像７１を液晶画面に表示する。

図２は本発明の実施の形態１におけるアプリケーション描画端末である携帯電話装置のハードウエア構成を模式的に示す図である。携帯電話装置はＣＰＵ２１と主記憶部２２とグラフィックアクセラレータ２３とクロマキー合成器２５を含む表示制御ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）コントローラ２４とで構成される。ＣＰＵ８はＪａｖａ（登録商標）仮想マシン１が動作するハードウエアである。主記憶部２２は図１のアプリケーション画像記憶部５、主画面記憶部６、表示画像記憶部７のハードウエア部材であり、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などで構成される。グラフィックアクセラレータ３３は描画ライブラリ３が動作するハードウエアである。表示制御用ＤＭＡコントローラ３４は、表示ドライバ４が動作するハードウエアである。クロマキー合成器２５はクロマキー合成部４１が動作するハードウエアでる。

図３は、携帯電話装置におけるＪａｖａ（登録商標）アプリケーション表示中の表示画像７１を構成する部品を模式的に示したものである。図３（ａ）は携帯電話装置の状態を示す主画像６１の画像構成を示す。図３（ａ）において、主画像６１は電池残量や無線強度などを示すインジケータ部６２と、Ｊａｖａ（登録商標）アプリケーションの操作ボタンの内容などを表すソフトキー部６４、およびアプリケーション画像５１を配置するためのアプリケーション画像部６３とからなる。図３（ｂ）はアプリケーション画像５１をあらわす図である。アプリケーション画像５１はＪａｖａ（登録商標）仮想マシン１が描画ライブラリ３を用いて生成した描画結果のビットマップデータそのものである。図３（ｃ）はアプリケーション画像５１と主画像６１の重ねあわせ方を示した図であり、図３（ａ）のＡ−Ａ‘断面図である。図３（ｃ）において、主画像６１のアプリケーション画像部６３の下にアプリケーション画像５１を重ね、合成する。アプリケーション画像部６３は透過であることを示す特定色で塗られているため、主画像６１とアプリケーション画像５１を合成すると、アプリケーション画像部６３にアプリケーション画像５１が嵌った画像が生成される。この、特定色部分を透過して合成する方法をクロマキー合成と呼ぶ。

アプリケーション動作時の出力画像である表示画像７１は、ＬＣＤ８内での各パーツの位置とサイズが固定されている。すなわちインジケータ部６２は幅ｘ１、高さｙ１の矩形領域、ソフトキー部６４は幅ｘ１、高さｙ３の矩形領域、アプリケーション画像部６３は幅ｘ１、高さｙ２の矩形領域であり、ＬＣＤ画像の座標原点（ＬＣＤの左上端の点とする）から順にインジケータ部６２、アプリケーション画像部６３、ソフトキー部６４が重ならないように配置される。主画像６１は、ＸツールキットやウイジェットセットなどのＸウインドウのツール群を用いて効率的に生成する。クロマキー合成部４１は、透明色を意味する特定色（たとえば深緑）をあるビットマップＡ内に塗っておき、他のビットマップＢの上に重ねあわせると、深緑は透明と判定されてビットマップＢの画像がビットマップＡ越しに透けて見える機能であるクロマキー合成を行う。実施の形態１においては、Ｊａｖａ（登録商標）アプリケーション動作中の主画像６１を生成する際に、アプリケーション画像部６３には透明色を意味する特定の色（キーカラー）で塗りつぶしを行う。

図４はＪａｖａ（登録商標）アプリケーション起動時の画像を表示する動作を説明したフローチャート図である。図４においてＪａｖａ（登録商標）アプリケーションが起動すると、Ｊａｖａ（登録商標）仮想マシン１はＸウインドウ２のシステムを使って、主画像を更新する（ステップＳ４０１）。

Ｊａｖａ（登録商標）仮想マシン１はＪａｖａ（登録商標）アプリケーションを動作させ（ステップＳ４０２）、描画ライブラリ３を用いてアプリケーション画像５１を生成・更新する（ステップＳ４０３）。生成されたアプリケーション画像５１は、アプリケーション画像記憶部５に格納される。Ｊａｖａ（登録商標）仮想マシン１はウインドウ抽象化インターフェース９を通じて表示ドライバ４に合成開始のトリガーと合成画像の場所を指示する（ステップＳ４０４）。

次に図５と図６を用いて図４のフローチャートの各動作について詳しく説明する。図４のステップＳ４０１の主画像更新の動作について、図５を用いて説明する。主画像６１の更新において、Ｊａｖａ（登録商標）仮想マシン１がＸウインドウ２の機能を用いて主画像６１を生成する（図５のステップＳ５０１）。主画像６１は図３（ａ）で説明を行ったように、インジケータやソフトキーなどのパーツと、特定色で塗りつぶされたアプリケーション画像部を合成して生成される。Ｊａｖａ（登録商標）仮想マシン１は生成された主画像６１を主画像記憶部６に格納する（ステップＳ５０２）。

次に図６を用いて、図４のステップＳ４０３のアプリケーション画像更新の動作について説明する。アプリケーション画像５１の更新時は、Ｊａｖａ（登録商標）仮想マシン１が描画ライブラリ３の機能を用いてアプリケーション画像５１を生成する（ステップ６０１）。次に描画ライブラリ３は生成したアプリケーション画像５１をアプリケーション画像記憶部５に格納する（ステップＳ６０２）。

次にＪａｖａ（登録商標）アプリケーション動作中の合成画像を更新する動作について、図７のフローチャートを用いて説明する。図７においてＪａｖａ（登録商標）仮想マシン１は主画像６１の更新がある場合（ステップＳ７０１のＹＥＳ）、主画像６１の更新を行い（ステップＳ７０２）、ステップＳ７０３に移る。主画像６１の更新がない場合（ステップＳ７０１のＮＯ）は、ステップＳ７０３に移る。ステップ７０２の主画像更新の詳細な内容については図５にて説明済みである。ステップＳ７０３において、Ｊａｖａ（登録商標）仮想マシン１はアプリケーション画像５１の更新がある場合（ステップＳ７０３のＹＥＳ）、アプリケーション画像５１の更新を行い（ステップＳ７０４）、終了する。アプリケーション画像５１の更新がない場合（ステップＳ７０３のＮＯ）は、そのまま終了する。ステップ７０４のアプリケーション画像５１の更新の詳細な内容については図６にて説明済みである。

次にＬＣＤ８の表示の更新について説明する。通常、ＬＣＤ８が表示する画像の更新は、ＬＣＤ８からの垂直同期割り込みと、表示制御ＤＭＡコントローラ２４のＤＭＡ転送を使って、表示ドライバ４が自律的に行う。ＤＭＡ転送とは、ＣＰＵを介すことなく、各記憶部のデバイスからシステムのメモリへのデータ転送を行なう方法である。Ｊａｖａ（登録商標）仮想マシン１がアプリケーション画像５１と主画像６１とをＬＣＤ８に表示することを開始するには、合成を指示する開始トリガーを、ウインドウ抽象化インターフェース９を通じて表示ドライバ４に対して通知する。この開始トリガーはＪａｖａ（登録商標）アプリケーション起動時に図４のステップＳ４０４において実施済みである。

図８はＬＣＤ８に表示される合成画像の更新動作を説明するフローチャート図である。表示制御ＤＭＡコントローラ２４はＬＣＤ８の垂直同期割り込みのタイミングにあわせて、アプリケーション画像記憶部５からアプリケーション画像５１のポインタを渡すなどで直接参照し、取得する（ステップＳ８０１）。次に表示制御ＤＭＡコントローラ２４は主画像記憶部６から主画像６１を参照し、取得する（ステップＳ８０２）。次に表示ドライバ４はクロマキー合成部４１を用いて、アプリケーション画像５１と主画像６１を重ね合わせ、合成する（ステップＳ８０３）。次に、表示ドライバ４は合成した表示画像７１を表示画像記憶部７に格納する。よって、ＬＣＤ８は垂直同期割り込みが起こったときに、表示画像記憶部７に格納された表示画像７１を参照するため、表示が更新される。

一般に、携帯電話装置におけるインジケータやソフトキーなどは、時間が経過してもほとんど変化しない場合が多い。そのため、主画面記憶部６に格納される主画像６１の更新は稀である。反対にゲームなどのＪａｖａ（登録商標）アプリケーション動作中は、アプリケーション画像５１は高速に変化することが多く、アプリケーション画像５１の更新は頻度が高い。そのため、アプリケーション画像５１と主画像６１の合成の頻度も高くなる。この合成において、アプリケーション画像を処理負荷の高いＸウインドウ２を用いず、表示制御ＤＭＡコントローラ２４が直接アプリケーション画像を参照して、合成を行うことにより、高速なＪａｖａ（登録商標）グラフィック描画の表示が可能となる。

（実施の形態２）
本発明の実施の形態２におけるアプリケーション描画端末である携帯電話装置の概略ブロック図を図９に示す。実施の形態２の携帯電話装置はＪａｖａ（登録商標）仮想マシン１と、Ｘウインドウ２と、描画ライブラリ３と、表示ドライバ４２とアプリケーション画像記憶部５と、主画像記憶部６と、表示画像記憶部７と、ＬＣＤ８とで構成される。

実施の形態２の携帯電話装置において、Ｊａｖａ（登録商標）仮想マシン１は描画ライブラリ３を使ってアプリケーション画像５２を描画する。描画ライブラリ３は、アプリケーション画像５２を描画し、アプリケーション画像記憶部５に格納する。アプリケーション画像記憶部５はＪａｖａ（登録商標）仮想マシン１が描画ライブラリを使って生成したビットマップ状態のアプリケーション画像５２を格納している。

Ｘウインドウ２はアプリケーション描画端末の電池や通信状況などに応じたインジケータや端末装置の状態に応じたソフトキーを合成し、主画像６２の生成を行う。そして、Ｘウインドウ２は生成した主画像をＸウインドウ２の管理化にあるウインドウバッファなどで構成される主画像記憶部６に格納する。

図１０は本発明の実施の形態２におけるアプリケーション描画端末のハードウエア構成図である。図１０は実施の形態２のアプリケーション描画端末におけるアプリケーション処理ブロックのハードウエア構成を模式的に示す図である。携帯電話装置はＣＰＵ３１と主記憶部３２とグラフィックアクセラレータ３３とグラフィック専用ＲＡＭ３５と表示制御ＤＭＡコントローラ３４で構成される。ＣＰＵ３１はＪａｖａ（登録商標）仮想マシン１が動作するハードウエアである。主記憶部３２はＪａｖａ（登録商標）アプリケーションなどのデータが格納されているハードウエア部材である。グラフィックアクセラレータ３３は描画ライブラリが動作するハードウエアである。表示制御用ＤＭＡコントローラ３４は、表示ドライバが動作するハードウエアであり、矩形転送機能を具備している。グラフィック専用ＲＡＭ３５はアプリケーション画像記憶部５、主画像記憶部６、表示画像記憶部７などの画像データを持つハードウエア部材である。

図１１は、携帯電話装置におけるＪａｖａ（登録商標）のアプリケーション表示中の表示画像７２を構成する部品を模式的に示したものである。図１１（ａ）は携帯電話装置の状態を示す主画像６５の画像構成を示す。図１１（ａ）において、主画像６５は電池残量や無線強度などを示すインジケータ部６６と、Ｊａｖａ（登録商標）アプリケーションの操作ボタンの内容などを表すソフトキー部６７、とからなる。主画像６５にはアプリケーション画像を重ねる部分のパーツは存在しない。図１１（ｂ）はアプリケーション画像５２をあらわす図である。アプリケーション画像５２はＪａｖａ（登録商標）仮想マシン１が描画ライブラリ３を用いて生成した描画結果のビットマップそのものである。実施の形態２では、アプリケーション画像５２と主画像６５の各パーツのサイズおよび位置が固定している。すなわちインジケータ部６６は幅ｘ１、高さｙ１の矩形領域、ソフトキー部６７は幅ｘ１、高さｙ３の矩形領域、アプリケーション画像５２は幅ｘ１、高さｙ２の矩形領域であり、ｙ１＋ｙ２＋ｙ３の値が表示画像７２すなわちＬＣＤ８の高さに一致し、表示画像７２の座標原点（表示画像７２の左上端の点）から順にインジケータ部６５、アプリケーション画像５２、ソフトキー部６７を重ならないように配置する。このとき主画像６５のパーツであるインジケータ部６６とソフトキー部６７はＸウインドウのツール群（Ｘツールキットやウイジェットセットなど）を用いて効率的に生成する。

次に、Ｊａｖａ（登録商標）アプリケーション動作中におけるＬＣＤ８への表示のための表示画像７２を構成する動作を説明する。主画像の各パーツであるインジケータ部６６とソフトキー部６７およびアプリケーション画像５２マップを生成する手続きは、実施の形態１と同様である。生成された主画像のパーツは主画像記憶部６に、アプリケーション画像はアプリケーション画像記憶部５にそれぞれ格納される。また、ＬＣＤ８への表示画像の更新がＬＣＤ８からの垂直同期割り込みと、表示制御ＤＭＡコントローラ３４のＤＭＡ転送を使って、表示ドライバ４２にて自律的に行われる点も実施の形態１と同様である。

表示画像記憶部７内の表示画像７２にアプリケーション描画の結果を反映させるための手続きを説明する。Ｊａｖａ（登録商標）仮想マシン１は表示ドライバ４２に合成開始のトリガーをかける。合成開始を指示すると、表示制御ＤＭＡコントローラ３４はＬＣＤ８からの垂直同期のタイミングにあわせて主画像記憶６とアプリケーション画像記憶部５から画像を読み出す。このとき表示ドライバ４２および表示制御ＤＭＡコントローラ３４は矩形転送機能を具備しているため、指定した矩形領域だけを抜き出してＤＭＡ転送することができる。

図１２を用いて合成の様子を以下に説明する。表示ドライバ４２は主画像記憶部６からインジケータ部６６の矩形領域を抜き出し、表示画像記憶部７６の座標原点Ａ（０，０）をターゲット始点としてＤＭＡによる矩形転送を起動する。次に表示ドライバ４２はアプリケーション画像記憶部５からアプリケーション画像５２の矩形領域を抜き出し、表示画像記憶部７の座標Ｃ（０，ｙ１）をターゲット始点としてＤＭＡによる矩形転送を起動する。最後に表示ドライバ６は主画像記憶部インドウバッファ６からソフトキー部６７の矩形領域を抜き出し、表示画像記憶部７の座標Ｅ（０，ｙ１＋ｙ２）をターゲット始点としてＤＭＡによる矩形転送を起動する。この一連のＤＭＡ転送により、表示画像記憶部７内に表示画像７２が格納され、ＬＣＤ８に表示される。

なお、表示ドライバ４２とＸウインドウ２において、インジケータ部６６、ソフトキー部６７、アプリケーション画像５２の各々のビットマップが書きかえられなかった場合にはそれぞれのＤＭＡによる矩形転送を起動しない取り決めを具備させると、無駄なメモリ転送をしないで済むため、オーバーヘッドの削減にいっそう寄与することができる。

なお、実施の形態２においてはグラフィックアクセラレータ３３を用いて描画を行っているが、ＣＰＵ３１上のソフトウエア描画ライブラリにて描画を行ってもよい。

本発明にかかるアプリケーション描画端末、アプリケーション描画の表示方法およびアプリケーション描画プログラムは、Ｊａｖａ（登録商標）仮想マシンおよびＸウインドウシステムもしくはそのサブセットを搭載したアプリケーション描画端末において、Ｊａｖａ（登録商標）アプリケーションの描画結果をＬＣＤ等の表示画面に高速表示が可能となるため、携帯電話装置、ＰＤＡなどのＪａｖａ（登録商標）仮想マシンを搭載した組み込み機器において有用である。

本発明の実施の形態１のアプリケーション描画端末の概略ブロック図 本発明の実施の形態１のハードウエア構成図 （ａ）本発明の実施の形態１の携帯電話装置における主画像の画面構成図（ｂ）アプリケーション画像の図（ｃ）はアプリケーション画像と主画像の重ねあわせ方を示した図 本発明の実施の形態１のＪａｖａ（登録商標）アプリケーション起動時の画像を表示する動作のフローチャート 本発明の実施の形態１の主画像更新の動作のフローチャート 本発明の実施の形態１のアプリケーション画像更新の動作のフローチャート 本発明の実施の形態１の合成画像を更新する動作のフローチャート 本発明の実施の形態１のＬＣＤの更新動作を説明するフローチャート 本発明の実施の形態２のアプリケーション描画端末の概略ブロック図 本発明の実施の形態２のハードウエア構成図 （ａ）本発明の実施の形態２の携帯電話装置における主画像の画面構成図（ｂ）アプリケーション画像の図 本発明の実施の形態２の画面合成を説明する図 従来の携帯電話装置の概略構成図 従来の携帯電話装置の概略構成図

符号の説明

１ Ｊａｖａ（登録商標）仮想マシン
２ Ｘウインドウ
３ 描画ライブラリ
４、４２ 表示ドライバ
５ アプリケーション画像記憶部
５１、５２ アプリケーション画像
６ 主画像記憶部
６１、６２ 主画像
７ 表示画像記憶部
７１、７２ 表示画像
８ ＬＣＤ

Claims (9)

1. アプリケーション描画端末の情報を示す主画像を生成するＸウインドウシステムまたはそのサブセットと、
   描画ライブラリを用いてアプリケーション画像を描画するＪａｖａ（登録商標）仮想マシンと、
   前記描画ライブラリが前記アプリケーション画像を記憶する第１画像記憶部と、
   前記第１画像記憶部から直接前記アプリケーション画像を取得し、前記主画像と前記アプリケーション画像とを合成して表示する表示ドライバとを備えたアプリケーション描画端末。
2. 前記主画像は、前記アプリケーション画像を配置する矩形領域の位置とサイズが保持し、
   前記アプリケーション画像と前記主画像を表示装置に合成して表示する際に、
   前記矩形領域に透明を意味する特定の色を塗り、
   前記表示ドライバが前記アプリケーション画像の上に、前記主画像をクロマキー合成にて重ね合わせ、表示することを特徴とする請求項１記載のアプリケーション描画端末。
3. 前記主画像は１または複数の矩形領域であり、
   前記アプリケーション画像と前記主画像を表示装置に合成して表示する際に、
   前記表示ドライバは前記第１画像記憶部から直接前記アプリケーション画像を取得し、
   前記の前記主画像の矩形領域と、アプリケーション画像をつなぎ合わせて表示することを特徴とする請求項１記載のアプリケーション描画端末
4. Ｘウインドウシステムまたはそのサブセットがシステムの情報を示す主画像を生成する工程と、
   前記Ｊａｖａ（登録商標）仮想マシンが描画ライブラリを用いてアプリケーション画像を描画する工程と、
   描画ライブラリが描画した前記アプリケーション画像を第１画像記憶部に格納する工程と、
   表示ドライバが前記第１画像記憶部から直接前記アプリケーション画像を取得する工程と、
   前記表示ドライバが前記アプリケーション画像と前記主画像とを合成して表示する工程とからなるアプリケーション描画の表示方法。
5. 前記主画像は、前記アプリケーション画像を配置する矩形領域の位置とサイズを保持し、
   前記アプリケーション画像と前記主画像を表示装置に合成して表示する工程において、
   前記矩形領域に透明を意味する特定の色を塗る工程と、
   前記表示ドライバが前記アプリケーション画像の上に前記主画像をクロマキー合成にて重ね合わせる工程と、
   からなる請求項４記載のアプリケーション描画の表示方法。
6. 前記主画像は１または複数の矩形領域であり、
   前記アプリケーション画像と前記主画像を表示装置に合成して表示する工程において、
   前記表示ドライバは前記第１画像記憶部から直接前記アプリケーション画像を取得し、
   前記の前記主画像の矩形領域と、アプリケーション画像をつなぎ合わせる工程とからなる特徴とする請求項４記載のアプリケーション描画の表示方法。
7. Ｘウインドウシステムまたはそのサブセットがシステムの情報を示す主画像を生成するステップと、
   Ｊａｖａ（登録商標）仮想マシンが描画ライブラリを用いてアプリケーション画像を描画するステップと、
   描画ライブラリが描画した前記アプリケーション画像を第１画像記憶部に格納するステップと、
   表示ドライバが前記第１画像記憶部から直接前記アプリケーション画像を取得するステップと、
   前記表示ドライバが前記アプリケーション画像と前記主画像とを合成して表示するステップとからなるアプリケーション描画のプログラム。
8. 前記主画像は、前記アプリケーション画像を配置する矩形領域の位置とサイズを保持し、
   前記アプリケーション画像と前記主画像を表示装置に合成して表示するステップにおいて、
   前記矩形領域に透明を意味する特定の色を塗るステップと、
   前記表示ドライバが前記アプリケーション画像の上に前記主画像をクロマキー合成にて重ね合わせるステップと、
   からなる請求項７記載のアプリケーション描画のプログラム。
9. 前記主画像は１または複数の矩形領域であり、
   前記アプリケーション画像と前記主画像を表示装置に合成して表示するステップにおいて、
   前記表示ドライバは前記第１画像記憶部から直接前記アプリケーション画像を取得し、
   前記の前記主画像の矩形領域とアプリケーション画像をつなぎ合わせるステップと、
   からなる請求項７記載のアプリケーション描画のプログラム。
   

Images