JP6812973B2 - 情報処理装置、および情報処理方法、並びにプログラム - Google Patents

Description

本開示は、情報処理装置、および情報処理方法、並びにプログラムに関する。さらに詳細には、画像の描画処理を行ない、さらに描画画像に対する画像変換を実行する情報処理装置、および情報処理方法、並びにプログラムに関する。

昨今、テレビその他の表示装置として、高解像度画像や、広ダイナミックレンジ画像、あるいは、より広い色空間の色を出力可能な表示装置が開発され、利用が広がりつつある。
なお、高解像度、広ダイナミックレンジ、出力色空間の広い画像は、例えばＵＨＤ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）画像と呼ばれ、このＵＨＤ画像を表示するＵＨＤ対応表示装置の利用も普及段階にある。

しかし、現時点では、ＵＨＤ画像を表示可能な表示装置であるＵＨＤ対応表示装置と、従来型の表示装置が混在する。
このような現状において、例えばＢＤ（Ｂｌｕ−ｒａｙ（登録商標）Ｄｉｓｃ）から画像データを読み出して、表示部に表示する処理を実行する場合、従来型の表示装置、およびＵＨＤ対応表示装置のいずれの表示装置でも、それぞれの表示機能に応じた画像を表示可能とすることが要求される。

このためには、まず、従来型の表示装置において表示可能な、例えばＳＤＲ（Ｓｔａｎｄａｒｄ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）画像を生成し、その後、必要に応じて、解像度変換、ダイナミックレンジ変換、あるいは色空間変換などの画像変換を実行して、ＵＨＤ対応表示装置に表示する構成をとる必要がある。

この場合、例えば、画像描画アプリケーションによる画像描画処理と、描画画像に対する画像変換処理、さらに、画像表示処理という異なるフェーズの処理を順次、実行することが必要となる。
このような複数の異なる処理を実行する場合、例えば１つの画像描画コマンドの完了前に画像変換や表示処理が開始されると、不完全な画像が表示されとしまう。
完全な変換画像を表示するためには、描画処理の完了後に変換処理や表示処理を実行することが必要であり、各処理の実行タイミングを何らかの手法で制御することが必要となる。

なお、特許文献１（特許第４９６２６７４号公報）には、３Ｄ画像を構成する左眼用画像と右眼の整合性を確保し、描画の完了した画像を表示するための表示タイミングを決定する構成を開示している。
しかし、この開示文献は、３Ｄ画像を構成する左眼用画像と右眼の整合性を確保するための処理タイミングの制御構成を開示しているに過ぎない。

特許第４９６２６７４号公報

本開示は、例えば上記問題点に鑑みてなされたものであり、解像度変換、ダイナミックレンジ変換、あるいは色空間変換などの画像変換を実行して、表示装置に表示する処理を行なう構成において、描画処理の完了タイミングを検知した上で、画像変換を実行して表示画像の出力を行う情報処理装置、および情報処理方法、並びにプログラムを提供することを目的とする。

本開示の第１の側面は、
描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
前記アプリケーション実行部は、
描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行し、
前記バッファ管理部は、
前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行し、
前記表示画像生成部は、
前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行する情報処理装置にある。

さらに、本開示の第２の側面は、
情報処理装置において実行する情報処理方法であり、
前記情報処理装置は、
描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
前記アプリケーション実行部は、
描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行し、
前記バッファ管理部は、
前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行し、
前記表示画像生成部は、
前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行する情報処理方法にある。

さらに、本開示の第３の側面は、
情報処理装置において情報処理を実行させるプログラムであり、
前記情報処理装置は、
描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
前記プログラムは、
前記アプリケーション実行部に、
描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行させ、
前記バッファ管理部に、
前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行させ、
前記表示画像生成部に、
前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行させるプログラムにある。

なお、本開示のプログラムは、例えば、様々なプログラム・コードを実行可能な情報処理装置やコンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体によって提供可能なプログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、情報処理装置やコンピュータ・システム上でプログラムに応じた処理が実現される。

本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本開示の一実施例の構成によれば、アプリケーションが実行する描画コマンドによる描画処理の完了を検知して、描画処理完了画像に対する変換処理や表示処理を行なう構成が実現される。
具体的には、描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、記憶部の描画画像に対する変換処理を実行する表示画像生成部と、記憶部の複数バッファの切り替えを実行するバッファ管理部を有する。アプリケーション実行部は、描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出しを実行し、バッファ管理部は、描画完了通知ＡＰＩの呼び出しに応じてバッファ切り替え処理を実行する。表示画像生成部は、アプリ実行部の描画中のバッファと異なるバッファの格納画像に対する画像変換を実行する。
本構成により、アプリケーションが実行する描画コマンドによる描画処理の完了を検知して、描画処理完了画像に対する変換処理や表示処理を行なう構成が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

ＢＤＭＶフォーマットの概要を説明する図である。 ＢＤのファイルの管理構造を説明する図である。 記録メディア１０から読み取られたデータの再生処理例を示す図である。 情報処理装置２０の一部構成であり、画像を出力するための構成例を示す図である。 ＢＤ−Ｊアプリケーション等を実行するデータ処理部３０の具体的な構成例について説明する図である。 データ処理部３０の実行する画像変換処理の具体例について説明する図である。 データ処理部３０の実行する画像変換処理の具体例について説明する図である。 スクリーンティアリングについて説明する図である。 画像フレーム単位の描画コマンドの設定例と実行態様を示す図である。 実施例１の情報処理装置の構成と処理について説明する図である。 実施例１の情報処理装置の実行する処理について説明するフローチャートを示す図である。 実施例２の情報処理装置の構成と処理について説明する図である。 実施例２の情報処理装置の実行する処理について説明するフローチャートを示す図である。 情報処理装置のハードウェア構成例を示す図である。

以下、図面を参照しながら本開示の情報処理装置、および情報処理方法、並びにプログラムの詳細について説明する。なお、説明は以下の項目に従って行なう。
１．情報記録媒体の記録データと再生処理例について
２．情報処理装置におけるＢＤ−Ｊアプリケーションを利用した画像出力処理例について
３．画像変換を伴う画像出力処理における問題点について
３−１．スクリーンティアリングについて
３−２．画像変換処理の負荷について
４．本開示の情報処理装置の実行する処理の概要について
５．（実施例１）記憶部（グラフィックスプレーン）をダブルバッファとした構成を適用した実施例について
６．（実施例２）記憶部（グラフィックスプレーン）４０をトリプルバッファとした構成を適用した実施例について
７．情報処理装置のハードウェア構成例について
８．本開示の構成のまとめ

［１．情報記録媒体の記録データと再生処理例について］
まず、情報記録媒体の記録データと再生処理例について説明する。
以下では、情報記録媒体の一例として、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃの記録データと、再生処理例を説明する。

図１以下を参照して、読み出し専用タイプのＢＤであるＢＤ−ＲＯＭに記録されたコンテンツ、すなわち、ＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）データ等の管理構造（以下、ＢＤＭＶフォーマットともいう）について説明する。

例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）ビデオや、ＭＰＥＧオーディオ等の符号化方式で符号化され、ＭＰＥＧ２システムに従って多重化されたビットストリームは、クリップＡＶストリーム（またはＡＶストリーム）と呼ばれる。クリップＡＶストリームは、ＢＤに関する規格の一つである「Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ Ｒｅａｄ−Ｏｎｌｙ Ｆｏｒｍａｔ ｐａｒｔ２で定義されたファイルシステムにより、ファイルとしてＢＤに記録される。クリップＡＶストリームのファイルは、クリップＡＶストリームファイル（またはＡＶストリームファイル）と呼ばれる。

クリップＡＶストリームファイルは、ファイルシステム上での管理単位であり、クリップＡＶストリームファイル（のクリップＡＶストリーム）を再生に必要な情報等は、データベースとしてＢＤに記録される。このデータベースについては、ＢＤ規格の一つである「Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ Ｒｅａｄ−Ｏｎｌｙ Ｆｏｒｍａｔ ｐａｒｔ３で規定されている。

図１は、ＢＤＭＶフォーマットの概要を説明する図である。
ＢＤＭＶフォーマットは、４層のレイヤから構成される。

最下位のレイヤは、クリップＡＶストリームが属するレイヤであり、以下、適宜、クリップレイヤともいう。

クリップレイヤの１つ上のレイヤは、クリップＡＶストリームに対する再生箇所を指定するための、プレイリスト（Ｍｏｖｉｅ ＰｌａｙＬｉｓｔ）が属するレイヤで、以下、プレイリストレイヤともいう。

プレイリストレイヤの１つ上のレイヤは、プレイリストに対して再生順等を指定するコマンドからなるムービーオブジェクト（Ｍｏｖｉｅ Ｏｂｊｅｃｔ）等が属するレイヤで、以下、オブジェクトレイヤともいう。

オブジェクトレイヤの１つ上のレイヤ（最上位のレイヤ）は、ＢＤに格納されるタイトル等を管理するインデックステーブルが属するレイヤで、以下、インデクスレイヤともいう。

クリップレイヤ、プレイリストレイヤ、オブジェクトレイヤ、および、インデクスレイヤについて、さらに説明する。
クリップレイヤには、クリップＡＶストリームや、クリップ情報（Ｃｌｉｐ Ｉｎｆｏｒｍａｔｉｏｎ）等が属する。

クリップＡＶストリームは、コンテンツのデータとしてのビデオデータやオーディオデータ等をＴＳ（ＭＰＥＧ２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ））の形にしたストリームである。
クリップ情報（Ｃｌｉｐ Ｉｎｆｏｒｍａｔｉｏｎ）は、クリップＡＶストリームに関する情報であり、ファイルとして、ＢＤに記録される。

なお、クリップＡＶストリームには、字幕やメニュー等のグラフィクスのストリームも、必要に応じて含まれる。

字幕（のグラフィクス）のストリームは、プレゼンテーショングラフィクス（ＰＧ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓ））ストリームと呼ばれ、メニュー（のグラフィクス）のストリームは、インタラクティブグラフィクス（ＩＧ（Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓ））ストリームと呼ばれる。

また、クリップＡＶストリームファイルと、対応するクリップ情報（そのクリップＡＶストリームファイルのクリップＡＶストリームに関するクリップ情報）のファイル（クリップ情報ファイル）とのセットは、クリップ（Ｃｌｉｐ）と呼ばれる。

クリップは、クリップＡＶストリームとクリップ情報とから構成される、１つのオブジェクトである。

クリップを構成するクリップＡＶストリームに対応するコンテンツを時間軸上に展開したときの最初と最後の位置（時刻）を含む複数の位置は、アクセスポイントに設定される。アクセスポイントは、主に、タイムスタンプで、上位のレイヤのプレイリスト（ＰｌａｙＬｉｓｔ）により指定される。

クリップを構成するクリップ情報は、プレイリストがタイムスタンプで指定したアクセスポイントが表す、クリップＡＶストリームの位置のアドレス（論理アドレス）を含む。

プレイリストレイヤには、プレイリスト（Ｍｏｖｉｅ ＰｌａｙＬｉｓｔ）が属する。
プレイリストは、再生を行うＡＶストリームファイルと、そのＡＶストリームファイルの再生箇所を指定する再生開始点（ＩＮ点）、および、再生終了点（ＯＵＴ点）とを含むプレイアイテム（ＰｌａｙＩｔｅｍ）から構成される。
したがって、プレイリストは、プレイアイテムの集合で構成される。

ここで、プレイアイテムの再生とは、そのプレイアイテムに含まれるＩＮ点とＯＵＴ点とによって特定される、クリップＡＶストリームの区間の再生を意味する。

オブジェクトレイヤには、ムービーオブジェクト（Ｍｏｖｉｅ Ｏｂｊｅｃｔ）や、ＢＤ−Ｊオブジェクト（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ Ｊａｖａ（登録商標） Ｏｂｊｅｃｔ）が属する。

ムービーオブジェクトは、ＨＤＭＶ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｏｖｉｅ）ナビゲーションコマンドプログラム（ナビコマンド）と、ムービーオブジェクトとを連携するターミナルインフォメーションを含む。

ナビコマンドは、プレイリストの再生を制御するためのコマンドである。ターミナルインフォメーションは、ＢＤを再生するＢＤプレーヤに対するユーザのインタラクティブな操作を許可するための情報を含む。ＢＤプレーヤでは、ターミナルインフォメーションに基づき、メニューの呼び出しや、タイトルサーチといったユーザオペレーションが制御される。

ＢＤ−Ｊオブジェクトは、Ｊａｖａ（登録商標）プログラムであり、ナビコマンドよりも、より高度な（洗練された）インタラクティブ機能を、ユーザに提供することができる。

インデクスレイヤには、インデクステーブル（Ｉｎｄｅｘ ｔａｂｌｅ）が属する。
インデクステーブルは、ＢＤ−ＲＯＭディスクのタイトルを定義する、トップレベルのテーブルである。

インデクステーブルのエントリ（欄）は、タイトルに対応し、各エントリからは、そのエントリに対応するタイトル（ＨＤＭＶタイトル、ＢＤ−Ｊタイトル）のオブジェクト（ムービーオブジェクト、ＢＤ−Ｊオブジェクト）にリンクがはられる。

図２は、記録メディア（ＢＤ）１０のファイルの管理構造を説明する図である。
ＢＤでは、ファイルは、ディレクトリ構造により階層的に管理される。

ＢＤの最上位階層のディレクトリは、ルート（ｒｏｏｔ）ディレクトリになっている。
ルートディレクトリの直下には、ディレクトリ「ＢＤＭＶ」が存在する。
ディレクトリ「ＢＤＭＶ」には、図１で説明したＢＤＭＶフォーマットのファイルが格納される。

ディレクトリ「ＢＤＭＶ」の直下には、ファイル「ｉｎｄｅｘ．ｂｄｍｖ」、および「ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ」の２つのファイルが格納される。なお、ディレクトリ「ＢＤＭＶ」の直下には、ファイル「ｉｎｄｅｘ．ｂｄｍｖ」、および「ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ」以外のファイル（ディレクトリを除く）は、格納することができない。

ファイル「ｉｎｄｅｘ．ｂｄｍｖ」は、ＢＤを再生するメニューに関する情報としての、図１で説明したインデクステーブルを含む。

ＢＤプレーヤは、例えば、ＢＤのコンテンツを全て再生する、特定のチャプタのみを再生する、繰り返し再生をする、所定のメニューを表示する等の内容の項目を含む初期メニュー（の画面）を、ファイル「ｉｎｄｅｘ．ｂｄｍｖ」に基づいて再生する。

また、ファイル「ｉｎｄｅｘ．ｂｄｍｖ」には、各項目が選択されたときに実行するムービーオブジェクト（Ｍｏｖｉｅ Ｏｂｊｅｃｔ）を設定することができ、ユーザにより初期メニュー画面から１つの項目が選択された場合、ＢＤプレーヤは、ファイル「ｉｎｄｅｘ．ｂｄｍｖ」に設定されているＭｏｖｉｅ Ｏｂｊｅｃｔのコマンドを実行する。

ファイル「ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ」は、Ｍｏｖｉｅ Ｏｂｊｅｃｔの情報を含むファイルである。Ｍｏｖｉｅ Ｏｂｊｅｃｔは、ＢＤに記録されているＰｌａｙＬｉｓｔの再生を制御するコマンドを含み、例えば、ＢＤプレーヤは、ＢＤに記録されているＭｏｖｉｅＯｂｊｅｃｔの中から１つを選択して実行することにより、ＢＤに記録されているコンテンツ（タイトル）を再生する。

ディレクトリ「ＢＤＭＶ」の直下には、ディレクトリ「ＰＬＡＹＬＩＳＴ」，「ＣＬＩＰＩＮＦ」，「ＳＴＲＥＡＭ」，「ＡＵＸＤＡＴＡ」，「ＭＥＴＡ」，「ＢＤＪＯ」，「ＪＡＲ」、および「ＢＡＣＫＵＰ」が設けられる。

ディレクトリ「ＰＬＡＹＬＩＳＴ」には、プレイリストのデータベースが格納される。すなわち、ディレクトリ「ＰＬＡＹＬＩＳＴ」には、プレイリストのファイル「ｘｘｘｘｘ．ｍｐｌｓ」が格納される。ファイル「ｘｘｘｘｘ．ｍｐｌｓ」のファイル名には、５桁の数字「ｘｘｘｘｘ」と、拡張子「ｍｐｌｓ」とからなるファイル名が用いられる。

ディレクトリ「ＣＬＩＰＩＮＦ」は、クリップのデータベースが格納される。すなわち、ディレクトリＣＬＩＰＩＮＦ」には、クリップＡＶストリームファイルのそれぞれに対するクリップインフォメーションファイル「ｘｘｘｘｘ．ｃｌｐｉ」が格納される。クリップインフォメーションファイル「ｘｘｘｘｘ．ｃｌｐｉ」のファイル名には、５桁の数字「ｘｘｘｘｘ」と、拡張子「ｃｌｐｉ」とからなるファイル名が用いられる。

ディレクトリ「ＳＴＲＥＡＭ」には、クリップＡＶストリームファイル「ｘｘｘｘｘ．ｍ２ｔｓ」が格納される。クリップＡＶストリームファイル「ｘｘｘｘｘ．ｍ２ｔｓ」には、ＴＳが格納される。クリップＡＶストリームファイル「ｘｘｘｘｘ．ｍ２ｔｓ」のファイル名には、５桁の数字「ｘｘｘｘｘ」と、拡張子「ｍ２ｔｓ」とからなるファイル名が用いられる。

なお、あるクリップを構成するクリップインフォメーションファイル「ｘｘｘｘｘ．ｃｌｐｉ」と、クリップＡＶストリームファイル「ｘｘｘｘｘ．ｍ２ｔｓ」のファイル名としては、拡張子を除き、一致するファイル名が用いられる。これにより、あるクリップを構成するクリップインフォメーションファイル「ｘｘｘｘｘ．ｃｌｐｉ」と、クリップＡＶストリームファイル「ｘｘｘｘｘ．ｍ２ｔｓ」とを、容易に特定することができる。

ディレクトリ「ＡＵＸＤＡＴＡ」には、メニューの表示等に用いられる、サウンドファイル、フォントファイル、フォントインデクスファイルおよびビットマップファイル等が格納される。

ディレクトリ「ＭＥＴＡ」には、メタデータのファイルが格納される。ディレクトリ「ＢＤＪＯ」およびディレクトリ「ＪＡＲ」は、ＢＤ−Ｊオブジェクトのファイルが格納される。ＪＡＶＡ（登録商標）プログラム、コマンド等を格納したＢＤ−Ｊアプリケーション等のファイルである。
ディレクトリ「ＢＡＣＫＵＰ」は、ＢＤに記録されたファイルのバックアップが格納される。

図３は、図１、図２を参照して説明した記録データを持つ記録メディア１０から読み取られたデータの再生処理例を示す図である。
記録メディア１０は、例えばＰＣ２１、再生装置２２、ＴＶ２３等の情報処理装置２０に装着され、再生される。
ＰＣ２１、再生装置２２、ＴＶ２３等の情報処理装置２０にはＢＤドライブが設けられ、ＢＤからのデータ読み取りが可能な構成を持つ。

情報処理装置２０は、記録メディア１０から読み取ったコンテンツ、具体的には、クリップＡＶストリームファイルに格納された画像や音声データを取得し、プレイリストファイル等の再生制御情報ファイルに従って、コンテンツ再生処理を実行する。
再生データに含まれる画像は、図３に示すように、表示部を持つ機器、例えばＰＣやＴＶ等の表示部（ディスプレイ）に表示出力される。

［２．情報処理装置におけるＢＤ−Ｊアプリケーションを利用した画像出力処理例について］
次に、図１、図２を参照して説明した記録データを持つ記録メディア１０からのデータ再生処理を行なう情報処理装置２０の実行するＢＤ−Ｊアプリケーションを利用した画像出力処理例について説明する。

図２を参照して説明したように、記録メディア１０には、ＢＤ−Ｊアプリケーションが記録されている。
情報処理装置２０には、プログラムデータ実行機能を持つＣＰＵ等を備えたデータ処理部を有し、データ処理部において、Ｊａｖａ（登録商標）仮想マシンを実行し、そのＪａｖａ（登録商標）仮想マシン上で、ＢＤ−Ｊアプリケーションを実行する。

図４は、情報処理装置２０の一部構成であり、画像を出力するための構成例を示す図である。
情報処理装置２０のデータ処理部３０は、ＢＤ−Ｊアプリケーションを実行し、記憶部４０に各画像フレームを順次、描画し、格納する。
なお、画像データを格納する記憶部３０は、グラフィクスプレーンとも呼ばれる。グラフィクスプレーンに格納された画像データに対して、様々な画像変換を施すことができる。なお、記憶部（グラフィクスプレーン）４０は、ハードウェア的にはＲＡＭによって構成される。

データ処理部３０は、さらに、記憶部４０に格納された画像に対する画像変換処理を実行する。画像変換は、例えば表示部５０の表示機能に応じた画像変換処理であり、具体的には、例えば、以下のいずれか１つ、または複数を組み合わせた変換処理である。
ａ．解像度変換処理
ｂ．ダイナミックレンジ変換処理
ｃ．色空間変換処理

データ処理部３０は、例えば表示部５０の表示機能に応じて上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する。
ａ．解像度変換は、具体的には例えば２Ｋ画像（１９２０×１０８０画素）から４Ｋ画像（３８４０×２１６０画素）への変換処理等である。
ｂ．ダイナミックレンジ変換処理は、具体的には例えば、ＳＤＲ（Ｓｔａｎｄａｒｄ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）画像から、ＨＤＲ（Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）画像への変換処理等である。
ｃ．色空間変換処理は、具体的には例えば、ＢＴ．７０９色空間から、ＢＴ．２０２０色空間への変換処理等である。
なお、ＢＴ．２０２０色空間は、ＢＴ．７０９色空間より、表現可能な色範囲が広く、肉眼で観察される色空間にほぼ匹敵する自然な色彩表現が可能である。

これらの画像変換は、表示部の出力可能な画素数、ダイナミックレンジ、色空間に応じて行われるものである。
データ処理部３０は、記憶部４０に格納された画像に対して、表示部５０の仕様に応じた画像変換処理を実行することになる。

データ処理部３０は、画像変換された画像データを表示部５０に出力する。
表示部５０に表示される画像は、所定の画像変換処理によって変換された画像であり、例えば表示部５０が、高解像度、広ダイナミックレンジ、出力色空間の広いＵＨＤ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）画像を出力可能な表示部であれはＵＨＤ画像が表示される。

次に、図５を参照してＢＤ−Ｊアプリケーション等を実行するデータ処理部３０の具体的な構成例について説明する。
図５は、データ処理部３０において画像に関する処理を実行する機能構成を示す図である。
データ処理部３０は、図５に示す以下の機能を利用した処理を実行する。
（ａ）ＢＤ−Ｊアプリケーション３１
（ｂ）画像変換処理ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）３３
（ｃ）プレゼンテーションエンジン（Ｐｒｅｓｅｎｔａｔｉｏｎ ｅｎｇｉｎｅ）３４
（ｄ）画像デコーダ（Ｖｉｄｅｏ ｄｅｃｏｄｅｒ）３５
（ｅ）表示制御部（Ｄｉｓｐｌａｙ ｐｒｏｃｅｓｓｏｒ）３６

なお、上記（ａ）〜（ｅ）の構成中、
（ｂ）画像変換処理ＡＰＩ３３
（ｃ）プレゼンテーションエンジン（Ｐｒｅｓｅｎｔａｔｉｏｎ ｅｎｇｉｎｅ）３４
（ｄ）画像デコーダ（Ｖｉｄｅｏ ｄｅｃｏｄｅｒ）３５
（ｅ）表示制御部（Ｄｉｓｐｌａｙ ｐｒｏｃｅｓｓｏｒ）３６
これらの構成をＢＤ−Ｊアプリケーション３１と区別して、表示画像生成部３２と呼ぶ。
表示画像生成部３２は、ＢＤ−Ｊアプリケーション３１が記憶部（グラフィックスプレーン）４０に描画した画像に対する変換処理や表示制御を実行する。

図５に示す各構成の実行する処理について説明する。
（ａ）ＢＤ−Ｊアプリケーション３１は、記憶部（グラフィクスプレーン）４０に対する画像の描画処理を実行する。

（ｂ）画像変換処理ＡＰＩ３３は、ａ．解像度変換処理、ｂ．ダイナミックレンジ変換処理、ｃ．色空間変換処理、これらの画像変換処理を実行するＡＰＩを適用した画像変換処理を実行する。
例えば、解像度変換処理を実行する場合、ＢＤ−Ｊアプリケーション３１は、解像度変換ＡＰＩを呼び出し、解像度等の変更（設定）を要求する。

解像度設定ＡＰＩは、ＢＤ−Ｊアプリケーションからの要求に応じて、プレゼンテーションエンジン、画像デコーダ、表示制御部のうちの必要なものを、直接的に、または間接的に制御することで、解像度を変更する。
ダイナミックレンジ変換処理や、色空間変換処理を行なう場合も、それぞれの変換処理を行なうＡＰＩを利用して処理が行われる。

なお、図５において、プレゼンテーションエンジン（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ）は、オーディオ、ビデオ、および、ＨＤＭＶグラフィクスのデコード機能とプレゼンテーション機能（Ｐｒｅｓｅｎｔａｔｉｏｎ ｆｕｎｃｔｉｏｎｓ）を、ＢＤの再生を制御する、図示せぬプレイバックコントロールエンジン（Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ）に提供する。

また、図５において、ビデオデコーダ（Ｖｉｄｅｏ ｄｅｃｏｄｅｒ）は、画像のデコードを行う。さらに、表示制御部（Ｄｉｓｐｌａｙ ｐｒｏｃｅｓｓｏｒ）は、記憶部（グラフィクスプレーン）４０に格納された画像や変換画像を表示部５０に出力する。

データ処理部３０の実行する画像変換処理の具体例について、図６、図７を参照して説明する。
図６は、ダイナミックレンジ変換処理（ＳＤＲ画像からＨＤＲ画像への変換）を実施しない場合の画像変換例である。

グラフィックス・ソース５１は、ＢＤ−Ｊアプリケーションによって記憶部３０に描画される画像である。
図６に示す例において、グラフィックス・ソース５１は、
１９２０×１０８０画素の画像であり、各画素単位でＲＧＢ各８ビット表現のなされたＳＤＲ画像である。

データ処理部３０は、ステップＳ２１において色空間変換を実行して、図６に示す画像５２、または画像５３、または画像５４のいずれかを生成する。
画像５２は、１９２０×１０８０画素の画像であり、色空間ＢＴ．７０９対応の色情報を持ち、各画素単位で８ビット表現のなされたＳＤＲ画像である。
画像５３は、１９２０×１０８０画素の画像であり、色空間ＢＴ．７０９対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。
画像５４は、１９２０×１０８０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。

データ処理部３０は、このように、ステップＳ２１において、色空間変換を実行して、図６に示す画像５２、または画像５３、または画像５４のいずれかを生成する。

図６に示すステップＳ２２の処理は、上記の画像５３に対する解像度変換処理である。データ処理部３０は、画像５３に対する解像度変換を実行する。
画像５３は、１９２０×１０８０画素の画像であり、色空間ＢＴ．７０９対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。
データ処理部３０は、この画像５３に対する解像度変換を実行して画像５５を生成する。
画像５５は、３８４０×２１６０画素の画像であり、色空間ＢＴ．７０９対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。

また、図６に示すステップＳ２３の処理は、上記の画像５４に対する解像度変換処理である。データ処理部３０は、画像５４に対する解像度変換を実行する。
画像５４は、１９２０×１０８０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。
データ処理部３０は、この画像５４に対する解像度変換を実行して画像５６を生成する。
画像５６は、３８４０×２１６０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。

図６には、データ処理部３０の実行する画像変換処理例として３つの変換処理例を示している。
（Ａ）ＢＤ−Ｊアプリケーションによって描画されたグラフィックス・ソース５１に対してステップＳ２１の色空間変換のみを実行して出力画像５２を生成する変換処理例
（Ｂ）ＢＤ−Ｊアプリケーションによって描画されたグラフィックス・ソース５１に対してステップＳ２１の色空間変換と、ステップＳ２２の解像度変換を実行して出力画像５５を生成する変換処理例
（Ｃ）ＢＤ−Ｊアプリケーションによって描画されたグラフィックス・ソース５１に対してステップＳ２１の色空間変換と、ステップＳ２３の解像度変換を実行して出力画像５６を生成する変換処理例

データ処理部３０は、例えば表示部５０の出力可能な画像態様に応じて、これらのいずれかの変換処理を実行する。

次に示す図７は、ダイナミックレンジ変換処理（ＳＤＲ画像からＨＤＲ画像への変換）を実施する場合の画像変換例である。

グラフィックス・ソース５１は、ＢＤ−Ｊアプリケーションによって記憶部４０に描画される画像である。
図７に示す例において、グラフィックス・ソース５１は、図６を参照して説明したと同様、
１９２０×１０８０画素の画像であり、各画素単位でＲＧＢ各８ビット表現のなされたＳＤＲ画像である。

データ処理部３０は、ステップＳ３１において色空間変換を実行して、図７に示す画像７２を生成する。
画像７２は、１９２０×１０８０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。

データ処理部３０は、このように、ステップＳ３１において、色空間変換を実行して、図７に示す画像７２を生成する。

図７に示すステップＳ３２の処理は、上記の画像７２に対するダイナミックレンジ変換処理である。データ処理部３０は、画像７２に対するダイナミックレンジ変換処理を実行する。
画像７２は、１９２０×１０８０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＳＤＲ画像である。
データ処理部３０は、この画像７２に対するダイナミックレンジ変換処理を実行して画像７３を生成する。
画像７３は、１９２０×１０８０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＨＤＲ画像である。

また、図７に示すステップＳ３３の処理は、上記の画像７３に対する解像度変換処理である。データ処理部３０は、画像７３に対する解像度変換を実行する。
画像７３は、１９２０×１０８０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＨＤＲ画像である。
データ処理部３０は、この画像７３に対する解像度変換を実行して画像７４を生成する。
画像７４は、３８４０×２１６０画素の画像であり、色空間ＢＴ．２０２０対応の色情報を持ち、各画素単位で１０ビット表現のなされたＨＤＲ画像である。

図７には、データ処理部３０の実行する画像変換処理例として以下の１つの変換処理例を示している。
（Ｄ）ＢＤ−Ｊアプリケーションによって描画されたグラフィックス・ソース７１に対してステップＳ３１の色空間変換と、ステップＳ３２のダイナミックレンジ変換処理と、ステップＳ３３の解像度変換を実行して出力画像７４を生成する変換処理例
データ処理部３０は、例えば表示部５０の出力可能な画像態様に応じて、上記の変換処理を実行する。

このように、データ処理部３０は、ＢＤ−Ｊアプリケーションの実行によって、記憶部に描画された画像の変換処理を実行して、表示部５０に出力する画像を生成する。

［３．画像変換を伴う画像出力処理における問題点について］
次に、図４、図５を参照して説明した構成を有する情報処理装置における画像出力処理、すなわち画像変換処理を伴う画像出力処理における問題点について説明する。
上述した説明から理解されるように、４Ｋ画像や広ダイナミックレンジ画像、あるいはＢＴ．２０２０色空間を持つような、高画質画像、いわゆるＵＨＤ画像の出力を行う場合、図４に示す記憶部（グラフィックスプレーン）４０は、解像度変換や、ダイナミックレンジ変換、色空間変換等の各種の画像変換処理をサポートする記憶領域として利用される。

データ処理部３０は、図５に示すＢＤ−Ｊアプリケーション３１の実行によって記憶部（グラフィックスプレーン）４０に画像を描画する。
記憶部（グラフィックスプレーン）４０は、ＢＤ−Ｊアプリケーション３１の実行による描画画像（ＢＤ−Ｊグラフィックス）に対する様々な画像変換を行うために利用される記憶領域でもある。
すなわち、
画像の解像度を拡大する機能を有する記憶領域であり、
また、画像のダイナミックレンジ変換をサポートする記憶領域であり、
また、複数の色空間を変換する機能を有する。色空間の変換は、例えば、ＢＴ．７０９準拠データをＢＴ．２０２０準拠データに変換する処理である。

このような記憶部（グラフィックスプレーン）４０への描画処理に際して、ＢＤ−Ｊアプリケーション３１は、以下の２つのいずれかの手法を適用した処理を行なう、
（描画手法１）ダイレクト・ドローイング（Ｄｉｒｅｃｔ ｄｒａｗｉｎｇ）
ダイレクト・ドローイング（Ｄｉｒｅｃｔ ｄｒａｗｉｎｇ）を適用した描画手法では、ＢＤ−Ｊアプリケーション３１自身が描画コマンドを発行して描画処理を実行する。Ｊａｖａ（登録商標）では、
「ｄｒａｗＬｉｎｅ（）メソッド」
のようなメソッドが提供されており、アプリケーションによる描画（ドローイング）が可能になっている。

（描画手法２）リペイント（Ｒｅｐａｉｎｔ）
リペイント（Ｒｅｐａｉｎｔ）を適用した描画手法では、システムが提供するウィジェットを使用した描画処理を実行する。Ｊａｖａ（登録商標）ではＡＷＴ（Ａｂｓｔｒａｃｔ Ｗｉｎｄｏｗｉｎｇ ｔｏｏｌｋｉｔ）コンポーネントと呼ばれる複数のアプリケーションで共通のウィジェットが提供されている。このウィジェットを使用した描画処理を実行する手法である。

ＢＤ−Ｊアプリケーション３１は、上記の描画処理のいずれかを利用して描画処理を実行する。
なお、例えばＳＤＲ画像のみを再生可能な従来型の機器（レガシー機器）においても、ＳＤＲ画像の再生処理を可能とするため、ＢＤ−Ｊアプリケーションは、ＳＤＲのグラフィックス・ソースだけを用いた描画を行い、ＨＤＲ画像の再生可能な再生機器のみがその描画画像をＨＤＲ画像に変換するといった態様とすることが好ましい。
このように、再生機器によって、画像変換が実施される場合に発生する問題点について説明する。

［３−１．スクリーンティアリングについて］
以下においては、問題点として、「スクリーンティアリング」について説明する。
そもそも、ＢＤ−Ｊグラフィックスでは、グラフィックスのコマンドをＣＰＵなどプロセッサで実行して描画する処理と、完成したグラフィックスプレーンを読み出して表示するモニタとが、非同期に動作しているためにスクリーンティアリングが発生するという問題がある。

スクリーンティアリングとは、表示部に複数の画像フレームが重なって表示される現象であり、例えば表示画像を生成する処理がフレーム表示速度に追いつかない場合等に発生する。
例えば図８に示すように、フレーム（ｆｎ）の表示タイミングにおいて、フレーム（ｆｎ）の一部の表示画像生成が間に合わず、画面の一部に前の表示フレーム（ｆｎ−１）が表示されてしまうといった現象である。

このようなスクリーンティアリングについては、１）パーソナルコンピューター等でも同様の問題が発生しており、ＢＤ−Ｊアプリケーションに限った問題ではなく、また、２）何らかのデータ変換処理をサポートしているグラフィックスプレーンに特有の問題でもない。

しかしながら、スクリーンティアリング自体は動作不良のように見えるため回避すべきである。
このスクリーンティアリングを回避するための手段として、描画画像を、事前に複数作成して複数のバッファに格納するダブルバッファリングやトリプルバッファリング手法が用いられる場合がある。
一般的なスクリーンティアリングは、このダブルバッファリングやトリプルバッファリングを導入すればスクリーンティアリングの発生を回避できる。

しかし、ＢＤ−Ｊアプリケーションが描画画像（ＢＤ−Ｊグラフィックス）を生成する場合、例えばＢＤ−Ｊアプリケーションは、１つのフレーム画像を描画する場合、複数の描画命令を順次実行して描画処理を行なう。
この各フレーム画像の描画処理において不可分な描画命令の区切り（フレーム間の区切り）を、画像表示を行う表示制御部等は、知ることができない。
つまり、ＢＤ−Ｊアプリケーションによるグラフィックスプレーンへの描画が「完了した」か否かを表示制御部等のグラフィックスシステム側が知る術がなく、その点が課題となる。

［３−２．画像変換処理の負荷について］
上記のスクリーンティアリングの問題点に加えて、記憶部（グラフィックスプレーン）４０に格納した画像の変換処理を実行する場合、この変換処理の負荷が過大になり、各フレームの表示処理に間に合わなくなる場合があるという問題がある。

例えば、記憶部（グラフィックスプレーン）４０に格納した画像の色空間を変換する処理を行なう場合について説明する。
例えば、表示部（モニタ）が６０Ｈｚのリフレッシュレートを有する場合、１／６０秒ごとにグラフィックスプレーンの色空間を変換して表示出力するプロセスは、ハードウェア負荷が高く合理的ではない。

１／６０秒ごとに記憶部（グラフィックスプレーン）４０の格納画像の全ピクセルを書き換えなければならないことは非常にまれであり、グラフィックスの更新された領域のみを変換対象とすることで負荷を軽減できる。しかし、このような領域限定処理を行なうと、今度は、ピクセル単位で、色空間情報やダイナミックレンジ情報などを保持しなければならなくなるという問題が発生する。

最良の方法は、図５に示すＢＤ−Ｊアプリケーション３１による記憶部（グラフィックスプレーン）４０に対する描画処理が「完了した」か否かを、図５に示す表示画像生成部３２が知ることができる構成とすることである。表示画像生成部３２が、ＢＤ−Ｊアプリケーション３１による描画完了タイミングを知ることができれば、表示画像生成部３２は、その時点から変換を実行して表示出力する処理を行なうことができる。

なお、ビットマップ画像の描画については、アプリケーションが１秒間に描画可能なピクセル数を規定することで上記の課題を回避可能である。しかし、ＢＤ−Ｊアプリケーション３１は、複数のコマンドを適用した描画を実行し、このコマンド適用型の描画を制御するためには、ビットマップ描画と同様の描画量の定量的な制御は困難である。

［４．本開示の情報処理装置の実行する処理の概要について］
次に、上述した問題点を解決する本開示の情報処理装置の実行する処理の概要について説明する。
先に説明したように、ＢＤ−Ｊアプリケーション３１は、記憶部（グラフィックスプレーン）４０への描画処理に際して、以下の２つのいずれかの手法を適用した処理を行なう、
（描画手法１）ダイレクト・ドローイング（Ｄｉｒｅｃｔ ｄｒａｗｉｎｇ）
ＢＤ−Ｊアプリケーション３１自身が描画コマンドを発行して描画処理を実行する。
（描画手法２）リペイント（Ｒｅｐａｉｎｔ）
システムが提供するウィジェット（ＡＷＴ（Ａｂｓｔｒａｃｔ Ｗｉｎｄｏｗｉｎｇ ｔｏｏｌｋｉｔ）コンポーネントと呼ばれる複数のアプリケーションで共通のウィジェット）を使用した描画処理を実行する。

ＢＤ−Ｊアプリケーション３１は、これら２つのいずれかの手法を適用した処理を行なう。
上記の（描画手法２）リペイント（Ｒｅｐａｉｎｔ）が利用される場合、システムが提供するウィジェット（ＡＷＴ（Ａｂｓｔｒａｃｔ Ｗｉｎｄｏｗｉｎｇ ｔｏｏｌｋｉｔ）コンポーネントと呼ばれる複数のアプリケーションで共通のウィジェット）を使用した描画処理が実行される。
ＡＷＴペイントモデルにより、ルートコンテナのｒｅｐａｉｎｔ（）メソッドが各コンポーネントのｕｐｄａｔｅ（）メソッドを呼び出し、呼び出さたメソッドによる描画処理が行われる。
従って、図５に示す表示画像生成部３２側は、ｕｐｄａｔｅ（）メソッドの実行が完了するまで表示出力を待機することで、表示画像の出力タイミングを制御することができる。

しかし、ＢＤ−Ｊアプリケーション３１が、上記の（描画手法１）ダイレクト・ドローイング（Ｄｉｒｅｃｔ ｄｒａｗｉｎｇ）を実行して描画処理を行なう場合は、ＢＤ−Ｊアプリケーション３１自身が描画コマンドを発行して描画処理を実行する。
この場合、図５に示す表示画像生成部３２側は、ＢＤ−Ｊアプリケーション３１による描画コマンドの発行が完了したかどうかを知る術がない。

ＢＤ−Ｊアプリケーション３１は、１つの画像フレームの描画処理において、複数の描画コマンドを順次、実行する。
すなわち、ＢＤ−Ｊアプリケーション３１が、描画コマンド＃１，＃２，・・・，＃Ｎを発行し、その描画コマンド＃１ないし＃Ｎに従って画像描画が行われた場合に、その後、ＢＤ−Ｊアプリケーション３１から、さらに、描画コマンドが発行されるかどうか、つまり、ＢＤ−Ｊアプリケーションによる描画コマンドの発行が完了したのかどうかを、表示画像生成部３２は、認識することができない。

図９は、各画像フレーム単位の描画コマンドの設定例と実行態様を示す図である。
横軸ａ〜ｂは、１つの画像フレーム対応の描画コマンドキュー格納領域に相当する。
縦軸に下から、順次時間経過に伴って表示される画像フレーム（フレーム番号２０〜２４）を示している。
画像フレーム番号２０の画像フレームが、全ての描画コマンドによる描画を完了し、デコード処理や変換処理を伴う表示処理に移行している段階にある。

画像フレーム２１〜２４には、各画像フレームの描画に必要となる実行予定の描画コマンドを示している。
描画コマンドは、各画像フレーム毎に必要となる数や、コマンド実行に必要となる時間が異なる。

画像フレーム２２は、フレーム単位のコマンドキユーを超過した描画コマンドを実行する必要がある。この超過部分は、次のフレーム（画像フレーム２３）用のキューに設定される。
このような設定がなされると、描画コマンドの実行完了が遅れてしまう、
一方、画像フレームの個々の表示期間は一定であるため、描画コマンドの実行期間が複数の画像フレームの描画処理期間にまたがると、描画途中の画像がそのままディスプレイに送り出されるということになる。

このような問題を解消するため、描画コマンドによる画像描画を行うＢＤ−Ｊアプリケーション３１に、描画コマンドの１つとして、ある１つの描画コマンドによる描画処理の終了を通知する描画完了通知ＡＰＩの呼び出しコマンドを設定する。
ＢＤ−Ｊアプリケーション３１は、例えば、１つの画像フレームの描画を行うための一連の描画コマンドによる描画処理が完了した時点など、ある描画コマンドによる描画処理の完了時点で、描画完了通知ＡＰＩの呼び出しコマンドを実行する。

表示画像生成部３２は、この描画完了通知ＡＰＩの呼び出しコマンドの実行を検出することで、１つの描画コマンドによる描画処理が完了したことを検出することができる。
表示画像生成部３２は、ＢＤ−Ｊアプリケーション３１による描画完了通知ＡＰＩの呼び出し処理が実行されたことを検出して、記憶部（グラフィックスプレーン）４０に対する描画コマンドによる描画完了タイミングを認識することができる。

ここで、描画完了通知ＡＰＩとしては、例えば、
「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」
を採用することができる。
表示画像生成部３２は、描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しが行われない限りは、記憶部（グラフィックスプレーン）４０に描画された画像の出力は行わない。

なお、１つの画像フレームの間に、描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しが、複数回行われると、画像フレームがコマ落ちする可能性がある。従って、描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しを連続で複数回行うことや、描画量が少ないコマンドの発行をはさんだ描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しの連続実行は禁止する設定とする。

描画コマンドと、描画完了通知ＡＰＩ「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しコマンドの実行シーケンスの例を以下に示す。
描画コマンド＃１
描画コマンド＃２
・・・
描画コマンド＃Ｎ
ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）
描画コマンド＃Ｎ＋１
描画コマンド＃Ｎ＋２
・・・
描画コマンド＃Ｎ＋Ｍ
ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）

上記コマンド設定例は、描画コマンド＃１から描画コマンド＃Ｎまでをアトミック、すなわち連続して実行する設定である。なお、この間、途中経過はエンドユーザに対して出力されない。
例えば、ＢＤ−Ｊアプリケーションが、描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出し処理を１つの画像フレームに対応する描画コマンド列の完了時に実行する構成とすれば、表示画像生成部は、画像フレーム単位の描画処理の完了を知ることが可能となり、その後、その画像フレームに対して画像変換を実行することができる。

上記のようなコマンド列を実行して、描画コマンドによる描画完了後の画像に対する画像変換を実行するためには、ＢＤ−Ｊアプリケーション３１による描画対象データを格納する記憶部（グラフィックスプレーン）４０をダブルバッファ、あるいはトリプルバッファ等の構成とすればよい。
以下に示す２つの実施例について、順次、説明する。
（実施例１）記憶部（グラフィックスプレーン）４０をダブルバッファとした構成
（実施例２）記憶部（グラフィックスプレーン）４０をトリプルバッファとした構成

［５．（実施例１）記憶部（グラフィックスプレーン）をダブルバッファとした構成を適用した実施例について］
まず、実施例１として、記憶部（グラフィックスプレーン）をダブルバッファとした構成を適用した実施例について説明する。

図１０は、本実施例１の情報処理装置１００の構成と処理について説明する図である。
なお、図１０には、画像処理に利用される構成部のみを示している。
情報処理装置１００は、データ処理部２００、記憶部（グラフィックスプレーン）２２０、表示部２５０を有する。
なお、表示部２５０は、情報処理装置１００の必須構成ではなく、図示しない出力部を介して接続される表示装置を利用する構成としてもよい。

データ処理部２００は、
ＢＤ−Ｊアプリケーション実行部２１０、
表示画像生成部２３０、
バッファ管理部２４０、
を有する。

ＢＤ−Ｊアプリケーション実行部２１０は、先に図５を参照して説明した構成におけるＢＤ−Ｊアプリケーション３１に相当する。
表示画像生成部２３０は、先に図５を参照して説明した構成における表示画像生成部３２に相当し、画像変換処理ＡＰＩ３３、プレゼンテーションエンジン３４、画像デコーダ３５、表示制御部３６の実行する処理を実行する。
バッファ管理部２４０は、記憶部（グラフィックスプレーン）２２０内のバックバッファ２２１、フロントバッファ２２２の切り替え処理等を実行する。

なお、表示画像生成部２３０は、
ａ．解像度変換処理
ｂ．ダイナミックレンジ変換処理
ｃ．色空間変換処理
上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する。すなわち、表示画像生成部２３０は、画像を出力する表示部２５０の表示機能に応じて画像変換態様を決定して、上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する。

記憶部（グラフィックスプレーン）２２０は、
バックバッファ２２１、
フロントバッファ２２２、
これら２つのバッファを有するダブルバッファ構成となっている。

図１０に示す処理ステップＳ１０１〜Ｓ１０６の順に処理を実行する。
図１１に示すフローチャートは、図１０に示す処理ステップＳ１０１〜Ｓ１０６の処理をフローとして示したものである。

図１０に示すデータ処理部は、プログラム実行機能を持つＣＰＵを有し、図示しないメモリに格納されたプログラムを読み出して、図１１に示すフローに従った処理を実行する。
以下、図１０、図１１に示すステップＳ１０１〜Ｓ１０６の各処理の詳細について、順次、説明する。

（ステップＳ１０１）
情報処理装置１００のデータ処理部２００のＢＤ−Ｊアプリケーション実行部２１０は、ステップＳ１０１において、ＢＤ−Ｊアプリケーションに規定された描画コマンドを実行する。

（ステップＳ１０２）
次に、ＢＤ−Ｊアプリケーション実行部２１０は、ステップＳ１０２において、ＢＤ−Ｊアプリケーションに規定された描画コマンドの実行結果としての画像を記憶部２２０のバックバッファ２２１に格納する。

（ステップＳ１０３）
次に、情報処理装置１００のデータ処理部の表示画像生成部２３０は、ステップＳ１０１〜Ｓ１０２において実行される描画コマンドの実行および実行結果のバックバッファ格納処理に並行して、フロントバッファ２２２に格納された画像の変換処理（解像度、ダイナミックレンジ、色変換の少なくともいずれか）を実行して、変換画像を表示部２５０に出力する。

（ステップＳ１０４）
次に、表示画像生成部２３０は、ステップＳ１０４において、ＢＤ−Ｊアプリケーション実行部２１０からの描画完了ＡＰＩの呼び出しがあったか否かを判定する。
ＢＤ−Ｊアプリケーション実行部２１０から描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しがあったか否かを判定する。

ＡＰＩ呼び出しがない場合は、ステップＳ１０１〜Ｓ１０３の処理を繰り返す。
ＡＰＩ呼び出しがあった場合は、ステップＳ１０５以下の処理を実行する。

（ステップＳ１０５）
ＢＤ−Ｊアプリケーション実行部２１０からの描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しのあったことが確認された場合、情報処理装置１００のデータ処理部２００のバッファ管理部２４０は、ステップＳ１０４において、記憶部２２０のバックバッファ２２１と、フロントバッファ２２２の切り替え処理を行なう。
すなわち、バックバッファ２２１をフロントバッファに設定し、フロントバッファ２２２をバックバッファに設定する。

（ステップＳ１０６）
次に、データ処理部２００のバッファ管理部２４０は、フロントバッファ（切り替え前のバックバッファ）の格納画像を、バックバッファ（切り替え前のフロントバッファ）にコピーする。
なお、このコピー処理期間内は、バックバッファに対する描画処理は停止する。

以降、ステップＳ１０１〜Ｓ１０６の処理を繰り返す。

この図１０、および図１１を参照して説明したダブルバッファ構成を用いた場合の描画処理対象バッファの切り替えについて説明する。
例えば、ＢＤ−Ｊアプリケーションによる描画コマンドが以下のようなシーケンスで設定されているとする。
描画コマンド＃１
描画コマンド＃２
・・・
描画コマンド＃Ｎ
描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））
描画コマンド＃Ｎ＋１
描画コマンド＃Ｎ＋２
・・・
描画コマンド＃Ｎ＋Ｍ
描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））

描画コマンド＃１〜＃Ｎは、バックバッファ２２１に対して実行される。
その後、
表示画像生成部２３０が、描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））の発行を検出すると、
バッファ管理部２４０が、バックバッファ２２１とフロントバッファ２２２の切り替えを実行して、さらに、フロントバッファ（切り替え前のバックバッファ２２１）に格納されていた描画データをバックバッファ（切り替え前のフロントバッファ２２２）にコピーする。
この時点で、バッファ切り替え後のバックバッファ（切り替え前のフロントバッファ２２２）には、描画コマンド＃１〜＃Ｎによる描画結果が格納された状態になる。

その後、ＢＤ−Ｊアプリケーションによって、描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍが実行され、バッファ切り替え後のバックバッファ（切り替え前のフロントバッファ２２２）に対して、描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍの実行結果が格納される。

このように、描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））の発行前後において、ＡＰＩ発行前の描画結果（描画コマンド＃１〜＃Ｎの実行結果）を格納した一方のバッファの描画データが他方のバッファにコピーされ、その後、そのコピーされた描画データに対して、ＢＤ−Ｊアプリケーションによる、その後の描画コマンド（描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍ）が実行され、途切れのない継続的なコマンド実行が可能となる。

さらに、その後の、描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））の発行によって、描画コマンド（描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍ）の実行結果を格納したバッファがフロントバッファに切り替えられ、フロントバッファの格納画像に対して画像変換処理、画像出力処理が実行されることになる。

このように、本実施例により、ＢＤ−Ｊアプリケーションによる描画コマンドを各画像フレーム単位で全て実行することが可能となる。
また、表示画像生成部２３０による画像変換、すなわち、
ａ．解像度変換処理
ｂ．ダイナミックレンジ変換処理
ｃ．色空間変換処理
これらの処理をＢＤ−Ｊアプリケーションによる描画処理の完了した画像フレームに対して実行することが可能となり、その後の画像出力処理も、画像フレーム単位で完成された変換画像として出力することが可能となる。

［６．（実施例２）記憶部（グラフィックスプレーン）４０をトリプルバッファとした構成を適用した実施例について］
次に、実施例２として、記憶部（グラフィックスプレーン）をトリプルバッファとした構成を適用した実施例について説明する。

図１２は、本実施例２の情報処理装置３００の構成例を示す図である。
なお、図１２には、画像処理に利用される構成部のみを示している。
情報処理装置３００は、データ処理部４００、記憶部（グラフィックスプレーン）４２０、表示部４５０を有する。
なお、表示部４５０は、情報処理装置３００の必須構成ではなく、図示しない出力部を介して接続される表示装置を利用する構成としてもよい。

データ処理部４００は、
ＢＤ−Ｊアプリケーション実行部４１０、
表示画像生成部４３０、
バッファ管理部４４０、
を有する。

ＢＤ−Ｊアプリケーション実行部４１０は、先に図５を参照して説明した構成におけるＢＤ−Ｊアプリケーション３１に相当する。
表示画像生成部４３０は、先に図５を参照して説明した構成における表示画像生成部３２に相当し、画像変換処理ＡＰＩ３３、プレゼンテーションエンジン３４、画像デコーダ３５、表示制御部３６の実行する処理を実行する。
バッファ管理部４４０は、記憶部（グラフィックスプレーン）４２０内のフロントバッファ１，４２２−１、フロントバッファ２，４２２−２の切り替え処理等を実行する。

なお、表示画像生成部４３０は、
ａ．解像度変換処理
ｂ．ダイナミックレンジ変換処理
ｃ．色空間変換処理
上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する。すなわち、表示画像生成部４３０は、画像を出力する表示部２５０の表示機能に応じて画像変換態様を決定して、上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する。

記憶部（グラフィックスプレーン）４２０は、
バックバッファ４２１、
フロントバッファ１，４２２−１、
フロントバッファ２，４２２−２、
これら３つのバッファを有するトリプルバッファ構成となっている。

図１２に示す処理ステップＳ３０１〜Ｓ３０６の順に処理を実行する。
図１３に示すフローチャートは、図１２に示す処理ステップＳ３０１〜Ｓ３０６の処理をフローとして示したものである。

図１２に示すデータ処理部は、プログラム実行機能を持つＣＰＵを有し、図示しないメモリに格納されたプログラムを読み出して、図１３に示すフローに従った処理を実行する。
以下、図１２、図１３に示すステップＳ３０１〜Ｓ３０６の各処理の詳細について、順次、説明する。

（ステップＳ３０１）
情報処理装置３００のデータ処理部４００のＢＤ−Ｊアプリケーション実行部４１０は、ステップＳ３０１において、ＢＤ−Ｊアプリケーションに規定された描画コマンドを実行する。

（ステップＳ３０２）
次に、ＢＤ−Ｊアプリケーション実行部４１０は、ステップＳ３０２において、ＢＤ−Ｊアプリケーションに規定された描画コマンドの実行結果としての画像を記憶部４２０のバックバッファ４２１に格納する。

（ステップＳ３０３）
次に、情報処理装置３００のデータ処理部のバッファ管理部４４０は、ステップＳ３０１〜Ｓ３０２において実行される描画コマンドの実行および実行結果のバックバッファ格納処理に並行して、バックバッファ４２１に格納された画像データをフロントバッファ１，４２２−１にコピーする処理を実行する。

（ステップＳ３０４）
次に、情報処理装置３００のデータ処理部の表示画像生成部４３０は、ステップＳ３０１〜Ｓ３０３の各処理に並行して、ステップＳ３０４において、フロントバッファ２，４２２−２に格納された画像の変換処理（解像度、ダイナミックレンジ、色変換の少なくともいずれか）を実行して、変換画像を表示部４５０に出力する。

（ステップＳ３０５）
次に、表示画像生成部４３０は、ステップＳ３０５において、ＢＤ−Ｊアプリケーション実行部４１０からの描画完了ＡＰＩの呼び出しがあったか否かを判定する。
ＢＤ−Ｊアプリケーション実行部４１０から描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しがあったか否かを判定する。

ＡＰＩ呼び出しがない場合は、ステップＳ３０１〜Ｓ３０４の処理を繰り返す。
ＡＰＩ呼び出しがあった場合は、ステップＳ３０６の処理を実行する。

（ステップＳ３０６）
ＢＤ−Ｊアプリケーション実行部４１０からの描画完了通知ＡＰＩ、すなわち「ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（）メソッド」の呼び出しのあったことが確認された場合、情報処理装置３００のデータ処理部４００のバッファ管理部４４０は、ステップＳ３０６において、記憶部４２０のフロントバッファ１，４２２−１と、フロントバッファ２，４２２−２の切り替え処理を行なう。
すなわち、フロントバッファ１，４２２−１をフロントバッファ２に設定し、フロントバッファ２，４２２−２をフロントバッファ１に設定する。
以降、ステップＳ３０１〜Ｓ３０６の処理を繰り返す。

この図１２、および図１３を参照して説明したトリプルバッファ構成を用いた場合の描画処理対象バッファの切り替えについて説明する。
例えば、ＢＤ−Ｊアプリケーションによる描画コマンドが以下のようなシーケンスで設定されているとする。
描画コマンド＃１
描画コマンド＃２
・・・
描画コマンド＃Ｎ
描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））
描画コマンド＃Ｎ＋１
描画コマンド＃Ｎ＋２
・・・
描画コマンド＃Ｎ＋Ｍ
描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））

描画コマンド＃１〜＃Ｎは、バックバッファ４２１に対して実行され、同時に、コピーデータがフロントバッファ１，４２２−１にも格納される。
その後、
表示画像生成部４３０が、描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））の発行を検出すると、
バッファ管理部４４０が、フロントバッファ１，４２２−１と、フロントバッファ２，４２２−２の切り替えを実行する。
この時点で、バッファ切り替え後のフロントバッファ２（切り替え前のフロントバッファ１）には、描画コマンド＃１〜＃Ｎによる描画結果が格納された状態になる。

その後、ＢＤ−Ｊアプリケーションによって、描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍが実行され、バックバッファ、およびバッファ切り替え後のフロントバッファ２（切り替え前のフロントバッファ１）に対して、描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍの実行結果が格納される。

このように、描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））の発行前後において、ＡＰＩ発行前の描画結果（描画コマンド＃１〜＃Ｎの実行結果）を格納した一方のフロントバッファに対して、ＢＤ−Ｊアプリケーションによる、その後の描画コマンド（描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍ）の実行結果を格納することが可能となり、途切れのない継続的なコマンド実行結果の格納処理が可能となる。

さらに、その後の、描画完了通知ＡＰＩ（ｊａｖａ．ａｗｔ．Ｔｏｏｌｋｉｔ＃ｓｙｎｃ（））の発行によって、描画コマンド（描画コマンド＃Ｎ＋１〜＃Ｎ＋Ｍ）の実行結果を格納したバッファが出力対象となるフロントバッファに切り替えられ、出力対象フロントバッファの格納画像に対して画像変換処理、画像出力処理が実行されることになる。

このように、本実施例により、ＢＤ−Ｊアプリケーションによる描画コマンドを各画像フレーム単位で全て実行することが可能となる。
また、表示画像生成部４３０による画像変換、すなわち、
ａ．解像度変換処理
ｂ．ダイナミックレンジ変換処理
ｃ．色空間変換処理
これらの処理をＢＤ−Ｊアプリケーションによる描画処理の完了した画像フレームに対して実行することが可能となり、その後の画像出力処理も、画像フレーム単位で完成された変換画像として出力することが可能となる。

［７．情報処理装置のハードウェア構成例について］
最後に、図１４を参照して、上述した処理を実行する情報処理装置のハードウェア構成例について説明する。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）５０２、または記憶部５０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述したフローチャートに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５０３には、ＣＰＵ５０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ５０１、ＲＯＭ５０２、およびＲＡＭ５０３は、バス５０４により相互に接続されている。

ＣＰＵ５０１はバス５０４を介して入出力インタフェース５０５に接続され、入出力インタフェース５０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部５０６、ディスプレイ、スピーカなどよりなる出力部５０７が接続されている。ＣＰＵ５０１は、入力部５０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部５０７に出力する。

入出力インタフェース５０５に接続されている記憶部５０８は、例えばハードディスク等からなり、ＣＰＵ５０１が実行するプログラムや各種のデータを記憶する。通信部５０９は、インターネットやローカルエリアネットワークなどのネットワークを介して外部の装置と通信する。

入出力インタフェース５０５に接続されているドライブ５１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア５１１を駆動し、記録されているコンテンツや鍵情報等の各種データを取得する。例えば、取得されたコンテンツや鍵データを用いて、ＣＰＵによって実行する再生プログラムに従ってコンテンツの復号、再生処理などが行われる。

［８．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１） 描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
前記アプリケーション実行部は、
描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行し、
前記バッファ管理部は、
前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行し、
前記表示画像生成部は、
前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行する情報処理装置。

（２） 前記記憶部は、
フロントバッファとバックバッファから構成されるダブルバッファ構成であり、
前記アプリケーション実行部は、
描画コマンドによる描画処理結果を前記バックバッファに格納し、
前記バッファ管理部は、
前記描画完了通知ＡＰＩの呼び出しに応じて、フロントバッファとバックバッファとの切り換え処理を実行する（１）に記載の情報処理装置。

（３） 前記表示画像生成部は、
前記フロントバッファに格納された画像に対する画像変換処理を実行する（２）に記載の情報処理装置。

（４） 前記記憶部は、
バックバッファと、第１フロントバッファと、第２フロントバッファから構成されるトリプルバッファ構成であり、
前記アプリケーション実行部は、
描画コマンドによる描画処理結果を前記バックバッファに格納し、
前記第１フロントバッファは、前記バックバッファのコピーデータを格納する構成であり、
前記バッファ管理部は、
前記描画完了通知ＡＰＩの呼び出しに応じて、第１フロントバッファと第２フロントバッファとの切り換え処理を実行する（１）に記載の情報処理装置。

（５） 前記表示画像生成部は、
前記第２フロントバッファに格納された画像に対する画像変換処理を実行する（４）に記載の情報処理装置。

（６） 前記表示画像生成部は、
ａ．解像度変換処理
ｂ．ダイナミックレンジ変換処理
ｃ．色空間変換処理
上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する（１）〜（５）いずれかに記載の情報処理装置。

（７） 前記表示画像生成部は、
画像を出力する表示部の表示機能に応じて画像変換態様を決定する（１）〜（６）いずれかに記載の情報処理装置。

（８） 情報処理装置において実行する情報処理方法であり、
前記情報処理装置は、
描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
前記アプリケーション実行部は、
描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行し、
前記バッファ管理部は、
前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行し、
前記表示画像生成部は、
前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行する情報処理方法。

（９） 情報処理装置において情報処理を実行させるプログラムであり、
前記情報処理装置は、
描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
前記プログラムは、
前記アプリケーション実行部に、
描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行させ、
前記バッファ管理部に、
前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行させ、
前記表示画像生成部に、
前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行させるプログラム。

また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本開示の一実施例の構成によれば、アプリケーションが実行する描画コマンドによる描画処理の完了を検知して、描画処理完了画像に対する変換処理や表示処理を行なう構成が実現される。
具体的には、描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、記憶部の描画画像に対する変換処理を実行する表示画像生成部と、記憶部の複数バッファの切り替えを実行するバッファ管理部を有する。アプリケーション実行部は、描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出しを実行し、バッファ管理部は、描画完了通知ＡＰＩの呼び出しに応じてバッファ切り替え処理を実行する。表示画像生成部は、アプリ実行部の描画中のバッファと異なるバッファの格納画像に対する画像変換を実行する。
本構成により、アプリケーションが実行する描画コマンドによる描画処理の完了を検知して、描画処理完了画像に対する変換処理や表示処理を行なう構成が実現される。

１０ 記録メディア
２０ 情報処理装置
２１ ＰＣ
２２ 再生装置
２３ ＴＶ
３０ データ処理部
３１ ＢＤ−Ｊアプリケーション
３２ 表示画像生成部
３３ 画像変換処理ＡＰＩ
３４ プレゼンテーションエンジン
３５ 画像デコーダ
３６ 表示制御部
１００ 情報処理装置
２００ データ処理部
２１０ ＢＤ−Ｊアプリケーション実行部
２２０ 記憶部（グラフィックスプレーン）
２２１ バックバッファ
２２２ フロントバッファ
２３０ 表示画像生成部
２４０ バッファ管理部
２５０ 表示部
３００ 情報処理装置
４００ データ処理部
４１０ ＢＤ−Ｊアプリケーション実行部
４２０ 記憶部（グラフィックスプレーン）
４２１ バックバッファ
４２２ フロントバッファ
４３０ 表示画像生成部
４４０ バッファ管理部
４５０ 表示部
５０１ ＣＰＵ
５０２ ＲＯＭ
５０３ ＲＡＭ
５０４ バス
５０５ 入出力インタフェース
５０６ 入力部
５０７ 出力部
５０８ 記憶部
５０９ 通信部
５１０ ドライブ
５１１ リムーバブルメディア

Claims (9)

1. 描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
   前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
   前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
   前記アプリケーション実行部は、
   描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行し、
   前記バッファ管理部は、
   前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行し、
   前記表示画像生成部は、
   前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行する構成であり、
   前記アプリケーション実行部による第１バッファに対する描画画像格納処理と、前記表示画像生成部による第２バッファ格納画像に対する画像変換処理を並列に実行する情報処理装置。
2. 前記記憶部は、
   フロントバッファとバックバッファから構成されるダブルバッファ構成であり、
   前記アプリケーション実行部は、
   描画コマンドによる描画処理結果を前記バックバッファに格納し、
   前記バッファ管理部は、
   前記描画完了通知ＡＰＩの呼び出しに応じて、フロントバッファとバックバッファとの切り換え処理を実行する請求項１に記載の情報処理装置。
3. 前記表示画像生成部は、
   前記フロントバッファに格納された画像に対する画像変換処理を実行する請求項２に記載の情報処理装置。
4. 前記記憶部は、
   バックバッファと、第１フロントバッファと、第２フロントバッファから構成されるトリプルバッファ構成であり、
   前記アプリケーション実行部は、
   描画コマンドによる描画処理結果を前記バックバッファに格納し、
   前記第１フロントバッファは、前記バックバッファのコピーデータを格納する構成であり、
   前記バッファ管理部は、
   前記描画完了通知ＡＰＩの呼び出しに応じて、第１フロントバッファと第２フロントバッファとの切り換え処理を実行する請求項１に記載の情報処理装置。
5. 前記表示画像生成部は、
   前記第２フロントバッファに格納された画像に対する画像変換処理を実行する請求項４に記載の情報処理装置。
6. 前記表示画像生成部は、
   ａ．解像度変換処理
   ｂ．ダイナミックレンジ変換処理
   ｃ．色空間変換処理
   上記ａ〜ｃの少なくともいずれかの画像変換処理を実行する請求項１に記載の情報処理装置。
7. 前記表示画像生成部は、
   画像を出力する表示部の表示機能に応じて画像変換態様を決定する請求項１に記載の情報処理装置。
8. 情報処理装置において実行する情報処理方法であり、
   前記情報処理装置は、
   描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
   前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
   前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
   前記アプリケーション実行部は、
   描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行し、
   前記バッファ管理部は、
   前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行し、
   前記表示画像生成部は、
   前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行し、
   前記アプリケーション実行部による第１バッファに対する描画画像格納処理と、前記表示画像生成部による第２バッファ格納画像に対する画像変換処理を並列に実行する情報処理方法。
9. 情報処理装置において情報処理を実行させるプログラムであり、
   前記情報処理装置は、
   描画処理を実行し、描画結果を記憶部に格納するアプリケーション実行部と、
   前記記憶部の描画画像に対する画像変換処理を実行して表示部に出力する表示画像を生成する表示画像生成部と、
   前記記憶部に設定された複数のバッファの切り替え処理を実行するバッファ管理部を有し、
   前記プログラムは、
   前記アプリケーション実行部に、
   描画コマンドによる描画処理の完了後に、描画完了通知ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し処理を実行させ、
   前記バッファ管理部に、
   前記描画完了通知ＡＰＩの呼び出しに応じて、前記アプリケーション実行部による描画画像の格納バッファを切り替えるバッファ切り替え処理を実行させ、
   前記表示画像生成部に、
   前記アプリケーション実行部による描画処理実行中のバッファと異なるバッファに格納された画像に対する画像変換処理を実行させ、
   前記アプリケーション実行部による第１バッファに対する描画画像格納処理と、前記表示画像生成部による第２バッファ格納画像に対する画像変換処理を並列に実行させるプログラム。

Images