JP2006073001A - ハードウェアグラフィックレイヤへのトランスペアレントなアクセスを提供するシステム - Google Patents

Abstract

【課題】 コンピュータファイル管理の新しい方法とシステムとを提供する。
【解決手段】 ソフトウェアアプリケーションとオペレーティングシステムとを含むコンピュータ環境において、コンピュータはグラフィック（ビデオ）スカード（２０）とビデオディスプレイ（１４）とを備え、ビデオカードはイメージをビデオディスプレイに提供するよう動作可能である。ビデオカード上でハードウェアレイヤをサポートするユニバーサルＡＰＩを備えるオペレーティングシステム（３６）は、ユニバーサルＡＰＩを介してドローイベントを受信し、どのハードウェアレイヤがビデオカード上で利用可能であり、パラメータが何であるかを決定し、およびビデオカード上で利用可能なハードウェアレイヤのいずれかに選択的にドロー要求をレンダリングすることによってソフトウェアアプリケーションからのドロー要求に応答するように動作可能である。
【選択図】 図２

Description

本発明は一般的にコンピュータグラフィックスに関し、より詳細には、１つのビデオディスプレイを構成するのに用いられる複数のハードウェアグラフィックスレイヤを設定し、制御し、およびアクセスするためのシステムの方法に関する。

ウィンドウズ（登録商標）タイプのオペレーティングシステムにより、ユーザおよび開発者は、一貫したグラフィカルユーザインターフェース（ＧＵＩ）を介してソフトウェアアプリケーションと情報のやり取りをすることができ、それと同時に、いっせいに複数のソフトウェアアプリケーションと情報のやり取りする能力をユーザおよび開発者に提供する。理想的には、オペレーティングシステムは、一貫したＡＰＩ（アプリケーションプログラムインターフェース）を維持する一方で可能な限りその下にあるグラフィカルハードウェアの機能へのアクセスを提供すべきである。オペレーティングシステムＡＰＩは、オペレーティングシステムと、それにアクセスするソフトウェアアプリケーションとの間のインターフェースを構成する一組のルーチンと、プロトコルと、ツールとである。ソフトウェアアプリケーションと動作環境（すなわち、ビデオディスプレイ、ハードドライブ、キーボード等）との間のインタラクションは、オペレーティングシステムＡＰＩを介してなされる。

加えて、オペレーティングシステムは、ある程度のフィーチャートランスペアレンシー（ｆｅａｔｕｒｅ ｔｒａｎｓｐａｒｅｎｃｙ）をサポートすべきである。すなわち、ソフトウェアアプリケーションは、システムフィーチャーの詳細を隅々まで認識しなくても、システムフィーチャーからの利益を享受することができるべきである。例えば、１６ビットカラー深みのディスプレイを有するシステム上に設計されたソフトウェアアプリケーションは、３２ビットカラー深みのディスプレイを有するシステム上で意図されるように起動すべきである。ソフトウェアアプリケーションは、それが起動しているビデオディスプレイのサポートされたカラー深みを認知する必要はない。オペレーティングシステムから提供されるフィーチャートランスペアレンシーの程度が高くなればなるほど、様々な環境で起動することができるソフトウェアアプリケーションを開発する容易さが高まり、かつ、所与のプラットフォームで使用することができるソフトウェアアプリケーションの選択の幅が広がる。

（ビデオメモリ、ビデオサーフェスおよびレイヤ）
パーソナルコンピュータおよび他のコンピュータデバイスは、一般的に、グラフィックスカード、ビデオカードまたはビデオボードと呼ばれる回路基板を備えており、これにより、パーソナルコンピュータはＬＣＤ（液晶ディスプレイ）またはＣＲＴ（ブラウン管）モニタといったフィジカルディスプレイを駆動することができる。これらグラフィックスカードには、典型的に、独自のビデオメモリが含まれており、その結果、コンピュータのＲＡＭ（ランダムアクセスメモリ）は、ビデオディスプレイデータを格納することを必要とされない。多くのグラフィックスカードには、独自のオンボードマイクロプロセッサも含まれており、その結果、グラフィックスを提供するために要求される処理が、コンピュータのメインマイクロプロセッサへの負担とならずに、非常に早く行われ得る。

グラフィックスカードは、典型的に、単一の表示画面のコンテンツを格納するために必要とされるよりもはるか多くのビデオメモリを有する。ビデオメモリのコンテンツは、ダイナミックに定義および再定義され得るチャンク（ｃｈｕｎｋ）にパーティションで区切られる。このチャンクはそれぞれ、特定の幅、高さおよび他の特徴を有する。各チャンクは、ビデオ「サーフェス」と呼ばれ、これらビデオサーフェスのうち１つはプライマリディスプレイとして扱われる。プライマリディスプレイと関連するビデオサーフェスに描くことによって、フィジカルディスプレイ上に可視的なグラフィックスがもたらされる。プライマリディスプレイ以外のビデオサーフェスに近づいても、そのサーフェスのコンテンツがプライマリディスプレイのビデオサーフェスに「ブリット（ｂｌｉｔｔｅｄ）」されない限り、眼に見えない。

「レイヤ」ハードウェアにより、グラフィックスカードは１つ以上のビデオサーフェスをプライマリディスプレイの一部として有することができる。様々なビデオサーフェスが結合および／または混合されることによりプライマリディスプレイを作製する方法は、グラフィックスカード上のレイヤハードウェアを介して設定することができる。レイヤハードウェアは、非破壊的にプライマリディスプレイをターゲットにした全てのサーフェスを結合する。すなわち、様々なビデオサーフェスのコンテンツは、レイヤリングハードウェアからの影響を受けず、ディスプレイデバイス上で可視的な最終結果のみが影響を受ける。これにより、自動車テレマティックスシステムといった高度なグラフィックスコンポジションを要求する低性能のプラットフォームに理想的なレイヤリングハードウェアを有するグラフィックスカードが作製され、例えば、道路地図上での換気システム（ｖｅｎｔｉｌａｔｉｏｎ ｓｙｓｔｅｍ）または再生中のビデオプログラミングの設定を表示することが所望され得る。

「自動車テレマティックスシステム」は、自動車内の環境システムとエンターテイメントシステムとを管理するためのコンピュータによる制御システムの技術を参照する。これらシステムは、自動車「インフォテインメント（ｉｎｆｏｔａｉｎｍｅｎｔ）」または「ｉｎｆｏｔｒｏｎｉｃ」システムとも呼ばれ、あるいは他の類似する名前で呼ばれる。そのようなシステムが管理し得る機能のうちいくつかには、以下のものが含まれる。
１．ラジオ放送、ビデオゲームおよび映画再生といったエンターテイメントアプリケーションをサポートすることであり、これらエンターテイメントアプリケーションは、乗り物内の異なるディスプレイ、スピーカーおよびヘッドフォンシステムに選択的に向けられ得る。
２．乗り物の環境制御システムを管理すること。
３．インターネットアクセス、電子メールおよびインスタントメッセージサービスを提供すること。
４．盗難防止および自動ダイヤルといったセキュリティシステムを提供すること。
５．パーソナルデジタルアシスタント（携帯情報端末）（ＰＤＡ）、ラップトップコンピュータおよびノートブックコンピュータといったポータブルコンピュータデバイスとインターフェースをとり、同期化すること。
６．正しい地図を選択し、乗り物の実際の位置を地図上で特定するためにＧＰＳ（グローバルポジショニングシステム）技術を用いて電子道路地図を表示する。また、この技術を用いることによって、近くのガソリンスタンド、レストランおよび他の施設をユーザにアドバイスし、交通情報、ナビゲーションアドバイスおよび駐車場の利用性を提供し得る。
７．ガソリンスタンドの「販売時点管理（ｐｏｉｎｔ ｏｆ ｓａｌｅ）」および関連の自動銀行業務と無線で情報のやり取りをすることであって、例えば、これにより、ユーザは実際に参加して交流しなくても、ガソリンを購入し、車を洗浄してもらい、かつ、映画をダウンロードすることができる（例えば、２００１年、サンマイクロシステムズ社による「Ｔｈｅ ｅＧａｓＳｔａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ − Ｊａｖａ（登録商標） Ｔｅｃｈｎｏｌｏｇｙ Ｂａｓｅｄ Ｍａｎａｇｅｄ Ｓｅｒｖｉｃｅｓ ｆｏｒ Ｒｅｔａｉｌ Ｓｅｒｖｉｃｅ Ｓｔａｔｉｏｎｓ」）。

このリストは、自動車テレマティックスシステムがサポートするよう設計され得たことのうちの僅かな例である。さらなるサービスがやがて、テレマティックスシステムによってサポートされることは確実であろう。

（既存のビデオシステム）
本技術におけるビデオシステムには２つの共通する設定がある。

１つのシステムにおいて、ソフトウェアアプリケーションは、グラフィックスカードのメモリおよびレジスタを直接操作することによりディスプレイに影響を与えるオペレーティングシステムのＡＰＩを用いて、イメージと、ベクトルと、文字とを描く。ソフトウェアアプリケーションは、オペレーティングシステムＡＰＩを使用するが、ソフトウェアアプリケーション自体は、ハードウェアを直接操作するグラフィックスドライバとして機能する。そのようなシステムでは、ハードウェアの競合（ｃｏｎｔｅｎｔｉｏｎ）問題があるために、一度にグラフィックスカードへのアクセスを有するのは、１つのソフトウェアアプリケーションのみである。

もう一方のシステムにおいて、ソフトウェアアプリケーションは、ドロー要求（ｄｒａｗ ｒｅｑｕｅｓｔ）をパッケージにして送信するオペレーティングシステムのＡＰＩを用いて描く。パッケージ化されたドロー要求が、オペレーティングシステムのＡＰＩを用いることにより、グラフィックスカードのメモリおよびレジスタを操作してディスプレイに影響を与えるソフトウェアアプリケーションに配信されると、それらドロー要求は、グラフィックスカードに提供され、可視的なディスプレイに影響を及ぼし得る。この設定において、ドローイングアプリケーションおよびグラフィックスドライバは、別個のソフトウェアプロセスであり、複数のアプリケーションが単一のグラフィックスカードを用いて描くことができるようにする。パッケージ化されたドロー要求を配信するメカニズムは、周知のウィンドウシステム内で様々である。

図１は、従来技術で周知のレイヤをサポートするグラフィックスカードの典型的な構造１０のブロック図を示す。ソフトウェアアプリケーション１２がイメージ、文字またはベクトルを表示画面１４に描くことを望む場合、「ドロー」要求をオペレーティングシステム１８のＡＰＩ１６に送信する。オペレーティングシステム１８は、ドロー要求を処理し、かつ、適切な指示をグラフィックスカード２０に送信する。これら指示は、オペレーティングシステムのＡＰＩ１６とグラフィックスカード２０のＡＰＩ２２とを介して送信される。オペレーティングシステム１８は、グラフィックスカード２０におけるハードウェアレイヤ２４に関する知識がないため、全てのドロー要求は、単に、同一のレイヤ、プライマリレイヤ２６にパスされていく。プライマリレイヤ２６内のビデオイメージは、その後、表示画面１４にパスされる。

ソフトウェアアプリケーション１２が、グラフィックスカード２０のＡＰＩ２２に関して特別な知識を有し、残りのシステムがそれを可能にする場合、次いで、ソフトウェアアプリケーション１２は、メッセージを直接グラフィックスカード２０へ、また、直接グラフィックスカード２０からパスすることにより、グラフィックスカード２０のメモリおよびレジスタを操作し得る（これは、上記の第１の方法である）。あるいは、オペレーティングシステム１８は、グラフィックスカード２０のＡＰＩ２２に関する特別な知識を有するグラフィックスドライバを有し、かつ、残りのシステムがそれを可能にする場合、次いで、オペレーティングシステム１８におけるグラフィックスドライバは、グラフィックスカード２０のレイヤ性能を操作し得る（これは、上記の第２の方法である）。

ビデオのハードウェアレイヤにアクセスして制御するＡＰＩは、第１に、レイヤをサポートするグラフィックスカードを製造していたグラフィックスカード製造者によって提供された。しかしながら、これら初期のＡＰＩに関して少なくとも２つの主要な問題があった。
１．異なる製品からのＡＰＩは、互いに類似性をあまり有さず、グラフィックスカードのレイヤフィーチャーにアクセスして制御するのに必要とされるソフトウェアアプリケーションは、１つの製品のグラフィックスカード上でのみ機能するということを意味する点と、
２．ウィンドウズ（登録商標）タイプのオペレーティングシステムがビデオのハードウェアレイヤの存在に完全に気付いていないため、レイヤは、オペレーティングシステムＡＰＩを介してアクセスされ得ないという点とが問題であった。

最近になって、ソフトウェアアプリケーションは、この特定のオペレーティングシステムＡＰＩを使用して、ハードウェアによってサポートされたレイヤを提供することが可能であることが依然として必要とされるが、ハードウェアレイヤリング性能への一貫しているが限られたインターフェースを提供するオペレーティングシステムＡＰＩが利用可能になった。この制限によって、第三者ソフトウェアをレイヤが可能なシステムに統合させることが不可能になった。言い換えると、この新しいオペレーティングシステムＡＰＩは、依然として、第三者ソフトウェアアプリケーションが、新しいオペレーティングシステムＡＰＩはハードウェアレイヤへのアクセスを有していることを知っていることと、それを使用する方法を知っていることとを要求する。典型的に、第三者ソフトウェアアプリケーションは、この知識を有していないため、これは「トランスペアレントな」解決策ではない。

１つのそのようなＡＰＩは、限られた方法でビデオレイヤ性能への包括的なアクセスを提供する「ＤｉｒｅｃｔＦＢ」のＡＰＩである。ＤｉｒｅｃｔＦＢは、サーフェスの専属的使用に限られ、ある程度は、プライマリディスプレイサーフェスを共有する能力を有する。

ソフトウェアアプリケーションがグラフィックスハードウェアレイヤへの直接アクセスを有することを可能にする既存のオペレーティングシステムＡＰＩは、一般的に、ハードウェアの競合問題があるために、そのレイヤが複数のソフトウェアアプリケーションによって共有されることを妨げる。

自動車市場、医用計測市場、消費市場、およびインダストリアルオートメーション市場において、グラフィックスソリューションへの需要が成長してきた。１つのプロジェクトより多くのプロジェクトをターゲットにした第三者ソフトウェアアプリケーションと、レガシーアプリケーションと、新しいソフトウェアアプリケーションとを使用することにより、選択されたグラフィックスハードウェアのレイヤリング性能を利用することが可能になる。

それ故、上で概要を説明した問題を扱うグラフィカルハードウェアレイヤを設定し、制御し、およびアクセスする（レンダリングする）統合的アプローチの必要性がある。選択されたアプローチは、目標市場の必要性を考慮に入れなければならない。つまり、自動車市場は、大きさと性能に非常にセンシティブであり、消費市場は、大きさと性能に非常にセンシティブであり、医用計測市場は、性能にセンシティブであり、インダストリアルオートメーションは、性能に非常にセンシティブであるということを考慮に入れなければならない。また、この設計は、実行速度、信頼性、複雑性およびスケーラビリティを考慮にいれて提供されねばならない。

それ故、従来技術の不利点のうち少なくとも１つを防ぐか、軽減するコンピュータファイル管理の新しい方法およびシステムを提供することが本発明の目的である。

（本発明の要旨）
本発明の１つの局面は、以下のように広く定義される。すなわち、ソフトウェアアプリケーションと、コンピュータ上で作動するオペレーティングシステムとを含むコンピュータ環境において、このコンピュータは、グラフィックスカードとビデオディスプレイとを備え、このグラフィックスカードは、イメージをビデオディスプレイに提供するように動作可能である。この改善には、グラフィックスカード上でハードウェアレイヤをサポートするユニバーサルアプリケーションプログラミングインターフェース（ＡＰＩ）を備えるオペレーティングシステムと、オペレーティングシステムは、ユニバーサルＡＰＩを介してドローイベントを受信し、どのハードウェアレイヤがグラフィックスカード上で利用可能であり、それらのパラメータが何であるかを決定し、グラフィックスカード上で利用可能なハードウェアレイヤのいずれかに選択的にドロー要求をレンダリングすることによってソフトウェアアプリケーションからのドロー要求に応答するように動作可能であり、コンピュータ環境により、ソフトウェアアプリケーションがグラフィックスカード上で利用可能なハードウェアレイヤを利用することが可能になることとが含まれる。

好ましい本発明の実施形態において、ウィンドウ環境およびレイヤハードウェアが、ビデオレイヤについて知らないソフトウェアアプリケーションが、実際に、レイヤにレンダリングすることができるように、すなわち、ソフトウェアアプリケーションが、ビデオレイヤＡＰＩを全く使用せずに、かつ、特別なドローコマンドを用いずに、レイヤにレンダリングされ得るように、設定されることを可能にするメカニズムが提供される。このメカニズムは、修正されないレガシーアプリケーションをレイヤのある環境で使用することを可能にする。

本発明は、さらに以下の手段を提供する。

（項目１）
コンピュータシステムにおけるビデオディスプレイを管理する方法であって、
該コンピュータシステムは、グラフィックスカードと、ビデオディスプレイと、オペレーティングシステムとを備え、
該コンピュータシステムは、ソフトウェアアプリケーションを作動するように動作可能であり、
該グラフィックスカードは、イメージを該ビデオディスプレイに提供するように動作可能であり、
該方法は、
グラフィックスカード上でハードウェアレイヤをサポートする該オペレーティングシステムのユニバーサルアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、該ソフトウェアアプリケーションからドローイベントを受信するステップと、
どのハードウェアレイヤが該グラフィックスカード上で利用可能であるのか決定し、かつ、それらのパラメータは何であるかを決定するステップと、
該オペレーティングシステムが、該グラフィックスカード上で該利用可能なハードウェアレイヤのうちの特定の１つに対応するビデオレイヤに選択的に該ドロー要求をレンダリングするステップと、
該グラフィックスカードが、該ビデオレイヤ上で、該ビデオディスプレイ上のディスプレイに該利用可能なハードウェアレイヤのうちの特定の１つにデータをマッピングするステップとを包含し、
該ソフトウェアアプリケーションは、ハードウェアレイヤの存在を知らずに、該グラフィックスカード上で利用可能なハードウェアレイヤを利用し得る、方法。

（項目２）
上記レンダリングするステップは、上記ドロー要求を特有のビデオレイヤにレンダリングすることによって、該特有のビデオレイヤの識別を含む該ドロー要求に応答するステップを包含する、項目１に記載の方法。

（項目３）
上記レンダリングするステップは、どのビデオレイヤに上記ドロー要求がレンダリングされるべきかを決定し、それに従って該ドロー要求をレンダリングすることによって特有のビデオレイヤを識別しない該ドロー要求に応答するステップを包含する、項目２に記載の方法。

（項目４）
上記決定するステップは、上記ドロー要求の幾何学およびドローセンシティブ領域の幾何学に従って、該ドロー要求が向けられるビデオレイヤを選択するステップを包含する、項目３に記載の方法。

（項目５）
上記グラフィックスカードは、非破壊的にビデオレイヤデータを格納するメモリを備える、項目３に記載の方法。

（項目６）
三次元Ｅｖｅｎｔ Ｓｐａｃｅを構築し、ドローイベントとソフトウェア領域とを管理する座標系を定義するステップであって、該ソフトウェア領域のそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内で平面領域として定義され、該ドローイベントのそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内でベクトルとして定義され、該ソフトウェア領域は、選択的に設定されることにより、該ソフトウェア領域中を通過するドローイベントに応答する、ステップをさらに包含する、項目５に記載の方法。

（項目７）
上記ドローイベントは、上記ビデオディスプレイ上にイメージ、ベクトルまたは文字を提示する要求を備える、項目６に記載の方法。

（項目８）
上記ソフトウェア領域のそれぞれは、上記三次元Ｅｖｅｎｔ Ｓｐａｃｅ内で大きさおよび位置的なパラメータを含む、項目７に記載の方法。

（項目９）
上記グラフィックドライバの大きさ（ｄｉｍｅｎｓｉｏｎ）は、フィジカルディスプレイの大きさに等しい、項目８に記載の方法。

（項目１０）
上記三次元Ｅｖｅｎｔ Ｓｐａｃｅにおけるルート領域の大きさは、上記ビデオディスプレイの大きさより大きく、ドロー要求がスクリーンを離れたコンテクストに提供されることを可能にする、項目８に記載の方法。

（項目１１）
上記コンピュータシステム上で作動する各ソフトウェアアプリケーションは、上記三次元Ｅｖｅｎｔ Ｓｐａｃｅにおける領域と関連付けられる、項目８に記載の方法。

（項目１２）
少なくとも１つの上記ソフトウェア領域は、上記グラフィックスカードに適切なグラフィックドライバである、項目１１に記載の方法。

（項目１３）
２つ以上の上記ソフトウェア領域はグラフィックドライバであり、該２つ以上のグラフィックドライバは、該ｓｐａｃｅ内で重複せず、該２つ以上のグラフィックドライバは、別個のグラフィックハードウェアレイヤと関連付けられる、項目１２に記載の方法。

（項目１４）
上記グラフィックスカード上で関連付けられたハードウェアレイヤのパラメータに従ってドライバ領域を生成するステップをさらに包含する、項目５に記載の方法。

（項目１５）
設定アプリケーションを用いて、ビデオサーフェスと、ドライバ領域と、レイヤ関連へのサーフェスと、レイヤ属性とを設定するステップをさらに包含する、項目５に記載の方法。

（項目１６）
ビデオディスプレイを管理する方法であって、
設定アプリケーションを用いて、ビデオサーフェスと、ドライバ領域と、レイヤ関連へのサーフェスと、レイヤ属性とを設定するステップであって、どのハードウェアレイヤがグラフィックスカード上で利用可能であるのか決定し、それらのパラメータは何であるかを決定するステップを包含する、ステップと、
オペレーティングシステムのユニバーサルＡＰＩを介して到達するドローイベントの受信に応答するステップであって、
ドロー要求が特有のビデオレイヤについて立てられる（ｆｌａｇｇｅｄ）かどうかを決定し、立てられる場合、該ドロー要求を該特有のビデオレイヤに向け、立てられない場合、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅにおいてドローイベントを処理することと、
該Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅが、少なくとも三次元を有し、複数のプログラムのオペレーティング環境を表すＥｖｅｎｔ Ｓｐａｃｅを定義することであって、該Ｅｖｅｎｔ Ｓｐａｃｅは、該Ｅｖｅｎｔ Ｓｐａｃｅの第１の端部にルート面を有しており、各セットの特徴は、大きさ特徴と位置特徴とを含み、該大きさ特徴は、該Ｅｖｅｎｔ Ｓｐａｃｅ内で平面領域の一組の大きさを示し、該位置特徴は、該Ｅｖｅｎｔ Ｓｐａｃｅ内で該平面領域の位置を該Ｅｖｅｎｔ Ｓｐａｃｅ内で少なくとも第２の平面領域と比較して示す、こととによって、応答するステップと、
該グラフィックスカードが、該ビデオレイヤ上で、該ビデオディスプレイ上のディスプレイに該利用可能なハードウェアレイヤのうちの特定の１つにデータをマッピングするステップと
を包含する、方法。

（項目１７）
上記設定するステップは、
設定アプリケーションによって行われるステップであって、
利用可能なハードウェアレイヤの数に対して、特定のディスプレイについてグラフィックスドライバをクエリーするステップと、
各ビデオレイヤの性能について、該グラフィックスドライバをクエリーするステップと、
所望された数のビデオサーフェスを生成するステップと、
該利用可能なハードウェアレイヤの数および性能に基づいて対応するレイヤを設定するステップと
を包含する、項目１６に記載の方法。

（項目１８）
ビデオサーフェスを特有のハードウェアレイヤと直接関連付けられるものと定義するステップをさらに包含する、項目に１７記載の方法。

（項目１９）
上記応答するステップは、
ソフトウェアアプリケーションプログラムから受信したイベントに応答するステップであって、第１のイベントシグナルは、イベントタイプと領域特性とを有しており、該領域特性は上記Ｅｖｅｎｔ Ｓｐａｃｅ内でイベント領域を定義する、ステップと、
該イベント領域が第１のプログラム領域と交差するかどうかを決定するステップであって、該第１のプログラム領域は、該Ｅｖｅｎｔ Ｓｐａｃｅ内で定義され、該第１のプログラムに対応し、交差すると決定される場合、
該第１のプログラムが該第１のイベントシグナルにセンシティブであるかどうか、該イベントタイプを検査することによって決定するステップであって、センシティブである場合、出力シグナルを該第１のプログラムに伝達し、該出力シグナルは該第１のイベントシグナルに対応する情報を含む、ステップと、
該第１のプログラムが該第１のイベントシグナルを修正することにあるかどうか、該イベントタイプを検査することによって決定するステップであって、修正することにある場合、該第１のプログラム領域を該イベント領域から切り抜くことによって、該領域特性を修正する、ステップと、
を行うステップと、
を包含する、項目１８に記載の方法。

（項目２０）
コンピュータシステムであって、
コンピュータと、
該コンピュータにインストールされたグラフィックスカードと、
該グラフィックスカードに電気的に接続されたビデオディスプレイと、
該コンピュータ上で作動するソフトウェアアプリケーションと、
該コンピュータ上で作動するオペレーティングシステムであって、該グラフィックスカード上でハードウェアレイヤをサポートするユニバーサルアプリケーションプログラミングインターフェース（ＡＰＩ）を備えるオペレーティングシステムと、
該オペレーティングシステムは、該ユニバーサルＡＰＩを介してドローイベントを受信し、どのハードウェアレイヤが該グラフィックスカード上で利用可能であるか、該ハードウェアレイヤのパラメータは何であるかを決定し、該ソフトウェアアプリケーションからのドロー要求に、該ドロー要求を該グラフィックスカード上で該利用可能なハードウェアレイヤのうち特定の１つに選択的にレンダリングすることによって応答するように、動作可能であり、
該ビデオディスプレイ上のディスプレイに該利用可能なハードウェアレイヤのうちの特定の１つに該ビデオレイヤ上でデータをマッピングするよう動作可能である該グラフィックスカードと
を備え、
該コンピュータ環境により、ソフトウェアアプリケーションが該グラフィックスカード上で利用可能なハードウェアレイヤを利用することが可能になる、コンピュータシステム。

（項目２１）
上記オペレーティングシステムは、ドロー要求を特有のハードウェアレイヤにレンダリングすることによって該特有のハードウェアレイヤの識別を含む該ドロー要求に応答するようにさらに動作可能である、項目２０に記載のコンピュータシステム。

（項目２２）
上記オペレーティングシステムは、
三次元Ｅｖｅｎｔ Ｓｐａｃｅを構築し、ドローイベントとソフトウェア領域とを管理する座標系を定義するようにさらに動作可能であり、
該ソフトウェア領域のそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内で平面領域として定義され、
該ドローイベントのそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内でベクトルとして定義され、
該ソフトウェア領域は、選択的に設定されることにより、該ソフトウェア領域中を通過するドローイベントに応答する、項目２０に記載のコンピュータシステム。

（項目２３）
上記オペレーティングシステムは、上記グラフィックスカード上でハードウェアレイヤと関連付けられるドライバ領域を生成するようにさらに動作可能である、項目２０に記載のコンピュータシステム。

（項目２４）
上記システム上で作動する各ソフトウェアアプリケーションは、上記ＰｈｏｔｏｎＥｖｅｎｔ Ｓｐａｃｅにおける領域と関連付けられる、項目２２に記載のコンピュータシステム。

（項目２５）
上記オペレーティングシステムは、関連したハードウェアレイヤのパラメータに従って、ドライバ領域を定義するようにさらに動作可能である、項目２０に記載のコンピュータシステム。
（摘要）
本発明は、一般的に、コンピュータグラフィックスに関し、より詳細には、単一のビデオディスプレイを構成するために用いられる複数のハードウェアグラフィックスレイヤを設定し、制御し、およびアクセスする方法とシステムとに関する。本発明の１つの局面は、以下のように広く定義される。すなわち、ソフトウェアアプリケーションと、コンピュータ上で作動するオペレーティングシステムとを含むコンピュータ環境において、このコンピュータは、グラフィックスカードとビデオディスプレイとを備え、このグラフィックスカードは、イメージをビデオディスプレイに提供するように動作可能である。この改善には、グラフィックスカード上でハードウェアレイヤをサポートするユニバーサルアプリケーションプログラミングインターフェース（ＡＰＩ）を備えるオペレーティングシステムと、オペレーティングシステムは、ユニバーサルＡＰＩを介してドローイベントを受信し、どのハードウェアレイヤがグラフィックスカード上で利用可能であり、それらのパラメータが何であるかを決定し、グラフィックスカード上で利用可能なハードウェアレイヤのいずれかに選択的にドロー要求をレンダリングすることによってソフトウェアアプリケーションからのドロー要求に応答するように動作可能であり、コンピュータ環境により、ソフトウェアアプリケーションがグラフィックスカード上で利用可能なハードウェアレイヤを利用することが可能になることとが含まれる。

一般的に言えば、本発明は、１．グラフィックスカード上のハードウェアレイヤをサポートするユニバーサルＡＰＩを有するオペレーティングシステムと、２．どのレイヤが使用中のグラフィックスカード上で利用可能であるかを決定し、それらレイヤのパラメータが何であるかを決定するオペレーティングシステムと、３．利用可能なビデオレイヤを活かすことによってソフトウェアアプリケーションからのドロー要求に反応するオペレーティングシステムとを提供することによる従来技術における問題を扱う。このシステムは、グラフィカルハードウェアレイヤを与えるためにフィーチャートランスペアレンシーを提供する。本発明の多数の実施形態は、ここに記載されるが、明らかに、本発明は、多くの異なる方法で実行され得る。図２のブロック図は、本発明を採用する典型的なシステムの概観を示す。

図２のブロック図は、図１のブロック図と対照され得る。図２の場合において、ソフトウェアアプリケーション３２が、イメージ、文字またはベクトルを表示画面１４に描くことを望む場合、ソフトウェアアプリケーション３２は、利用可能なレイヤサポートに関する知識を有し得るかもしれないし、有し得ないかもしれない。よって、システム３０は、オペレーティングシステム３６のＡＰＩ３４に対する２つの異なるタイプのドロー要求をサポートする。すなわち、ハードウェアレイヤ情報を含む要求３８と、含まない要求４０とをサポートする。

本発明のオペレーティングシステム３６は、ビデオサーフェス（レイヤに関連付けられ得る）３８へターゲットするドロー要求をサポートするＡＰＩ３４を有するが、ターゲットしないドローもまたサポートする。レガシーな第三者ソフトウェアアプリケーションをサポートするために、オペレーティングシステム３６は、従来の方法で、レイヤのないタイプの要求４０を操作しなければならない。あるいは、２つの種類のドローＡＰＩが定義され得る。すなわち、ターゲットせず、それによりレイヤのない有能なＡＰＩを提供する従来のＡＰＩと、ビデオサーフェスと、レイヤとへの直接アクセスを提供するサーフェスまたはレイヤドローＡＰＩとが定義され得る。

オペレーティングシステム３６は、また、どのレイヤがグラフィックスカード２０上で利用可能であるかを決定する手段をも有する。この知識は、例えば、システムインストレーションの一環としてそれぞれを起動する（ｏｎ ｅａｃｈ ｂｏｏｔ−ｕｐ）、またはハードコーディング（ｈａｒｄ−ｃｏｄｉｎｇ）するといった様々な方法で、グラフィックスカード２０からオペレーティングシステム３６へ転送され得る。オペレーティングシステム３６は、典型的に、グラフィックスカードといった出力デバイスに特有のソフトウェア「ドライバ」を備えるように設計される。ユーザが新しいグラフィックスカードをインストールするとき、インストレーション手順の一部に、グラフィックスカードドライバをシステム上にロードすることが含まれる。これらドライバは、一般的に、特定のオペレーティングシステム、およびグラフィックスカードの構成およびモデルに特異的である。ドライバはしばしば、ＣＤ−Ｒｏｍ上のグラフィックスカードとともに流通されるが、一般的にオンラインでも利用可能である。

本発明は、図１に関して記載されたグラフィックスカード２０およびディスプレイ１４への変更を必要としないことを留意されたい。ソフトウェアアプリケーション３２もまた、利用可能なレイヤと、あるビデオハードウェアレイヤが使用されることを要求する能力とに関する知識を有さない場合、ソフトウェアアプリケーション１２と同じであり得る。

ドロー要求を受信し次第、オペレーティングシステム３６は、この要求を処理し、オペレーティングシステム３６のＡＰＩ３４およびグラフィックスカード２０のＡＰＩ２２を介して、適切な指示をグラフィックスカード２０に送信する。オペレーティングシステム３６が、グラフィックスカード２０におけるハードウェアレイヤ２４に関する知識を有さない図１のシステムとは異なって、本発明の場合におけるオペレーティングシステム３６は、ハードウェアレイヤ２４に関する知識を有しており、また、グラフィックスカード２０のＡＰＩを補完するＡＰＩ３４内にドライバを有する。よって、ドロー要求は、オペレーティングシステム３６によって決定されたレイヤに向けられ、場合によっては、このビデオハードウェアレイヤは、イメージ、文字またはベクトルを描くことを望んで、ソフトウェアアプリケーション３２によって決定されるが、別の場合では、放出されたイベントの幾何学、ドローセンシティブ（ｄｒａｗ ｓｅｎｓｉｔｉｖｅ）領域の幾何学およびデータの優先順位を用いて、オペレーティングシステム３６自体が決定する。これにより、どのエレメントが位置的にどの領域に配信されるのか制御することが可能になる。

典型的な例は、例えば、ビデオサーフェスよりも優先するレイヤと関連する領域下に位置的に生じる警戒レンダリングを有しており、この警戒が他のコンテンツ、気候データまたは複合ディスプレイに表示されている映画の全てで可視的であることを確実にする。

イメージのこれらレイヤは全て個別に、グラフィックスカード２０上に格納され、非破壊的に、単一の複合イメージ内に構成される。複合ビデオイメージはその後、上映するために、グラフィックスカード２０によって表示画面１４に送信される。

本発明のシステムは、下にあるハードウェアレイヤに関する知識を有するかどうかに関わらず、グラフィックスカードハードウェアレイヤが任意の第三者アプリケーションソフトウェアによって利用されることを可能にする。本発明のシステムはまた、均一なインターフェースを提供し、その結果、ソフトウェアアプリケーションは、特定のグラフィックスカードの細部を認識していなくてもよい。本発明の他の利点は、以下に続く本発明のさらに詳細な説明から明らかになる。

好ましい本発明の実施形態は、本発明は実質的にはいずれのオペレーティングシステム上でも実施され得るが、ＱＮＸ（登録商標） ＲＴＯＳ（リアルタイムオペレーティングシステム）上で起動するＰｈｏｔｏｎ（登録商標）ウィンドウシステムに関して説明される。本発明を他のオペレーティングシステムに適用するのに必要な変形は、本明細の説明から当業者にとって明らかである。

本発明の実施形態において、Ｐｈｏｔｏｎ Ｅｖｅｎｔ ｓｐａｃｅおよびＱＮＸオペレーティングシステム環境５０を象徴的に視覚化したものが図３に示される。

ＱＮＸオペレーティングシステムは、「メッセージパッシングオペレーティングシステム」である。これは、ソフトウェアアプリケーションと、オペレーティングシステム自体と、ウィンドウズ（登録商標）ＧＵＩ（グラフィックユーザインターフェース）ソフトウェアとを含むソフトウェアの全てが、システム上で別個のソフトウェアプロセスとして作動することを意味する。これらソフトウェアプロセスは、図３のセクション５２におけるブロックで描かれる。メッセージパッシングは、これらソフトウェアプロセス間におけるプロセス間通信（ＩＰＣ）の基本的な手段である。メッセージは、特別な意味がメッセージのコンテンツに付随せずに、１つのプロセスから他のプロセスへパスされるバイトのパケットである。メッセージにおけるデータは、メッセージの送信器とその受信器とにとって意味を有するが、一般的に他にはどれに対しても意味を有さない。

Ｐｈｏｔｏｎ環境５０は、三次元仮想「Ｅｖｅｎｔ Ｓｐａｃｅ」５４を提供し、ここで、ユーザ６０は、見ているこの空間の外側にいるように想像され得る。Ｐｈｏｔｏｎ環境５０は、アプリケーションプログラムが所有する「領域」を管理し、様々な「イベント」がこのＥｖｅｎｔ Ｓｐａｃｅ５４における領域を流れるので、このイベントを切り抜くこと（ｃｌｉｐｐｉｎｇ）と操縦することとを行うためだけに、自身を限定する。ソフトウェアアプリケーションは、このＥｖｅｎｔ Ｓｐａｃｅ５４内に、パスされ得る様々なタイプのイベントにセンシティブ（敏感）な領域、または、不透明な領域、もしくはセンシティブで不透明な領域を置くことができる。

ソフトウェアアプリケーションは、それぞれのソフトウェアプロセス自身が所有するこれら長方形の領域のうち１つ以上からＰｈｏｔｏｎ環境５０に影響を及ぼし得る。例えば、特定のＰｈｏｔｏｎアプリケーション５６は、領域５８を生成し得る。領域は、イベントと呼ばれるオブジェクトを放出し、かつ収集し得る。これらイベントは、Ｅｖｅｎｔ Ｓｐａｃｅ５４を介していずれの方向にも（すなわち、ユーザ６０に向けて、または、ユーザ６０から離れて）動くことができる。イベントがＥｖｅｎｔ Ｓｐａｃｅ５４中を移動するにつれて、イベントは他の領域と情報のやり取りをする。これは、ソフトウェアアプリケーションが互いに情報のやり取りをする方法である。領域は固定されているが、イベントはＥｖｅｎｔ Ｓｐａｃｅ５４中を移動する。

イベントがＥｖｅｎｔ Ｓｐａｃｅ５４中を流れるにつれて、その長方形セットは、他のソフトウェアプロセスによって、Ｅｖｅｎｔ Ｓｐａｃｅ５４内に置かれた領域と交差する。これが生じると、オペレーティングシステムは、イベントが交差される領域の属性に従って、イベントの長方形セットを調整する。

イベントは、様々な種類で現れ、様々な属性を有する。イベントは、発生領域、タイプ、方向、添付の長方形のリスト、および任意で、あるイベント特定のデータによって定義される。
・ キーを押すこと、キーボード状態情報と、
・ マウスボタンを押すことおよび放すことと、
・ （マウスボタンを押して、または押さずに）ポインタの動きと、
・ 領域境界交差と、
・ 露出された領域または覆われた領域と、
・ ドラッグ動作と、
・ドロー機能と
を表すために、イベントが用いられる。

グラフィックスドライバ６４の通常動作は、フィジカルディスプレイデバイス１４と同じ大きさと、イベントへの感度とによって、ＰｈｏｔｏｎのＥｖｅｎｔ Ｓｐａｃｅ５４に領域を生成することである。ドローイベント（例えば、出力イベント６６）をグラフィックスドライバ領域下のエリアから放出する任意のソフトウェアアプリケーションは、そのイベントにグラフィックスドライバの領域と交差させ、かつ、イベントのデータは、グラフィックスドライバに配信される。グラフィックスドライバ６４は、ドローイベント（ｐｈｏｔｏｎドローストリーム）からのデータを用いて、所望のグラフィックスをビデオハードウェア２０と、フィジカルディスプレイデバイス１４上とに提供する。

領域は、イベントが領域と交差するときに、イベントがどのように処理されるのかを制御する２つの属性、すなわち、感度および不透明度を有する。領域が、特定のタイプのイベントにセンシティブであると、次いで、領域の所有者が領域と交差するそのタイプのイベントの一部を収集する。感度の属性は、イベントの長方形セットを改変せず、また、Ｅｖｅｎｔ Ｓｐａｃｅ中を流れ続けるイベントの能力に影響を及ぼさない。特有のイベントタイプに不透明な領域は、そのタイプのイベントの長方形セットの部分がさらにＥｖｅｎｔ Ｓｐａｃｅにおいて動くことを妨げる。領域がイベントタイプに不透明である場合、領域と交差するそのタイプのいずれかのイベントは、交差エリアを切り抜くように調整された長方形セットを有する。イベントが完全に不透明な領域の交差点によって切り抜かれる場合、ドローイベントは消滅する。

以下の表は、領域の属性がどのように領域と交差するイベントに影響を及ぼすのかをまとめたものである。

Ｅｖｅｎｔ Ｓｐａｃｅ全体に領域を置くことによって、プロセスは、その領域を通過する任意のイベントをインターセプトし、かつ修正することができる。領域がセンシティブ（敏感）かつ不透明である場合、イベントの修正版を再度放出することを選ぶことができる。

ルート領域６２と呼ばれる特別な領域は、常に、ユーザ６０から最も離れた領域である。全ての他の領域は、何らかの方法で、ルート領域６２から伝わったものである。ユーザ６０から離れて動くイベントがルート領域６２に到達するとすぐに、そのイベントは消滅する。

本発明は、この概念を広げることにより、ソフトウェアアプリケーションがＰｈｏｔｏｎのＥｖｅｎｔ Ｓｐａｃｅにおいて具現しない「スクリーンを離れたコンテクスト」または「ビデオサーフェス」にレンダリングされることを可能にする。これを達成するために、ビデオサーフェスが生成された時にグラフィックスドライバから提供された識別子は、そのビデオサーフェスを独自に識別するドローストリーム内に挿入される。グラフィックスドライバは、その後、識別されたビデオサーフェス内に直接ドロー要求を与える。

言い換えると、ソフトウェアアプリケーションは、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ５４において出力イベントを放出するソフトウェアプロセスを開始し得る。この出力イベントは、出力イベントが向けられているのはどのビデオレイヤかを示す識別子を含み得る。グラフィックスドライバは、そのサーフェス内に与えるためにビデオサーフェス識別子を含む、要求されたビデオサーフェスを生成することによって、識別子の存在に応答する。

特有のビデオサーフェスをターゲットにするドローストリームを含むイベントは、グラフィックスドライバの領域に直接放出され得る。言い換えると、特定のビデオサーフェスをターゲットにしたドローストリームは、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ５４中を動かずにグラフィックスドライバに直接与えられ得、ドローイベントの長方形のうちの一部、または全てをブロックする領域の可能性を排除する。

ハードウェアレイヤへのトランスペアレントなアクセスを提供するために、２つの考えが混合された。
１．グラフィックスドライバが、ビデオサーフェスに与えられたその領域上で収集されたドローストリームを有するＰｈｏｔｏｎのＥｖｅｎｔ Ｓｐａｃｅ５４にドライバ領域を生成する機能が加えられた（すなわち、ドライバ領域はコレクターのように機能し、その感度と一致するイベントはグラフィックスドライバに配信される）。
２．スクリーンを離れたコンテクストまたはビデオサーフェスをグラフィックスカード上のレイヤハードウェアに関連付ける能力もまた加えられた。

ＡＰＩを提供し、かつ、ソフトウェアアプリケーションが、利用可能なハードウェアレイヤの数をクエリーすることと、どの性能を各ハードウェアレイヤがサポートするのかを決定することと、ハードウェアレイヤによって課された制限に一致するスクリーンを離れたコンテクスト／ビデオサーフェスを生成することと、ドライバ領域がそのサーフェスをターゲットにするＰｈｏｔｏｎ ｓｐａｃｅに生成されることを要求することと、最後に、サーフェスをレイヤリングハードウェアの一面に関連付けて、レイヤリングハードウェアの性能を設定することとを可能にするドライバをサポートすることによって、任意のソフトウェアアプリケーションは、いかなる方法でもソフトウェアアプリケーションを修正する必要がなく、かつ、ビデオハードウェアレイヤが存在することを知っていても、ソフトウェアアプリケーションなしで、レイヤへのアクセスを与えられ得る。

設定アプリケーションは、ビデオサーフェスと、ドライバ領域と、レイヤ関連へのサーフェスと、レイヤ属性とを設定する。設定されるとすぐに、設定アプリケーションが要求されるドライバ領域の下に位置づけられる任意のソフトウェアアプリケーションは、そのドライバ領域がターゲットにするサーフェスにレンダリングされ、続いて、レイヤリングハードウェアを介してプライマリディスプレイにレンダリングされる。

図４は、この概念の例示的なグラフィック図を示す。
・ レイヤは、レイヤが関連付けられるビデオサーフェスのコンテンツをプライマリディスプレイに複合する（ビデオサーフェスは、システムのオペレーティングシステム側で管理されるソフトウェアエンティティである一方で、レイヤは、グラフィックスカード上のファームウェアエンティティであることを思い起こす）ことと、
・ ビデオサーフェスは、レイヤと関連付けられるかもしれないし、関連付けられないかもしれないことと、
・ ソフトウェアアプリケーションは、特定のビデオサーフェスをターゲットにしたドローストリームまたは複数のビデオサーフェスの存在を無視するドローストリームを放出し得ることと、
・ ドローが特有のビデオサーフェスをターゲットにしていない場合、イベントは、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ中を流れ、イベントが交差するドローにセンシティブな任意の領域によって収集されることと、
・ ドローが特有のビデオサーフェスをターゲットにしている場合、ドローイベントは、ターゲットにされたビデオサーフェスを所有するドライバによって生成された領域に直接配信され、他の領域はドローイベントをブロックしたり、もしくは修正することができるＰｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅを介して、通常のイベント伝達をバイパスすることと
に留意する。

複数のドライバ領域は、プライマリディスプレイと関連する１つのビデオサーフェス以外のビデオサーフェスをターゲットにする単一のドライバによってＰｈｏｔｏｎのＥｖｅｎｔ Ｓｐａｃｅ内に置かれ得る。これは実質的に、ドローが最終的にどこに行くのかを知っているソフトウェアアプリケーションなしで、その領域下のソフトウェアアプリケーションが、ドライバ領域が関連付けられるビデオサーフェスにレンダリングされることを引き起こす。

そのような領域が、レイヤと関連付けられるビデオサーフェスをターゲットにする場合、ドライバ領域下のソフトウェアアプリケーションからのドローコマンドは、ビデオサーフェスにレンダリングされ、かつ、レイヤによって複合される。

よって、ソフトウェアアプリケーションは、レイヤに明白にレンダリングされず、それらは、Ｐｈｏｔｏｎ ｓｐａｃｅを介してドローを捕まえるものならどれにでもレンダリングされるか、特有のビデオサーフェスにレンダリングされる。ビデオサーフェスがレイヤと関連していたという事実により、ソフトウェアアプリケーションが描くときに使用するコマンド／ＡＰＩはもたらされない。

図４において、ソフトウェアアプリケーションＡＰＰ １は、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０を介して描いている。そのドローは、図らずも、プライマリディスプレイ（グラフィックスカード上で最上位のハードウェアレイヤ）と関連付けられるビデオサーフェス８４をターゲットにするドライバ領域８２と交差する。すなわち、ビデオドライバ９４が領域８２から受信する任意のドローイベントは、サーフェス８４にレンダリングされる。

ソフトウェアアプリケーションＡＰＰ ２は、ＡＰＰ １と同じ方法で描くが、そのドローは、ビデオサーフェス８８をターゲットにしているか、もしくはビデオサーフェス８８と関連するドライバ領域８６と交差する。このビデオサーフェス８８は、グラフィックスカード上の別のレイヤと関連付けられる。

ソフトウェアアプリケーションＡＰＰ ３は、アプリケーションＡＰＰ １およびＡＰＰ ２と同じドローイングＡＰＩを用いて描くが、ＡＰＰ ３は、そのドローターゲットを意図的にビデオサーフェス９０に設定している。この用いられたメカニズムは、プライマリサーフェス領域に直接送信されたＡＰＰ ３のドローストリームを有する。ドローストリームは、このドローストリームがこの場合においてビデオサーフェス９０にレンダリングされるべきであることをイベントのコレクター、グラフィックスドライバに通知する識別子を有する。図４において、ビデオサーフェス９０は、第３のレイヤと関連付けられる。

ここでも再び、ソフトウェアアプリケーションは、ビデオサーフェスにレンダリングされるのであって、特にグラフィックスカード上のレイヤにレンダリングされるのではないことを注記する。ビデオサーフェス８８および９０は、容易にレイヤ関連を全く有さないこともあり得る。その場合に見られるそれらサーフェスのコンテンツについて、ビデオサーフェス８４に関連付けられるレイヤにブリットされねばならない。

グラフィックスカード上のレイヤハードウェア９２は、ビデオサーフェス８４、８８、９０を操作し、かつ、それらをグラフィックス情報ルート内に引っ張り、フィジカルディスプレイデバイス１４上で見られる複合ディスプレイを生成する。ビデオサーフェス８４、８８、９０は、単に、従来技術において周知の通り、ビデオハードウェアのビデオメモリ９６における定義された領域である。

よって、第三者ソフトウェアアプリケーションのソフトウェアプロセスによって生成されたドロー指示は、これらビデオサーフェス８４、８８、９０のいずれかに位置づけられ得、かつそれに従って処理される。

好ましい本発明の実施形態において、図４に示されるＰｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅにおけるビデオレイヤおよびグラフィックドライバ領域の設定は、「設定アプリケーション」と呼ばれる別個のソフトウェアプロセスによって生成される。この設定アプリケーションは、例えば、図５のフローチャートに示される工程を行うことにより、この環境を設定し得る。

ステップ１００において、設定アプリケーションは、利用可能なハードウェアレイヤの数に対して、特定のフィジカルディスプレイデバイス１４についてグラフィックスドライバをクエリーする。グラフィックスドライバは、特定のグラフィックスカード２０への専用であるが、レイヤサポートを有する全てのＰｈｏｔｏｎドライバは、レイヤハードウェアのクエリーおよび制御のための同一のインターフェースを有する。

設定アプリケーションは、その後、各ビデオレイヤの性能について、ステップ１０２においてグラフィックスドライバをクエリーする。この情報は、各ビデオレイヤの大きさ、カラー数、大きさ（ｄｉｍｅｎｓｉｏｎ）、解像度、スケール係数、仮想大きさの限界、クロマキー、アルファブレンディング性能といったパラメータと、特有の環境毎に他のパラメータとを含む。

グラフィックスドライバからこの情報を装備して、設定アプリケーションは、その後、ステップ１０４において、要求された数のビデオサーフェス（Ｐｈｏｔｏｎで「スクリーンを離れたコンテクスト」と呼ばれる）を生成し、ステップ１０６において、利用可能なハードウェアレイヤの数と性能とに基づいて対応するレイヤを設定する。

設定アプリケーションは、その後任意で、ステップ１０８において、それらドライバ領域をＰｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０内に置く。Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０に全てのドライバ領域を置くことを所望されない可能性もあるので、このステップは任意である（ビデオサーフェスについてｐｈｏｔｏｎ ｓｐａｃｅ内のドライバ領域の欠如は、そのサーフェスにレンダリングされることを特に意図していないソフトウェアアプリケーションが不注意にレンダリングされることを防ぐ）。上記のように、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０を通過する必要なく、特定のビデオレイヤに直接いくつかのドロー要求を送信することが所望され得、あるドロー要求が他の領域によって修正またはブロックされる可能性を避ける。

例えば、レイヤを設定してアラーム状態をユーザに提示することが所望され得る。このレイヤは、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０の外で設定されて、これらアラーム状態がとにかくユーザ６０に提示されることを保障し得る。

この時点で、システムは、グラフィックスカードのハードウェアレイヤの性能を利用するよう設定される。

設定アプリケーションは、その後、終了し得、上記のように設定されたＰｈｏｔｏｎシステムを残す。レイヤと関連するビデオサーフェスをターゲットにしたグラフィックドライバ領域の下に位置づけられる任意の第三者ソフトウェアアプリケーションは、実質的にそのレイヤにレンダリングされる。第三者ソフトウェアアプリケーションは、レイヤが存在していることさえも知る必要がないので、マルチレイヤシステムにおいてレンダリングされる修正は一切必要ない。

この時点で、レイヤと関連するビデオサーフェスに接続されるドライバ領域の下からレンダリングする任意のアプリケーションは、そのレイヤ内にレンダリングされ、かつ、ハードウェアは、レイヤ属性の設定に基づいて最終的なディスプレイ内へのレンダリングの結果を複合する。

ビデオサーフェスに接続されるドライバ領域の下からレンダリングする任意のソフトウェアアプリケーションは、そのビデオサーフェス内にレンダリングされることを留意されたい。必ずしも、ビデオサーフェスはレイヤリングハードウェアにも接続されるということはない。例えば、スクリーンセイバーは、ドライバ領域が１０２４,７６８〜２０４７,１５３５において生成されることを要求し得、およびその領域を０,０において操作および表示するビデオサーフェスに関連付け得る。その結果は、コンソール５上のソフトウェアアプリケーションからのコンテンツを使用するスクリーンセイバーであり、解像度を１０２４×７６８と仮定してそのディスプレイを生成する。

Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅにおけるデフォルトウィンドウマネージャ配置が図６に示される。ディスプレイフレームワークは、「コンソール」からなり、コンソール５は、コンソール１から右側に１つ、下側に１つ目のコンソールである。

システムが設定されるとすぐに、ドロー要求は、図７のフローチャートに提示される方法で処理され得る。このフローチャートは、実際のソフトウェアコードがどのように構成されるのかを表すものとは対照的に、プロセスの流れを表示するために簡易化されている。例えば、オペレーティングシステムの現実の実施は、一般的に、ステップ１２０に関して示される「ｎｏ」ループを含まない。オペレーティングシステムは一般的に、応答待ちする処理ループにいるよりもむしろ、インタラプトの到着、関数呼出しの発行、または、周期的なポーリングへの応答に対応する。しかしながら、本発明の実際のソフトウェアコード実施は、この単純化した方法で、本発明の説明から当業者にとって明らかである。

ドローイベントがステップ１２０において受信されると、あるいは同様に、イメージ、ベクトルまたは文字をフィジカルディスプレイに提供する任意の要求が受信されると、制御がステップ１２２にパスされる。ステップ１２２において、ルーチンは、特有のビデオハードウェアレイヤにドロー要求が出されるかどうかを決定する。出さない場合、次いで、ステップ１２４毎に、ドローイベントがＰｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０を介して送信される。そのようなイベントは、ステップ１２５において、その後、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０内の領域に配信される。ドローイベントが割り当てられる領域を決定することが、ドローイベントのソースの幾何学によって決定される。上記したように、例えば、ビデオイメージより高い優先順位を有する領域にアラームディスプレイを送信することが所望され得る。実際、一般的なレイヤを成すインターフェースを実行するために、サーフェス／レイヤドローイベントが影響を及ぼして終了することを制御可能であることは、必要である。

ステップ１２２で識別されるドローイベントが特有のビデオサーフェスに向けられるものである場合、次いで、放出（ｅｍｉｔｔｅｒ）領域からＰｈｏｔｏｎ ｓｐａｃｅ中を動かなくてもグラフィック領域に直接パスされる。図５のステップ１０８に関して上記したように、いくつかのドロー要求を特定のハードウェアレイヤに直接パスすることが所望され得、よって、ドロー要求が別の領域によってブロックまたは修正される可能性を避ける。ドロー要求がＰｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０に意図される場合、次いで、制御はステップ１２４にパスされる。他方で、ドロー要求がハードウェアレイヤに直接行くことが意図される場合、制御はステップ１３０にパスされる。

ステップ１３２において、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０の全体が図３および図４に関して記載されたように処理される。これにより、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０内で処理され、場合によっては１つ以上のグラフィックドライバ領域上に与えられるドローイベントがもたらされる。

これらグラフィックドライバ領域は、ステップ１３４において、特定のビデオハードウェアレイヤと関連付けられているので、それらビデオハードウェアレイヤ上に与えられる。ドローイベントがステップ１３０にパスされた場合、次いで、単純に、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅ８０におけるドライバ領域に直接放出され、ドローのソースとドライバ領域との間の全ての介在する領域を、ドローソースの幾何学または受信するドライバ領域を問わずにバイパスする。ドローは、その後、所望のハードウェアレイヤ１３４に提供される。

ステップ１３６において、ビデオハードウェアレイヤがその後、グラフィックスカードによって処理され、フィジカル表示画面上に提示される。制御はその後ステップ１２０に戻り、さらなるドローイベントの到達を待ち受ける。

そのような方法で構成されたシステムにより、第三者ソフトウェアアプリケーションは、グラフィックスカードにおけるビデオハードウェアレイヤサポートを利用することが、そのようなハードウェアレイヤが存在していることすら気づかずに可能である。そのようなシステムにより、例えば、ｐｉｐ（ピクチャーインピクチャー）ウィンドウで、テレビディスプレイがコンピュータディスプレイまたは電子メールをサポートできるようになった。電子メールフィーチャーは、（スポーツイベント中のスコアを不明瞭にし過ぎないように）テレビが別個のレイヤ上で表示して、電子メールアプリケーションのユーザ設定可能なトランスペアレンシー制御を可能にする標準的な電子メールアプリケーションであり得る。同様に、スタンドアロンマッピングアプリケーションは、１つのレイヤ上に置かれ得、自動車情報（旅行コンピュータ情報、ｈｖａｃ設定等）は、システムのマイクロプロセッサに与える影響を最小限にして地図上で表示され得る。

本発明の特定の実施形態が図示され、かつ説明されてきたが、本発明の真の範囲および精神から逸脱せずに、改変および修正がそのような実施形態にされ得ることは明らかである。

本発明の方法ステップは、オブジェクトコードまたはソースコードといった様々なフォーマットで格納された実行可能な機械コードの実施形態であり得る。そのようなコードは、単純化するために、ここでは包括的にプログラミングコードまたはソフトウェアコードと記載される。明らかに、実行可能な機械コードは、他のプログラムのコードと統合され得、外部のプログラムコールによって、あるいは、従来技術で周知の他の技術によって、サブルーチンとして実行される。

本発明の実施形態は、コンピュータプロセッサ、または、方法ステップの方法でプログラムされた類似のデバイスによって実施され得、あるいは、これらステップを実施する手段を提供される電子システムによって実施され得る。マイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、マイクロコントローラ、および特定用途向け集積回路（ＡＳＩＣ）は、そのような実施が可能であるデバイスの典型的な例である。同様に、コンピュータディスケット、ＣＤ−Ｒｏｍ、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）あるいは、周知の類似するコンピュータソフトウェア記憶媒体といった電子メモリメディアは、本発明の方法を行うのに要求されるソフトウェアコードを格納するために使用されえる。その上、これら方法ステップを表す電気信号もまた、通信ネットワークを介して伝達され得る。

従来技術で周知のレイヤをサポートするビデオレイヤを有するコンピュータシステムのブロック図を示す。 本発明の実施形態において、レイヤをサポートするビデオを有するコンピュータシステムのブロック図を示す。 本発明の実施形態において、Ｐｈｏｔｏｎ（登録商標）Ｅｖｅｎｔ ＳｐａｃｅおよびＱＮＸ（登録商標）オペレーティングシステム環境を象徴的に視覚化したものを示す。 本発明の実施形態において、ビデオハードウェアレイヤ管理をサポートする修正されたＰｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅを象徴的に視覚化したものを示す。 本発明の実施形態において、ビデオレイヤサポートを設定する方法のフローチャートを示す。 本発明の実施形態において、デフォルトウィンドウマネージャコンソール配置の図を示す。 本発明の実施形態において、ドローイベントを操作する方法のフローチャートを示す。

符号の説明

１４ ディスプレイ
２０ ビデオカード
２２ ビデオカードＡＰＩ
２４ レイヤ
３０ システム
３２ ソフトウェアアプリケーション
３４ レイヤを有するＡＰＩ
３６ オペレーティングシステム
６０ ユーザ
６２ ルート領域
６４ グラフィックスドライバ
６６ 出力イベント
９２ ハードウェアレイヤ
９４ ビデオドライバ
９６ ビデオメモリ

Claims (25)

1. コンピュータシステムにおけるビデオディスプレイを管理する方法であって、
   該コンピュータシステムは、グラフィックスカードと、ビデオディスプレイと、オペレーティングシステムとを備え、
   該コンピュータシステムは、ソフトウェアアプリケーションを作動するように動作可能であり、
   該グラフィックスカードは、イメージを該ビデオディスプレイに提供するように動作可能であり、
   該方法は、
   グラフィックスカード上でハードウェアレイヤをサポートする該オペレーティングシステムのユニバーサルアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、該ソフトウェアアプリケーションからドローイベントを受信するステップと、
   どのハードウェアレイヤが該グラフィックスカード上で利用可能であるのか決定し、かつ、それらのパラメータは何であるかを決定するステップと、
   該オペレーティングシステムが、該グラフィックスカード上で該利用可能なハードウェアレイヤのうちの特定の１つに対応するビデオレイヤに選択的に該ドロー要求をレンダリングするステップと、
   該グラフィックスカードが、該ビデオレイヤ上で、該ビデオディスプレイ上のディスプレイに該利用可能なハードウェアレイヤのうちの特定の１つにデータをマッピングするステップとを包含し、
   該ソフトウェアアプリケーションは、ハードウェアレイヤの存在を知らずに、該グラフィックスカード上で利用可能なハードウェアレイヤを利用し得る、方法。
2. 前記レンダリングするステップは、前記ドロー要求を特有のビデオレイヤにレンダリングすることによって、該特有のビデオレイヤの識別を含む該ドロー要求に応答するステップを包含する、請求項１に記載の方法。
3. 前記レンダリングするステップは、どのビデオレイヤに前記ドロー要求がレンダリングされるべきかを決定し、それに従って該ドロー要求をレンダリングすることによって特有のビデオレイヤを識別しない該ドロー要求に応答するステップを包含する、請求項２に記載の方法。
4. 前記決定するステップは、前記ドロー要求の幾何学およびドローセンシティブ領域の幾何学に従って、該ドロー要求が向けられるビデオレイヤを選択するステップを包含する、請求項３に記載の方法。
5. 前記グラフィックスカードは、非破壊的にビデオレイヤデータを格納するメモリを備える、請求項３に記載の方法。
6. 三次元Ｅｖｅｎｔ Ｓｐａｃｅを構築し、ドローイベントとソフトウェア領域とを管理する座標系を定義するステップであって、該ソフトウェア領域のそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内で平面領域として定義され、該ドローイベントのそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内でベクトルとして定義され、該ソフトウェア領域は、選択的に設定されることにより、該ソフトウェア領域中を通過するドローイベントに応答する、ステップをさらに包含する、請求項５に記載の方法。
7. 前記ドローイベントは、前記ビデオディスプレイ上にイメージ、ベクトルまたは文字を提示する要求を備える、請求項６に記載の方法。
8. 前記ソフトウェア領域のそれぞれは、前記三次元Ｅｖｅｎｔ Ｓｐａｃｅ内で大きさおよび位置的なパラメータを含む、請求項７に記載の方法。
9. 前記グラフィックドライバの大きさは、フィジカルディスプレイの大きさに等しい、請求項８に記載の方法。
10. 前記三次元Ｅｖｅｎｔ Ｓｐａｃｅにおけるルート領域の大きさは、前記ビデオディスプレイの大きさより大きく、ドロー要求がスクリーンを離れたコンテクストに提供されることを可能にする、請求項８に記載の方法。
11. 前記コンピュータシステム上で作動する各ソフトウェアアプリケーションは、前記三次元Ｅｖｅｎｔ Ｓｐａｃｅにおける領域と関連付けられる、請求項８に記載の方法。
12. 少なくとも１つの前記ソフトウェア領域は、前記グラフィックスカードに適切なグラフィックドライバである、請求項１１に記載の方法。
13. ２つ以上の前記ソフトウェア領域はグラフィックドライバであり、該２つ以上のグラフィックドライバは、該ｓｐａｃｅ内で重複せず、該２つ以上のグラフィックドライバは、別個のグラフィックハードウェアレイヤと関連付けられる、請求項１２に記載の方法。
14. 前記グラフィックスカード上で関連付けられたハードウェアレイヤのパラメータに従ってドライバ領域を生成するステップをさらに包含する、請求項５に記載の方法。
15. 設定アプリケーションを用いて、ビデオサーフェスと、ドライバ領域と、レイヤ関連へのサーフェスと、レイヤ属性とを設定するステップをさらに包含する、請求項５に記載の方法。
16. ビデオディスプレイを管理する方法であって、
    設定アプリケーションを用いて、ビデオサーフェスと、ドライバ領域と、レイヤ関連へのサーフェスと、レイヤ属性とを設定するステップであって、どのハードウェアレイヤがグラフィックスカード上で利用可能であるのか決定し、それらのパラメータは何であるかを決定するステップを包含する、ステップと、
    オペレーティングシステムのユニバーサルＡＰＩを介して到達するドローイベントの受信に応答するステップであって、
    ドロー要求が特有のビデオレイヤについて立てられるかどうかを決定し、立てられる場合、該ドロー要求を該特有のビデオレイヤに向け、立てられない場合、Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅにおいてドローイベントを処理することと、
    該Ｐｈｏｔｏｎ Ｅｖｅｎｔ Ｓｐａｃｅが、少なくとも三次元を有し、複数のプログラムのオペレーティング環境を表すＥｖｅｎｔ Ｓｐａｃｅを定義することであって、該Ｅｖｅｎｔ Ｓｐａｃｅは、該Ｅｖｅｎｔ Ｓｐａｃｅの第１の端部にルート面を有しており、各セットの特徴は、大きさ特徴と位置特徴とを含み、該大きさ特徴は、該Ｅｖｅｎｔ Ｓｐａｃｅ内で平面領域の一組の大きさを示し、該位置特徴は、該Ｅｖｅｎｔ Ｓｐａｃｅ内で該平面領域の位置を該Ｅｖｅｎｔ Ｓｐａｃｅ内で少なくとも第２の平面領域と比較して示す、こととによって、応答するステップと、
    該グラフィックスカードが、該ビデオレイヤ上で、該ビデオディスプレイ上のディスプレイに該利用可能なハードウェアレイヤのうちの特定の１つにデータをマッピングするステップと
    を包含する、方法。
17. 前記設定するステップは、
    設定アプリケーションによって行われるステップであって、
    利用可能なハードウェアレイヤの数に対して、特定のディスプレイについてグラフィックスドライバをクエリーするステップと、
    各ビデオレイヤの性能について、該グラフィックスドライバをクエリーするステップと、
    所望された数のビデオサーフェスを生成するステップと、
    該利用可能なハードウェアレイヤの数および性能に基づいて対応するレイヤを設定するステップと
    を包含する、請求項１６に記載の方法。
18. ビデオサーフェスを特有のハードウェアレイヤと直接関連付けられるものと定義するステップをさらに包含する、請求項に１７記載の方法。
19. 前記応答するステップは、
    ソフトウェアアプリケーションプログラムから受信したイベントに応答するステップであって、第１のイベントシグナルは、イベントタイプと領域特性とを有しており、該領域特性は前記Ｅｖｅｎｔ Ｓｐａｃｅ内でイベント領域を定義する、ステップと、
    該イベント領域が第１のプログラム領域と交差するかどうかを決定するステップであって、該第１のプログラム領域は、該Ｅｖｅｎｔ Ｓｐａｃｅ内で定義され、該第１のプログラムに対応し、交差すると決定される場合、
    該第１のプログラムが該第１のイベントシグナルにセンシティブであるかどうか、該イベントタイプを検査することによって決定するステップであって、センシティブである場合、出力シグナルを該第１のプログラムに伝達し、該出力シグナルは該第１のイベントシグナルに対応する情報を含む、ステップと、
    該第１のプログラムが該第１のイベントシグナルを修正することにあるかどうか、該イベントタイプを検査することによって決定するステップであって、修正することにある場合、該第１のプログラム領域を該イベント領域から切り抜くことによって、該領域特性を修正する、ステップと、
    を行うステップと、
    を包含する、請求項１８に記載の方法。
20. コンピュータシステムであって、
    コンピュータと、
    該コンピュータにインストールされたグラフィックスカードと、
    該グラフィックスカードに電気的に接続されたビデオディスプレイと、
    該コンピュータ上で作動するソフトウェアアプリケーションと、
    該コンピュータ上で作動するオペレーティングシステムであって、該グラフィックスカード上でハードウェアレイヤをサポートするユニバーサルアプリケーションプログラミングインターフェース（ＡＰＩ）を備えるオペレーティングシステムと、
    該オペレーティングシステムは、該ユニバーサルＡＰＩを介してドローイベントを受信し、どのハードウェアレイヤが該グラフィックスカード上で利用可能であるか、該ハードウェアレイヤのパラメータは何であるかを決定し、該ソフトウェアアプリケーションからのドロー要求に、該ドロー要求を該グラフィックスカード上で該利用可能なハードウェアレイヤのうち特定の１つに選択的にレンダリングすることによって応答するように、動作可能であり、
    該ビデオディスプレイ上のディスプレイに該利用可能なハードウェアレイヤのうちの特定の１つに該ビデオレイヤ上でデータをマッピングするよう動作可能である該グラフィックスカードと
    を備え、
    該コンピュータ環境により、ソフトウェアアプリケーションが該グラフィックスカード上で利用可能なハードウェアレイヤを利用することが可能になる、コンピュータシステム。
21. 前記オペレーティングシステムは、ドロー要求を特有のハードウェアレイヤにレンダリングすることによって該特有のハードウェアレイヤの識別を含む該ドロー要求に応答するようにさらに動作可能である、請求項２０に記載のコンピュータシステム。
22. 前記オペレーティングシステムは、
    三次元Ｅｖｅｎｔ Ｓｐａｃｅを構築し、ドローイベントとソフトウェア領域とを管理する座標系を定義するようにさらに動作可能であり、
    該ソフトウェア領域のそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内で平面領域として定義され、
    該ドローイベントのそれぞれは該三次元Ｅｖｅｎｔ Ｓｐａｃｅ内でベクトルとして定義され、
    該ソフトウェア領域は、選択的に設定されることにより、該ソフトウェア領域中を通過するドローイベントに応答する、請求項２０に記載のコンピュータシステム。
23. 前記オペレーティングシステムは、前記グラフィックスカード上でハードウェアレイヤと関連付けられるドライバ領域を生成するようにさらに動作可能である、請求項２０に記載のコンピュータシステム。
24. 前記システム上で作動する各ソフトウェアアプリケーションは、前記ＰｈｏｔｏｎＥｖｅｎｔ Ｓｐａｃｅにおける領域と関連付けられる、請求項２２に記載のコンピュータシステム。
25. 前記オペレーティングシステムは、関連したハードウェアレイヤのパラメータに従って、ドライバ領域を定義するようにさらに動作可能である、請求項２０に記載のコンピュータシステム。

Images