JP5313225B2 - ディスプレイ・データ管理技法 - Google Patents

Description

本発明は、ディスプレイ・データの管理に関する。

コンピュータ・アプリケーションは一般に、ユーザーに情報を与えるためにグラフィック出力を用いる。そのような情報は、テキスト、図、画像（動画または静止画）などの形であってもよい。そのような情報は典型的には、通信インターフェースを通じて処理プラットフォーム（たとえばパーソナル・コンピュータ）に接続された表示装置上で出力される。

通常、グラフィックの生成は、アプリケーションから受領される指令〔ディレクティブ〕に基づいてフレーム・データ（または画像データ）の形で表示内容をレンダリングするグラフィクス・パイプラインを必要とする。生成されると、このフレーム・データが典型的には処理プラットフォーム内のフレーム・バッファ・メモリに記憶される。

この記憶が行われたのち、フレーム・データは通常のディスプレイ・インターフェースを通じて表示装置に送られてもよい。そのような通常のインターフェースの例は、ビデオ・グラフィクス・アレイ（VGA: video graphics array）、デジタル・ビジュアル・インターフェース（DVI: digital visual interface）、高精細度マルチメディア・インターフェース（HDMI: high-definition multimedia interface）、ディスプレイポート（DP: DisplayPort）およびアナログ・テレビジョン・フォーマットを含む。これは、処理プラットフォームまたは表示装置内にある論理によって管理されうるタイミングに基づく。

システムの複雑さが増すにつれ、ディスプレイ・データの効率的かつ柔軟な管理が所望される。

本発明は、請求項記載の構成によって従来技術の欠点を軽減ないし解消する。

図面において、同様の参照符号は一般に同一、機能的に類似および／または構造的に類似の要素を示す。要素が最初に現れる図面は、参照符号中の左端の数字によって示される。本発明について、付属の図面を参照しつつ述べる。

例示的な動作環境を示す図である。 例示的なグラフィクス・パイプライン実装を示す図である。 流れ図である。 グラフィクス・パイプラインとフレーム・バッファとの間のマッピングを示す図である。 流れ図である。 流れ図である。 フレーム・マッピング・メモリ実装を示す図である。 流れ図である。

諸実施形態は、ディスプレイ・データの生成および出力のための技法を提供する。たとえば、諸実施形態は、表示装置内でのフレーム・データ記憶に関わる特徴を提供する。また、諸実施形態は、異なるフレーム・バッファへの異なるユーザー・コンテキストの孤立化に関わる特徴を提供する。さらに、諸実施形態は、電力状態の間の遷移の際にフレーム・データを保存するための効率的な技法を提供する。さらに、諸実施形態は、複数の表示内容を物理的なディスプレイに柔軟かつ動的に割り当てる技法を提供する。

たとえば、装置は、グラフィクス入力データからフレーム・データを生成するためのグラフィクス・レンダリング・エンジンと、結合されている表示装置がフレーム・バッファを含むかどうかを判定するフレーム・バッファ制御モジュールとを含んでいてもよい。結合されている表示装置がフレーム・バッファを含むとき、フレーム・バッファ制御モジュールは、ローカルなフレーム・バッファ内のフレーム・データの記憶をバイパスし、フレーム・データを結合されている表示装置に送る。

フレーム・データは現在のフレームと前のフレームとの間の差分データを含んでいてもよい。また、フレーム・バッファ制御モジュールは、結合されている表示装置との通信インターフェース（たとえば、これに限られないがUSBインターフェースおよび／またはLANインターフェース）の一つまたは複数の特性に基づいて圧縮伝送フォーマットと非圧縮伝送フォーマットとの間の選択をしてもよい。これらの一つまたは複数の特性は、通信インターフェースの容量を含んでいてもよい。さらに、フレーム・バッファ制御モジュールは、表示装置に送られるべきフレーム・データを暗号化してもよい。通信インターフェース・モジュールが、結合されている表示装置に通信インターフェースを通じてフレーム・データを伝送する。

方法は、グラフィクス入力データからフレーム・データを生成し；表示装置がフレーム・バッファを含むことを判別し；そのフレーム・データを、フレーム・バッファ内に記憶するために、表示装置に送ることを含む。この送ることは、ローカル・フレーム・バッファ内でのフレーム・データの記憶をバイパスすることを含んでいてもよい。フレーム・データは、現在フレームと前のフレームとの間の差分データを含んでいてもよい。フレーム・データを送ることは、フレーム・データを通信インターフェースを通じて表示装置に送信することを含んでいてもよい。

また、本方法は、通信インターフェースを通じて伝送されるフレーム・データを暗号化してもよい。また、本方法は、通信インターフェースの一つまたは複数の特性に基づいて圧縮伝送フォーマットと非圧縮伝送フォーマットとの間の選択をしてもよい。通信インターフェースの該一つまたは複数の特性は、通信インターフェースの容量を含んでいてもよい。

物品が命令を記憶されている機械アクセス可能媒体を有していてもよい。前記命令は、機械によって実行されたときに、前記機械に：グラフィクス入力データからフレーム・データを生成し；表示装置がフレーム・バッファを含むことを判別し；そのフレーム・データを、フレーム・バッファ内に記憶するために、表示装置に送ることを行わせる。この送ることは、ローカル・フレーム・バッファ内でのフレーム・データの記憶をバイパスすることを含んでいてもよい。

システムが処理プラットフォームおよび表示装置を含んでいてもよい。処理プラットフォームは、グラフィクス入力データからフレーム・データを生成するためのグラフィクス・レンダリング・エンジンと、表示装置がフレーム・バッファを含むかどうかを判定するフレーム・バッファ制御モジュールとを含む。表示装置がフレーム・バッファを含むとき、フレーム・バッファ制御モジュールは、ローカルなフレーム・バッファ内のフレーム・データの記憶をバイパスし、フレーム・データを表示装置に送る。

さらなるシステムは、処理プラットフォームおよび表示装置を含んでいてもよい。処理プラットフォームは、一つまたは複数のアプリケーションの第一の集合のために第一のフレーム・データを生成するための第一のグラフィクス・パイプラインと、一つまたは複数のアプリケーションの第二の集合のために第二のフレーム・データを生成するための第二のグラフィクス・パイプラインとを有する。表示装置は第一のフレーム・バッファおよび第二のフレーム・バッファを含む。第一のグラフィクス・パイプラインは第一のフレーム・データを第一のフレーム・バッファに送る。また、第二のグラフィクス・パイプラインは第二のフレーム・データを第二のフレーム・バッファに送る。

表示装置は物理的なディスプレイおよびユーザー・インターフェースを有していてもよい。ユーザー・インターフェースは前記第一および第二のフレーム・バッファの一つのユーザー選択を受領してもよい。物理的なディスプレイは選択されたフレーム・バッファ内のフレーム・データを出力する。

一つまたは複数のアプリケーションの第一の集合は第一のオペレーティング・システムに対応してもよく、一つまたは複数のアプリケーションの第二の集合は第二のオペレーティング・システムに対応してもよい。

本システムはさらに、処理プラットフォームと表示装置との間の通信インターフェースを含んでいてもよい。処理プラットフォームは、通信インターフェースを介して第一のフレーム・データを第一の接続を通じて送り、通信インターフェースを介して第二のフレーム・データを第二の接続を通じて送ってもよい。これら第一および第二の接続は孤立させられていてもよい。通信インターフェースはUSBインターフェースまたはLANであってもよい。

さらなる方法は：一つまたは複数のアプリケーションの第一の集合のために第一のフレーム・データを生成し；一つまたは複数のアプリケーションの第二の集合のために第二のフレーム・データを生成し；第一のフレーム・データを表示装置内の第一のフレーム・バッファに送り；第二のフレーム・データを前記表示装置内の第二のフレーム・バッファに送り；ユーザー選択に基づいて、前記第一のフレーム・データおよび前記第二のフレーム・データのうちの一方を物理的なディスプレイに出力することを含んでいてもよい。一つまたは複数のアプリケーションの第一の集合は第一のオペレーティング・システムに対応してもよく、一つまたは複数のアプリケーションの第二の集合は第二のオペレーティング・システムに対応してもよい。第一のフレーム・データを送ることは、通信インターフェースの第一の接続を通じて第一のフレーム・データを送信することを含んでいてもよく、第二のフレーム・データを送ることは、通信インターフェースの第二の接続を通じて第二のフレーム・データを送信することを含んでいてもよい。第一および第二の接続は互いから孤立させられていてもよい。

表示装置は、（たとえば一つまたは複数のフレーム・バッファ内の）フレーム・データを記憶する揮発性記憶媒体と；不揮発性記憶媒体と；より低い電力状態への遷移に基づいて前記不揮発性記憶媒体にフレーム・データを保存する制御モジュールとを含んでいてもよい。このより低い電力状態は、スリープ状態であってもよい。より低い電力状態への遷移は、結合されている処理プラットフォームから受領される指令に基づいてであってもよい。制御モジュールは、前記より低い電力状態からより高い電力状態への遷移に基づいてフレーム・データを揮発性記憶媒体中に復元してもよい。揮発性記憶媒体は、動的ランダム・アクセス・メモリ（RAM）を有していてもよく、不揮発性記憶媒体はフラッシュ・メモリを有していてもよい。

さらなる方法は：表示装置に含まれ揮発性記憶媒体を有するフレーム・バッファにフレーム・データを記憶し；より低い電力状態（たとえばスリープ状態）への遷移に基づいて前記表示装置に含まれる不揮発性記憶媒体にフレーム・データを保存することを含んでいてもよい。本方法はまた、処理プラットフォームから前記より低い電力状態への遷移のための指令を受領することを含んでいてもよい。本方法はまた、前記より低い電力状態からあるより高い電力状態へ遷移し、その遷移に基づいてフレーム・データをフレーム・バッファ中に復元することを含んでいてもよい。

さらなる方法は：一つまたは複数のフレーム・データ・ストリームを物理的なディスプレイに出力するためのユーザー選択を受領し；ユーザー選択に基づいて、ローカル記憶媒体の一つまたは複数のフレーム・バッファ記憶部分を割り当て、前記一つまたは複数のフレーム・バッファ記憶部分は前記一つまたは複数のフレーム・データ・ストリームに対応し；処理プラットフォームから前記一つまたは複数のフレーム・データ・ストリームを受領し；前記一つまたは複数の受領されたフレーム・データ・ストリームを記憶媒体中に記憶し、該記憶は前記割り当てに基づいてであり；前記一つまたは複数の受領されたフレーム・データ・ストリームを、前記ユーザー選択に基づいて物理的なディスプレイに出力することを含む。

前記ローカル記憶媒体の前記一つまたは複数のフレーム・バッファ記憶部分を割り当てることは、フレーム・マッピング・テーブル（FMT: frame mapping table）を生成することを含む。また、本方法は、前記FMTを前記ローカルな記憶媒体に記憶することを含みうる。前記方法はさらに：前記一つまたは複数のフレーム・データ・ストリームのそれぞれについて解像度を決定することを含み、処理プラットフォームに対して、前記一つまたは複数のフレーム・データ・ストリームのそれぞれについての解像度を示すことを含んでいてもよい。

処理プラットフォームから前記一つまたは複数のフレーム・データ・ストリームを受領することは、対応する決定された解像度に従って前記一つまたは複数のフレーム・データ・ストリームのそれぞれを受領することを含んでいてもよい。また、処理プラットフォームから前記一つまたは複数のフレーム・データ・ストリームを受領することは、通信インターフェースを通じて前記一つまたは複数のフレーム・データ・ストリームを受領することを含む。さらに、前記一つまたは複数のフレーム・データ・ストリームのそれぞれは、通信インターフェースにおける対応する接続を通じて受領されてもよい。

上記の特徴は例示的である。よって、実施の形態はこれらの特徴に限定されるものではない。諸実施形態のさらなる特徴は、以下の記述および付属の図面から明白となるであろう。

本明細書を通じて「一つの実施形態」または「ある実施形態」という言い方をするのは、その実施形態との関連で記述される特定の特徴、構造または特性が少なくとも一つの実施形態に含まれることを意味する。よって、本明細書を通じた随所に「一つの実施形態では」または「ある実施形態では」といった表現が現れることは、かならずしもみなが同じ実施形態について述べているのではない。さらに、特定の特徴、構造または特性は、一つまたは複数の実施形態にいかなる好適な仕方で組み合わされてもよい。

図１は、本稿に記載される技法を用いてもよい例示的な動作環境１００を示す図である。環境１００はさまざまな要素を含みうる。たとえば、図１は、処理プラットフォーム１０１、表示装置１０３およびインターフェース１０５を含む環境１００を示している。これらの要素は、ハードウェアおよび／またはソフトウェアのいかなる組み合わせにおいて実装されてもよい。

処理プラットフォーム１０１は、一つまたは複数のオペレーティング・システム（OS）を含んでいてもよい。たとえば、図１は、オペレーティング・システム１０８ａおよび１０８ｂを走らせている処理プラットフォーム１０１を示しているが、オペレーティング・システムをいくつ用いてもよい。これらのオペレーティング・システムを通じて、さまざまなコンピュータ・アプリケーションが実行されうる。たとえば、図１は、アプリケーション１０２ａ〜ｄを実行する処理プラットフォーム１０１を示している。これらのアプリケーションのそれぞれは、OS １０８ａ〜ｂの個別の一つのもとで実行されてもよい。

アプリケーション１０２ａ〜ｄは、一つまたは複数のディスプレイ（表示装置１０３のような）上に出力されるグラフィクスを用いる。例示的なアプリケーションは、さまざまなビジネス関係のアプリケーション（たとえば、ワード・プロセッサ、スプレッドシート・アプリケーション、プレゼンテーション・アプリケーション、電子メール、メッセージング・アプリケーションなど）、ゲーム・アプリケーション、ビデオ・アプリケーションおよび／または他のアプリケーションを含む。

処理プラットフォーム１０１はさらに、一つまたは複数のグラフィクス・パイプラインを含んでいてもよい。たとえば、図１は、グラフィクス・パイプライン１０６ａおよび１０６ｂを含む処理プラットフォーム１０１を示す。しかしながら、グラフィクス・パイプラインをいくつ用いてもよい。これらのグラフィクス・パイプラインは、アプリケーション１０２ａ〜ｄのためのグラフィクス動作を提供する。諸実施形態において、これは一つまたは複数のアプリケーション・プログラミング・インターフェース（API）（図示せず）を通じて扱われる。そのようなAPIは、グラフィクス・パイプライン１０６ａ〜ｂとインターフェースをもつさまざまなルーチン、データ構造、オブジェクト・クラスおよび／またはプロトコルを提供しうる。例示的なAPIは、オープンGL（OpenGL）、ダイレクトX（DirectX）などといった（これに限定されないが）商業的に入手可能なAPIを含む。

特に、グラフィクス・パイプライン１０６ａ〜ｂは、グラフィクスAPIを通じて受領され、処理されたディレクティブに応答してグラフィクス動作を実行する。例示的な動作は、画像（フレーム）をレンダリングし、表示装置１０３に出力することを含む。上記のように、グラフィクス・パイプライン１０６ａ〜ｂは、ハードウェアおよび／またはソフトウェアのいかなる組み合わせで実装されてもよい。よって、諸実施形態において、グラフィクス・パイプライン１０６ａ〜ｂは一つまたは複数のグラフィクス処理ユニット（GPU）で実装されてもよい。

図１は、表示装置１０３が物理的ディスプレイ１０９、記憶媒体１１０、制御モジュール１１２、ユーザー・インターフェース１１３および不揮発性記憶媒体１１４を含むことを示している。

物理的ディスプレイ１０９は、ユーザーに対して視覚的な出力を提供する。諸実施形態において、この出力は逐次的な画像（またはフレーム）の形である。よって、例示的な物理的ディスプレイは、発光ダイオード（LED）ディスプレイ、液晶ディスプレイ（LCD）、プラズマ・ディスプレイおよび陰極線管（CRT）を含む。しかしながら、実施の形態はこれらの例に限定されるものではない。

物理的なディスプレイ１０９によって出力されるフレームのそれぞれは、複数のピクセルを有していてもよい。これらのピクセルを表すデータ（たとえば色および／または強度の値）は、記憶媒体１１０内のフレーム・バッファに記憶される。このデータは「フレーム・データ」と称されてもよい。よって、フレーム・データを記憶することによって、フレーム・バッファは物理的ディスプレイ１０９を「駆動する」。

諸実施形態において、表示装置１０３は複数のフレーム・バッファを提供しうる。たとえば、図１は、フレーム・バッファ１１１ａおよび１１１ｂを含む表示装置１０３を示している。しかしながら、フレーム・バッファをいくつ用いてもよい。これらのフレーム・バッファは記憶媒体１１０に含まれていてもよい。記憶媒体１１０は、揮発性のランダム・アクセス・メモリ（RAM）（たとえば動的RAM）を有していてもよい。しかしながら、不揮発性メモリのような他の型の記憶媒体を用いてもよい。

諸実施形態において、表示装置１０３は処理プラットフォーム１０１からフレーム・データを受領する。より具体的には、グラフィクス・パイプライン１０６ａ〜ｂは（インターフェース１０５を通じて）フレーム・データ１２０を表示装置１０３に送達してもよい。受領すると、表示装置１０３はフレーム・データをフレーム・バッファ１１１ａおよび／または１１１ｂ内に記憶する。今度は、この記憶されたフレーム・データは、本稿に記載される技法に従って物理的ディスプレイ１０９によって出力されてもよい。

上記のように、表示装置１０３は制御モジュール１１２を含む。制御モジュール１１２は表示装置１０３のさまざまな動作を指令する。そのような動作は、処理プラットフォーム１０１から受領されるフレーム・データの受領、記憶および出力を含む。よって、制御モジュール１１２はインターフェース１０５による通信、表示タイミング、電力管理手順などを扱いうる。また、制御モジュール１１２は、ユーザー・インターフェース１１３を通じてまたは仮想化制御ソフトウェア・スタックへの制御経路１２２を通じてユーザー対話を管理してもよい。

ユーザー・インターフェース１１３は、ユーザーが表示装置１０３と対話することを許容する。この対話は、ユーザーが本稿に記載されるさまざまな動作を実行することに関わってもよい。そのような動作は、（これに限定されないが）表示装置１０３内で出力のためのフレーム・バッファを選択すること、単一フレーム・バッファ出力モードまたは複数フレーム・バッファ出力モードを選択すること、ならびに表示装置１０３のための動作電力を加えるおよび除去することを含む。ユーザー・インターフェース１１３はさまざまな仕方で実装されうる。ユーザー・インターフェース１１３はさまざまなボタン、キー、ダイヤルおよび／または他の入力装置を含んでいてもよい。加えて、あるいはこれに代えて、ユーザー・インターフェース１１３は、物理的ディスプレイ１０９を通じて提供されるさまざまなメニューおよび／またはタッチスクリーン機能を含んでいてもよい。

諸実施形態において、表示装置１０３は不揮発性記憶媒体１１４（たとえばフラッシュ・メモリ）を含んでいてもよい。のちにさらに詳細に述べるように、不揮発性記憶媒体１１４は、表示装置１０３が電力状態の間を遷移する（たとえばより高い電力状態からより低い電力状態に）ときにフレーム・バッファ１１１ａ〜ｂの内容の記憶を提供しうる。あるいはまた、諸実施形態は、不揮発性メモリを用いてフレーム・バッファ１１１ａ〜ｂを実装することによってそのような機能を提供し、それが常に利用可能でありその内容を保持するようにしてもよい。

インターフェース１０５は、処理プラットフォーム１０１と表示装置１０３の間に結合される。特に、インターフェース１０５は、処理プラットフォーム１０１が表示装置１０３にフレーム・データ１２０を提供できるようにする。インターフェース１０５はまた、処理プラットフォーム１０１および表示装置１０３が制御情報１２２を互いと交換できるようにする。

インターフェース１０５は、さまざまな仕方で実装されうる。たとえば、諸実施形態において、インターフェース１０５は、ユニバーサル・シリアル・バス（USB）インターフェース（たとえば、USB1.0、USB2.0、USB3.0など）のような「プラグアンドプレイ」インターフェースを含んでいてもよい。しかしながら、さまざまな他のシリアルおよび／またはパラレル・インターフェースを用いてもよい。さらに、インターフェース１０５は（イーサネット（登録商標）・ネットワークのような）有線のローカル・エリア・ネットワーク（LAN）を用いて実装されてもよい。さらに、インターフェース１０５は無線ネットワークを用いて実装されてもよい。例示的な無線ネットワークはIEEE802.11無線LAN（WiFi）ネットワーク、IEEE802.16 WiMAXネットワークおよび無線パーソナル・エリア・ネットワーク（WPAN）（たとえば60GHz WPAN）を含む。しかしながら、実施の形態はこれらの例に限定されるものではない。

諸実施形態において、表示装置１０３のフレーム・バッファ１１１ａ〜ｂは、処理プラットフォーム１０１内のプロセスおよび／またはオペレーティング・システムには「ディスプレイ」のように見える。よって、諸実施形態において、それらのプロセスおよび／またはオペレーティング・システムは、表示装置１０３の物理的なディスプレイ１０９に気づかない。さらに、諸実施形態において、ユーザーまたは独立したソフトウェア・スタックが、表示装置１０３内のフレーム・バッファが物理的なディスプレイ１０９上で実際にどのように見られるかを管理する。たとえば、諸実施形態は、ユーザーまたはソフトウェアがさまざまなフレーム・バッファを通じてページングするまたは「フリップする／めくる」ことができるようにする。これに代えてまたはこれに加えて、諸実施形態は、ユーザーまたはソフトウェアがさまざまなフレーム・バッファを物理的なディスプレイ１０９上のさまざまな独立した領域にマッピングして、複数のフレームが同時に見られるようにすることを許容する。

諸実施形態において、図１の要素はコンピュータ・システムとして実装されてもよい。たとえば、処理プラットフォーム１０１はパーソナル・コンピュータであってもよく、表示装置１０３はその対応するモニタであってもよい。しかしながら、諸実施形態は、そのような構成に限定されるものではない。

さらに、図１の要素は、一つまたは複数のプロセッサ（たとえばマイクロプロセッサ）を含んでいてもよい。たとえば、処理プラットフォームはマイクロプロセッサのいかなる組み合わせを有していてもよい。一例として、本稿に記載される動作（OS １０８ａ〜ｂ、アプリケーション１０２ａ〜ｂおよびグラフィクス・パイプラインの動作など）は、中央処理ユニットCPU（単数または複数）および／またはグラフィクス処理ユニットGPU（単数または複数）によって提供されてもよい。これらのCPUおよび／またはGPUは、記憶媒体中に記憶されている命令（たとえばソフトウェア）に従って動作してもよい。この記憶媒体（処理プラットフォーム１０１に含まれてもよい）は、メモリ（揮発性または不揮発性）、ディスク記憶などを含んでいてもよい。よって、表示装置１０３はまた、本稿に記載される機能を提供するための一つまたは複数のプロセッサを含む。そのようなプロセッサは、記憶媒体に記憶されている命令（たとえばソフトウェア）を実行してもよい。この記憶媒体（表示装置１０３に含まれてもよい）は、メモリ（揮発性または不揮発性）、ディスク記憶などを含んでいてもよい。そのような実装に関するさらなる詳細はのちに述べる。

さまざまな実施形態についての動作は、以下の図面および付属の例を参照しつつ記載されうる。図面のいくつかは、論理フローを含むことがありうる。本稿に呈示されるそのような図は特定の論理フローを含んでいることがあるが、その論理フローは単に、本稿に記載される一般的な機能がどのようにして実装されうるかの例を与えるものであることは理解できる。さらに、所与の論理フローは、特に記されていない限り、必ずしも、呈示される順序で実行される必要はない。さらに、所与の論理フローは、ハードウェア要素、一つまたは複数のプロセッサによって実行されるソフトウェア要素またはそれらの任意の組み合わせによって実行されうる。実施の形態はこのコンテキストに限定されるものではない。

伝統的なグラフィック／ビデオ・プロセス・パイプラインは、表示コンテンツが処理プラットフォーム内のシステム・フレーム・バッファ・メモリにレンダリングされ、次いでレンダー・データ（フレーム・データ）が通常のディスプレイ・インターフェースを通じて表示装置に送られることを含む。そのような通常のインターフェースの例は、ビデオ・グラフィクス・アレイ（VGA）、デジタル・ビジュアル・インターフェース（DVI）、高精細度マルチメディア・インターフェース（HDMI）、ディスプレイポート（DP）およびアナログ・テレビジョン・フォーマットを含む。次いで今度は、表示装置は受領されたフレーム・データを用いてディスプレイを駆動する。これは、処理プラットフォームまたは表示装置内にある論理によって管理されうるタイミングに基づく。

近年、処理プラットフォームのフレーム・バッファから現在フレームを横取り〔インターセプト〕するアプローチが開発されている。横取りされたフレームは読まれ、前のフレームと比較される。この比較に基づいて、差分（「デルタ」）が決定される。次いでこのデルタ（これは無損失の圧縮を与える）は、USBまたはイーサネット（登録商標）インターフェースのような一般的なインターフェースを通じて表示装置に送られる。

受領すると、表示装置はその内部論理を使って前記デルタを圧縮解除し、圧縮解除されたデータを自分自身のフレーム・バッファに記憶する。さらに、表示装置は、ローカル表示画面リフレッシュ、スケーリング、回転および表示のオン／オフといったさまざまな動作を扱ってもよい。これらの技法は共通のインターフェースを使うので、いくつかの表示装置がサポートされてもよい（処理プラットフォームのフレーム・バッファ・サイズおよびその処理帯域幅に制限される）。

残念ながら、これらの横取り、読み取りおよび比較動作（処理プラットフォームによって実行される）は、プラットフォームの処理容量のかなりの量を要求する。たとえば、動きの多いビデオは、典型的な処理プラットフォームの（たとえばパーソナル・コンピュータの）処理容量の実質的にすべてを要求することがある。

よって、このアプローチはさまざまな欠点を呈する。一つの欠点は、処理プラットフォームがフレーム・バッファ横取りに気づかず、リモート・フレーム・バッファを活用しないということである。結果として、処理プラットフォームは、ローカル・グローバル・メモリにおいてそれ自身のフレーム・バッファを構築および維持することによって、処理帯域幅および電力を浪費する。

このアプローチのさらなる欠点は、処理プラットフォームのフレーム・バッファの（たとえばサードパーティーのフレーム・スクラッピング・ソフトウェアによる）横取りおよび読み取りがセキュリティ・ホールになるということである。これは、そのようなサードパーティー・ソフトウェアは（個人データを含む内容のような）いかなるフレーム内容でも捕捉し、それをどこにでも送ることができるからである。よって、そのようなフレーム・スクラッピングは将来は禁止される可能性が高い。

諸実施形態は、統合されたフレーム・バッファを有するディスプレイを活用することによって、そのような欠点を克服する。たとえば、諸実施形態において、処理プラットフォームは、リモートに位置するフレーム・バッファを把握し、リモート・フレームを全体的なグラフィック・プロセス・パイプラインの一部として含めるグラフィック・パイプライン（単数または複数）を有していてもよく、生成から表示までコンテンツが安全である（secure）ことを保証してもよい。リモートのフレーム・バッファは、いかなるデジタル・インターフェースを通じて取り付けられてもよく、コンテンツが暗号化されることを要求する場合、そのインターフェースの適切な暗号化方法が採用される。

リモート・フレーム・バッファの概念を含めることによって、処理プラットフォームは、フレームからフレームへのデルタ・データだけを提供すればよく、よって前述のフレームとフレームの比較動作の必要をなくす。さらに、諸実施形態は、そのようなデータを圧縮するか圧縮しないかを、インターフェースを通じて送る前に決定しうる。この決定は、インターフェースの利用可能な帯域幅に基づいていてもよい。たとえば、圧縮は、USB1.0およびUSB2.0インターフェースについて用いられてもよいが、USB3.0インターフェースについては用いなくてもよい。

図２は、図１のグラフィクス・パイプラインのいずれかにおけるような、グラフィクス・パイプラインに含まれうる例示的な実装２００の図である。この実装は、さまざまな要素を含んでいてもよい。（限定ではなく）例解の目的のため、図２はグラフィクス・レンダリング・エンジン２０１、フレーム・バッファ制御モジュール２１４、フレーム・バッファ２１６および通信インターフェース・モジュール２１８を示している。これらの要素は、ハードウェアおよび／またはソフトウェアのいかなる組み合わせで実装されてもよい。

グラフィクス・レンダリング・エンジン２０１は、グラフィクス入力データ２２０からフレーム・データを生成する。グラフィクス・レンダリング・エンジン２０１はさまざまな仕方で実装されうる。図２は、変換モジュール２０２、ライティング・モジュール２０４、セットアップ・モジュール２０６、ラスタ化モジュール２０８、テクスチャー・ユニット２１０、ピクセル処理モジュール２１２を含むグラフィクス・レンダリング・エンジン２０１を示している。

図２に示されるように、グラフィクス・レンダリング・エンジン２０１は、変換モジュール２０２においてグラフィクス入力データ２２０を受領する。グラフィクス入力データ２２０は、モデル空間（たとえば三次元空間）内のシーンの表現を含む。諸実施形態では、グラフィクス入力データ２２０は、一つまたは複数のアプリケーションから（たとえばグラフィクスAPI（単数または複数）を通じて）受領されてもよい。

変換モジュール２０２は、グラフィクス入力データ２２０における座標を、モデル空間から画面空間に変換する。さらに、変換モジュール２０２は、クリップ試験（clip testing）および任意のクリッピング動作（clipping operations）のような動作を実行する。

ライティング・モジュール２０４は、バーテックス法線および事前に指定された素材色に基づいてバーテックス色を計算する。任意的に、これはバーテックスごとの色に関わってもよい。セットアップ・モジュール２０６は、プリミティブのエッジの傾きならびに深さ、色およびテクスチャー・パラメータの勾配（X方向およびY方向の変化）を計算する。

ラスタ化モジュール２０８は、プリミティブについてのすべての有効なピクセル・サンプルを見出し、各サンプル点における正しい深さ、色およびテクスチャー値を計算する。テクスチャー・ユニット２１０はテクスチャー・メモリから一つまたは複数のテクセル値を見出し、テクスチャー固有のブレンド動作をはいってくるピクセル値に対して実行する。

ピクセル処理モジュール２１２は、深さ比較、ピクセル・ブレンドおよび他の同様な動作といったピクセルごとに一回生起する動作を実行する。結果として、ピクセル処理モジュール２１２は、フレーム・バッファ制御モジュール２１４に、単一の画面画像〔スクリーン・イメージ〕の内容を表すピクセル・データを提供する。

フレーム・バッファ制御モジュール２１４は、ピクセル・データの記憶に関する動作を実行する。たとえば、フレーム・バッファ制御モジュール２１４は、ピクセル・データをフレーム・バッファ２１６にローカルに記憶するかどうか、あるいはピクセル・データを（表示装置１０３のような）表示装置内のフレーム・バッファに送るかどうかを決定する。

通信インターフェース・モジュール２１８は、表示装置に接続するインターフェース（図１のインターフェース１０５のような）へのアクセスを提供する。たとえば、通信インターフェース・モジュール２１８は、インターフェースに、ピクセル・データ（フレーム・バッファ２１６から、あるいはフレーム・バッファ制御モジュール２１４から直接、受領される）を提供してもよい。また、通信インターフェース・モジュール２１８は、（前記インターフェースを通じて）前記表示装置によって与えられる制御情報を受領してもよい。そのような制御データは、前記表示装置がフレーム・バッファ（単数または複数）を有するかどうかを示してもよい。諸実施形態において、制御データは、拡張ディスプレイ識別データ（EDID: extended display identification data）構造のような表示装置の機能を記述するデータ構造であってもよい。しかしながら、他のデータ・フォーマットを用いてもよい。

図２に示されるように、通信インターフェース・モジュール２１８は、フレーム・バッファ制御モジュール２１４に、そのような制御情報を提供する。たとえば、図２は、通信インターフェース・モジュール２１８がフレーム・バッファ制御モジュール２１４にフレーム・バッファ・インジケータ２２２およびインターフェース容量インジケータ２２４を提供することを示している。フレーム・バッファ・インジケータ２２２は、表示装置がフレーム・バッファを含むかどうかを示す。インターフェース容量インジケータ２２４は、処理プラットフォームの、表示装置とのインターフェースの容量（「帯域幅」）を示す。諸実施形態において、このインジケータは、インターフェース型（たとえば、USB1.0、USB2.0、USB3.0など）を指定してもよい。しかしながら、容量の他の指標を用いてもよい。

これらのインジケータに基づいて、フレーム・バッファ制御モジュール２１４は、生成されたフレーム・データをいかにして扱うかを決定する。たとえば、接続されている表示装置が統合されたフレーム・バッファを有さない場合は、生成されたフレーム・データをフレーム・バッファ２１６においてローカルに記憶する。さらに、そのようなローカルに記憶されたフレーム・データは、通常の表示インターフェース技法（たとえばVGA、DVI、HDMI、DP、テレビジョンなど）に従って表示装置に送られる。

対照的に、接続されている表示装置が統合されたフレーム・バッファを有する場合には、フレーム・バッファ制御モジュール２１４はフレーム・データ（たとえば、前のフレームからの「デルタ」または差分）を表示装置に（インターフェース・モジュール２１４および接続されているインターフェースを介して）、その統合されたフレーム・バッファ内での記憶のために、送る。このフレーム・データは、インターフェースの容量に基づいて送られる。たとえば、より高い容量のインターフェースについては、フレーム・データ（たとえばデルタ）は、圧縮されないフォーマットで送られてもよい。しかしながら、より低い容量のインターフェースについては、フレーム・データ（たとえばデルタ）は圧縮されたフォーマットで送られてもよい。しかしながら、実施の形態は、この例に限定されない。

さらに、フレーム・バッファ制御モジュール２１４は、（通信インターフェース・モジュール２１８を通じて）インターフェースを通じて送られるフレーム・データを暗号化してもよい。処理プラットフォームと表示装置の間のインターフェースによって用いられる標準的な暗号化機構のようなさまざまな暗号化技法が用いられうる。よって、表示装置（たとえばその制御モジュール）は、そのようなデータを受領に際して復号できる。

図３は、一つまたは複数の実施形態によって実行される動作を表しうる論理フロー３００の図である。このフローは、一つまたは複数のグラフィクス・パイプラインを有する処理プラットフォームと、一つまたは複数のフレーム・バッファを有する表示装置とに関わる。よって、このフローは、図１の要素によって実行されてもよい。しかしながら、実施の形態はこのコンテキストに限定されるものではない。図３は、特定のシーケンスを示しているが、他のシーケンスを用いてもよい。また、描かれている動作は、さまざまな並列および／または逐次的な組み合わせにおいて実行されてもよい。

ブロック３０２では、処理プラットフォーム（たとえば処理プラットフォーム１０１）は表示装置が統合されたフレーム・バッファを有するかどうかを判定する。諸実施形態において、これは表示装置から制御情報（たとえばEDID）を受け取ることを含んでいてもよい。もし有する場合、動作はブロック３０４に進む。そうでない場合には、動作はブロック３０８に進む。

ブロック３０４では、処理プラットフォームは、インターフェースの容量（帯域幅）を判別する。これに基づいて、処理プラットフォームは、ブロック３０６でフレーム・データについて送信フォーマットを決定する。たとえば、より低い容量については、処理プラットフォームは、フレーム・データのために圧縮伝送フォーマットを用いることを決定してもよい。しかしながら、より高い容量については、処理プラットフォームは、フレーム・データについて非圧縮伝送フォーマットを用いることを決定してもよい。

諸実施形態において、容量は用いられるインターフェースの型によって決定されてもよい。たとえば、USB1.0およびUSB2.0インターフェースは、（圧縮伝送フォーマットを使う）より低い容量のインターフェースと考えられてもよい。対照的に、USB3.0およびLAN（たとえばイーサネット（登録商標））インターフェースは、（非圧縮伝送フォーマットを使う）より高い容量のインターフェースと考えられてもよい。しかしながら、実施の形態はこれらの例に限定されるものではない。

こうして、ブロック３０７では、処理プラットフォームはフレーム・データを生成し、選択された伝送フォーマットに従ってそれをインターフェースを通じてディスプレイに送る。

上記のように、ブロック３０８は、表示装置が統合されたフレーム・バッファを有さない場合に実行される。したがって、ブロック３０８では、処理プラットフォームはフレーム・データを生成し、それを自分自身のフレーム・バッファに記憶する。図２のコンテキストでは、これは、フレーム・バッファ制御モジュール２１４が実装２００によって生成されるフレーム・データをフレーム・バッファ２１６に記憶することを含んでいてもよい。

これに続いて、ブロック３１０が実行される。ここでは、処理プラットフォームがローカルに記憶されたフレーム・データを、通常のディスプレイ・インターフェース技法（たとえばVGA、DVI、HDMI、DP、テレビジョンなど）に従って表示装置に送る。

上記のように、諸実施形態は、（表示装置１０３のような）表示装置内に複数のフレーム・バッファを設けていてもよい。たとえば、図１は、フレーム・バッファ１１１ａおよび１１１ｂを有する表示装置を示している。そのような複数のフレーム・バッファの間の完全な孤立化〔アイソレーション〕が維持されてもよい。こうして、表示装置における各フレーム・バッファは、さまざまなプロセス（単数または複数）または動作（単数または複数）に割り当てられてもよい。たとえば、各フレーム・バッファは、特定のOSに、あるいは一つまたは複数の特定のアプリケーションに割り当てられてもよい。さらに、上記のように、処理プラットフォーム（処理プラットフォーム１０１のような）は複数のグラフィクス・パイプラインを含んでいてもよい。諸実施形態において、そのような複数のパイプラインのそれぞれは、対応する表示装置フレーム・バッファに向けられてもよい。

図４は、図１のコンテキストにおいてフレーム・データの例示的な配送を示す図である。具体的には、図４は、グラフィクス・パイプライン１０６ａがフレーム・データ・ストリーム４２０ａをフレーム・バッファ１１１ａに提供し、グラフィクス・パイプライン１０６ｂがフレーム・データ・ストリーム４２０ｂをフレーム・バッファ１１１ｂに提供することを示している。図１を参照すると、これらのフレーム・データ・ストリームはフレーム・データ１２０および制御情報１２２の一部であってもよい。諸実施形態では、フレーム・データ・ストリーム４２０ａおよび４２０ｂは、インターフェース１０５によって提供される異なる接続（たとえば孤立させられた接続）を通じて送られてもよい。あるいはまた、同じ接続がすべてのフレーム・データについて使われてもよい。しかしながら、そのような接続内では、フレーム・データ伝送は源（たとえば処理プラットフォーム）によって、その適切なフレーム・バッファのためにタグ付けされる。用いられるタグ付け方式は、表示装置におけるユーザー選択を通じて決定されてもよい。こうして、諸実施形態において、孤立化は、表示装置（たとえば、表示装置内の制御モジュール）によって達成されてもよい。

フレーム・データ・ストリーム４２０ａおよび４２０ｂは、異なるユーザー・コンテキスト（たとえば、処理プラットフォーム１０１の異なるプロセスまたは動作）に対応してもよい。たとえば、フレーム・データ・ストリーム４２０は、処理プラットフォーム１０１上で走る第一のオペレーティング・システムのプロセス（たとえばアプリケーション）に対応してもよく、一方、フレーム・データ・ストリーム４２２は、処理プラットフォーム１０１上で走る第二のオペレーティング・システムのプロセス（たとえばアプリケーション）に対応してもよい。また、フレーム・データ・ストリーム４２０は、一つまたは複数のアプリケーションの第一のグループに対応してもよく、フレーム・データ・ストリーム４２２は、一つまたは複数のアプリケーションの第二のグループに対応してもよい。アプリケーションのこれらのグループは、一つまたは複数のオペレーティング・システムの間でいかなる仕方で分配されてもよい。諸実施形態において、個別のアプリケーションまたはオペレーティング・システムは、その対応するフレーム・バッファのみを認識してもよい。

諸実施形態は、フレーム・データ・ストリームの間の孤立化を提供してもよい。この孤立化は、インターフェースによって提供される複数の接続を通じて提供されてもよい。たとえば、USBインターフェースのコンテキストにおいて、各フレーム・データ・ストリーム（およびその対応する制御情報）は、一つまたは複数のUSBパイプを通じて交換されてもよい。しかしながら、他のインターフェースする技法および／または孤立化技法を用いてもよい。さらに、表示装置１０３内の各フレーム・バッファは特定のフレーム・データ・ストリームに「ロックされ」て適正なユーザー・クレデンシャルなしでは割り当て直すことができなくてもよい。

このアプローチは、有利なことに、ユーザーが、表示装置上で異なるコンテンツの表示の間を行ったり来たりスイッチングする便利な方法を提供しうる。また、このアプローチは、個人的なコンテンツについての安全な経路を提供する。たとえば、このアプローチは、安全なOSおよびユーザーOSがモニタ（表示装置）を共有することを許容する。さらに、このアプローチは、複雑なメモリ・スワッピングやマッピングなしで、環境間の迅速なスイッチングを許容しうる。

図５は、一つまたは複数の実施形態によって実行される動作を表しうる論理フロー５００の図である。このフローは、処理プラットフォームおよび表示装置に関わる。よって、このフローは図１の要素によって実行されうる。しかしながら、実施の形態はこのコンテキストに限定されるものではない。図５は具体的なシーケンスを示しているが、他のシーケンスを用いてもよい。また、描かれている動作は、さまざまな並列および／または逐次的な組み合わせにおいて実行されてもよい。

ブロック５０２では、ユーザーは処理プラットフォームの動作の、表示装置内の複数のフレーム・バッファへの割り当てを決定する。たとえば、ユーザーは、第一のオペレーティング・システムのプロセスを第一のフレーム・バッファに割り当て、第二のオペレーティング・システムのプロセスを第二のフレーム・バッファに割り当ててもよい。

ブロック５０４では、割り当てのそれぞれについて、フレーム・バッファとの孤立させられた接続が確立される。たとえば、一つまたは複数のインターネット・プロトコル（IP）トンネルが、割り当てのそれぞれについて確立されてもよい。

こうして、ブロック５０６において、割り当てられた動作についてのフレーム・データが、対応する接続（単数または複数）を通じて表示装置に転送される。このデータは、ブロック５０８で、表示装置内の割り当てられたフレーム・バッファにおいて受領され、記憶される。

ブロック５１０では、ユーザーは、ディスプレイによる出力のためにフレーム・バッファを選択する。諸実施形態において、これは、ユーザーが表示装置のユーザー・インターフェースと対話することを含んでいてもよい。しかしながら、諸実施形態は、この例に限定されるものではない。この選択に基づいて、表示装置は、ブロック５１２において、選択されたフレーム・バッファの内容を出力する。図５に示されるように、動作がブロック５１０に戻って、ユーザーがブロック５１２における出力のためのフレーム・バッファ選択を変更してもよい。

上記のように、諸実施形態は、フレーム・バッファ（単数または複数）および不揮発性記憶媒体を有する表示装置を提供してもよい。たとえば、図１は、フレーム・バッファ１１１ａ〜ｂおよび不揮発性記憶媒体１１４を含む表示装置１０３を示している。この特徴は、電力状態を効果的に扱うことを許容する。たとえば、より低電力の状態（たとえば電力サスペンド状態）に遷移するとき、表示装置はそのフレーム・バッファ（単数または複数）の内容を不揮発性記憶媒体中に保存してもよい。逆に、より高電力の状態に戻ると、表示装置は保存された内容をそのフレーム・バッファに書き戻してもよい。

そのような特徴は、有利なことに、従来のアプローチの欠点を克服する。たとえば、従来のアプローチは表示装置におけるそのような不揮発性記憶を提供しない。さらに、フレーム・バッファを有する表示装置について、従来のアプローチは対応する処理プラットフォーム内にフレーム・バッファを維持しない。よって、表示装置がそのような低電力状態（たとえば電力サスペンド状態）にはいるためには、処理プラットフォームは表示装置からフレーム・バッファ内容を読み戻してその内容をそれ自身の不揮発性記憶媒体に保存す必要がある。残念ながら、これは過度のエネルギーおよび時間を消費することがある。

図６は、一つまたは複数の実施形態によって実行される動作を表しうる論理フロー６００の図である。このフローは、処理プラットフォーム、一つまたは複数のフレーム・バッファおよび不揮発性記憶媒体を有する表示装置を含む。よって、このフローは図１の要素によって実行されうる。しかしながら、実施の形態はこのコンテキストに限定されるものではない。図６は特定のシーケンスを示しているが、他のシーケンスを用いてもよい。また、描かれている動作は、さまざまな並列および／または逐次的な組み合わせで実行されてもよい。

ブロック６０２において、処理プラットフォームは、電力状態の変化（たとえばシステム・スリープ・イベント）が起ころうとしていることを判別する。具体的には、処理プラットフォームは、第一の（より高い）電力状態から第二の（より低い）電力状態への遷移が起ころうとしていることを判定する。この判定は、一つまたは複数のトリガー条件（たとえばユーザーの不活動、低バッテリー・レベルなど）の生起に基づいていてもよい。諸実施形態では、システム・スリープ・イベントは、先進構成・電力インターフェース（Advanced Configuration and Power Interface）仕様に基づくC3またはC4スリープ状態であってもよい。しかしながら、実施の形態は、これらの例示的な状態に限定されるものではない。

この判定に基づいて、処理プラットフォームは（ブロック６０４で）電力状態変化指令を表示装置に送る。図１のコンテキストでは、そのような指令はインターフェース１０５を通じて制御情報１２２として交換されうる。

表示装置はブロック６０６でこの指令を受領する。今度は、表示装置はそのフレーム・バッファ（単数または複数）への動作電力がサスペンドされるべきであることを判別する。したがって、ブロック６０８では、表示装置はこれらのバッファ（単数または複数）の内容（たとえばフレーム・データ）をその不揮発性記憶媒体に保存する。これに続いて、表示装置は、ブロック６１０において指令された電力状態にはいりうる。図１のコンテテキストにおいて、ブロック６０６〜６１０の実行は、制御モジュール１１２によって管理されてもよい。

ブロック６１２では、処理プラットフォームは、さらなる電力状態の変化が起ころうとしていることを判別する。具体的には、処理プラットフォームは、前記第二の（より低い）電力状態からより高い電力状態への遷移が起ころうとしていることを判定する。諸実施形態において、これは前記第一の電力状態への回帰であってもよい。あるいはまた、これは異なるより高い電力状態への遷移であってもよい。

したがって、ブロック６１４において、処理プラットフォームは表示装置に指令を送る。図１を参照するに、この指令は、インターフェース１０５を通じて制御情報１２２として送られてもよい。

表示装置はブロック６１６でこの指令を受領する。受領すると、表示装置は、ブロック６１８でそのフレーム・バッファ（単数または複数）に動作電力を提供する。今度は、ブロック６２０において、表示装置は保存されたコンテンツを不揮発性メモリからそのフレーム・バッファ（単数または複数）にコピーし戻す。こうして、フレーム・データがそのフレーム・バッファに復元される。図１のコンテキストでは、ブロック６１６〜６２０の実行は制御モジュール１１２によって管理されてもよい。

本稿で記載しているように、諸実施形態は、統合されたフレーム・バッファを有する表示装置を提供してもよい。これは、ローカルなディスプレイ・フレーム・メモリにおいて実装されてもよい。また、諸実施形態において、表示装置（たとえば表示装置１０３）はそのローカルなディスプレイ・フレーム・メモリへのフレーム・マップ・テーブル（FMT）を有していてもよい。FMTは、このメモリを、単一の物理的ディスプレイにマッピングされる複数の独立したフレーム・バッファ中に分割できるよう、管理してもよい。

この特徴は、有利なことに、大きなディスプレイが、一つの閲覧体験として、あるいは複数の独立した表示体験を提供する「分割画面（split screen）」として選択的に使われることを許容する。たとえば、ユーザーは画面を半分に（横にまたは縦に）分割して独立した表示の体験を得ることができる。さらに、ユーザーは、単一表示体験と複数の独立表示体験との間で動的に切り換えてもよい。

ビジネス・システムに追加されるモニタ一つにつき50%生産性が高まると言われている。よって、この特徴は、有利なことに、ユーザーに、一つのモニタでマルチモニタ体験を得ることを提供する。このように、この特徴は、有利なことに、デスクスペースを節約する。

また、FMTは、ディスプレイ・フレーム・メモリのブロックに関連付けられたタグ・フィールドを含んでいてもよい。タグ・フィールドは、ブロックを互いから保護してメモリが異なるオペレーティング・システム、アプリケーションおよび／またはユーザーに割り当てられることを許容する。

諸実施形態において、FMTは、表示装置上でユーザー・インターフェースを通じて管理される。これは、FMTの管理が、対応する処理プラットフォーム（たとえば処理プラットフォーム１０１）によって提供されるユーザー・インターフェースとは独立であるため、ウィンドウ環境とは異なる。

そのようなユーザー選択（たとえば、マルチモニタおよび単一モニタ）は、異なる出力解像度を伴う。こうして、この特徴を提供するために、表示装置は、処理プラットフォームに、これらの要素を接続するインターフェース（たとえばインターフェース１０５）を通じて（ユーザーの選択に基づく）解像度情報を与える。この解像度情報は、EDIDデータ構造（単数または複数）などさまざまなフォーマットで与えられうる。

この情報を受領すると、処理プラットフォーム（たとえばそのグラフィクス・パイプライン（単数または複数））は適切な解像度（単数または複数）を決定し、その解像度に従ってフレーム・データを生成する。

上記のように、図１を参照するに、表示装置１０３は、第一のフレーム・バッファ１１１ａおよび第二のフレーム・バッファ１１１ｂを提供する記憶媒体１１０を含む。図７は、FMTを用いる代替的な構成の図である。特に、図７は、表示装置１０３のような表示装置において使用されうる記憶媒体１１０′を示している。

図７に示されるように、記憶媒体１１０′は、一つまたは複数のフレーム・バッファを提供するために柔軟に割り当てられうるフレーム・バッファ空間７０２を含む。この柔軟な割り当ては、FMT ７０４によって決定される。たとえば、図７は、FMT ７０４がフレーム・バッファ空間７０２を第一のフレーム・バッファ部分７０６および第二のフレーム・バッファ部分７０８中に割り当てることを示している。しかしながら、諸実施形態において、FMT ７０４はフレーム・バッファ空間７０２を単一のフレーム・バッファ部分に割り当ててもよく、あるいはいかなる複数のフレーム・バッファ部分に割り当ててもよい。

図８は、一つまたは複数の実施形態によって実行される動作を表しうる論理フロー８００の図である。このフローは、処理プラットフォームと、一つまたは複数のフレーム・バッファおよび不揮発性記憶媒体を有する表示装置とに関わる。よって、このフローは図１の要素によって実行されてもよい。しかしながら、実施の形態はこのコンテキストに限定されるものではない。図８は特定のシーケンスを示しているが、他のシーケンスが用いられてもよい。また、描かれた動作は、さまざまな並列および／または逐次的な組み合わせで実行されてもよい。

ブロック８０２では、表示装置は、一つまたは複数の表示データ・ストリームをその物理的なディスプレイに出力するユーザー選択を受領する。たとえば、ユーザー選択は、単一のフレーム・データ・ストリームを出力するというものであってもよい（単一モニタ体験）。あるいはまた、ユーザー選択は、複数のフレーム・データ・ストリームを出力するというものであってもよい（複数モニタ体験）。さらに、ユーザー選択は出力フォーマット（たとえば、横並び、上から下への敷き詰めなど）を指示してもよい。このユーザー選択は、表示装置のユーザー・インターフェースを通じて（たとえば図１のユーザー・インターフェース１１３を通じて）受領されてもよい。

ユーザー選択に基づいて、表示装置は（ブロック８０４で）その記憶媒体内にフレーム・バッファ記憶部分を割り当てる。たとえば、図７のコンテキストでは、それらの部分はフレーム・バッファ空間７０２内であってもよい。さらに、この割り当てはFMTを生成することに関わってもよい。

ブロック８０６では、表示装置は処理装置にユーザー選択に関する情報を指示する。この情報は、選択されたフレーム・データ・ストリームを指示してもよい。また、この情報は、（ユーザー選択に基づく）解像度情報を指示してもよい。諸実施形態では、この情報は、処理プラットフォームと表示装置との間のインターフェース（たとえばインターフェース１０５）を通じて送られてもよい。

ブロック８０７において、処理プラットフォームはブロック８０６で送られた情報を受領する。この情報に基づいて、処理プラットフォームは、受領した指示に従って（たとえば、指示された解像度（単数または複数）に従って）選択されたフレーム・データ・ストリーム（単数または複数）を生成する。また、処理プラットフォームは、選択されたフレーム・データ・ストリームをインターフェースを通じて送る。本稿で記載されるように、各フレーム・データ・ストリームは、インターフェースによって提供される対応する接続（たとえば孤立させられた接続）を通じて送られてもよい。

表示装置は、ブロック８０８で、選択されたフレーム・データ・ストリームを受領する。今度は、表示装置は、ブロック８１０で、その記憶媒体の対応する割り当てられた部分に、フレーム・データを記憶する。

これから、表示装置は、ブロック８１２で、ユーザー選択に従って、選択されたフレーム・データ・ストリーム（単数または複数）を出力する。

本稿で述べているように、さまざまな実施形態はハードウェア要素、ソフトウェア要素または両者の任意の組み合わせを使って実装されうる。ハードウェア要素の例は、プロセッサ、マイクロプロセッサ、回路、回路要素（たとえばトランジスタ、抵抗器、コンデンサ、インダクタなど）、集積回路、特定用途向け集積回路（ASIC）、プログラム可能型論理デバイス（PLD）、デジタル信号プロセッサ（DSP）、現場プログラム可能型ゲート・アレイ（FPGA）、論理ゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセットなどを含んでいてもよい。

ソフトウェアの例は、ソフトウェア・コンポーネント、プログラム、アプリケーション、コンピュータ・プログラム、アプリケーション・プログラム、システム・プログラム、機械プログラム、オペレーティング・システム・ソフトウェア、ミドルウェア、ファームウェア、ソフトウェア・モジュール、ルーチン、サブルーチン、関数、メソッド、プロシージャ、ソフトウェア・インターフェース、アプリケーション・プログラム・インターフェース（API）、命令セット、コンピューティング・コード、コンピュータ・コード、コード・セグメント、コンピュータ・コード・セグメント、語、値、シンボルまたはこれらの任意の組み合わせを含んでいてもよい。

いくつかの実施形態は、たとえば、機械によって実行されると該機械に前記の諸実施形態に基づく方法および／または動作を実行させうる命令または命令の組を記憶しうる具体的な機械可読媒体（記憶媒体）または物品を使って実装されてもよい。そのような機械は、たとえば、任意の好適な処理プラットフォーム、コンピューティング・プラットフォーム、コンピューティング・デバイス、処理装置、コンピューティング・システム、処理システム、コンピュータ、プロセッサなどを含んでいてもよく、ハードウェアおよび／またはソフトウェアの任意の好適な組み合わせを使って実装されてもよい。

前記機械可読媒体（記憶媒体）または物品は、たとえば、任意の好適な型のメモリ・ユニット、メモリ・デバイス、メモリ物品、メモリ媒体、記憶デバイス、記憶物品、記憶媒体および／または記憶ユニット、たとえば、メモリ、リムーバブルまたは非リムーバブル・メディア、消去可能型または消去可能でないメディア、書き込み可能または書き換え可能型メディア、デジタルまたはアナログ・メディア、ハードディスク、フロッピー（登録商標）ディスク、コンパクトディスク読み出し専用メモリ（CD-ROM）、記録可能型コンパクトディスク（CD-R）、書き換え可能型コンパクトディスク（CD-RW）、光ディスク、磁気媒体、光磁気媒体、リムーバブル・メモリ・カードまたはディスク、さまざまな型のデジタル多用途ディスク（DVD）、テープ、カセットなどを含んでいてもよい。前記命令は、ソース・コード、コンパイルされたコード、インタープリットされたコード、実行可能コード、静的コード、動的コード、暗号化されたコードなどといった、任意の好適な高レベル、低レベル、オブジェクト指向、ビジュアル、コンパイルされたおよび／またはインタープリットされたプログラミング言語を使って実装された、任意の好適な型のコードを含んでいてもよい。

いくつかの実施形態は、「結合された」および「接続された」という表現またその派生形を使って記述されることがありうる。これらの用語は互いに同義と意図されているのではない。たとえば、いくつかの実施形態は「接続」および／または「結合」されているという用語を使って記述されることがありうるが、これは、二つ以上の要素が互いに直接的な物理的また電気的な接触があることを示す。しかしながら、「結合されている」は、二つ以上の要素が互いに直接接触してはいないがそれでも互いと協働または相互作用することをも意味することがありうる。

本発明のさまざまな実施形態が上述されてきたが、これらは限定ではなく単に例として呈示されたことは理解しておくべきである。よって、本発明の精神および範囲から外れることなく形および細部におけるさまざまな変更を施すことができることは当業者には明白であろう。このように、本発明の広さおよび範囲は、上記の例示的な実施形態のいずれによっても限定されるべきではなく、付属の請求項およびその等価物に基づいてのみ定義されるべきである。

１００ 環境
１０１ 処理プラットフォーム
１０２ アプリケーション
１０３ 表示装置
１０５ インターフェース
１０６ グラフィクス・パイプライン
１０８ ＯＳ（オペレーティング・システム）
１０９ 物理的なディスプレイ
１１０ 記憶媒体
１１１ フレーム・バッファ
１１２ 制御モジュール
１１３ ユーザー・インターフェース
１１４ 不揮発性記憶媒体
１２０ フレーム・データ
１２２ 制御情報
２０１ グラフィクス・レンダリング・エンジン
２０２ 変換モジュール
２０４ ライティング・モジュール
２０６ セットアップ・モジュール
２０８ ラスタ化モジュール
２１０ テクスチャー・ユニット
２１２ ピクセル処理モジュール
２１４ フレーム・バッファ制御モジュール
２１６ フレーム・バッファ
２１８ 通信インターフェース・モジュール
２２０ グラフィクス入力データ
２２２ フレーム・バッファ・インジケータ
２２４ インターフェース容量インジケータ
３０２ 表示装置がフレーム・バッファを含むか
３０４ 処理プラットフォームがインターフェース容量を判別
３０６ 処理プラットフォームが判別されたインターフェース容量に基づいてフレーム伝送フォーマットを決定
３０７ 処理プラットフォームがフレーム・データを生成し、選択された伝送フォーマットに従ってインターフェースを通じて送信
３０８ 処理プラットフォームがフレーム・データを生成し、それをローカルなフレーム・バッファに記憶
３１０ 処理プラットフォームがローカルに記憶されたフレーム・データを通常のディスプレイ・インターフェース技法に従って表示装置に送信
４２０ａ フレーム・データ・ストリーム（第一のユーザー・コンテキスト）
４２０ｂ フレーム・データ・ストリーム（第二のユーザー・コンテキスト）
５０２ ユーザーが、処理プラットフォームの動作の、表示装置内の複数のフレーム・バッファへの割り当てを決定
５０４ フレーム・バッファとの独立した諸接続が確立される
５０６ 割り当てられた動作についてのフレーム・データが、対応する接続を通じて処理プラットフォームから表示装置に転送される
５０８ 表示装置が割り当てられたフレーム・バッファにおいてフレーム・データを受信し、記憶
５１０ ユーザーが表示装置による出力のためにフレーム・バッファを選択
５１２ 表示装置が選択されたフレーム・バッファの内容を出力
６０２ 処理プラットフォームが、電力状態の変化が起ころうとしていることを判別
６０４ 処理プラットフォームが表示装置に電力状態変化指令を送信
６０６ 表示装置が指令を受信
６０８ 表示装置がフレーム・バッファ内容を不揮発性記憶媒体に保存
６１０ ユーザーが表示装置による出力のためにフレーム・バッファを選択
６１２ 処理プラットフォームがさらなる電力状態の変化が起ころうとしていることを判別
６１４ 処理プラットフォームは表示装置に電力状態変化指令を送信
６１６ 表示装置が指令を受信
６１８ 表示装置がそのフレーム・バッファに動作電力を提供
６２０ 表示装置が保存された内容をフレーム・バッファにコピーして戻す
７０４ ＦＭＴ（フレーム・マップ・テーブル）
７０２ フレーム・バッファ空間
７０６ 第一のフレーム・バッファ部分
７０８ 第二のフレーム・バッファ部分
８０２ 表示装置が、一つまたは複数の表示データ・ストリームを出力するためのユーザー選択を受領
８０４ 表示装置がその記憶媒体内で一つまたは複数のフレーム・バッファ記憶部分を割り当てる
８０６ 表示装置が処理プラットフォームにユーザー選択に関する情報を指示
８０７ 処理プラットフォームが指示に従って選択されたデータ・フレーム・ストリームを生成
８０８ 表示装置が選択されたフレーム・データ・ストリームを受信
８１０ 表示装置が、受信したフレーム・データ・ストリームについてのフレーム・データを割り当てられた部分に記憶
８１２ 表示装置が、記憶されたデータを物理的なディスプレイに出力

Claims (20)

1. グラフィクス入力データからフレーム・データを生成するグラフィクス・レンダリング・エンジンと；
   結合されている表示装置がフレーム・バッファを含むかどうかを判定するフレーム・バッファ制御モジュールとを有する装置であって、
   前記結合されている表示装置がフレーム・バッファを含むとき、前記フレーム・バッファ制御モジュールは、ローカルなフレーム・バッファ内での前記フレーム・データの記憶をバイパスし、前記フレーム・データを前記結合されている表示装置に送る、
   装置。
2. 前記フレーム・データが現在のフレームと前のフレームとの間の差分データを含む、請求項１記載の装置。
3. 前記フレーム・バッファ制御モジュールが、前記結合されている表示装置との通信インターフェースの一つまたは複数の特性に基づいて圧縮伝送フォーマットと非圧縮伝送フォーマットとの間の選択をする、請求項１記載の装置。
4. 前記一つまたは複数の特性が、前記通信インターフェースの容量を含む、請求項３記載の装置。
5. 前記結合されている表示装置に前記通信インターフェースを通じて前記フレーム・データを伝送する通信インターフェース・モジュールをさらに有する、請求項３記載の装置。
6. 前記通信インターフェースがユニバーサル・シリアル・バス（USB）インターフェースである、請求項３記載の装置。
7. 前記通信インターフェースがローカル・エリア・ネットワーク（LAN）インターフェースである、請求項３記載の装置。
8. 前記フレーム・バッファが前記表示装置に送られるフレーム・データを暗号化する、請求項１記載の装置。
9. グラフィクス入力データからフレーム・データを生成する段階と；
   表示装置がフレーム・バッファを含むことを判別する段階と；
   前記フレーム・データを、前記フレーム・バッファ内に記憶するために、前記表示装置に送る段階とを含む方法であって、
   前記送る段階は、ローカルなフレーム・バッファ内での前記フレーム・データの記憶をバイパスすることを含む、
   方法。
10. 前記フレーム・データは、現在のフレームと前のフレームとの間の差分データを含む、請求項９記載の方法。
11. 前記送る段階は、前記フレーム・データを通信インターフェースを通じて前記表示装置に送信することを含む、請求項９記載の方法。
12. 前記通信インターフェースを通じて伝送されるフレーム・データを暗号化する段階をさらに含む、請求項１１記載の方法。
13. 前記通信インターフェースの一つまたは複数の特性に基づいて圧縮伝送フォーマットと非圧縮伝送フォーマットとの間の選択をする段階をさらに含む、請求項１１記載の方法。
14. 前記通信インターフェースの前記一つまたは複数の特性は、前記通信インターフェースの容量を含む、請求項１３記載の方法。
15. 命令が記憶されている機械アクセス可能媒体を有する物品であって、前記命令は、機械によって実行されたときに、前記機械に：
    グラフィクス入力データからフレーム・データを生成する段階と；
    表示装置がフレーム・バッファを含むことを判別する段階と；
    そのフレーム・データを、前記フレーム・バッファ内に記憶するために、前記表示装置に送る段階とを行わせ、
    前記送る段階は、ローカルなフレーム・バッファ内での前記フレーム・データの記憶をバイパスすることを含む、
    物品。
16. 前記フレーム・データが、現在のフレームと前のフレームとの間の差分データを含む、請求項１５記載の物品。
17. 前記命令は、前記機械によって実行されたときに、前記機械にさらに：
    前記フレーム・データを通信インターフェースを通じて前記表示装置に送信する段階を行わせる、請求項１５記載の物品。
18. 前記命令は、前記機械によって実行されたときに、前記機械にさらに：
    前記通信インターフェースを通じて伝送されるフレーム・データを暗号化する段階を行わせる、請求項１７記載の物品。
19. 前記命令は、前記機械によって実行されたときに、前記機械にさらに：
    前記通信インターフェースの一つまたは複数の特性に基づいて圧縮伝送フォーマットと非圧縮伝送フォーマットとの間の選択をする段階を行わせる、請求項１７記載の物品。
20. 処理プラットフォームおよび表示装置を有するシステムであって：
    前記処理プラットフォームは、グラフィクス入力データからフレーム・データを生成するグラフィクス・レンダリング・エンジンと、前記表示装置がフレーム・バッファを含むかどうかを判定するフレーム・バッファ制御モジュールとを含み、
    前記表示装置がフレーム・バッファを含むとき、前記フレーム・バッファ制御モジュールは、ローカルなフレーム・バッファ内での前記フレーム・データの記憶をバイパスし、前記フレーム・データを前記表示装置に送る、
    システム。

Images