(57)【要約】【課題】ソフトウェアにより画像の描画を行う表示システムにおいて、ＣＰＵの負担の軽減および描画速度の向上を図る。【解決手段】表示システムは、各論理描画面２０４に一旦描画してからそれらを各描画面の重なりを考慮してフレームバッファ２０６に転送することで各描画面の重なりを再現する通常描画モードと、フレームバッファ２０６に直に描画する直接描画モードとを有している。通常描画モードと直接描画モードのどちらを使用して描画を行うかを、アプリケーション２０１の使用する描画面の数に応じて切り替える。【選択図】図２
2005275028.tif 000002
【特許請求の範囲】
【請求項１】
表示デバイスに複数の描画面を重ねて表示可能な表示システムであって、
個々の描画面の画像データである第１画像データを生成するデータ生成手段と、
前記第１画像データを描画面ごとに保持可能な第１メモリと、
前記表示デバイスに実際に表示させるための画像データである第２画像データを保持する第２メモリと、
前記データ生成手段、前記第１メモリおよび前記第２メモリの間における前記第１画像データの受け渡しを制御する第１データ制御部とを備え、
前記第１データ制御部は、
前記データ生成手段が生成した前記第１画像データを一旦第１メモリに書き込み、その後、前記第１メモリ内の前記第１画像データを前記第２メモリに転送することによって、前記第２画像データを作成する第１描画モードと、
前記データ生成手段が生成した前記第１画像データを、前記第１メモリを介することなく、前記第２メモリ内の前記第２画像データの少なくとも一部に上書きすることで、新たな前記第２画像データを作成する第２描画モードと、を切り換え可能である
ことを特徴とする表示システム。
【請求項２】
請求項１記載の表示システムであって、
前記データ生成手段は、複数のアプリケーションプログラムに基づいて動作しており、
前記第１データ制御部は、前記アプリケーションプログラムごとに前記第１描画モードと前記第２描画モードとを切り換える
ことを特徴とする表示システム。
【請求項３】
請求項２記載の表示システムであって、
前記第１データ制御部は、
前記データ生成手段が複数の描画面を使用する前記アプリケーションプログラムに基づいて動作している場合は前記第１描画モードを選択し、単一の描画面のみを使用する前記アプリケーションプログラムに基づいて動作している場合は前記第２描画モードを選択する
ことを特徴とする表示システム。
【請求項４】
請求項１記載の表示システムであって、
前記データ生成手段は、発生したイベントに応じた処理を行うアプリケーションプログラムに基づいて動作しており、
前記第１データ制御部は、前記イベントごとに前記第１描画モードと前記第２描画モードとを切り換える
ことを特徴とする表示システム。
【請求項５】
請求項４記載の表示システムであって、
前記第１データ制御部は、
前記データ生成手段が複数の前記描画面を使用する前記イベントに基づいて動作している場合は前記第１描画モードを選択し、単一の前記描画面のみを使用する前記イベントに基づいて動作している場合は前記第２描画モードを選択する
ことを特徴とする表示システム。
【請求項６】
請求項１から請求項５のいずれかに記載の表示システムであって、
前記第２メモリから前記表示デバイスへの前記第２画像データの転送を制御する第２データ制御部をさらに備え、
前記第１データ制御部は、
前記第２描画モードにおいて、前記第２データ制御部が特定の動作を行っている間は前記第２メモリへの前記第１画像データの書き込みを待機するロック機能を有している
ことを特徴とする表示システム。
【請求項７】
請求項１から請求項５のいずれかに記載の表示システムであって、
前記第２メモリから前記表示デバイスへの前記第２画像データの転送を制御する第２データ制御部をさらに備え、
前記第１データ制御部は、
前記第２データ制御部が特定の動作を行っている間は前記第２メモリに書き込んだ前記第１画像データに関する情報を順次マージして記憶し、前記特定の動作の後で、前記第２データ制御部に前記第２画像データの転送を前記マージした情報に基づいて行なわせるマージ機能を有している
ことを特徴とする表示システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、表示デバイスに複数の描画面を重ねて表示可能な表示システムに関するものである。
【背景技術】
【０００２】
例えばパーソナルコンピュータや携帯情報端末（ＰＤＡ）などのディスプレイに複数のウィンドウを同時に表示可能なマルチウィンドウシステムにおいて、ウィンドウ同士を重ねて表示可能にしたオーバーラップウィンドウ方式が広く用いられている。ウィンドウ同士の重ね合わせ表示を実現するためには、各ウィンドウのどの部分が別のウィンドウによって覆われているかを常に把握し、他のウィンドウに覆われていない部分だけを画面に描画するなどの処理を行い、画面表示の整合性を保つ必要がある。
【０００３】
その方式の一つとして、ソフトウェアにより表示画面を生成する方式が知られている。この方式の表示システムでは、汎用メモリ上にウインドウ毎の論理描画領域が確保される。それぞれのウインドウの描画処理は各論理描画領域において行われ、その後、各ウインドウの重なり具合に従ってそれぞれの論理描画領域のデータをフレームバッファにコピーすることによって最終的な表示画面を生成する。
【０００４】
そのような従来のソフトウェアによる描画面（ウィンドウやメッセージダイアログ等）の重ね合わせ処理は、ＣＰＵへの負担が大きい。そのため、描画面の大きさやその枚数（レイヤ）が増えると、ＣＰＵでの処理時間に長時間を要するようになり、描画速度が遅くなってしまうという欠点がある。
【０００５】
その改善策としては、グラフィックアクセラレータと呼ばれる描画処理専用のハードウェアを表示システムに搭載させるのが一般的である（例えば特許文献１，２）。高負荷な画像処理をグラフィックアクセラレータに担当させることによって、ＣＰＵの負担は軽減される。しかし、描画処理専用のハードウェアを追加すると、当然、表示システムの規模が大きくなってしまい、その省スペース化の妨げとなる。そのため、ＰＤＡや携帯電話のような小型機器にそれを搭載させるのは困難である。また、ハードウェアの追加は、製品のコストを上げる要因にもなる。
【０００６】
【特許文献１】特開２０００−２０６９５３号公報
【特許文献２】特開平１１−１８４６６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記のように、従来のソフトウェアによる描画面の重ね合わせの手法では、描画面の拡大やその数の増加により、十分な描画速度を得ることができなかった。また近年におけるディスプレイ装置の高解像度化に伴って、この問題はさらに大きくなりつつある。上記のように、その問題は描画処理専用のハードウェアを使用することにより解決することができるが、表示システムの大規模化並びにコストの増大という別の問題を伴ってしまう。
【０００８】
本発明は以上のような課題を解決するためになされたものであり、描画処理専用のハードウェアを使用せずに、ＣＰＵの負担の軽減および描画速度の向上が可能な表示システムを提供する目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る表示システムは、表示デバイスに複数の描画面を重ねて表示可能な表示システムであって、個々の描画面の画像データである第１画像データを生成するデータ生成手段と、前記第１画像データを描画面ごとに保持可能な第１メモリと、前記表示デバイスに実際に表示させるための画像データである第２画像データを保持する第２メモリと、前記データ生成手段、前記第１メモリおよび前記第２メモリの間における前記第１画像データの受け渡しを制御する第１データ制御部とを備え、前記第１データ制御部が、前記データ生成手段が生成した前記第１画像データを一旦第１メモリに書き込み、その後、前記第１メモリ内の前記第１画像データを前記第２メモリに転送することによって、前記第２画像データを作成する第１描画モードと、前記データ生成手段が生成した前記第１画像データを、前記第１メモリを介することなく、前記第２メモリ内の前記第２画像データの少なくとも一部に上書きすることで、新たな前記第２画像データを作成する第２描画モードと、を切り換え可能であるものである。
【発明の効果】
【００１０】
本発明によれば、例えば複数の描画面を使用するアプリケーションに対しては高速性に優れた第１描画モードでの描画処理を行い、単一の描画面のみを使用するアプリケーションに対しては比較的単純なアルゴリズムで描画面の重畳を再現可能な直接描画モードで描画処理を行うことによって、全体としてＣＰＵの負担の軽減および描画速度の向上が実現できる。
【発明を実施するための最良の形態】
【００１１】
＜実施の形態１＞
図１は、本発明に係る表示システムのハードウェア構成を示す図である。本システムは、表示デバイス１０７に複数の描画面を重ねて表示することができる。ＣＰＵ１０１は汎用メモリ１０２内に格納されたプログラムを動作させることによって、個々の描画面の画像データである第１画像データを生成する。汎用メモリ１０２には、前記プログラムおよび当該プログラムが演算に使用するデータが保持される。さらに汎用メモリ１０２には、各描画面ごとの第１画像データが論理描画面として保持される。フレームバッファ１０６は、実際に表示デバイス１０７に表示させるための画像データである第２画像データを保持するためのメモリである。即ち、表示デバイス１０７は、フレームバッファ１０６から転送される第２画像データに基づく画像を画面上に出力する。
【００１２】
表示コントローラ１０８は、フレームバッファ１０６および表示デバイス１０７を制御する。本システムにおいては、フレームバッファ１０６および表示デバイス１０７へのアクセスは、常に表示コントローラ１０８を介して行なわれる。また、フレームバッファ１０６から表示デバイス１０７への第２画像データの転送は、表示コントローラ１０８が単独で制御して（ＣＰＵ１０１の処理を介することなく）行うことが可能である。汎用バス１０３は、本システム内の各要素間でデータを受け渡しするためのバスである。
【００１３】
図２は、本発明に係る表示システムのソフトウェア構成を示す図である。簡単のため、以下の説明において、本システムの動作の説明はこのソフトウェア構成に基づいて行う。同図に示すアプリケーション２０１、グラフィックスライブラリ２０３およびディスプレイドライバ２０５は、図１に示した汎用メモリ１０２内に格納されたプログラムをＣＰＵ１０１が実行することによって実現される構成要素である。また、フレームバッファ２０６、表示デバイス２０７および表示コントローラ２０８は、それぞれ図１に示したフレームバッファ１０６および表示デバイス１０７および表示コントローラ１０８に対応している。
【００１４】
アプリケーション２０１は、当該表示システムの外部から入力される外部イベント２０２に基づいて、個々の描画面の画像データである第１画像データの生成など所定の処理を行う。つまりアプリケーション２０１は、個々の描画面の第１画像データを生成するデータ生成手段として機能する。外部イベント２０２は、例えばアプリケーション２０１が提供するＧＵＩ（Graphical User Interface）などのユーザーインターフェースを介してユーザから入力される場合もあるし、例えばタイマなど他のプログラムから自動的に入力される場合もある。
【００１５】
図２にはアプリケーション２０１は１つのみ描かれているが、本実施の形態では、アプリケーション２０１は複数個存在する。そして複数のアプリケーション２０１のうちには、例えばウィンドウやメッセージダイアログを互いに重ねずに並べて表示するアプリケーションのような単一の描画面のみを使用するものと、例えばメッセージダイアログをウィンドウ上に重ねて表示させるアプリケーションのような複数の描画面を使用するものとが存在している。
【００１６】
論理描画面２０４は図１の汎用メモリ１０２内に確保されており、アプリケーション２０１が生成した第１画像データを描画面ごとに保持することが可能な第１メモリとして機能する。フレームバッファ２０６は、実際に表示デバイス２０７に表示させるための画像データである第２画像データを保持する第２メモリとして機能する。
【００１７】
グラフィックスライブラリ２０３は、アプリケーション２０１の処理による描画動作を制御している。アプリケーション２０１はグラフィックスライブラリ２０３が提供する描画関数を実行することによって、描画対象（論理描画面２０４あるいはフレームバッファ２０６）に描画すること（即ち、第１画像データを書き込むこと）ができる。ディスプレイドライバ２０５は、論理描画面２０４−フレームバッファ２０６間の第１画像データの転送動作を制御する。グラフィックスライブラリ２０３がディスプレイドライバ２０５から提供される転送命令を実行することにより、ディスプレイドライバ２０５は論理描画面２０４からフレームバッファ２０６へ第１画像データを転送する。この転送の際には、各描画面の重なりの状態が再現されるよう考慮される。このように、グラフィックスライブラリ２０３およびディスプレイドライバ２０５は、アプリケーション２０１、論理描画面２０４、フレームバッファ２０６の間における第１画像データの受け渡しを制御する第１データ制御部として機能している。
【００１８】
ディスプレイドライバ２０５は、表示デバイス２０７の画面表示を更新するための命令であるリフレッシュ命令を、グラフィックスライブラリ２０３に提供している。グラフィックスライブラリ２０３がリフレッシュ命令を実行すると、ディスプレイドライバ２０５は表示コントローラ２０８に対してリフレッシュ要求を行う。表示コントローラ２０８はリフレッシュ要求を受けると、フレームバッファ２０６内の第２画像データを表示デバイス２０７へ転送する。表示コントローラ２０８は、フレームバッファ２０６から表示デバイス２０７への第２画像データの転送を制御する第２データ制御部として機能する。表示デバイス２０７は、フレームバッファ２０６から転送された第２画像データに基づく画像を画面に表示する。
【００１９】
このとき、第２画像データの転送は表示デバイス２０７固有のリフレッシュレート（例えば６０Ｈｚ）で発生するリフレッシュタイミングに同期したタイミングで行われる。また、フレームバッファ２０６内の第２画像データは、毎回全て（画面上の全座標のデータ）が表示デバイス２０７に転送されるわけではなく、画面上で画像が変化した部分など必要な領域のデータのみを転送することで処理の高速化を図っている。そのためリフレッシュ命令およびリフレッシュ要求には、第２画像データのうちの表示デバイス２０７へ転送する領域を示す座標データが含まれている。
【００２０】
図３は、表示コントローラ２０８の動作を示すフローチャートである。グラフィックスライブラリ２０３によりリフレッシュ命令が実行され、表示コントローラ２０８がディスプレイドライバ２０５からのリフレッシュ要求を受け取ると（Ｓ２１）、当該表示コントローラ２０８はリフレッシュタイミングが発生するまで待機する（Ｓ２２）。そして、次のリフレッシュタイミングに同期して、フレームバッファ２０６内の第２画像データを表示デバイス２０７へ転送する（Ｓ２３）。この待機および転送の処理は、ＣＰＵ１０１の制御とは独立しており、表示コントローラ２０８が単独で制御する。従って、ＣＰＵ１０１はその間にもプログラム続けて実行することが可能である。表示コントローラ２０８は、第２画像データの転送が完了すると再びリフレッシュ命令の待機状態に戻る。
【００２１】
但し、表示コントローラ２０８におけるリフレッシュタイミングの待機期間（Ｓ２２）および表示デバイス２０７への第２画像データの転送期間（Ｓ２３）の間は、グラフィックスライブラリ２０３によるリフレッシュ命令の実行は制限される。これは、表示デバイス２０７への第２画像データ転送中に、新たなリフレッシュ命令によって転送領域を示す座標データが変更されることにより表示デバイス２０７の画面表示が乱れることを防ぐためである。本明細書においては、表示コントローラ２０８におけるリフレッシュタイミングの待機期間（Ｓ２２）および表示デバイス２０７への第２画像データの転送期間（Ｓ２３）を総合して「表示手続期間」と称する。
【００２２】
本発明に係る表示システムは、アプリケーション２０１で生成された第１画像データに基づきフレームバッファ２０６内に第２画像データを作成するための２つの描画モードを有している。まず第１の描画モードは、論理描画面２０４を使用して第２画像データを作成する「通常描画モード」である。この描画モードでは、アプリケーション２０１が生成した第１画像データを、一旦所定の論理描画面２０４に書き込む。そして各描画面の重畳を考慮して、各論理描画面２０４の第１画像データをフレームバッファ２０６に転送することにより、フレームバッファ２０６内に第２画像データを作成する。この描画モードでは、比較的単純なアルゴリズムで描画面の重畳を再現できるため、複数の描画面が重畳する複雑な画面構成のアプリケーションに対して有効である。
【００２３】
第２の描画モードは、論理描画面２０４を使用せずに、フレームバッファ２０６に直接第１描画データを書き込むことによって第２画像データを作成する「直接描画モード」である。この描画モードでは、アプリケーション２０１が生成した第１画像データを、論理描画面２０４を介することなく、フレームバッファ２０６内の第２画像データの少なくとも一部に上書きすることで、新たな第２画像データを作成するのである。この直接描画モードでは、単一の描画面を扱うのであればＣＰＵ１０１への負担が軽く、高速な処理が可能である。その反面、複数の描画面の重畳を再現しようとする場合には複雑なアルゴリズムの処理が必要になり、かえって描画速度が低下してしまうことが懸念される。つまり、直接描画モードは単一の描画面のみを使用する単純な画面構成のアプリケーションに有効である。
【００２４】
本実施の形態に係る表示システムにおいては、通常描画モードと直接描画モードのどちらを使用してフレームバッファ２０６への描画（第２画像データの作成）を行うかを、グラフィックスライブラリ２０３が、アプリケーション２０１の使用する描画面数に応じて切り替える。即ち、描画を行うアプリケーション２０１が複数の描画面を使用するものである場合は通常描画モードが選択され、単一の描画面のみを使用するものである場合は直接描画モードが選択される。
【００２５】
図４は実施の形態１における描画方法を示すフローチャートである。この図に基づいて、実施の形態１の表示システムの動作を説明する。
【００２６】
まず、アプリケーション２０１は、グラフィックスライブラリ２０３が提供する論理描画面作成命令を実行する。論理描画面作成命令が実行されると、グラフィックスライブラリ２０３は、汎用メモリ上１０２にアプリケーション２０１が必要としている大きさのメモリ領域を確保することで論理描画面２０４を作成する（Ｓ１１）。このとき、複数の描画面を使用するアプリケーション２０１には描画対象として論理描画面２０４が必要な枚数だけ割当てられる。一方、単一の描画面のみを使用するアプリケーション２０１には描画対象としてフレームバッファ２０６が割当てられる。アプリケーション２０１は、自己の描画対象を指定し、グラフィックスライブラリ２０３が提供する描画関数を実行することによって、指定した描画対象の任意の場所に描画（第１画像データの書き込み）を行うことができる。つまり、複数の描画面を使用するアプリケーション２０１は、任意の論理描画面２０４に描画を行うことができ、単一の描画面のみを使用するアプリケーション２０１は、フレームバッファ２０６に直接描画を行うことができる。描画対象を確保したアプリケーション２０１のそれぞれは、外部イベント２０２が入力されるのを待つ待機状態になる。
【００２７】
外部イベント２０２が発生してそれをアプリケーション２０１が受け付けると（Ｓ１２）、当該外部イベント２０２に応じた所定の処理を行う（Ｓ１３）。そしてグラフィックスライブラリ２０３はアプリケーション２０１の描画モードを判断して、アプリケーション２０１にその描画モードに応じた描画処理を実行させる（Ｓ１４）。上述のように本実施の形態では、描画を行うアプリケーション２０１が複数の描画面を使用するものである場合は通常描画モードが選択され、単一の描画面のみを使用するものである場合には直接描画モードが選択される。
【００２８】
通常描画モードの場合は、アプリケーション２０１は描画対象として任意の論理描画面２０４を指定して、描画関数を実行することによりそれに第１画像データを書き込む（Ｓ１５）。論理描画面２０４への書き込みが完了すると、グラフィックスライブラリ２０３は転送命令を実行する。転送命令が実行されると、ディスプレイドライバ２０５は各論理描画面２０４の第１画像データを、各描画面の重なり具合を考慮してフレームバッファ２０６に転送する（Ｓ１６）。それにより、フレームバッファ２０６内に新たな第２画像データが作成される。その後、グラフィックスライブラリ２０３は表示コントローラ２０８の状態が表示手続期間かどうかを判定し（Ｓ１８）、当該表示手続期間中でなければすぐにリフレッシュ命令を実行し（Ｓ１９）、アプリケーション２０１の外部イベント２０２の待機状態に戻る。表示手続期間中であればそれが終了するまで待機した後でリフレッシュ命令を実行して（Ｓ１９）、アプリケーション２０１の外部イベント２０２の待機状態に戻る。
【００２９】
一方、直接描画モードの場合、アプリケーション２０１は描画対象であるフレームバッファ２０６を指定して描画関数を実行することにより、フレームバッファ２０６内の第２画像データの一部に第１画像データを上書きする（Ｓ１７）。それにより、フレームバッファ２０６内に新たな第２画像データが作成される。フレームバッファ１０６への書き込みが完了すると、グラフィックスライブラリ２０３は表示コントローラ２０８の状態が表示手続期間にあるどうかを判定し（Ｓ１８）、当該表示手続期間中でなければすぐにリフレッシュ命令を実行し（Ｓ１９）、アプリケーション２０１の外部イベント２０２の待機状態に戻る。表示手続期間中であればそれが終了するまで待機した後でリフレッシュ命令を実行して（Ｓ１９）、アプリケーション２０１の外部イベント２０２の待機状態に戻る。
【００３０】
図５は実施の形態１に係る表示システムの通常描画モードにおける動作を説明するための動作タイミング図である。表示デバイスのリフレッシュレートは６０Ｈｚであると仮定する。つまり、表示デバイスヘのデータ供給は、１６．７ｍｓｅｃ毎に１回行われることになる。
【００３１】
複数の描画面を使用する通常描画モードのアプリケーション２０１において、時刻ｔ１１に外部イベント２０２が発生したとする。アプリケーション２０１は当該外部イベント２０２を処理し、その処理結果に応じて論理描画面２０４への描画（第１画像データの書き込み）を開始する。時刻ｔ１２で論理描画面２０４への描画が完了すると、グラフィックスライブラリ２０３は転送命令を実行する。転送命令が実行されると、ディスプレイドライバ２０５は各描画面の重なり具合を考慮して論理描画面２０４からフレームバッファ２０６へ第１画像データの転送を行う。それにより、表示デバイス２０７内に第２画像データが作成される。当該転送が終了した時刻ｔ１３で、グラフィックスライブラリ２０３はリフレッシュ命令を実行する。ディスプレイドライバ２０５はリフレッシュ命令を受け、表示コントローラ２０８（図５では不図示）にリフレッシュ要求を行う。リフレッシュ要求を受けた表示コントローラ２０８は、表示デバイス２０７のリフレッシュタイミングまで待機し、リフレッシュタイミングである時刻ｔ１４でフレームバッファ２０６内の第２画像データの表示デバイス２０７への転送を開始する。そして時刻ｔ１５で当該転送が完了し、第２画像データに基づく画像が表示デバイス２０７上に表示される。
【００３２】
また、図６は実施の形態１に係る表示システムの直接描画モードにおける動作を説明するための動作タイミング図である。ここでも、表示デバイスのリフレッシュレートは６０Ｈｚであるとする。
【００３３】
単一の描画面のみを使用する直接描画モードのアプリケーション２０１において、時刻ｔ２１に外部イベント２０２が発生したとする。アプリケーション２０１は当該外部イベント２０２を処理し、その処理結果に応じてフレームバッファ２０６への描画（第１画像データの書き込み）を開始する。時刻ｔ２２でフレームバッファ２０６への描画が完了すると、グラフィックスライブラリ２０３はリフレッシュ命令を実行する。ディスプレイドライバ２０５はリフレッシュ命令を受け、表示コントローラ２０８（図６では不図示）にリフレッシュ要求を行う。リフレッシュ要求を受けた表示コントローラ２０８は、表示デバイス２０７のリフレッシュタイミングまで待機し、リフレッシュタイミングである時刻ｔ２３でフレームバッファ２０６内の第２画像データの表示デバイス２０７への転送を開始する。そして時刻ｔ２４で転送が完了し、第２画像データに基づく画像が表示デバイス２０７上に表示される。
【００３４】
図５、図６を見て分かるように、直接描画モードの場合は、論理描画面２０４を介することなくフレームバッファ２０６内に新たな第２画像データを作成するので、表示デバイス２０７への描画処理に要する時間を短縮することができる。本実施の形態によれば、複数の描画面を使用するアプリケーション２０１は、従来と同様に通常描画モードで描画を行うが、単一の描画面のみを使用するアプリケーション２０１は直接描画モードで描画を行うため、全体としてＣＰＵの負担の軽減および描画速度の向上が実現できる。
【００３５】
また、アプリケーション２０１の動作に着目すると、本実施の形態の直接描画モードは、グラフィックスライブラリ２０３によりアプリケーション２０１に割当てられる描画対象が、従来の論理描画面２０４からフレームバッファ２０６に変わったのみである。つまり、本発明の実施にあたり、従来のアプリケーション構造から大幅な変更を加える必要はない。よって、高速描画のためのアプリケーション開発コストを抑えることができる。また、描画処理専用のハードウェアを使用するのではないため、表示システムの大規模化並びにコスト増大が抑制されていることは言うまでもない。
【００３６】
＜実施の形態２＞
実施の形態１では、アプリケーション２０１が複数の描画面を使用するものであるか、単一の描画面のみを使用するものであるかによって、使用する描画モードが切り替えられていた。即ち、アプリケーション２０１ごとに予め描画モードが定められているので、例えば、複数の描画面を使用するアプリケーション２０１が実際には単一の描画面しか使用していない場合でも、通常描画モードでの描画が実行される。
【００３７】
しかし、複数の描画面を使用するアプリケーション２０１であっても、実際には殆どの時間は単一の描画面しか使用しておらず、メッセージダイアログの表示など複数の描画面を必要とする外部イベント２０２が発生することが稀であることも多い。そこで、本実施の形態では各アプリケーション２０１の描画モードを、発生した外部イベント２０２ごとに切り替える。つまり、複数の描画面を使用するアプリケーション２０１であっても、単一の描画面しか必要としない外部イベント２０２の処理には、直接描画モードを使用可能にする。
【００３８】
実施の形態２の表示システムの動作を説明する。なお、本実施の形態においても、表示システムのハードウェア構成およびソフトウェア構成はそれぞれ図１および図２で示したものと同様であり、表示コントローラ２０８の動作は図３で示したフローチャートに基づいている。
【００３９】
図７は実施の形態２における描画方法を示すフローチャートである。同図から分かるように、図４に示したフローと異なるのは、グラフィックスライブラリ２０３が描画モードを判断するステップＳ１４の前に、アプリケーション２０１の描画モードを設定するステップＳ２０が実行される点である。それ以外のフローに関しては、図４で同一符号を付したものと同様の内容であるので、ここでの詳細な説明は省略する。
【００４０】
上記ステップＳ２０においては、外部イベント２０２が複数の描画面を必要とするものか、単一の描画面を必要とするものかによって、使用する描画モードを切り替える。即ち、外部イベント２０２が複数の描画面を必要とするものであれば通常描画モードが選択され、単一の描画面を必要とするものであれば直接描画モードが選択される。
【００４１】
図８は、ステップＳ２０における処理を示すフローチャートである。まず、グラフィックスライブラリ２０３は、現時点のアプリケーション２０１の描画モードと、外部イベント２０２の処理（図７のＳ１３）の結果アプリケーション２０１が今回使用する描画面数を確認する（Ｓ２０１，Ｓ２０１，Ｓ２０３）。
【００４２】
このとき、描画モードが直接描画モードであり、且つ、アプリケーション２０１が単一の描画面数のみを使用するのであれば、そのまま直接描画モードを維持する（Ｓ２０４）。また、現時点の描画モードが直接描画モードであり、且つ、アプリケーション２０１が複数の描画面を使用するのであれば、描画モードを通常描画モードに切り替えることになるが、現時点では描画対象がフレームバッファ２０６であり、論理描画面２０４が確保されていない可能性がある。そのため、グラフィックスライブラリ２０３は、汎用メモリ１０２内に指定された描画面に対応する論理描画面２０４を確保し（Ｓ２０４）、ディスプレイドライバ２０５を用いてフレームバッファ２０６内の第２画像データを当該論理描画面２０４に転送した後で（Ｓ２０５）、描画モードを通常描画モードに切り替える（Ｓ２０６）。
【００４３】
さらに、描画モードが通常描画モードであり、且つ、アプリケーション２０１が複数の描画面数を使用するのであれば、そのまま通常描画モードを維持する（Ｓ２０８）。また、現時点の描画モードが通常描画モードであり、且つ、アプリケーション２０１が単一の描画面を使用するのであれば、描画モードを直接描画モードに切り替えることになるが、現時点では描画対象がフレームバッファ２０６ではなく論理描画面２０４になっている状態である。そのため、グラフィックスライブラリ２０３は、ディスプレイドライバ２０５を用いて、指定された論理描画面２０４内の第１画像データを論理描画面２０４に転送し（Ｓ２０９）、フレームバッファ２０６を当該アプリケーション２０１の描画対象として割当てた後で（Ｓ２１０）、描画モードを直接描画モードに切り替える（Ｓ２１１）。
【００４４】
その結果、ステップＳ１２で発生した外部イベント２０２が複数の描画面を必要とするものであれば、ステップＳ２０でアプリケーション２０１の描画モードは通常描画モードに設定され、ステップＳ１５，Ｓ１６により通常描画モードでの描画処理が実行される。また、ステップＳ１２で発生した外部イベント２０２が単一の描画面のみを必要とするものであれば、アプリケーション２０１が複数の描画面を使用するものであっても、ステップＳ２０で当該アプリケーション２０１の描画モードは直接描画モードに設定され、ステップＳ１７により通常描画モードでの描画処理が実行される。
【００４５】
本実施の形態によれば、複数の描画面を使用するアプリケーション２０１であっても、単一の描画面しか必要としない外部イベント２０２の処理には、直接描画モードを使用することが可能になる。そのため、複数の描画面を使用するアプリケーション２０１の描画速度も向上され、実施の形態１よりも高速な描画処理を行うことができる。
【００４６】
＜実施の形態３＞
実施の形態１および２において、直接描画モードではアプリケーション２０１は、論理描画面２０４を介することなく、フレームバッファ２０６に直接第１描画データを書き込むことによって第２画像データを作成する。また、フレームバッファ２０６から表示デバイス２０７への第２画像データの転送は、ＣＰＵ１０１とは独立して表示コントローラ２０８が処理を行っているので、場合によってはフレームバッファ２０６への第１画像データの書き込み中に、表示デバイス２０７への第２画像データの転送が開始されることも考えられる。その場合、表示デバイス２０７へは描画途中の画像が表示されてしまうことになる。
【００４７】
図９はその現象を説明するための動作タイミング図である。例えば、実施の形態１の表示システムにおいて、時刻ｔ３１でグラフィックスライブラリ２０３がリフレッシュ命令を実行し、ディスプレイドライバ２０５はリフレッシュ命令を受け、表示コントローラ２０８にリフレッシュ要求を行ったとする。リフレッシュ要求を受けた表示コントローラ２０８は、表示デバイス２０７のリフレッシュタイミングである時刻ｔ３３まで待機する（図３のステップＳ２２）。
【００４８】
その間にもアプリケーション２０１の外部イベント２０２の待機状態に戻る（図４のステップＳ１２）。そして、時刻ｔ３３より前の時刻ｔ３２で別の外部イベント２０２に起因して、直接描画モードでのフレームバッファ２０６への描画（第１画像データの書き込み）が開始されたとする（図４のステップＳ１８）。続いて、当該描画が完了する時刻ｔ３４より前の時刻ｔ３３でリフレッシュタイミングが発生すると、表示コントローラ２０８は、フレームバッファ２０６内の第２画像データを表示デバイス２０７へ転送し始める（図３のステップＳ２３）。当該転送は時刻ｔ３５で完了するが、表示デバイス２０７へ転送された第２画像データは描画途中のものであるので、表示デバイス２０７へは不完全な画像が表示されてしまうことになる。
【００４９】
なお、時刻ｔ３４でフレームバッファ２０６への描画が完了したときに発生するリフレッシュ要求は、時刻ｔ３１〜ｔ３５の表示手続期間が終わるのを待機した後で表示コントローラ２０８に送られる（図４のステップＳ１８，Ｓ１９）。表示コントローラ２０８はリフレッシュタイミングである時刻ｔ３６まで待機した後で、フレームバッファ２０６内の第２画像データの表示デバイス２０７への転送を開始する。そして時刻ｔ３７で当該転送が完了し、そのとき初めて時刻ｔ３２〜ｔ３４で作成された第２画像データに基づく画像が表示デバイス２０７上に完全に表示される。
【００５０】
実施の形態３に係る表示システムは、表示デバイス２０７へは不完全な画像が表示されてしまうことを防止するロック機能を有するものである。以下、実施の形態３に係る表示システムの動作を説明する。なお、本実施の形態においても、表示システムのハードウェア構成およびソフトウェア構成はそれぞれ図１および図２で示したものと同様であり、表示コントローラ２０８の動作は図３で示したフローチャートに基づいている。
【００５１】
図１０は実施の形態３における描画方法を示すフローチャートである。同図から分かるように、図４に示したフローと異なるのは、直接描画モードでフレームバッファ２０６への描画を行うステップＳ１５の前に、アプリケーション２０１がロック機能を使用するか否かを判定するステップＳ３０と、ロック機能を使用する場合に表示コントローラ２０８の表示手続期間が終了するのを待機するステップＳ３１が加わった点である。それ以外のフローに関しては、図４で同一符号を付したものと同様の内容であるので、ここでの詳細な説明は省略する。
【００５２】
上記ステップＳ３０においては、アプリケーション２０１がロック機能を使用するか否か判定されるが、本実施の形態では、その設定は予めグラフィックスライブラリ２０３が記憶しているものとする。例えばアプリケーション２０１ごとに、ロック機能を使用するアプリケーションと使用しないアプリケーションとを定めておいてもよいし、あるいは発生した外部イベント２０２ごとに、ロック機能を使用するイベントと使用しないイベントとを定めておいてもよい。もちろん、必要に応じてユーザがその設定を変更できるようにしてもよい。
【００５３】
図１１は本実施の形態におけるロック機能を説明するための動作タイミング図である。例えば、時刻ｔ４１でグラフィックスライブラリ２０３がリフレッシュ命令を実行し、ディスプレイドライバ２０５がリフレッシュ命令を受け、表示コントローラ２０８にリフレッシュ要求を行ったとする。リフレッシュ要求を受けた表示コントローラ２０８は、表示デバイス２０７のリフレッシュタイミングである時刻ｔ４３まで待機する（図３のステップＳ２２）。
【００５４】
その間にもアプリケーション２０１の外部イベント２０２の待機状態に戻る（Ｓ１２）。そして、時刻ｔ４３より前の時刻ｔ４２で単一の描画面のみを使用するアプリケーション２０１の外部イベント２０２が発生すると、直接描画モードでのフレームバッファ２０６への描画（第１画像データの書き込み）に先立って、アプリケーション２０１がロック機能を使用するか否かを判定し（Ｓ３０）、ここではロック機能を使用するので表示コントローラ２０８の表示手続期間が終了するのを待機する（Ｓ３１）。そして時刻ｔ４３でリフレッシュタイミングが発生すると、表示コントローラ２０８は、フレームバッファ２０６内の第２画像データを表示デバイス２０７へ転送し始める（図３のステップＳ２３）。このときアプリケーション２０１は待機中であるので、表示デバイス２０７へ転送される第２画像データには描画途中のものは含まれない。そして時刻ｔ４４で当該転送が完了して表示手続期間が終了すると、ステップＳ３１の待機を解除してフレームバッファ２０６への描画（第１画像データの書き込み）を開始する（Ｓ１７）。
【００５５】
そして、時刻ｔ４５でフレームバッファ２０６への書き込みが完了すると、グラフィックスライブラリ２０３はリフレッシュ命令を実行し、表示コントローラ２０８にリフレッシュ要求が送られる（Ｓ１９）。表示コントローラ２０８はリフレッシュタイミングである時刻ｔ４６まで待機した後で、フレームバッファ２０６内の第２画像データの表示デバイス２０７への転送を開始する。そして時刻ｔ４７で当該転送が完了し、時刻ｔ４４〜ｔ４５で作成された第２画像データに基づく画像が表示デバイス２０７上に完全に表示される。
【００５６】
なお、ロック機能を使用しない場合の動作は、実施の形態１および、図９で説明したものと同様であるので、説明は省略する。
【００５７】
このように本実施の形態に係る表示システムにおいては、ロック機能を用いることによって、描画途中の画像が表示デバイス２０７に表示されることが防止できる。例えば、画面上に表示されている入力ダイアログにユーザが文字を入力する際に、描画途中の文字が表示されてしまうような不具合を解消できる。また、一時的に不完全な画像が描画されたとしても使用上の問題の問題が生じないアプリケーション（あるいはイベント）には、ロック機能を使用しないように設定しておくことで描画の高速性を優先させることができる。
【００５８】
なお、本実施の形態では実施の形態１のように、アプリケーション２０１が複数の描画面を使用するものであるか、単一の描画面のみを使用するものであるかによって、使用する描画モードが切り替える構成を示したが、実施の形態２のように各アプリケーション２０１の描画モードを、発生した外部イベント２０２ごとに切り替えるようにしてもよい。その場合、図１０のフローチャートにおいてステップＳ１４の前に、アプリケーション２０１の描画モードを設定するステップＳ２０（図８）を実行すればよい。それによって、複数の描画面を使用するアプリケーション２０１の描画速度も向上され、よりも高速な描画処理を行うことができる。
【００５９】
＜実施の形態４＞
実施の形態１で説明したように、表示コントローラ２０８の表示手続期間はグラフィックスライブラリ２０３によるリフレッシュ命令の実行は制限され、当該表示手続期間が終了するまで待機する（図４のステップＳ１８）。これは、表示デバイス２０７への第２画像データ転送中に、新たなリフレッシュ命令によって転送領域を示す座標データが変更されることで画面表示が乱れることを防ぐためである。しかし、待機時間が多くなると、全体としての描画速度が低下してしまう。そこで、実施の形態４に係る表示システムでは、表示コントローラ２０８の表示手続期間中でも、グラフィックスライブラリ２０３に待機させることなく、第２画像データの転送領域をマージして、次の処理を進めるようにする。そして当該表示手続期間が終了した後でそれまでにマージした転送領域について、フレームバッファ２０６内の第２画像データの表示デバイス２０７への転送をまとめて行う。
【００６０】
実施の形態２の表示システムの動作を説明する。なお、本実施の形態においても、表示システムのハードウェア構成およびソフトウェア構成はそれぞれ図１および図２で示したものと同様であり、表示コントローラ２０８の動作は図３で示したフローチャートに基づいている。
【００６１】
図１２は実施の形態４における描画方法を示すフローチャートである。同図から分かるように、図４に示したフローと異なるのは、表示コントローラ２０８の表示手続期間か否かを判定するステップＳ１８において、表示手続期間中である場合の処理として、リフレッシュ命令に含まれる転送領域を示す座標データをマージするステップＳ４０が行なわれ、当該ステップＳ４０の実行後は待機することなく外部イベント２０２のイベント待ち状態に戻る点である。当該ステップＳ４０でマージされる座標手データは、汎用メモリ１０２内に記憶される。それ以外のフローに関しては、図４で同一符号を付したものと同様の内容であるので、ここでの詳細な説明は省略する。
【００６２】
図１３は本実施の形態に係る表示システムの動作を説明するための動作タイミング図である。例えば、時刻ｔ５１でグラフィックスライブラリ２０３がリフレッシュ命令を実行し、ディスプレイドライバ２０５がリフレッシュ命令を受け、表示コントローラ２０８にリフレッシュ要求を行ったとする。リフレッシュ要求を受けた表示コントローラ２０８は、表示デバイス２０７のリフレッシュタイミングである時刻ｔ５４まで待機し（図３のステップＳ２２）、その後時刻ｔ６７までの間、フレームバッファ２０６から表示デバイス２０７への第２画像データの転送を行う。
【００６３】
その間にもアプリケーション２０１の外部イベント２０２の待機状態に戻る（Ｓ１２）。そして、時刻ｔ５７より前の時刻ｔ５２〜ｔ５３の間に別の外部イベント２０２に起因する直接描画モードでのフレームバッファ２０６への描画（第１画像データの書き込み）が行なわれたとする（Ｓ１８）。グラフィックスライブラリ２０３は、当該描画処理が完了する時刻ｔ５３に発生するリフレッシュ要求（Ｓ１９）に含まれる転送領域を示す座標データを汎用メモリ１０２内にマージして記憶する。
【００６４】
その後は待機することなく、再びアプリケーション２０１の外部イベント２０２の待機状態に戻る（Ｓ１２）。そしてさらに時刻ｔ５７より前の時刻ｔ５５〜ｔ５６の間に別の外部イベント２０２に起因する直接描画モードでのフレームバッファ２０６への描画（第１画像データの書き込み）が行なわれたとする（Ｓ１８）。グラフィックスライブラリ２０３は、当該描画処理が完了する時刻ｔ５３に発生するリフレッシュ要求（Ｓ１９）に含まれる転送領域を示す座標データを汎用メモリ１０２内にマージして記憶する。
【００６５】
そしてマージされた座標データ（時刻ｔ５３およびｔ５６で発生したリフレッシュ要求に含まれる座標データ）は、時刻ｔ５１〜ｔ５７の表示手続期間が終わるとリフレッシュ要求と共に表示コントローラ２０８に送られる。その後は、表示コントローラ２０８はリフレッシュタイミングである時刻ｔ５８まで待機した後で、マージされた座標データに基づいて、フレームバッファ２０６内の第２画像データの表示デバイス２０７への転送を開始する。そして時刻ｔ５９で当該転送が完了し、時刻ｔ５２〜ｔ５３およびｔ５５〜ｔ５６で作成された第２画像データに基づく画像が表示デバイス２０７上に完全に表示される。
【００６６】
このように、本実施の形態によれば、表示コントローラ２０８の表示手続期間の終了を待つ待機時間を無くすことができるので、より高速な描画処理を行うことが可能になる。
【００６７】
なお、本実施の形態では実施の形態１のように、アプリケーション２０１が複数の描画面を使用するものであるか、単一の描画面のみを使用するものであるかによって、使用する描画モードが切り替える構成を示したが、実施の形態２のように各アプリケーション２０１の描画モードを、発生した外部イベント２０２ごとに切り替えるようにしてもよい。その場合、図１２のフローチャートにおいてステップＳ１４の前に、アプリケーション２０１の描画モードを設定するステップＳ２０（図８）を実行すればよい。それによって、複数の描画面を使用するアプリケーション２０１の描画速度も向上され、よりも高速な描画処理を行うことができる。
【００６８】
また、本実施の形態は、上記の実施の形態３のロック機能と組み合わせることも可能である。即ち、図１２のフローチャートにおいてステップＳ１５の前に、実施の形態３で説明したアプリケーション２０１がロック機能を使用するか否かを判定するステップＳ３０と、ロック機能を使用する場合に表示コントローラ２０８の表示手続期間が終了するのを待機するステップＳ３１とを加えてもよい。ロック機能を動作させない場合に、表示コントローラ２０８の表示手続期間の終了を待つ待機時間を無くすことができるので、より高速な描画処理を行うことが可能になる。
【図面の簡単な説明】
【００６９】
【図１】本発明に係る表示システムのハードウェア構成を示す図である。
【図２】本発明に係る表示システムのソフトウェア構成を示す図である。
【図３】実施の形態１に係る表示システムにおける表示コントローラの動作を示すフローチャートである。
【図４】実施の形態１に係る表示システムにおける描画方法のフローチャートである。
【図５】実施の形態１に係る表示システムの通常描画モードにおける動作タイミング図である。
【図６】実施の形態１に係る表示システムの直接描画モードにおける動作タイミング図である。
【図７】実施の形態２に係る表示システムの描画方法を示すフローチャートである。
【図８】実施の形態２における描画モード設定の処理を示すフローチャートである。
【図９】実施の形態１および実施の形態２の問題点を説明するための図である。
【図１０】実施の形態３に係る表示システムにおける描画方法のフローチャートである。
【図１１】実施の形態３におけるロック機能を説明するためのタイミング図である。
【図１２】実施の形態４における描画方法を示すフローチャートである。
【図１３】実施の形態４に係る表示システムの動作を説明するための動作タイミング図である。
【符号の説明】
【００７０】
１０１  ＣＰＵ、１０２  汎用メモリ、１０３  汎用バス、１０６  フレームバッファ、１０７  表示デバイス、１０８  表示コントローラ、２０１  アプリケーション、２０２  外部イベント、２０３  グラフィックスライブラリ、２０４  論理描画面、２０５  ディスプレイドライバ、２０６  フレームバッファ、２０７  表示デバイス、２０８  表示コントローラ。
【図１】
2005275028.tif 000003
【図２】
2005275028.tif 000004
【図３】
2005275028.tif 000005
【図４】
2005275028.tif 000006
【図５】
2005275028.tif 000007
【図６】
2005275028.tif 000008
【図７】
2005275028.tif 000009
【図８】
2005275028.tif 000010
【図９】
2005275028.tif 000011
【図１０】
2005275028.tif 000012
【図１１】
2005275028.tif 000013
【図１２】
2005275028.tif 000014
【図１３】
2005275028.tif 000015