JP2004506262A - グラフィックハードウェアおよびソフトウェアの開発 - Google Patents

Abstract

エンターテイメントコンテンツおよびグラフィックスハードウェアにおいて独立したイノベーションを達成するシステムおよび方法が提示される。このシステムおよび方法では、現在のイメージ生成ランタイムアプリケーションが、グラフィックスシステムをインプリメントするために必要なコネクティビティ、機能、および挙動を定義する新しいフレームワークと置き換えられる。この全ては、ランタイムアプリケーションにおける種々の実時間コンポーネントを動的に統合する最新の統合メカニズムを利用するソフトウェアプラットフォームのコンテキストで起こる。
【選択図】図１３Ｂ

Description

【０００１】
（発明の背景）
（発明の分野）
本発明はコンピュータグラフィクスに関し、より詳細には、グラフィクスハードウエアおよびソフトウエアの開発に関する。
【０００２】
（関連技術）
（初期のグラフィクスシステム）
Ｇｉｒａｖｉｏｎ−Ｄｏｒａｎｄからの、１９５４年版のＤＸ−５０のヘリコプター訓練器などの初期の画像システムは、光学および機械的システムを用い、そしてデータベース、画像システム、および表示システム間の区別をしなかった。これらのシステムハードウエア中枢構造は、当時の利用できるハードウエア技術に関連するリアルタイム性能および画像品質目標の意欲的背景から生まれた。画像生成技術の誕生は、Ｉｖａｎ　ＳｕｔｈｅｒｌａｎｄのＳＫＥＴＣＨＰＡＤシステムで始まった。Ｅｖａｎｓ　＆　Ｓｕｔｈｅｒａｎｄによって、１０年後に導入されたＣＴ３は、今日もなお使用されている画像生成アーキテクチャを形成した。ＮＡＳＡに初めて供給されたこのシステムは、プログラマブブルでないグラフィクスハードウエアに接続され、そのソフトウエアを実行させるフロントエンドプロセッサのＤＩＧＩＴＡＬ　ＥＱＵＩＰＭＥＮＴ　ＣＯＲＰＯＲＡＴＩＯＮのＰＤＰ−１１から構成されていた。このシステムの継続の技術革新は、その画像システムからデータベースを分離し、そしてカリグラフィックな表示器を装備したＰＤＰ−１１／４０上に、実行するモデリングツールを導入することであった。ＣＴ３は、エッジアンチエイリアジング機能およびＧｏｕｒａｕｄシェーディング機能を有し、９００形のポリゴンを２５Ｈｚで生成可能であり、そして１以上の関連表示サブシステムへの出力を有し、ハードウエアまたはソフトウエアインタフェースを介して、シミュレーションホストに接続され、その画像生成をデータベースで駆動されるシステムとして定義した。そのようなシステムは図１に示される。画像生成１０２には、データベース１０４からのデータを基に、画像を生成することが示される。その画像は次に、１以上の表示装置１０６に表示される。
【０００３】
（シーングラフツールキット）
初期の１９９０年台のもの以来、汎用のワークステーションは、リアルタイムの画像生成機能を実現するために、ＳＧＩのＩＲＩＳ　ＰＥＲＦＯＲＭＥＲなどの洗練されたソフトウエアを用い、専用のハードウエア画像生成装置に増々匹敵するようになった。例えば、シーングラフはグラフィックスの抽象物として用いられた。シーングラフは、高級レベルのシーンかつ描写記述用言語である。シーングラフは、ツールキットのアプリケーションプログラミングインタフェース（ＡＰＩ）の部分として用いられる。シーングラフの考えは、ＰＥＲＦＯＲＭＥＲおよび類似品を強調したもので、それは画像データベースを表し、処理の場としての役目を行い、そして新規に開発された拡張に対する連結点である。ＰＥＲＦＯＲＭＥＲはシーングラフの抽象物を用いて、ハードウエアおよび性能に関する項目の制御を維持しつつ、アプリケーション開発者に柔軟性を与える。それはまた、開発者のために、出発点として人気があったサンプルアプリケーションをも導入した。ＰＥＲＦＯＲＭＥＲは、汎用のグラフツールキットにおいてシーングラフの初めての使用者ではなかった。しかしながら、ＰＥＲＦＯＲＭＥＲは、開発者の便利さまたはハードウエアの独立性よりも性能重要性に焦点を合わせた。
【０００４】
ＩＲＩＳ　ＰＥＲＦＯＲＭＥＲのユーザの領域外では、中間ソフトウエア層はアプリケーションの性能を落としているという共通の考えが存在する。例えば、ゲーム業界での歴史的認識は、ツールキットはただ、プロトタイプ開発用に過ぎず、アプリケーションは、インストール前に書き直されなければならないということである。この点とは対照的に、ＩＲＩＳ　ＰＥＲＦＯＲＭＥＲおよびＰＡＲＡＤＩＧＭ　ＥＮＴＥＲＴＡＩＮＭＥＮＴのＶＩＳＫＩＴは、インテリジェントでかつ最適化されたソフトウエア層がアプリケーション性能を堅実に改善できていることを示している。
【０００５】
（第４の要素）
画像シミュレーション業界におけるＩＲＩＳ　ＰＥＲＦＯＲＭＥＲの成功は、ＯＰＥＮＧＬのようなインタフェースよりもより抽象的であるが、古典的な画像生成のインタフェース制御定義よりも、より柔軟性のあるいツールキットのレベルのＡＰＩの考えを流行させた。画像生成装置の構造に、第４の要素（画像シミュレーションのランタイム、すなわち、シーングラフを越えたさらなる機能を提供した高級レベルのソフトウエア）の導入へのこの導きは、古典的画像生成装置のターンキー機能を再生成する必要があった。これは図２に示される。この図において、データベース２０２内の情報は、ランタイムソフトウエア２０４によって用いられる。この結果のデータはグラフィックスワークステーション２０６によって用いられ、１以上の表示装置２０８上において表示する画像を生成する。
【０００６】
そのようなシステムの例には、ＡｅｃｈｅｌｏｎのＣ−Ｎｏｖａ、ＲａｙｔｈｅｏｎのＲｉｇｈｔＶｉｅｗ、ＴｈｏｍｓｏｎのＳｐａｃｅ　Ｍａｇｉｃ、ｔｈｅ　Ｅｑｕｉｐｅ　Ｓｉｍｕｌａｔｉｏｎ　Ｒｅａｌ　Ｔｉｍｅ、Ｍｕｌｔｉｇｅｎ−ＰａｒａｄｉｇｍのＶｅｇａ、および、ＷｏｒｍａｌｄのＷＩＧＳが含まれ、それぞれはＩＲＩＳに上の層に置かれる。そのシーングラフＡＰＩおよび画像生成ランタイムの対は、画像シミュレーションを改善させた。すなわち、危険性、日程、および費用を減少させた。開発者は、指定企業ベンダーの強化に依存しない機能を加味でき、統合者がシステム構成において独自の技術を使用しかつ保持するのを支援し、そして画像生成界のニーズへの商業的グラフィックスハードウエアの能力に、より良く整合させ得る。
【０００７】
しかしながら、ソフトウエア技術の進歩は、新しい障壁の発見を導き得る。このことは、そのシーングラフに関しても真実であり、ここにおいて開発者は一貫して同じ技術問題に遭遇する。
【０００８】
小さい拡張モデル（Ｗｅａｋ　Ｅｘｔｅｎｓｉｏｎ　Ｍｏｄｅｌ）。そのシーングラフは、階層的アーキテクチャ、ＢＳＰ定義、スイッチ範囲の詳細レベル（ＬＯＤ）、および類似の横断特性を表現するのに良い構造である。しかしながら、アプリケーション開発者がコールバック機能を付加し、シーングラフ要素の再定義を可能にすように拡張されると、問題が出現する。この「ツリー修飾（ｔｒｅｅ　ｄｅｃｏｒａｔｉｏｎ）」という比喩は、シーングラフを臨界的であるが暗黙の順序従属性に変換し、任意の２以上の拡張が不一致になりがちであるという結果を有するシーングラフ横断の意義を密かに変えている。
【０００９】
制限されたコード再利用。別々の開発者が、拡張モデル意味競合のために、共通のシーングラフに融合され得る独立した機能を構築することは、不可能でなくとも困難である。このことは、それらには独立のソフトウエアプロバイダからのサブ構成要素を統合化するフレームワークが不足しているため、統合者が固有の画像シミュレーションランタイム環境を開発するように導き、この結果、同じ基本機能の多数のバージョンを生むことになる。このことは、提案する技術評価者を悩ませ、彼等はあるマシーンがある機能を可能していることを知っているが、ある特定の競争者が所望通りにそれを実現しているかどうかを知ることができない。そして、あるプログラムの弱い手段を別のプログラムからの強い手段に置換する方法が存在しない。
【００１０】
統合化の困難。たとえ統合化タスクの最後の２０％が、見掛け上８０％の時間と費用を必要としても、これを支援するツールがわずかしかない。拡張モデル問題が統合化時間において表面化（異なったサブ構成要素が初めて共に動作する時）し、そして開発者がこのシーングラフの内部作用の輪郭把握、理解、または変更できない場合、シーングラフは部分的に責任がある。シミュレータが「殆ど常に」フレームレートで実行していることをテストで示された場合でも、この開発者は、このシーングラフが、フレーム拡張を起こさせるために、異なって何を行っているかを知るのに通常迷う。
【００１１】
アプリケーション状態の複製。シミュレーションのアプリケーションは、オブジェクトの位置、光源、および他の状態要素を計算または管理する。この同じ情報は、自己の性質により不透明な形態としてシーングラフにもまた現われなければならなく、そしてこれは、同期と更新時の問題を有して、２つの間のアプリケーション状態の複製を要求する。
【００１２】
シーングラフは自己の成功の犠牲者である。すなわち、それはグラフィクスの抽象物として良好に働くので、それは、アプリケーションの抽象物としてさらなるサービスの中に押しこまれたが、それはアプリケーションの抽象物ではない。これらの問題は、シーングラフの実現の欠陥というよりは、元来の構造不整合の印である。完全に異なった抽象およびこれに関連するデータ構造は、必要とされかつアプリケーションの最深部の本質を表現できる。新タイプのリアルタイムのグラフィックスソフトウエアは必要であり、これは、アプリケーションレベルの概念および関連事項のために、より高級レベルの対応パーツとして、シーングラフを補完する。
【００１３】
新しいファクターは、これらの問題に前例のない緊急性を加える。すなわち、より低コスト３Ｄグラフィックスハードウエアデバイスは、画像生成装置において働く機能、品質、および性能を有するが、これに関与するソフトウエアはこれらを有しない。多くの場合、次世代のハードウエアは、通常の訓練アプリケーションに必要とされるよりもさらなる機能を提供する。しかしながら、このことは、アプリケーションの構築がより容易でかつより費用がかからないということを意味しない。画像生成装置をワークステーションよりは、これらの構成要素から構築することの方がより困難になりがちで、このことは、丁度、幾人かの統合者が、ベンダーに合わされたＩＲＩＳ実行者用ＡＰＩの出現前に、強力な汎用のワークステーションを、古典的な専用画像生成装置よりも、理解するののが難しいと判断したのと同じである。低価格の点で、この分野での驚くべき性能を包含することは、高技術グラフィックスのアプリケーションソフトウエアの移植性に対応する必要があり、そしてこれは同じように、アプリケーションをあるハードウエアシステムから別のシステムに移動できる可搬型構成要素として考えることを意味していることは、発明者に認識されていた。ハードウエアベンダーは、同調かつ伝達するアプリケーションへの道筋として、標準機能のある別の手段を提供可能にさせることによって、ハードウエア能力の差別化を促進するソフトウエアが必要とされている。
【００１４】
図３Ａおよび図３Ｂは、異なった機能を有した異なったハードウエアプラットフォームの機能を用いる方法で、ゲームソフトウエアを開発することの問題を示す。図３Ａは、ＳＯＮＹ　ＰＬＡＹＳＴＡＴＩＯＮ２のプラットフォームに顧客専用化されたゲーム開発の階層化アプローチを示す。図３Ｂは、パーソナルコンピュータ（ＰＣ）のプラットフォームに顧客専用化されたゲーム開発の階層化アプローチを示す。ハードウエアとゲームソフトウエア間の一様でない境界線によって提案されるように、顧客専用化の階級は必要である。さらに、必要な顧客専用化の現象は、図示するように、上層へと拡張する傾向である。ゲームソフトウエアおよびゲーム内容間の境界もまた、必ず顧客専用化される。同じように、ゲーム内容および開発ツール間の境界も顧客専用化される（ゲーム内容の開発が図４にある例に関してさらに示される。この図は、レベルエディタを用いて、音、モデル、アニメーションおよび挙動などの内容の種々の局面の合体されたものを示す。）。
【００１５】
基本的に従来努力と異なるアプローチが必要とされ、この従来努力は、機能の同じ重要な実現をさせ、そしてより低レベルのハードウエアインタフェースのシステム依存型の手段およびシーングラフＡＰＩ間に、「つなぎ目（ｓｅａｍ）」を置いた。これらの低レベルアプローチは、移植可能な３Ｄグラフィックのベンチマークパッケージによって証明されたように、元来弱点を有する。低レベルの拡張メカニズムは、移植性のアプリケーションの最適化から、例えば、マルチプロセッシングを透明に挿入することを不可能にすることによって、ハードウエアベンダーを制限する。それらはまた、低レベルＡＰＩ開発者によって認可された特定のアプローチを用いて、高級レベル設計の実現を要求することによって、変革を抑制する傾向がある。
【００１６】
ハードウエアベンダーが、ＯｐｅｎＧＬの関連する拡張メカニズムを用いて、新機能を追加することは実に難しく、そしてそのようにした後で、アプリケーション開発者が書き替えるように誘発され、そしてこれらのシステム依存型の拡張を含む製品を再リリースしなければならない。この問題をより高いレベルの抽象物を提供することによって解決される新規のソフトウエアのアーキテクチャが必要とされ、この抽象化は、それらのハードウエアの相違をアクセスするために、ハードウエアベンダーに、実存の方法、コンパイルされたアプリケーションソフトウエアの実現機能を変えるメカニズムを提供する。
【００１７】
（発明の要旨）
これらの関連事項と直面して、これらの問題を一斉に解決し、そしてこのようにすることにおいて、リアルタイム画像生成装置の展望を、コンピュータグラフィックスのアプリケーション分野で拡張できるアプローチが提供され、そしてこのアプローチは、ゲーム、訓練、ネットワーク上の画像化、およびコンピュータグラフィックスが用いられる他の分野に限定されてないことを含む。この新規の技術は、下記のセクションで開示されるが、ソフトウエアプラットフォームおよびアプリケーションフレームワークの概念をベースにしている。これらのアイデアは、現在の画像生成ランタイムアプリケーションを、グラフィックスシステムを実現するに必要な接続性、機能、および挙動を定義する新しいフレームワークと置換する。このすべてが種々のリアルタイム構成要素をランタイムアプリケーションの中で動的に統合する統合化機構を用いたソフトウエアプラットフォームに関連して生じる。結局のところ、ハードウエアを開発努力の中心的焦点として置き、このソフトウエアプラットフォームは機能的に、少なくともシミュレーションホストコンピュータ、データベース開発者、および画像システムの調達および保守に責任のある人によって見えるように、グラフィックスのアプリケーションである。
【００１８】
革新的なソフトウエアのアーキテクチャの、グラフィカルアプリケーションプラットフォーム（ＧＡＰ）が提供される。ある実施形態では、このＧＡＰは、実行型の論理ブロックを含むアプリケーションのリアルタイムのカーネル（ＡＲＫ）および構成要素を含む。ＧＡＰは、画像生成装置、ワークステーション、およびプラットフォームおよびフレームワークの概念をリアルタイムのグラフィックスドメインに拡張することによるシーングラフ達成の上に構築する。このことは、画像生成関連と現代のハードウエアとソフトウエアの現実間のギャップを、内容、ハードウエアおよびアプリケーションを分離することによって橋渡しをすることである。この新規のアプローチはまた、新しい低コストで高性能のグラフィックスハードウエアに関しての選択と収集プロセスに関連する、急に発生する関連事項を解決する技術を提供する。
【００１９】
上述した本発明および本発明の他の特徴および利点は、添付の図面とともに、後述の本発明の好適な実施形態の詳細な説明からより明瞭になる。
【００２０】
（好適な実施形態の詳細な説明）
ここで、本発明の好ましい実施形態を図面を参照して説明する。ただし同じ参照番号は、同一かまたは機能上類似の要素を表す。また、図面において、各参照番号の最上桁は、この参照番号が初めて用いられた図面に対応する。特定の構成および処理を説明しているが、これは説明の目的のためだけになされたことを理解すべきである。他の構成および処理は、本発明の精神および範囲を逸脱すること無く用いられることを当業者は理解する。本発明が種々の他のデバイスおよびアプリケーションにも用いられる得ることは、当業者にとって明らかである。
【００２１】
（１．概要）
次のセクションで開示される発明は、ソフトウエアのプラットフォームおよびアプリケーションのフレームワークの概念をベースにしている。これらのアイデアは、現代のグラフィックのアプリケーションの構造、フレームワーク、またはライブラリを、画像生成装置を実現するのに必要な接続性、機能および挙動を定義した新規のフレームワークと置換する。このすべては、種々のリアルタイム構成要素を、リアルタイムアプリケーションで動的に統合する統合メカニズムを用いるソフトウエアのプラットフォームの関連で生じる。
【００２２】
この概要セクションは次のように編成される。
【００２３】
Ａ．プラットフォームおよびフレームワーク
Ｂ．グラフィカルアプリケーションのプラットフォーム
Ｃ．グラフィカルアプリケーションのフレームワーク
Ｄ．ＧＡＰの特徴
Ｅ．ブロック、接続、および拡張
１．ブロック構造およびインタフェース
２．ブロック間の接続
３．構成要素としてのブロックのパッケージ化
４．ブロック実行モデル
Ｆ．ＧＡＰの拡張化
Ｇ．ＧＡＰに従う世界
（Ａ．プラットフォームおよびフレームワーク）
本明細書で用いられる用語のプラットフォームは、プログラムを実行する完全な環境である。最も共通のプラットフォームは、システムおよび言語に関係するランタイムライブラリを有したオペレーティングシステムである。内部のＬｉｓｐインタプリタに介して、ユーザ拡張の方法で共に一体化した、低レベルのテキストマネージャー機能を有したＥＭＡＣＳのようなアプリケーションは、アプリケーションレベルのプラットフォームの革新的な先駆者である。本発明のアプローチおよびその先駆者の相違を描くには、ウエブのブラウザを類似品として用いることができる。
【００２４】
スクリプトおよびプログラム拡張がパッケージされた場合、現代のウエブブラウザは、ウエブページの「プログラム」を実行するプラットフォームを表す。ブラウザはまた、アプリケーションでもあり、そしてアプリケーションとプラットフォームの区別は微妙で、かつ度々見逃される。アプリケーション部分は、ネットワーク化されたペーパレス通信（ＨＴＭＬブラウジングとエディテング、電子メイル、ニュースリーデイングなど）、グラフィカルユーザインタフェース、およびお好みのウエブサイトにリンクするようなナビゲーション支援）に関連する機能を提供する。プラットフォーム部分は、「プログラム」（ＨＴＭＬ、Ｊａｖａ（Ｒ）、ＣＧＩスクリプトなどのフェッチ）、これらのプログラムの解釈のための標準化されたセマンティクス、およびＨＴＭＬ、Ｊａｖａ（Ｒ）、そしてスクリプト言語で書かれたプログラムを評価するランタイム「エンジン」をロードするメカニズムから成る。
【００２５】
歴史的には、ブラウザは、これら２つの機能を別々の局面であらわにしなかった。１つの局面は、ウエブページ、Ｊａｖａ（Ｒ）アプレット、またはブラウザのＧＵＩまたは機能を構築した他のものに再定義または拡張するＣＧＩスクリプトを作ることができず、そして外部の開発者がこのブラウザのインタフェースを異なったＨＴＭＬプラットフォームに移動させることができなかった。もしブラウザ開発者がそのような能力のもを設計をしたら、何が変わったか。彼等は、ＨＴＭＬ、Ｊａｖａ（Ｒ）、スクリプト言語をフェッチかつ実行できた「ブラウザ仮想マシン（ｂｒｏｗｓｅｒ　ｖｉｒｔｕａｌ　ｍａｃｈｉｎｅ）」（ＢＶＭ）を構築しただろう。これはプラットフォームになっただろう。どんな人でもそれを走らせるが、それについて少ししか知らないだろう。なぜならば、彼等は、以前のウエブブラウザと同じであるが、ＢＷＭによって実行可能なコードのモジュールで実現された「ブラウザアプリケーション」を構築しただろう。これは、エンドユーザが見るアプリケーションであり、そしてここにはルックアンドフィールが存在する。しかしながら、彼等は、変わり易さをＢＶＭに構築するので、開発者は、例えば、「ＧＵＩモジュール」を彼等固有のもののひとつに置換するか、または、「ＨＴＭＬモジュール」に新規機能を拡張するための、標準ブラウザのアプリケーションの各局面を変形し得る。
【００２６】
ブラウザ開発者はこれらの長所を認識し、そして、ウエブブラウジングが、ＨＴＭＬ、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ、およびＪａｖａ（Ｒ）を統合する、新規のアプリケーションを開発する基礎としての役目を果たすことができるように、プラットフォームおよびフレームワークアプローチに移動させようとしている。モジュールの拡張かつ置換するこの能力を提供することは、アプリケーションが、慣習的であるよりもより高級な程度の柔軟性および一般性を有するということを必要とする。フレームワークは、本発明に従うと、どのアプリケーションを構築するかで定まる構成セットのＡＰＩよりも、包括的であるが変更容易なアプリケーションのこの種のタイプとして、考えられ得る。
【００２７】
２つの階層的クリスマスツリーキッドを照合することはこの差を説明することになる。
【００２８】
構成セット。頑丈なツリー、ライト（ｌｉｇｈｔｓ）の箱、装飾品の箱、およびホックなし。取り扱い書「やって見よう（Ｇｏ　ｆｏｒ　ｉｔ）」、および美しい写真が付属する。
【００２９】
フレームワーク。装着済みのライト、ホック、およびわずかな装飾品がプリーインストール（ｐｒｅ−ｉｎｓｔａｌｌｅｄ）された同様のツリー。このホックは、作製されるどんな追加装飾の装着も可能にする。実存するライトおよび装飾品もまた取り除かれ得る。
【００３０】
フレームワークは、独立した開発者が、正確に同じ方法で共通の概念に依存するモジュールを書くことを可能にし、そしてそれは、プログラミングの複雑さが標準と新規アプリケーションとの差だけに限定されるので、開発を最小にする。構成セットのアプローチは常に、結果のアプリケーションの複雑さに比例した努力を必要とする。これらの相乗効果は、フレームワークの長所である。すなわち、それは、新規の開発プロジェクトを増分努力型に変換し、そして他の人と共用できるモジュールを奨励づける。これらの考え、すなわち、プラットフォームとフレームワークは、本明細書内で開示されるもので、ハードウエアの区分の各ビットをアクセスする移動型の、高性能のアプリケーションを開発するためのソフトウエア技術の中心である。これらの概念をブラウザからリアルタイムグラフィックス領域に変換する場合、完全なグラフィカルアプリケーションプラットフォームを実現するために、時間、同期、並列処理、およびロードマネージメントなどのブラウザに現われない追加の条件が処理されなければならない。
【００３１】
（Ｂ．グラフィカルアプリケーションプラットフォーム）
グラフィカルアプリケーションプラットフォーム（ＧＡＰ）は、グラフィカルアプリケーション開発のためのプラットフォームをインプリメントする。その広さおよび拡張性により、効率的でかつ移植性のよい、次世代の実時間のグラフィックスアプリケーションのインプリメンテーションが可能になる。その三つの主なセクションは、以下の通りである。
【００３２】
カーネル。アプリケーション実時間カーネル、すなわち、ＡＲＫは、アプリケーションレベルの実時間スレッドマネジャーである。それは、各利用可能なＣＰＵ上で走行している一つ以上のＡＲＫスレッドのそれぞれによって実行されるブロックを列挙する決定論的なスケージュールに従ってコードブロックを呼び出す。システム基礎構造要素のセットもまた、ＡＲＫの中に構築される。これらの要素は、コンポーネントを動的にロードおよびアンロードし、ブロックの実行をモニタし、そして、スレッド管理、メモリ共有、相互排除、および同期化を支援する。
【００３３】
コンポーネント。機能のインプリメンテーションは、実行可能なコンポーネントとしてパッケージングされ、そしてこのコンポーネントは、強力なネゴシエーションベースのリソース割当スキームをサポートする。標準コンポーネントは、表示構成および位置外挿および他の機能等の概念をインプリメントする。この他の機能は、オブジェクトのモーフィング（ｍｏｒｈｉｎｇ）、先進の表面シェーディング（Ｓｈａｄｉｎｇ）、ダイレクトＩ／Ｏ転送（ｔｒａｎｓｆｅｒ）、および普遍的なテクスチャ（ｔｅｘｔｕｒｅ）、地形（ｔｅｒｒａｉｎ）、オブジェクト、および文化的機能等をチューニングするシステム特有性に従う。コンポーネントは、ハードウェア製造業者の装置を通じて特定のハードウェアに再書き込みされる、移植可能なインプリメンテーションを有する。この構造およびチューニングスキームは、ＧＡＰの基本的な「差別化されるが移植可能な」機構である。この構造およびチューニングスキームを通じて、アプリケーション開発者は、対象（ｗｈａｔ）および理由（ｗｈｙ）に焦点を合わせ、この方法（ｈｏｗ　ｔｏ）をプラットフォーム開発者および同業のハードウェアパートナーに任せる。
【００３４】
接続。接続は、実行可能な内部のブロック間またはコンポーネント間のデータの流れをインプリメントする。それらは、上流ブロックから下流ブロックへの一方向の移送に影響を及ぼす。それらは、通信パターンを変更するために「プラグボード」を提供する。通信パターンの変更は、新しいブロックを挿入する場合または古いものを置き換える場合の必須のタスクである。例えば、潜在的に可視のオブジェクトを抽出するためにグラフを横切らせる一つのブロックとオブジェクトを受信し、かつそれらを描く別のブロックとの間の接続を考慮する。新しいブロック、例えば、所与のサイズよりも小さいオンスクリーンの映像を有する任意のものを拒絶するものをこれら二つの間に挿入することは望ましくあり得る。そのようにすることは、横切るのと描くのとの間の接続を削除し、横切るのと拒絶するのとの間および拒絶するのと描くのとの間の接続を加えることを意味する。ＡＲＫは、このようなランタイム（ｒｕｎ−ｔｉｍｅ）の再構成を再コンパイルなしで効果的な並行処理を意識した接続機能を通じてインプリメントする。
【００３５】
（Ｃ．グラフィカルアプリケーションフレームワーク）
ＧＡＰは、また、グラフィカルアプリケーション開発のためのフレームワークを提供する。完全なグラフィックスアプリケーションが提供され得、開発者は、その完全なグラフィクアプリケーションを直接使用し得、または、望み通りに変更および拡張し得る。標準のアプリケーションの提供によって、共通の名前付けおよび構造フレームワークが派生されたアプリケーション用に確立され、この派生アプリケーションは異質の機能とうまく組み合った柔軟性を非常に具体的な意味のあるコンテキストの中に収容する。
【００３６】
設計は、複数のＣＰＵおよび複数のグラフィックスデバイスへの拡張をサポートしているが、実際、これは、より小さい構成のための任意のオーバーヘッドを意図していない。この考えは、進歩した構成において、より十分に収容される構造を提供するだけのことである。フレームワークアプリケーションは、グラフィカルアプリケーションのための広範囲のクラスの共通の重要な構造を提供する。この構造は、取り除かれ、置き換えられ、拡張され、そして切断および再接続され得るブロック間の接続でもって露出されおよび隠され得るブロックから構築される。これにより、ある開発者は、カスタムアプリケーションをインプリメントするのに必要と判断される量のＧＡＰフレームワークを再成形することが可能となるが、このアプリケーションはシステムを論理的に損なわず、そして、所望ならば、他の開発者によって拡張可能である。それは、さらに、開発者は、変えたＧＡＰの部分を理解することのみが必要であることを意味する。
【００３７】
アプリケーションフレームワークは、いくつかのフェーズ（ｐｈａｓｅ）を定義し、フェーズのそれぞれは、潜在的に並行な実行スレッドに応答する。コンポーネントは、これらの種々のフレームワークフレーズ間に分割される。ＧＡＰアーキテクチャは、正確なパイプラインの実行のためにデータへの並行アクセスの自動検出を提供する。この機能は、透明であるが効果的な並行処理程度（ｐａｒａｌｌｅｌｉｓｍ）をすべてのレベルのインプリメンテーションにおいて可能にしつつ、ハードウェアアーキテクチャからの独立性を提供する。このＧＡＰの性能は、複雑な複数スレッドのアプリケーションに対して開発時間を大きく縮小し得る。
【００３８】
（Ｄ．ＧＡＰの機能）
ＧＡＰの機能は、四つのグループに組織化される。カーネルは、ハードウェアリソースおよびパブリックなデータ構造へのアクセスを提供する。標準プラットフォーム機能は、共通してアプリケーションに用いられるタスクをインプリメントする。市場指向の機能は、特定のドメインの概念を処理する。そして、アプリケーションの特定の機能は、独自性を特定のアプリケーションに提示する。
【００３９】
アプリケーション実時間カーネル（ＡＲＫ）。プロセス管理、実行スレッド、およびプロセッサ、グラフィックスパイプライン、ディスプレイ、テクスチャメモリ、フレームバッファメモリ、およびシステムメモリのような物理的リソース、相互アクセス排除、明示的データ共有、および内在のデータプライバシー；高精度カウンタ、タイマー、および日時計の時間；非同期ファイルシステム動作およびメモリ転送；およびランタイムコンポーネントのロードとアンロードとを含む。
【００４０】
標準プラットフォーム機能。入力デバイス管理；モーフィング、補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）、変形（ｄｅｆｏｒｍａｔｉｏｎ）、および評価；空間的音声処理；活性（ａｃｔｉｖｉｔｙ）ロギングおよび再生；構成ファイル構文解析（ｐａｒｓｉｎｇ）および評価；座標システム処理（精度管理および明瞭度（ａｒｔｉｃｕｌａｔｉｏｎ））グラフを含む；およびオブジェクト、テクスチャ、マテリアル（ｍａｔｅｒｉａｌ）、および音のページング等を含む。
【００４１】
市場指向機能。これらは、産業の標準的な概念である。基本的なビジュアルシミュレーションに対して、これは、暦表時；地球基準の一時的位置、太陽系オブジェクト位置および外観；天体領域および星座の視覚化；地形の高さ、視界交差の線、複数点の地形続き、オブジェクトの相互視認決定（ｉｎｔｅｒｖｉｓｉｂｉｌｉｔｙ　ｄｅｔｅｒｍｉｎａｔｉｏｎ）、および衝突検出；一様でない層状の霧、地平圏のもや、雨雲（ｓｃｕｄ　ｃｌｏｕｄ）、動的な雲の容積、および方向性を持つ地平圏の輝き；雨、みぞれ、雪に対する空間的な影響；多くの他の機能を有する大気モデル等をサポートする普遍的なモデルを含む。
【００４２】
アプリケーション特有の機能。フレームワークを特定のアプリケーションに拡張するかまたは再成形する要素。例えば、これは、運動モデル、コマンドライン処理、環境変数処理、グラフィカルユーザインターフェースのカスタマイゼーション、およびアプリケーション特有のデータベースのローディングおよびデコーディング論理を含み得る。
【００４３】
同時に、ＡＲＫおよび標準機能は、グラフィカルアプリケーションプラットフォーム（図５参照）を定義する。これは、一つ以上の市場指向機能のセットと組み合わされた場合、包括的な開発および開発プラットフォームを定義する。ＧＡＰを基礎とする開発者は、これらの機能、市場指向集合からの機能、および顧客アプリケーション特有の機能を用い、それらのアプリケーションをインプリメントする。
【００４４】
（Ｅ．ブロック、接続、および実行）
（１．ブロックの構造およびインターフェース）
ブロックは、ＧＡＰフレームワークの基本的要素であり、双方向のビジュアルコンピューティングの「アトム（ａｔｏｍｓ）」を定義する。それらは、ＧＡＰ内の実行の基本ユニットであり、入力および出力連鎖の終了点である。一旦構築されると、ブロックは、入力および出力点と他のブロック上のコンパチブルな点との間に接続を構成することによって、アプリケーション（またはカプセル化ブロック）に結合される。あるブロックは、入力を提供するブロックのアイデンティティ（ｉｄｅｎｔｉｔｙ）または出力に接続するブロックのアイデンティティ（ｉｄｅｎｔｉｔｙ）を知らない。ブロックインターフェース定義に明記されたデータにより、ＡＲＫは、コンパイルされたブロックのためにこのランタイムの動的接続機能を不可視でかつ効率的にインプリメントすることができる。ブロックのコンテンツは、図６に示され、以下の要素から成る。
【００４５】
入力接続点６０５。名前は、内部および外部の両方に接続を形成する場合に用いられる。タイプは、混合されたデータ構造であり得、その場合、アクセスは、集合体の「名前」の上に加わった、「名前のメンバー」に向けられ得る。
【００４６】
出力接続点６１０。出力点は、本来のオブジェクトから派生されたパブリック状態要素に対応する。これら内部オブジェクトへのアクセスは、対応する出力点に接続された他のブロックに提供される。
【００４７】
プライベート状態要素６１５（ブロックインスタンス（ｉｎｓｔａｎｃｅ）データを含む）。
【００４８】
標準関数６２０。ｃｏｎｓｔｒｕｃｔ（）、ｄｅｓｔｒｕｃｔ（）、およびｉｎｉｔｉａｌｉｚｅ（）等の標準機能は、オブジェクトにライフタイムサービスを提供し、ｅｖａｌｕａｔｅ（）関数は、ブロックの処理をインプリメントする。
【００４９】
一例において、大抵のブロックは、もともとそのシステム用にコンパイルされ、且つ、最適化されたアセンブラー、ＣおよびＣ＋＋コードで実行される（このため、我々の性能指向の戦いは、「一度の書き込みで、どこにおいてもコンパイルする」と大声で叫ぶ）。コンパウンドブロック（Ｃｏｍｐｏｕｎｄ　ｂｌｏｃｋｓ）として知られる他のものは、より簡単なブロックをプロセッシンググラフとして一緒に編み合わせることによって純粋に表現され得る。これらの網状物は、ブロックへのリンクおよびブロックからのリンクおよびブロックの入力および出力から内部ブロックへの連鎖および内部ブロック間の連鎖を定義し、単一のスクリプトによって定義されかつインプリメントされる。
【００５０】
（２．ブロック間の接続）
接続は、ブロックを一緒に連結する。それらは、本質的に一般的なトポロジーを通じたサブルーチンの呼び出し（ｉｎｖｏｃａｔｉｏｎ）のための引数（ａｒｇｕｍｅｎｔ）を特定するための手段である。このトポロジーにより、関数がコンパイルされた後に接続トポロジーへの変化が可能である。各ブロックの入力点から任意の他のブロックのコンパチブルな出力点への単一の接続が確立され得る。
【００５１】
多くの接続プロパティは、データが内部データメンバー（本来のオブジェクトから派生される）から一つのブロックの出力点（生産者−下流）を通じて入力点（別の消費者）に流れる一方向パイプラインとしてそれらを視覚化することによって説明される。接続は、ランタイムの時に生成され、実行する間に形成されおよび消去され得る。例えば、視点を風景を通じて移動させることは、幾何学的ページング機能が新しいアニメーションコンポーネントを新たにページングされた幾何学的図とともにロードすることを引き起こし得る。入来するアニメーションブロックは、カメラ位置に取り付けられる必要があり、この接続は、上記のように形成される。一旦接続されると、カメラ位置のデータは、ブロックの入力点に関連する内部アクセサ関数（ａｃｃｅｓｓｏｒ　ｆｕｎｃｔｉｏｎ）が呼び出された場合に新たにロードされたブロックに対して利用可能になる。
【００５２】
並行モードに関係なくこのデータフローモデルを維持することによって、ＡＲＫは、並行して実行するブロックの間での共有データへのコヒーレント（ｃｏｈｅｒｅｎｔ）なアクセスを提供し、異なる速度で同期するか、または、非同期で動作するブロック間のデータの散発的な発生と消費とを可能にし、そして同時に処理されるデータのいくつかの複数メガバイトフレームを有して、パイプラインを処理するために一時的なコヒーレンスを提供する。
【００５３】
（３．コンポーネントとしてのブロックのパッケージング）
コンポーネントは、ＧＡＰ環境における最も高レベルのオブジェクトである。それらは、反復使用の広域のリソース割当プロセスに基づいて、ブロックの新しい集合を生成するための工場であり、そして、このプロセスは、通常かなり異なる物理的実感を有する、論理的に同一の代替物間のものを選択する。
【００５４】
コンポーネントは、ランタイムでの以下の形態の質問に慎重に答えるように設計される。
【００５５】
「特定のハードウェア構成および利用可能なリソースに関する拘束条件が与えられた場合、特定の機能を挿入するために何がフレームワークに加えられるべきか」
この質問が困難であるのは、局所的および広域的な情報の両方に依存するからである。
【００５６】
局所的には、ある機能のいくつかの利用可能なインプリメンテーションの一つは、ハードウェアまたは他のリソースの利用可能性等の拘束条件に基づいて選択され得る。図７を参照のこと。広域的には、あるインプリメンテーションが、重大なリソースの過剰な使用を避けるため、または、画質または描写速度（ｒｅｎｄｅｒｉｎｇ　ｒａｔｅ）等のアプリケーション選好に基づいて最適化するために、別のものより好まれ得る。
【００５７】
各代替のインプリメンテーションは、システムメモリ、テキスチャメモリ、ＣＰＵ要求条件、そしてデータ転送帯域幅等のリソースのリストを有し、これらは、リソースのネゴシエーションが必要な場合には、これらの条件を縮小させ、そして、リソースが十分余っている場合には、この条件を拡張可能にするために使用される特定のインプリメンテーションと情報のインスタンスを首尾よく作るために必要とされる。
【００５８】
コンポーネントは、さらに、新しいリソースをシステムに導入し得る。図１９を参照のこと。各代替のインプリメンテーションは、該当する代替物によって提供されたリソースのリストを含む。新しいリソースは、さらに、リソースネゴシエーション情報を有し、新しいリソース上で次のネゴシエーションにおける供給側の取引をサポートする。
【００５９】
アプリケーション内のコンポーネントが識別された後、それぞれは、そのリソース要求について質問される。その答えは、代替のインプリメンテーションおよびそれらの要求されたリソースのリストにある。これらの要求の集計は、ランタイム多次元リソース割当タスクを特定する。
【００６０】
単一の解決法がある場合、選択された代替物は、各コンポーネントに通信され、次いで、各コンポーネントは、対応するインプリメンテーションのインスタンスを作り、このインプリメンテーションは、このインプリメンテーションのブロックの入出力のリンクとなるこのコンポーネントの入出力のリンクを有する。
【００６１】
代替のインプリメンテーションの一以上の組み合わせがリソース拘束条件に適合する場合、選択された構成は、コンポーネント定義に含まれる重み付けパラメータおよびアプリケーション開発者によって提供された評価等式に基づいている。この好適な解決法は、次いで、選択された代替物のインスタンスを作り、それらをフレームワークに連結するコンポーネントに通信される。
【００６２】
リソースが過度に申し込まれた場合、従って、直接的な解決法はなく、そしてシステムはネゴシエーションフェーズに入る。このネゴシエーションフェーズでは、各ブロックは、そのリソース要求のうちのどれが縮小され得るかということおよびそのようなトレードオフを形成したことに対するペナルティは何かということを質問される。典型的な例は、ぼやけた画像のペナルティに対して４分の１に縮小され得るテクスチャメモリリソースおよび余分なＣＰＵ利用およびデータ転送帯域幅消費を費やして完全な事前ローディングするよりも増分ページング機能によって最小化されたシステムメモリリソースである。このネゴシエーションは、受け入れ可能な構成が達成されるまで継続する。
【００６３】
リソース割当プロセスは、コンポーネントのインプリメンテーションが、全ての必要なリソースが利用可能にならない限りインスタンスを作られないことと利用可能なリソースに応答していくつかの代替物のうちのどれが選択されるかについての適切な決定とを確実にする。
【００６４】
（４．ブロック実行モデル）
図８に戻って、リソースネゴシエーションが完了された後、アプリケーションを含むブロックは、フレームワークのフェーズ間に、コンポーネント定義に明記されたように分配される。この結果、それぞれが０以上のブロックを含むフェーズリストが生じる。例えば、アプリケーションが標準データベース・ページングコンポーネントを含まない場合、データベース・ページングフェーズリストが空になる。それぞれの空でないフェーズリストは、潜在的に並行のアプリケーションのフェーズを定義する。
【００６５】
空でないフェーズは、実行のステージにマッピングされる。ステージは、図９に示すように、ＡＲＫが単一のスレッドにおいて実行するフェーズの集合である。結果として生じる実行のステージは、決定論的実行オーダーリストを生成することによって、実行のために準備される。この決定論的実行オーダーリストは、フェーズのブロックリスト内のブロックの全体の順序の中の接続によって強要された対様式のブロック順序（ｏｒｄｅｒｉｎｇ）を配列する。フェーズからステージへの処理の結果で生じる実行オーダーリストは、ＡＲＫへの入力であり、そしてこのようなリストの評価は、主たるＡＲＫ処理機能である。連続の実行環境において、単一のＡＲＫスレッドは、各パス間ブロックの一部または全てを選択しかつ実行する実行オーダーリストを超えて連続して繰り返す。ＡＲＫは、図１０に示すように、ブロックが異なるかまたは比較的主要な速度で走行する場合をサポートする。この図は、単一のＡＲＫスレッドマネジャーおよびその実行オーダーリストを表す。
【００６６】
ＡＲＫ内の並行サポートは、単一のプロセッサ上の複数のスレッド（マルチ−スレッディングまたはマルチ−プログラミングと称する）、複数のプロセッサのそれぞれの上の単一のスレッド（マルチ−プロセッシング）、およびこれらのモードの任意の組み合わせを統御する。並行実行において、Ｔ１〜Ｔｎの複数のＡＲＫスレッドがあり、それぞれは、図１１に示すように、それ自体のブロック実行オーダーリスト（ＥＯＬ）を有する。
【００６７】
平坦化されたアプリケーショングラフを複数のリストに変換することは、概して、ブロックのいくつかの間の接続がＡＲＫスレッド境界（異なるリストにおける上流および下流ブロックを有する）を広げることを引き起こす。これは、共有データに対する重大な影響、および大きな利点をアプリケーション開発者にもたらすようにＡＲＫによって不可視で処理されるケースを有する。
【００６８】
（Ｆ．ＧＡＰの拡張）
標準およびユーザ開発の両方のＧＡＰ機能は、コンポーネントとして設計されかつインプリメントされ、そしてそれ自体でそれらは、並外れた程度の柔軟性およ潜在的な効果を享受する。それらは、既存のコンポーネントを置き換え得、コンポーネント内の個々のブロックを置き換え得、既存の接続を変更し得、それ自体を既存のブロック間に挿入し得、およびそれらの代替のインプリメンテーションのそれぞれを有した所望の並行処理領域を定義し得る。これらのタスクのそれぞれは、シーングラフの匿名の「ツリー・デコレーション」モデルに対立するものとして、処理、効果、およびリソース影響をラベリングすることによって隠さずに行われる。ＧＡＰ拡張モデルにおける完全性は、任意のコンポーネントが殆どの任意のＧＡＰベースのアプリケーションにも加えられ得ることを保証する。コンポーネントは、それらの必要性のネゴシエーションを行い、ＡＲＫ最新統合プロセス（ｌａｔｅ−ｉｎｔｅｇｒａｔｉｏｎ）は、アプリケーションにおいて定義された選好を履行しながら、新しく挿入されたコンポーネントの要求に基づいてアプリケーションを広域的に調整する。
【００６９】
ＧＡＰの「普遍的なテクスチャ」機能を実行プロセスの例として考える。その所望は、単一の１０，９００テラバイト−テクスチャマップとしての地球表面のセンチメートル解像度の表示等の莫大な範囲のテクスチャ画像を有するアプリケーションを提供することである。この技術は、異なるハードウェアプラットフォーム上の同一のデータベースを用いる能力を提供するために、幾何学的細区分からのテクスチャページングの分離を含め、多くの実際的な利点を有する。これは、Ｃｏｓｍａｎ（１９９０）が最初に、Ｅｖａｎｓ＆Ｓｕｔｈｅｒｌａｎｄ　ＥＳＩＧ−４０００画像生成装置は何であるかについての文脈において記載している。これは、グローバルテクスチャ（ｇｌｏｂａｌ　ｔｅｘｔｕｒｅ）として既知である。
【００７０】
普遍的なテクスチャコンポーネントは、そのタスクを３ステップのプロセスでインプリメントする。すなわち、データをディスクからまたはネットワークを介してメインメモリに移動させるステップ、データをメインメモリからグラフィックスデバイステクスチャメモリに移動させるステップ、および画像情報およびフレーム毎を基礎とするダウンロードテクスチャを用いて普遍的テクスチャ概念をインプリメントするステップである。ＧＡＰインプリメンテーションは、これらのステップをいくつかの潜在的に並行処理するフェーズに分離し、それぞれは、ＡＲＫ接続を用いて相互接続されたいくつかのブロックを有し、全ては、リソース要求および選好に基づいて特徴付けられる。このインプリメンテーションは、ディスク転送のために効率がより高いダイレクトＩ／Ｏを用い、国際日付変更線および極でのキャッシュ更新複雑性を統御するテクスチャキャッシュとしてメインメモリを用い、普遍的テクスチャ意味論をインプリメントするために必要とされるようにテクスチャ処理詳細を再定義する。このコンポーネントがＧＡＰベースのアプリケーションに挿入される場合、それは、普遍的テクスチャ機能を、更新または他のモジュールの再コンパイルを要求することなく正しく提供し、グラフィックスハードウェアの範囲にわたってそのようなことを行う。
【００７１】
普遍的テクスチャをインプリメントするのに有用な特別の機能（例えば、Ｅ＆Ｓ広域テクスチャユニット、ＳＧＩクリップマップハードウェア、ＳＧＩＵＭＡビジュアルワークステーション、Ｓ３テクスチャ圧縮モード等）を提供するハードウェアベンダは、標準ＧＡＰインプリメンテーションをハードウェアの異なる機能にアクセスするものと置き換え得る。このようなベンダの局在性は、グラフィックス以上のものを定義する。それらは、さらに、ネゴシエーションの間に解決されたように、テクスチャロード待ち時間および他のコンポーネントとの相互作用のような問題に基づいてそれらのインプリメンテーションを適合させるために、並行モデルおよびアプリケーション構造を明記する。
【００７２】
図１２に示される地球眺望画像等の普遍的テクスチャ機能を用いるアプリケーションは、それらが実行された場合にベンダ特有のチューニングを受け継ぎ、そして以前にリリースされたＧＡＰベースのアプリケーションソフトウェアでさえ新しいハードウェアの利点にアクセスするために変更または再リリースを要求しないので、ハードウェア開発者が、それらの新しい機能の選定速度をいかに大きく増大し得るかを示す。
【００７３】
（Ｇ．ＧＡＰによる世界）
ＧＡＰアーキテクチャは、新しいインプリメンテーション技術を実時間画像化市場にもたらしている。これは、垂直なアプリケーションレベルの機能をそれらのインプリメンテーション環境から分離する。この分離は、従前からもつれ合った、アプリケーション開発者、コンテンツ開発者、およびハードウェア開発者のタスクを以下のようにもつれを解くことによって、グラフィックスおよびマルチメディアアプリケーションのモジュール性を拡張する。
【００７４】
アプリケーションおよびコンテンツの分断。ＧＡＰは、コンテンツから大きく独立してアプリケーションを形成する。これは、モデル構築者によってコンテンツとともにパッケージングされた挙動モジュールが、移植可能な挙動定義を提供し得るからである。モデリングツールとＧＡＰとの間の意味論上のブリッジは、モデリングツール内の活性な（ａｃｔｉｖｅ）コンテンツによって表示された特性が、このコンテンツがＧＡＰベースの実時間ソフトウェアに用いられた場合に示されたものと一致することを確実にする。
【００７５】
コンテンツおよびハードウェアの分断。ＧＡＰ環境は、コンテンツレベルの設計をハードウェアレベルのこれらの決定の表現から分離する。その構造により、コンテンツ開発者によってではなくハードウェアベンダによって、標準ＧＡＰコンポーネントのポーティング（ｐｏｒｔｉｎｇ）およびチューニング（ｔｕｒｎｉｎｇ）を通じて、各ハードウェアプラットフォームに合せられる意図の標準定義に基づくコンテンツの開発が可能になる。
【００７６】
ハードウェアおよびアプリケーションの分断。ＧＡＰは、アプリケーション開発者の独特のハードウェア特徴への依存性を取り除き、特定のハードウェアおよびオペレーティングシステムの組み合わせよりも、「仮想の」画像化プラットフォームのためのアプリケーション開発が可能になる。逆に、ＧＡＰは、ハードウェアベンダがハードウェアの独特の特徴を既存のアプリケーションに統合することを可能にし、アプリケーションを特別のハードウェア機能に引き付けることについてのベンダの関心を和らげる。
【００７７】
（ＩＩ．ＧＡＰおよびＡＲＫ）
（Ａ．プラットフォームおよびフレームワーク）
開発者は、かれらがソフトウェアをポートする場合に、一般的に、「私は、私のアプリケーションをＷｉｎｄｏｗｓ（Ｒ）プラットフォームに移動させた」または、「Ｐｏｗｅｒ　ＰＣプラットフォーム上で利用可能である」と言うことによって、プラットフォームのことを評するが、定義があまりにルーズであり、我々の目的に供することができない。用語「プラットフォーム」が本明細書で用いられる場合、それは、いくつかの種類のプログラムを実行するために自己に包含された環境を意味する。最も共通するプラットフォームは、システム関連および言語関連のランタイムライブラリと一緒のオペレーティングシステムである。ＥＭＡＣＳのようなアプリケーションは、ユーザ拡張可能な方法で内部リスプインタープリターによって一緒に結ばれた低レベルのテキストマネジメント機能を提供し、アプリケーションレベルのプラットフォームの進化論的な先祖である。本明細書に記載されたプラットフォームの種類は、ＥＭＡＣＳのようなアプリケーションおよび伝統的なオペレーションシステムプラットフォームとは異なる。差異および差異の原因を明らかにするため、３Ｄグラフィックスの話題をわきに置き、空間音声を少しの間わきに置き、そして概念が自明であるウェブブラウザ空間におけるプラットフォームおよびフレームワークについて考える。
【００７８】
Ｊａｖａ（Ｒ）ｓｏｆｔ　Ｊａｖａ（Ｒ）環境において、Ｊａｖａ（Ｒ）仮想マシン（ＪＶＭ）は、Ｊａｖａ（Ｒ）バイトコードを実行するためのプラットフォームである。ＪＶＭをバイトコードの形態の標準Ｊａｖａ（Ｒ）クラスで組み合わせると、Ｊａｖａ（Ｒ）アプリケーションのためのプラットフォームが生成される。類似の意味において、ネットスケープおよびマイクロソフトのインターネットエクスプローラーは、双方、ＨＴＭＬを実行するためのプラットフォームを含む。スクリプトリングかつプログラミングの拡張でパッケージングされた場合、これらのブラウザは、ブラウザアプリケーションのコンテキスト内のウェブページを実行するためのプラットフォームを表す。オペレーションシステムコンテキストにおいて、プログラムおよびシェルスクリプトは、ＨＴＭＬページを置き換え、そしてオペレーティングシステムはプラットフォームである。
【００７９】
ブラウザはまた、アプリケーションであるが、アプリケーションおよびプラットフォームの間の区別は微妙であり、しばしば、見落とされる。ネットスケープのアプリケーションは、ネットワークされたペーパレスの通信（ＨＴＭＬブラウジングおよびエディティング、電子メール、ニュースリーディング、その他など）、グラフィカルユーザインターフェース、および好みのウェブサイトへのリンクのようなナビゲーション支援に関連する機能を提供する。ネットスケープのプラットフォームの局面は、「プログラム」をロードする機構（ＨＴＭＬ、Ｊａｖａ（Ｒ）、ＣＧＩスクリプト等のフェッチ）、これらのプログラムの意義のための標準化された意味（ｓｅｍａｎｔｉｃｓ）、およびＨＴＭＬ、Ｊａｖａ（Ｒ）、そしてスクリプト言語で書かれたプログラムを評価するランタイムの「エンジン」から成る。歴史的に、ネットスケープのブラウザ製品は、これらの二つの役割を別々の局面として顕示しなかった。人は、ウェブページ、ｊａｖａ（Ｒ）アプレット、ブラウザのＧＵＩまたは他の「内側に構築された（ｂｕｉｌｔ　ｉｎ）」機能を再定義または拡張するＣＧＩスクリプトをつくることができず、また、ユーザは、ナビゲータブラウザインターフェースを異なるＨＴＭＬプラットフォームに移動させることもできない。しかし、ネットスケープがその能力があるように設計されたらどうなるだろうか。
【００８０】
１．それらは、ＨＴＭＬ、Ｊａｖａ（Ｒ）、およびスクリプト言語をフェッチし、実行することができる「ブラウザバーチャルマシン」を構築するだろう。これは、プラットフォームとなるだろう。全員がそれを走行させるだろうが、それについて知っているものは小数であるだろう。なぜなら、・・・。
【００８１】
２．それらは、機能においてネットスケープナビゲーターと同一であるが、ＢＶＭによって実行可能なコードのモジュールでインプリメントされる「ブラウザアプリケーション」を構築するだろう。これは、エンドユーザが見て、見て感じる（ｌｏｏｋ−ａｎｄ−ｆｅｅｌ）のすべてがそこにあるアプリケーションであるだろう。例外として・・・。
【００８２】
３．それらは、「拡張および置換」能力をＢＶＭに構築するだろう。このため、開発者は、標準ブラウザアプリケーションのあらゆる局面を造り直すことができる。例えば、「ＧＵＩモジュール」をそれら自体の一つと置き換えること、または、「ＨＴＭＬモジュール」を新しい機能とともに拡張することができる。
【００８３】
ネットスケープおよびマイクロソフトの双方は、このアプローチの重要性を認識する。それぞれは、ＨＴＭＬ、Ｊａｖａ（Ｒ）　Ｓｃｒｉｐｔ、およびＪａｖａ（Ｒ）を統合する他のアプリケーションを開発するための基礎として機能し得るウェブブラウジングへのプラットフォームおよびフレームワークのアプローチに対するサポートを公表している。マイクロソフトは、現在、ユーザインターフェースを置き換えさせ、標準機能を再定義するプラグ内蔵（ｐｌｕｇ−ｉｎ）のモジュールを受け入れ、他のアプリケーション内のＨＴＭＬレンダリングをサポートするプラグ内蔵モジュールとして機能し得るブラウザを提供する。この競合したプラットフォームの設計および構造は、全く異なっている。
【００８４】
・・ネットスケープのアプローチは、アプリケーションから独立したオペレーティングシステム内の完全なブラウザプラットフォームであることである。それらは、ＣＯＲＢＡコンポーネントプログラミングモデルを使用し、それらのＣＯＲＢＡインプリメンテーションはＪａｖａ（Ｒ）で書かれている。
【００８５】
・・マイクロソフトのインターネットエクスプローラーおよびインターネットエクスプローラーアプリケーションキットは、オペレーティングシステムをブラウザを行うためのプラットフォームとして定義するための戦い（ｆｉｇｈｔ）におけるキー機能のためのＷｉｎｄｏｗｓ（Ｒ）オペレーティングシステムサービスに依存する。ＩＥＡＫは、ＣＯＭコンポーネントプログラミングモデルおよびＣＯＭベースのＡｃｔｉｖｅＸコンポーネントを用いる。
【００８６】
・・ＳｕｎのＪａｖａ（Ｒ）は、第三の観点を取り、それらのプログラミング言語を普遍的なプラットフォームとして配置する。それらは、言語のランタイム環境におけるオペレーティングシステム機能性を含み、それらのインタープリタ内の本来利用可能な要素としてブラウジング（ＡＷＴ、Ｊａｖａ（Ｒ）２Ｄ、Ｊａｖａ（Ｒ）３Ｄ等）に必要なあらゆる機能の管理を委任する。
【００８７】
モジュールを拡張するおよびモジュールに取って代わる能力を提供することは、アプリケーションが通例のものよりより高度の柔軟性および一般性を有するように構築されることを要求する。「アプリケーションフレームワーク」は、まさにこの種類の変わり易いアプリケーションであるように定義される。アプリケーションフレームワークは、（おそらく潜在的な能力を有するにもかかわらず）完全なアプリケーションであるがことが明白に意図されることに留意のこと。この完全なアプリケーションは、アプリケーションが構築され得る構成セットよりもむしろ、すでに一般的な事項を標準的な方法で行っている。二つのアプローチ間の相違は、二つのクリスマスツリーキットを対比することによって、明らかになされ得る。
【００８８】
１．構成セット：頑丈なツリー、光の箱、装飾の大きな箱、およびフックがない。「Ｇｏ　ｆｏｒ　ｉｔ」という取扱説明書が付属し、そして美しいツリーの写真（ｄｅｍｏｓ；−）である。
【００８９】
２．フレームワーク：光、フック、および事前に取り付けられた少しの装飾を有する同じツリー。フックにより、何でも付加的な装飾を取り付けることができる。（光および装飾を取り除くこともできる。）
ある意味、これは、程度の問題にすぎないが、重要な概念である。
【００９０】
フレームワークは、独立した開発チームが、全く同一の方法で共通の概念について「話す」（その概念を信頼してモジュールを書き込む）ことができる構造を提供する。それは、さらに、プログラミングの複雑さが、標準のアプリケーションと新しいアプリケーションとの間の相違を制限されるために開発が容易になることを意味する。標準アプリケーションが共通機能の大部分を提供する場合、したがって、この相違は小さい。構成セットのアプローチは、常時、結果としてのアプリケーションの複雑さに比例するプログラミング労力を要求する。これらの効力は、フレームワークの相乗効果を定義する。フレームワークは、新しい開発を増分したのものに変化させ、他のものと共用され且つ他のものにライセンス提供し得るモジュールを助成する。
【００９１】
これらの概念が、ブラウザから実時間グラフィックの世界に翻訳された場合、それは、良好な調和であるが、ブラウザの類似性の部分ではない、いくつかの要求の多い問題が、対処されなければならない。これらの問題は、時間、同期、並行処理、および性能管理を含む。プラットフォーム（ｐｌａｔｆｏｒｍ）およびフレームワーク（ｆｒａｍｅｗｏｒｋ）の観念は、本明細書において記載された本発明の基本であり、そして、移植性があり、高性能の、メディアリッチなアプリケーション（ハードウェアによって提供された相違の全ビットを使用する）を可能にする。
【００９２】
本明細書において記載されたプラットフォームおよびフレームワークの概念のインプリメンテーションにより、結果として他のプラットフォームからの二つの主要な相違が生じる。
【００９３】
−−まず、互換性以前に性能のために設計することによって、ＣＯＲＢＡ（Ｒ）およびＣＯＭ（Ｒ）コンポーネントインターフェースによって直面する複雑さの多くは回避される。特に、これらのそれぞれは、他のものの支配を探求するので、それらは、互いのコンポーネントを外部機能インターフェースを通じてサポートすることを試みる。：Ｉｎｔｅｒｎｅｔ　Ｅｘｐｌｏｒｅｒ（Ｒ）のようなＣＯＭ（Ｒ）ベースのアプリケーションは、ＣＯＲＢＡ（Ｒ）コンポーネントを含み得、Ｎｅｔｓｃａｐｅ（Ｒ）のようなＣＯＲＢＡ（Ｒ）ベースのアプリケーションは、ＣＯＭ（Ｒ）コンポーネントを含み得る。このような互換性は、性能および複雑さの点で有意な支出に達する。ここでは、外部の互換性は、必要とされない。インターフェースモデルは、アプリケーション目的および根底をなすインプリメンテーションに最も良く適合するように構造化され得る。
【００９４】
−−第二に、マルチスレッディングは、我々のプラットフォームの固有の機能としてサポートされる。コンポーネントインターフェースは、不可視の並列処理を効率的にインプリメントする場合にパートナーであるように（アプリケーションレベルの実時間カーネルと共に）設計される。これは、順番に並んだロックが各エントリポイントを完了しない限りそれ自体スレッドセーフ（ｔｈｒｅａｄ−ｓａｆｅ）でなく、かつ、コンポーネント構築者に対する並列処理の問題がそのままになっているＣＯＭ（Ｒ）およびＣＯＲＢＡ（Ｒ）と対照的である。
【００９５】
これらの相違は、ＧＡＰを他のミドルウェア（ｍｉｄｄｌｅｗａｒｅ）のフレームワークから区別する。
【００９６】
（Ｂ．アプリケーションプラットフォームとしてのＧＡＰ）
図１３Ａを参照して、ＧＡＰは、グラフィカルアプリケーション開発のためのプラットフォームをインプリメントする。目的のアプリケーションの関連のある割合は、アプリケーション開発者によってＧＡＰに加えられ得る新しい能力と組み合わせて、ブロックと呼ばれる拡張モジュールの形態でＧＡＰによってサポートされる機能（ｆａｃｉｌｉｔｉｅｓ）内に表現可能である。ＧＡＰの「プラットフォームフード（ｐｌａｔｆｏｒｍｈｏｏｄ）」は、この構造から生じる。
【００９７】
カーネル。アプリケーション実時間カーネル（ＡＲＫ）、アプリケーションレベルの実時間スレッドマネジャー。ＡＲＫは、各利用可能なＣＰＵ上で実行する一以上のＡＲＫスレッドのそれぞれによって実行されるブロックを列挙するスケジュールによってブロックを呼び出す。システム構造基盤エレメントの非常に小さいセットは、ＡＲＫに付随する（およびある場合には、ＡＲＫに構築される）。これらのエレメントは、コンポーネントを動的にロードおよびアンロードし、ブロック実行をモニタし、スレッド管理のようなタスクにおいて、メモリ共用、相互排除、および同期化を支援する。
【００９８】
ＡＲＫは、効率的に構成可能な実時間の性能を中心とするグラフィックバーチャルマシンの定義および実行フレームワークを最も良好に考えられ得るモジュラー的なフレームワークを提供する。ＡＲＫは、データの流れを管理し、グラフィックスプロセスの処理のすべてをスケジューリングするように設計される。それは構造および意図を理解し、ついで、その意図を実時間で効率的かつ頑丈に管理することによりアプリケーションを少しづつ要約する洗練された接着剤である。可能な限り薄くかつ軽くなるように設計されるが、ＡＲＫは、最初から効率的なランタイムインプリメンテーションに対応するように設計された頑丈なアプリケーション定義のセマンティクス（ｓｅｍａｎｔｉｃ）からパワーを得る。ＡＲＫは、アプリケーション定義（データの流れおよび処理スケジューリングを含む）を明示的かつモジュール的にする。それは、より遅い機能インターフェース（すなわち、処理とデータの流れを分離する）よりも、高度に効率的なデータインターフェースを有するモジュール的なコードセグメント間のインターフェースを抽象化する。それは、開発者に、マシンのコンポーネントの垂直的な（ｖｅｒｔｉｃａｌ）機能開発を可能にする全体のアプリケーション機構への明示的な定義および関連の各コードモジュールを強要する。これらのコンポーネントは、素早くかつ現在のプログラミング方法論（ｃ／ｃ＋＋等）とは別個に開発される。すなわち、ＡＲＫは、標準プログラミングの方法論の開発者の使用上への直接的な影響を殆どまたは全く有さない。したがって、ＡＲＫは、事実上、全体のアプリケーションに対する新しい機能レベルの駆動モデルを定義する。この新しいアプリケーション駆動モデルは、（忠実に再構成可能なマルチスレッドされたアプリケーションのために必要な）自動的に再構成可能なマルチ−スレッド・マルチ−プロセス・マルチ−バッファの、単一スレッドコードモジュールのデータ管理を固有に提供する。ＡＲＫは、システムモジュール間に流れる全てのデータを管理するが、データ構造に寛容であり、複数の開発者にまたがってさえもユーザ定義のデータ構造のランタイム拡張を許可および管理する。要約すると、ＡＲＫは、アプリケーションを、そのコードモジュール、データ構造、およびデータの流れから定義する能力を提供する。すなわち、それは、定義時間のセマンティクスを（データの流れおよびモジュールスケジューリングの制御を介して）実施する効率的なランタイムカーネルとして動作するために必要なすべてを提供する。
【００９９】
ブロック。ＡＲＫについてのすべては、新規かつ力強いネゴシエーションベースのインターフェース定義をサポートする置き換え可能なコンポーネントにグループ化されるブロックを用いてインプリメントされる。用語「モジュール」は、三つのタイプのブロックへの一般的な参照である。その三つのタイプのブロックは、演算を行うシンプルブロック、内部的にインスタンス化されたブロックを接続するコンパウンド（ｃｏｍｐｏｕｎｄ）ブロック、およびシンプルおよびコンパウンドブロックの接続されたネットワークであるスーパーブロックである。コンポーネントは、特殊なメタブロックである。それらは、スーパーブロックの集合をリソースネゴシエーションの完成時に配達する「ブロックファクトリー」である。システムに関連するブロックに加えて、多数の標準的な機能レベルのコンポーネントが、ＧＡＰに提供される。これらのエレメントは、共通して用いられる機能（ウィンドウを開く、４元数（ｑｕａｔｅｒｎｉｏｎ）を補間する、位置を通報する、システムに特有のチューニングに従順な機能（オブジェクトをモーフィングする、バンプマップされた表面のシェーディング、ダイレクトＩ／Ｏ転送）、およびＧＡＰベースのアプリケーション（ユニバーサルテクスチャ、テラ引（ｔｅｒｒａｉｎ）、オブジェクト、およびカルチャ（ｃｕｌｔｕｒｅ））を区別すると信じる機能をインプリメントする。ブロック自体は、参照コードに移植可能にインプリメントされ、そしてハードウェア製造者の装置で特定のハードウェアのために特別にチューニングされる。この構造およびチューニングスキームは、ＧＡＰの主要な「区別されるが、移植可能である」メカニズムである。
【０１００】
接続。ブロックは、上流ブロックから下流ブロックへのデータの流れを表わす一方向の接続によってリンクされる。接続は、設計の重大なエレメントである。それは、新しいブロックを挿入するかまたは古いブロックを置き換える場合に必須のタスクである通信パターンを変更するために「プラグボード（ｐｌｕｇ　ｂｏａｒｄ）」を提供するからである。例えば、潜在的に可視のオブジェクトを抽出するためのグラフを横断させるコンポーネントと、オブジェクトを受け取り、次いで、それを描くコンポーネントとの間の接続を考慮する。本発明では、新しいコンポーネント、例えば、これら二つの間で、所与のサイズより小さい画面上の投影を有するものを拒絶するものを挿入することが望み得る。そのようなことを行うことは、横断および描画間の接続を削除すること、および横断と拒絶との間、および拒絶と描画との間の接続を追加することを意味する。これは、ＡＲＫの特殊なランタイム接続機能を通じて何らのブロックを再コンパイルすることなく、サポートされる。
【０１０１】
元からコンパイルされ、そして最適化されたコード（アセンブラー、Ｃ、Ｃ＋＋等）は、ブロック開発のための第一のインプリメンテーションモードとしてサポートされ得る。本来のコードアプローチは、純粋な翻訳に比較して移植性を制限するが、スピードに対するニーズがある。ブロックは、コンパイラーの互換性の程度において移植性があり、ブロックの開発者は、異なるプラットフォーム上において、条件付きのコンパイルまたはその代わりのインプリメンテーションを必要とし得る。
【０１０２】
元からコンパイルされたモジュールおよび言語に依存しないインターフェース定義のＧＡＰサポートは、開発者がＡＲＫのためのアプリケーションを構築した場合にすでに開発済みの技能およびコードを使用し得ることを意味する。
【０１０３】
いくつかのブロックは、他のブロックを一緒に処理しているグラフ（ｇｒａｐｈ）に組み入れることによって純粋に表現され得る。これらのタイプのブロックは、処理を行う「シンプルブロック（ｓｉｍｐｌｅ　ｂｌｏｃｋｓ）」に対立するものとして「コンパウンドブロック（ｃｏｍｐｏｕｎｄ　ｂｌｏｃｋｓ）」呼ばれる。接続専用のブロックを開発することは、ブロックへのおよびブロックからのリンクおよびブロック入力からのおよび出力への連結および内部でインスタンス作成されたブロック間の連結を定義することを意味する。これは、スクリプト言語または特別の軽い接続構文分析を通じてなされ得る。このような網目状のブロックは、ランタイムブロックコードを必要とせず、各「リンクからリンクへ（ｌｉｎｋ−ｔｏ−ａ−ｌｉｎｋ）」を単一のリンクに自動的に崩壊させる（ｃｏｌｌａｐｓｉｎｇ）ことによって、または、等価的にコンパウンドブロックを使用前に拡張されるマクロと考えることによって処理され得る。
【０１０４】
処理している負荷（ｄｕｔｉｅｓ）が軽いまたはまれな場合にスクリト言語を用いてブロックをインプリメントすることが望ましくあり得る。翻訳されるスクリプトは、コンパイラの変形物に無関係にＧＡＰインプリメンテーションにわたって保証された移植性を提供する。この計画は、柔軟性のあるスクリト機構（主として、マーク・アンド・スイープ廃物収集のように非決定論的処理を扱い、および、引数をインタプリータにおよびインタプリータから整列させる）を作成することであり、その結果、種々の言語が、同一の構造基盤によってサポートされ得る。
【０１０５】
（Ｃ．アプリケーションフレームワークとしてのＧＡＰ）
ＧＡＰは、グラフィカルアプリケーション開発のためのフレームワークも提供する。これは、開発者が直接使用し得るまたはそのほかに、望むように変更および拡張し得るグラフィックスアプリケーションである。このアプリケーションは、エンドユーザに配信され得る、著しく能力のある双方向グラフィックスビューアー（ｖｉｅｗｅｒ）を提供する。アプリケーション開発者は、ＧＡＰベースの製品を出荷する前にカスタムブロックを追加すること、および標準のもののいくつかと置き換えることによってアプリケーションに新形態をとらせ得る。標準のアプリケーションを提供することによって、共通のネーミングおよび構造フレームワークが、派生されたアプリケーションのために確立される。混合および調和の柔軟性が、具体的なコンテキストにおいて組み込まれる。
【０１０６】
概念的に、フレームワークアプリケーションは、以下の方法で設計される。第一に、ＧＡＰが処理するアプリケーションの分類が考えられる。これは、グラフックスに富むゲームおよび双方向エンターテイメント、従来のビジュアルシミュレーション、ビデオおよびフィルム製品および無線放送における実時間アプリケーション、および特命リハーサルに用いられる高度な地形空間（ｇｅｏ−ｓｐａｔｉａｌ）情報システム；１〜８の範囲のＣＰＵおよび１〜６のグラフィックスパイプラインのハードウェア構成；およびＷｉｎｄｏｗｓ（Ｒ）９８、Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴ、およびＵｎｉｘ（Ｒ）ライクの（ＩＲＩＸ、Ｓｏｌａｒｉｓ、およびＬｉｎｕｘ）オペレーティングシステムを含む。次に、これらのアプリケーションは、それらが必要とする共用体を処理し得る一般的な構造を見出すように試験される。得られる構造は、統一アプリケーションフレームワークを定義する。この統一アプリケーションフレームワークは、次いで潜在的な並行処理実行フェーズにセグメント化される必要がある。次いで、フレームワーク内のキー機能は、標準コンポーネントとして表現される。それらを含むブロックと同調するコンポーネント定義は、標準のブロックを定義する。
【０１０７】
ハードウェアの高度化においてアプリケーションドメインおよびレベルにわたる共通の基盤を見出すために努力を発揮することは、Ｇが、より低いコスト、より高い容量のプラットフィームに移動する（ｍｉｇｒａｔｅ）ような高度な機能のために自然なホームを提供することを意味する。
【０１０８】
設計は、複数のＣＰＵおよび複数のグラフックスデバイスへの拡張をサポートするが、これは、より小さい構成に対するオーバーヘッドを意味しない。高度な構成においてより完全に常駐させる構造が提供され得る。いくつかの重要な特徴が、ＧＡＰ一般に対する設計を暗示し得るフレームワークアプリケーションの設計の間に現れる。ここに要約がある。
【０１０９】
−−本発明の実施形態において、この設計は、アプリケーションの種々の部分におけるデータフローの間のバッファとして、大抵は、データがレンダリング期間にわたって再利用される洗練されたキャッシュの形態の、洗練された高レベルのデータ構造を採用する。ブロック形態において、これらの構造は、小さい制御インターフェースおよび暗黙の内部プロセッシングを有する。例は、オブジェクトグラフ、アーティキュレーショングラフ（ａｒｔｉｃｕｌａｔｉｏｎ　ｇｒａｐｈ）、アトラス（ａｔｌａｓ）および索引マップ、オブジェクト、イメージ、およびオーディオキャッシュ、および、コマンドおよびクラシフィケーション（ｃｌａｓｓｉｆｉｃａｔｉｏｎ）およびビンズス（ｂｉｎｓ）を含む。
【０１１０】
−−初期のプロセッシングコンポーネントは、概して、それら自体の両方と後部側との間で非同期である。終末ステージは、より簡単であり、イメージ演算レートで同期して実行する。
【０１１１】
−−大抵の接続は、フェーズに対してローカルである。二つの主要な例外がある。より低いレベルのＧＡＰ標準ブロックのいくつかへの連結は、どこにでも発生するが、並列処理に対して容易であるように見える。少数の連結は、ブロックグラフの前端近くから後端近くに移動し、短絡的な非同期の実行を行い、そして終端の間にパイプラインを形成する。
【０１１２】
フレームワークとして、このアプリケーションは、広い分類のグラフィカルアプリケーションのために共通のすべてを包含する構造を提供する。すなわち、取り除かれ、置き換えられ、および拡張され得るブロックから構築された構造であり、切断および再接続され、露出および隠され得るブロック間の接続を有する。これにより、開発者は、システムの残りを無処理かつ他のものによって拡張可能なままにしながら、アプリケーションをインプリメントするのに必要なだけのＧＡＰフレームワークに新形態をとらせることができる。また、それは、開発者が、変化させる必要があるだけのＧＡＰを理解および接触することのみが必要であることを意味する。
【０１１３】
これは、図１３Ａおよび１３Ｂに示されている。図１３Ａは、ＡＲＫによって提供された機能を用いるグラフィックスソフトウェアを示し、複数のハードウェアプラットフォームのいずれかの上での実行を促進する。対照的に、図１３Ｂは、アプリケーションに特有である機能を用いるグラフィックスソフトウェアを示し、複数のハードウェアプラットフォームのいずれかの上での実行を促進する。
【０１１４】
この柔軟性は、図１４Ａおよび１４Ｂに示されるように、ハードウェア開発者にさらに利用可能であることに留意のこと。図１４Ａでは、ハードウェアプラットフォームの開発者は、ＡＲＫによって提供された機能を用い、これにより、異なるソフトウェアプログラムがプラットフォーム上で実行することができる。図１４Ｂは、これに対して、ハードウェア開発者が代わりに、デバイス特有の機能を用いる場合を示し、これにより、異なるソフトウェアプログラムがプラットフォーム上で実行することができる。
【０１１５】
図１５は、類似の機能を行う異なる機能の利用可能性を示す。ここで、この機能は、シェーディング機能である。一般的なシェーダーが利用可能である。さらに、異なるシェーダーもまた、異なるグラフィックスソフトウェアによって開発されそして採用され得る。同様に、さらに他のシェーダーが異なるハードウェアデバイスのために採用され得る。
【０１１６】
図１６Ａおよび１６Ｂは、本発明の実施形態における、ＡＲＫ、アプリケーション、および二つのハードウェアプラットフォーム、プレイステーション２（Ｐｌａｙｓｔａｔｉｏｎ２）およびパーソナルコンピュータそれぞれの間の論理的な関係を示す。それぞれは、機能、すなわち、拡張が、ソフトウェア開発者（ハードウェアの属性を導入するために）か、またはハードウェア開発者（ソフトウェアの属性を導入するために）のいずれかによってどのように生成され得るを示す。また、これらの図は、Ｃ＋＋等のツールがソフトウェアの開発を促進するためにどのように用いられ得るかを示す。図１６Ｃ〜１６Ｅおよび１８は、種々のソフトウェアプラットフォームとＧＡＰとの間の論理的な関係をさらに示す。
【０１１７】
図１７は、実行中のデータフローの観点からこれらの関係を示す。アプリケーションは、出力オブジェクトおよびシーングラフ（ｓｃｅｎｅ　ｇｒａｐｈ）を生産するように示される。示された実施形態では、ハードウェアは、最終的には、ＧＡＰマイクロコードを介してアクセスされる。
【０１１８】
（Ｄ．ＧＡＰの理解）
フレームワークアプリケーション、コンポーネント、フェーズ、ブロック、接続、および実行セマンティックスを記載する前に、フレームワークおよびアプリケーション開発者の観点からのＧＡＰの主要なエレメントが考慮される。
【０１１９】
（１．ブロック）
ブロックは、ＧＡＰフレームワークの基本的なエレメントであり、本発明による双方向ビジュアル演算の「アトム」を定義する。用語「モジュール」は、三分類のブロックのいずれも意味する一般的な用語である。この三分類のブロックは、ブロック、スーパーブロック、およびコンポーネントである。ブロックは以下によって構築される。
【０１２０】
−−標準テンプレートを編集することまたはコーディングによって、コード発生ツールを用いてＧＡＰブロックインターフェース定義を生成する。この定義は、各入力および出力接続ポイントおよび全機能のタイプおよび名前を特定する。これは、ブロックが他のブロックに対して提示するインターフェースを集約的に特徴付ける。
【０１２１】
−−コンパイルされる手続またはインタプリータ入力スクリプトを要求されたブロックの実行可能なエレメントに結合する。これらの手続は、コンストラクター機能、初期化機能、デストラクター機能、およびブロックの暗示的演算としての単一の手続を含む。ブロック初期化機能は、特別のＡＲＫデータ割当機能を用いて内部データを割り当てる。本発明の実施形態において、文字の値および固有のオブジェクトから派生された動的に割り当てられたデータタイプのみが、接続を介してアクセスされ得る。
【０１２２】
−−一旦構築されると、ブロックは、その入力および出力ポイントと、他のブロック上のコンパチブルなポイントとの間に接続を構成することによって、アプリケーションまたはより高レベルのブロックにリンクされる。
【０１２３】
実行可能なブロックコンテンツは、他のブロックによるデータ出力に実際に関連する、特別な変数または関数に関連して分散されたＣまたはＣ＋＋コードであり得る。時折、ブロックは、プロセッシンググラフに接続されたいくつかの他のブロックを含む。これらは、「コンパウンドブロック」と称され、それらの定義における内部のネスティングは、任意の有限の深さに支持される。今後、実行可能なブロックコンテンツは、さらに、どのようなスクリプト言語または言語がサポートされたとしても、スクリプトであり得る。
【０１２４】
ブロックは、ＧＡＰ内の原子的（ａｔｏｍｉｃ）な実行ユニットであり、入力および出力連結が生成される（ａｔｔａｃｈ）レベルである。接続の詳細は、後に提示されるが、本発明の実施形態では、ブロックは、その入力を提供するブロックのアイデンティティまたはその出力に接続するブロックのアイデンティティを知らないことを理解することは重要である。ブロックインターフェース定義に特定化されるデータにより、ＡＲＫは、不可視かつ効率的に、コンパイルされたブロックのためのこのランタイムダイナミック接続機能をインプリメントすることができる。
【０１２５】
何がブロックを定義するか。ある例では、図６に模式的に示されるように、ブロックは、以下のエレメントを含む。
【０１２６】
１．以前に言及されたように、各ブロックは、一組の０以上の入力接続ポイントを有する。各入力ポイントは、名前およびタイプを有する。名前は、ブロックに接続をつくる場合に用いられ、そして、入力を介して利用可能なデータは、この名前によって内部的に参照される。タイプは、ＣまたはＣ＋＋構造によって表わされる混合されたデータ構造であり得る。この場合、ブロック内のアクセスは、これに対するシンタックス（ｓｙｎｔａｘ）は現在決定されていないが、この集合「名前」に加えて「名前のメンバー」へのものであり得る。
【０１２７】
２．ブロックは、一組の０以上の出力ポイントを有する。出力ポイントのそれぞれは、さらに、名前およびタイプを有する。これらの名前は、互いにおよびブロック内の入力名とは別個でなければならない。各出力ポイントは、固有のオブジェクトベースクラスから派生され、ランタイムに割り当てられるブロックの内部データメンバーまたは、このようなオブジェクトのメンバーのいずれかに対応する。これらの内部オブジェクトへのアクセスは、対応する出力ポイントに接続される他のブロックに提供される。
【０１２８】
３．ブロックは、出力ポイントを介して共有されない、一組の内部の固有のオブジェクト、および、固有のオブジェクトベースクラスから派生されない一組の他の内部オブジェクトを有し得る。固有のオブジェクトベースクラスから派生されないオブジェクトは、接続を通じて共有されない場合があり、ブロックベースクラスから派生されたオブジェクトだけが接続を有し得る。
【０１２９】
最後に、各ブロックは、１以上の関数を含み得る。ｃｏｎｓｔｒｕｃｔ（）、ｄｅｓｔｒｕｃｔ（）、およびｉｎｉｔｉａｌｉｚｅ（）の関数は、オブジェクトライフタイムサービスを提供し、ｅｖａｌｕａｔｅ（）関数は、ブロックのプロセシングをインプリメントする。元のコンパイルされたブロックでは、ブロックが実行されるべき場合はいつでも、ＡＲＫは、サブルーチンコールを介してそれを呼び出し、インタープリットされたブロックでは、登録されたインタプレータが関数定義としての評価関数の本体と共に呼び出される。
【０１３０】
（２．標準ブロック）
図５に示されるように、ＧＡＰブロックの分類は、三つの広いファミリーを有する。すなわち、ＡＲＫおよびＧＡＰ基盤構造（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）をインプリメントするブロック、ハードウェアおよびパブリックデータ構造に対するグローバルなリソース管理（ｒｅｓｏｕｒｃｅ　ｍａｎａｇｅｒ）を表わすブロック、および、アプリケーションレベルの機能（ｆｅａｔｕｒｅ）を提供するブロックである。機能は、さらに、それらの開発者対象者の大きさ（ｂｒｅａｄｔｈ）に基づいて細分される。すなわち、多くのアプリケーションに有用である標準ブロック、特定の産業内の広い使用のためのマーケット指向（ｍａｒｋｅｔ−ｏｒｉｅｎｔｅｄ）のブロック、および特定のアプリケーションの詳細をインプリメントするアプリケーション特有（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ）のブロックである。図５は、この細分化を図によって示す。ＡＲＫ関連の基盤構造およびリソースマネジャーブロックは示されない。それらは、ＡＲＫ自体のエレメントとして含まれる。
【０１３１】
ここでは、各ファミリーおよび対象の代表的なブロックを挙げる。
【０１３２】
１．基盤構造（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）。プロセス、制御スレッド、および物理的なプロセッサを管理する。ブロックインターフェースセマンティックスをインプリメントする。相互のアクセス排除、明示的なデータ共有、および暗示的なデータプライバシーを提供する。日時クロックおよび高精細の実時間タイムクロック、カウンター、およびタイマーをインプリメントする。メモリ転送および非同期のディスクアクセス等のデータ移動を行う。ＧＡＰ実行の間のコンポーネントのローディングおよびアンローディングによる動的なバインディングをサポートする。効率的な低レベルのパラレリズムアウェアキュー、スタック、リスト、およびアレイデータ構造。シーングラフ、ワーキングセット、およびイメージキャッシュを含む高レベルのパブリックデータ構造。
【０１３３】
２．リソース管理（Ｒｅｓｏｕｒｃｅ　Ｍａｎａｇｅｒ）。マルチプルプロセッサ、グラフィックスパイプライン、ディスプレイチャネル、テクスチャリソース、フレームバッファストレージ、およびメモリのような物理的なリソースのアクセスおよび割当。能力、容量、ステータス、および性能についてのリポートデータ。
【０１３４】
３．標準機能（Ｓｔａｎｄａｒｄ　Ｆｅａｔｕｒｅ）。キーボードおよびジョイスティック等のヒューマン入力デバイスに対する抽象化デバイス管理。属性のモーフィング、補間、変形、および評価。空間オーディオプロセッシング。活性ロギングおよびプレイバック。構成ファイル構文分析および評価。精度管理および連鎖を含む座標システムプロセッシング。音、ビジュアル、交差、およびアニメーションのカリング。オブジェクト、形状、テクスチャ、マテリアル、および音声の暗示的データベースのページング。
【０１３５】
４．マーケット指向の機能（基本的なビジュアルシミュレーションサブセット）。天文暦時間をサポートする宇宙モデル；地球基準の経時的測位；太陽、月、および星の位置および出現；および星領域および星座の視覚化。地形の高度；視界線の交差、多点地続き、衝突検出、およびオブジェクト内部視界決定。寄せ集めの層状の霧、水平線のもや、ちぎれ雲、動的な雲の容積、方向性の水平線輝き、雨、みぞれ、雪、および水面下の効果を有する大気モデル。
【０１３６】
５．アプリケーション特有の機能（Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ　Ｆｅａｔｕｒｅ）。これらは、開発者がＧＡＰを特定のアプリケーションにつくりなおすために書くブロックである。「地球の眺望」デモのために、これは、モーションモデル、コマンドライン処理、環境変数処理、グラフィカルユーザインターフェースカスタマイゼーション、アプリケーション特有のデータベースローディングおよびデコーディングロジック、スプラッシュスクリーン、およびウェブサイトへの連結のためのブラウザを生む能力を含む。
【０１３７】
ＡＲＫおよび標準ブロックは共にＧＡＰである。ＧＡＰは、産業のマーケット指向のブロックに結合された場合、マーケット指向の開発および配置プラットフォームを定義し、そして、最終的に、０以上のセットのマーケット指向のブロックおよびアプリケーション特有のブロックのカスタム集合によるＧＡＰは、完全なアプリケーションを定義する。
【０１３８】
ＧＡＰは、ハードウェアプラットフォームの詳細について良好にチューニングされかつ構造化される実行可能なアプリケーションを生産するために、ランタイムに自動的に「再構成」され得るアプリケーションコンポーネント間の内部関係を定義するために非常に高レベルの構造を提供することによって、新しいレベルのプログラム再利用をアプリケーションの間にインプリメントする。これにより、移植可能でかつ区別された実時間アプリケーションの準備を可能にする機能レベルの「デバイスドライバ」を介してハードウェアプロバイダによってグラフィックス、ビデオ、オーディオ、演算、および、ネットワーキングに関連するブロック等のハードウェア関連のブロックの交換が可能になる。これは、ＰＣおよび、ケーブルセットトップボックスおよび向上されたテレビを含む他のデバイスハードウェアプラットフォーム用の高度なグラフィックスアプリケーションを構築するアプリケーション開発者にとって重要な利点である。
【０１３９】
「ＧＡＰバーチャルマシン」の最初の命令セットまたは「ＧＡＰオペレーティングシステム」のシステムサービスとなる基盤構造、リソース、および標準ブロックを考慮する。マーケット指向のブロックは、本発明の標的とするマーケットの機能を追加することによって、このコアの命令セットを拡張する。それらは、別々にパッケージングされるが、全く同一の方法で用いられる。機能およびリソースを表すブロックは、接続と一緒に織り込まれて、開発者が変更および拡張し得るフレームワークアプリケーションを形成する。この変更のプロセスは、ブロック間の連結が説明された後に議論される。
【０１４０】
３．ブロックインターフェースの定義
インターフェースは、外界からブロックまたはコンポーネントを分離する「セル壁」である。インターフェースは、コネクション構成に対する名前付けされたターゲットとして機能するブロックの入力コネクションおよび出力コネクションの公開定義である。インターフェースは、また、ブロック内の機能を特定する。インターフェースはタイプ分けされ、タイプは、為されるコネクションに整合しなければならない。タイプの安全性およびデータの完全性について、各入力ポイントおよび出力ポイントは、また、潜在的なコネクションが完成されるリンクに整合する必要がある、特定のタイプを有する。出力ポイントは、また、出力ポイントへのリンクによってアクセスされるブロック内部のデータのアイデンティティをもプライベイトに特定する。入力ポイントは、ローカル変数またはアクセッサ機能が入力コネクションを介してブロック内に流れるデータを読み出し、書きこむことに対応することを（明示的に、または、暗示的に）特定する。
【０１４１】
マクロを用いてブロック入力にアクセスし得、それにより、ブロック構成およびＡＲＫインプリメンテーションは手続され、インターフェースインプリメンテーションのさらなる考慮が行われる。このマクロアプローチは、また、書き換えるブロックを必要とすることなく、テストされる代替技術を可能にする。このマクロアプローチは、異なるＧＡＰインプリメンテーションにおいて異なるデータ結合メカニズムを可能にする。
【０１４２】
４．ブロック間のコネクション
単一（ｓｉｎｇｌｅ）コネクションが、各ブロック入力ポイントから任意（ａｎｙ）の他のブロックの互換性（ｃｏｍｐａｔｉｂｌｅ）出力ポイントに確立され得る。
【０１４３】
１．　この定義において用語「単一（ｓｉｎｇｌｅ）」は、ファンイン（ｆａｎ−ｉｎ）が入力接合ポイントにおいて特定できないことを意味する。
【０１４４】
２．　「互換性（ｃｏｍｐａｔｉｂｌｅ）」は、インタフェース互換性およびデータタイプ互換性を意味する。インターフェース定義名（または識別子）は整合する必要があり、このエンドポイントデータタイプは整合する必要がある。文字列出力は、例えば、浮動小数点入力に接続され得ない。
【０１４５】
３．　最後に、宛先として「任意（ａｎｙ）」の出力ポイントを許容にすることは、出力接合ポイントにおいて任意のファンアウトを支援することを意味する。
【０１４６】
コンポーネントはスーパーブロック「ファクトリ」であり、ブロックを使用するところで使用され得るということを上述した。コネクションの文脈において、この違いは、コンポーネントがリソースに接続され得ることのみであり、リソースは、コンポーネントに対して指定されたコネクションポイントとして知られたブロックである。コネクションの多くの特性は、一方向パイプラインとしてコネクションを思い描くことによって説明され、この一方向パイプラインにおいて、データは、内部固有オブジェクト派生データメンバから、あるブロックの出力ポイント、プロデューサ、別のブロックの入力ポイントへのダウンストリーム、消費者を通って流れる。代替の見方は、コネクションを、ダウンストリームブロックによるアップストリームブロックの内部データへのアクセスとして解釈する。このアプローチは、コネクションアーキテクチャの性能、制限、そしてセマンティックをさらに明らかに表現する。
【０１４７】
コネクションはランタイムにおいて作成され、実行の間に行われ、壊され得る。例えば、あるシーンを通ってアイポイントが動くことにより、ジオメトリページング機能は、新たにページングされたジオメトリとともに新たなアニメーションコンポーネントをロードし得る。この入来のアニメーションブロックは、カメラ位置リソースに取りつけられる必要があり、そのコネクションは上述したように行われる。一旦、接続されると、その情報を所有するブロック内からのカメラ位置出力データは、内部アクセッサ機能またはブロックの入力ポイントに関連する代表変数がそれぞれ呼び出されるか、アクセスされる場合、新たにロードされたブロック内で利用可能である。
【０１４８】
ブロックおよびコンポーネントは、ともに、ＧＡＰを構築するのに必要な特別の抽象化を提供する。それらは、その機能がコンパイルされた後にコネクショントポロジへの変更を可能にする一般的なコネクショントポロジを通って、サブルーチン呼び出しについての引数を特定するための手段をインプリメントする。それらは、また、データをコピーするのではなく、間接ハンドルを交換することによって、コネクションに沿って、データの効率的な転送を支援する。
【０１４９】
シーンの背景に起こっていることは、一見しただけで見えるかもしれないものよりもかなり洗練されている。ブロックを任意のマルチ処理トポロジ上のこの明瞭なデータフロープログラミングモデルで提示することは、ＡＲＫ内の基本設計制約である。すべてのＧＡＰ関連データタイプを基礎とするＡＲＫおよびオブジェクトモデル内の複雑さの多くは、コネクションが上記のように動作し、極めて効率的であり、かつ、支援するという幻想を生み出すために存在している。
【０１５０】
−−同時実行ブロック間で共有データのコヒーレントアクセス。
【０１５１】
−−異なるレートで非同期または同期的に動作するブロック間のデータの見掛け散発生成または消費。
【０１５２】
−−メガバイトのデータが、一度に移動するいくつかのフレームデータでコネクションを通って流れるように見える必要がある、時間逐次処理パイプラインについての一時的なコヒーレンス。
【０１５３】
ブロック間のコネクションを行うこと、および、壊すことは、まれな事象であり得るが、コネクションを介してアクセスされたデータの量は、秒ごとに数百メガバイトのデータであり得る。それで、インプリメンテーションは、より遅いコネクション構築を犠牲にしても、より速いアクセスを常に好むべきである。
【０１５４】
コネクションは、ＧＡＰ環境の決定的な要素である。コネクションは、ブロックが効率的な通信を維持し得、一方で、ライタイムにおいて、かつ、ライタイムの間、相互接続トポロジの柔軟な再構成を支援する、機構である。この機能は、「再構成を通ったランタイムアプリケーション最適化」の基礎であり、これは、ソフトウェア開発者およびハードウェア製造者によって提供されたアドオンブロックを通ってＧＡＰベースアプリケーション開発者に提供される。
【０１５５】
５．コンポーネントとしてのパッケージングブロック
コンポーネントは、ＧＡＰ環境における最もハイレベルなオブジェクトである。それらは、繰返しグローバルリソース割り当てプロセスに基づいてブロックの新たな集合を生成するためのファクトリを表す。それらは、以下の形式の質問に賢明に応答するように設計されている：「利用可能なリソース上で特定のハードウェア構成および制約がある場合に、特定の機能を挿入するためには標準フレームワークに何を追加すべきですか」。
【０１５６】
これは、応答するのが困難な質問である。なぜなら、それは、ローカル情報とグローバル情報との両方に依存するからである。ローカルには、ある機能のいくつかの利用可能なインプリメンテーションは、ハードウェアまたは他のリソースの可用性などの制約に基づいて選択され得る。グローバルには、重要なリソースの酷使を避けるため、または、画像品質またはレンダリングレートなどのアプリケーション優先度に基づいて最適化するために、あるインプリメンテーションが、別のインプリメンテーションより好ましくあり得る。例えば、機能ＡおよびＢが、より多くのメモリか、または、より多くの処理を用いてインプリメントされ得る場合、そのとき、全体のメモリ使用および全体のＣＰＵ使用の両方が、利用可能なリソース内で、結果として生じたフレームレートに基づいて、特定の選択とフィットするように、それぞれのうちの一方のインプリメンテーションが選択される。
【０１５７】
コンポーネントは、コンピュータ選択可能バンドルにおいてインプリメンテーションの賢明さをパッケージ化したものである。それらは、正しい「変形物（ｖａｒｉａｔｉｏｎｓ）」が再使用機能のインプリメンテーションにおいてなされるという確信をもって、開発者が新たなアプリケーション内で以前に書かれたソフトウェアを再使用することを可能にするものである。
【０１５８】
構造的には、コンポーネントは、機能の１つ以上の代替のインプリメンテーションについてのコンテナである。このハイレベルの表記は、代替のインプリメンテーションのリストが示される、図７において図示される。
【０１５９】
それぞれの代替のインプリメンテーションに関連するのは、リソース（例えば、システムメモリ、テキスチャメモリ、ＣＰＵ要件およびデータ転送帯域）のリストであり、それらは、リソース交渉が必要な場合、これらの要件を減らすために用いられる特定のインプリメンテーションおよび情報のインスタンスを成功に作成するのに必要であり、リソースが大量にある場合、その要件をおそらく拡大することが必要である。コンポーネントは、また、リソースをシステムに導入し得、それにより、それぞれの代替のインプリメンテーションは、その代替によって提供されたリソースのリストを含む。新たに作成されたリソースのそれぞれは、また、リソース交渉情報を有する。この情報は、新たなリソースに対して後の交渉における供給者側の取引を支援する。最終的に、代替のインプリメンテーションは、スーパーブロックのリストを含む。そのスーパーブロックは、実際のインプリメンテーションである。それぞれは、アプリケーションフレームワークの実行の特定のフェーズに関連し、そのフェーズ内で実行されるブロックのリストを提供する。図１９は、単一の代替インプリメンテーションのコンテンツを示す。
【０１６０】
アプリケーション内のコンポーネントを識別した後、それぞれはそのリソース要件を尋ねられる。その応答は、代替インプリメンテーションおよびそれらに必要なリソースのリストである。これらの要件を集積することにより、代替物の少なくとも１つの構成がシステム制限内にフィットするかどうかを解決できる多次元リソース割り当て問題が生じる。
【０１６１】
−−単一の解決法が存在する場合、選択された代替物は各コンポーネントと通信され、それは、次いで、そのインプリメンテーションのブロック内および外へのリンクとなるコンポーネントの内および外へのリンクとの対応するインプリメンテーションのインスタンスを作成する。
【０１６２】
−−代替のインプリメンテーションの１つより多い組み合わせがリソース制約とフィットする場合、次いで、選択された構成は、アプリケーション開発者によって提供されたコンポーネント定義および評価式に含まれる重み付けパラメータに基づいている。この好ましい解決法は、次いで、コンポーネントと連絡され、そのコンポーネントは、選択された代替物のインスタンスを作り、それらをフレームワークにリンクする。
【０１６３】
−−リソースが予約過多の場合、したがって、直接的な解決法がなく、そして、そのシステムは、交渉フェーズになり、そこでは、各ブロックは、そのリソース要件のうちのどれを減らすことができるか、および、トレードオフを行うにはどんなペネルティがあるかを尋ねられる。典型的な例は、不明瞭な画像のペナルティにおいて１／４だけ減少され得るテキスチャメモリリソース、および、余剰ＣＰＵ利用化およびデータ転送帯域消費を犠牲にした完全なデータのプリローディングではなく、インクリメンタルページングによって最小化されたシステムメモリリソースである。コンポーネントが減少したリソースで適切な代替インプリメンテーションのインスタンスを作れると受容可能な構成が見出されるまで、または、制約された環境内で「強い意思をもった」余計なコンポーネントが存在する場合、解決法がないことがわかるまで、交渉は続く。この極端な場合において、このポーネントのいずれかは取り除かれ、そのプロセスは再スタートされ、または、そのプロセスが終了する。
【０１６４】
リソース割り当てプロセスは、すべての必要なリソースが利用可能でない場合、コンポーネントのインプリメンテーションのインスタンスを作れないこと、および、いくつかの代替物のどれかについての適切な決定が利用可能リソースに応答して選択されることを確実にする。例えば、本発明のある実施形態において、ユニバーサルテキスチャコンポーネントは、ＳＧＩインプリメンテーションにおいてのみ提供される「クリップマップ」リソースに依存するインプリメンテーションを有し、そして、依存しないインプリメンテーションを有する。前者の場合、そのインプリメンテーションは、利口なＳＧＩ無限リアリティハードウェア（ＩｎｆｉｎｉｔｅＲｅａｌｉｔｙ　ｈａｒｄｗａｒｅ）の利点を有し得、他のケースにおいて、一般的なソフトウェアバージョンが使用される。
【０１６５】
コンポーネントは、また、リソースをそのシステム内に導入し得る。時には、これらの新たなリソースが物理的なリソースを管理するが、他の場合には、それらは、他のブロックの接合ポイントを表す。例えば、モーフィングコンポーネントを取りつけた場合、モーフィングが使用されるたびに他のコンポーネントがこれらを取りつけ得るように、モーフィング直前、モーフィング中およびモーフィング後の接合ポイントを知ることはまた有用である。巧妙には、そのような「コンポーネント上のコンポーネント」接合は、第１のコンポーネントが存在する場合にのみ意味を為すことに留意されたい。これは、コンポーネントが見つからないリソースに起因してロードされない場合に、常に問題になるとは限らないことを意味する。それは、単に、計画された臨時性がアプリケーションの設定において具体化されていなかったことを意味する。
【０１６６】
６．実行のフェーズおよびステージ
アプリケーションフレームワークは、実行のいくつかのフェーズを定義し、そのフェーズは、潜在的な並列実行のスレッドに対応する。コンポーネント内の代替のインプリメンテーションのそれぞれは、１つ以上のスーパーブロックを含み、それぞれは、処理の単一フェーズに関連している。スーパーブロックは、また、新たなフェーズ（例えば、前の例の場合におけるモーフィングフェーズ）を定義し得る。各アクティブコンポーネントの選択された代替のインプリメンテーションのスーパーブロックのインスタンスが作られると、それらは、特定のフェーズに関連し、同様に、コネクションによってリソースにリンクされる。
【０１６７】
所望なコンポーネントのインスタンス化の結果は、フェーズのリストである。各フェーズに関連するのは、ゼロまたはより多くのスーパーブロックのリストである。これらのリストの多くは空であり得る。例えば、アプリケーションが、置換を定義することなく、標準データベースページングコンポーネントを抑制する場合、データベースページングフェーズリストは空であり得る。空でないフェーズリストのそれぞれは、アプリケーションの潜在的な並行フェーズを定義する。ある例のアプリケーションフレームワークに対して、これらのフェーズリストを図８に示す。
【０１６８】
次いで、空でないフェーズは、実行のステージにマッピングされる。実行ステージは、それぞれ、フェーズの集合を表し、ＡＲＫは単一のスレッドで実行する。ステージ構造を図９に示す。フェーズ−ステージマッピングを生成するためのアルゴリズムは当該分野において公知であり、単純な「すべてのフェーズが単一スレッド順次実行に対する単一ステージにマッピングされたもの」から「各フェーズが最大の並行処理で独立ステージにマッピングされたもの」までの範囲がある。
【０１６９】
次いで、実行順序リストを生成することによって実行の結果としてのステージが実行のために作成され、そのリストは、コネクションによって課せられた一対のブロック順序を、フェーズブロックリスト内においてブロックの全体の順序へと構成する。後述するように、ＡＲＫは、これらのリストにわたって繰返し、各参照ブロックのｅｖａｌｕａｔｉｏｎ（）関数を呼び出す。
【０１７０】
ステージは、大変複雑な表示（異なるレートで実行しながら、なお、共有データを読み出し、更新する単一アプリケーション内の多くの「制御のメインループ」）の単純な表現を提供する。
【０１７１】
（７．シーケンシャル実行および並列実行）
ＡＲＫベースのアプリケーションを実行するための準備は、アプリケーション目録（ｍａｎｉｆｅｓｔ）に列挙されたコンポーネントのロードを含む。この目録は、アプリケーションの最上位のレベルにおいて必要とされたユーザによって開発されたブロック、第三者ブロック、および市場指向ブロックのそれぞれを列挙する。ロードした後、これらのコンポーネントは、上述したリソースの割り当て、インプリメンテーション、インスタンス化、およびフェーズ／ステージ間のマッピングプロセスに関与する。コンパウンドブロックは、他のブロックへのリンクのみからなるコンパウンドブロックは、そのサブブロックおよびリンクをインスタンス化して、それらの定義によって示された接続を作成することにより再帰的に拡張される。これらのタスクの結果、アプリケーション実行の各ステージの定義が作られる。この定義のそれぞれは、ブロック実行オーダーリストならびにブロックおよび構成された接続の対応するセットを有する。
【０１７２】
この前処理から生じた実行オーダーリストはＡＲＫへの入力であり、このようなリストの評価はＡＲＫの基本的なタスクである。図１０は、実行オーダーリストを実行する単一のＡＲＫスレッドマネージャを有するこの構造を示す。
【０１７３】
シーケンシャル実行環境では、各パスの間、単一のＡＲＫスレッドがいくつかのまたは全てのブロックを選択しそして実行する実行オーダーリストにわたって連続的に反復する。ブロックが異なる速度で動作する場合についての部分的な実行が存在する。例えば、いくつかのブロックは６０Ｈｚで動作し、いくつかのブロックが３０Ｈｚで動作する場合、ＡＲＫは６０Ｈｚで反復するが、全部の時間で６０Ｈｚのブロックを選択するか、その半分の時間で３０Ｈｚのブロックを選択する。
【０１７４】
簡単なブロックは、開発者の観点から最高の精細度の潜在的な並列処理を示すが、上述のように、実際には、簡単なブロックは、実行の実際の原子的な要素である実行オーダーリストである。これは、各ブロックが単一のブロック実行オーダーリストによって参照され、このオーダーリストは、ブロック内の特定の機能ではなくブロックであり、ＡＲＫによってスケジュールされ、潜在的な並列ＡＲＫスレッドによって実行される。
【０１７５】
並列実行は、図１１によって示されるように、各ブロックのそれぞれがブロック実行オーダーリストを有する複数のＡＲＫスレッドが存在するより高度な場合である。支援された並列処理モードは、単一のプロセッサ（多重スレッドまたは多重プログラミングとして公知である）、マルチプルプロセッサのそれぞれに関する単一のスレッド（多重処理と呼ぶ）、および多重プログラミングおよび多重処理の任意の組み合わせを含む。
【０１７６】
並列実行において、ＡＲＫスレッド１つにつき複数の独立ブロック実行オーダーリストが存在する。平坦化されたアプリケーショングラフを複数のリストに変換することは、ブロック間のいくつかの接続にＡＲＫスレッド境界を拡張させ、この境界は、共有されたデータに対する重要な意味を有する異なるリストにおける上流および下流ブロックを有する。このケースは、ブロック開発者には非可観性であるが、余分な場面の背景加工がこの状況を適切に処理することを必要とするため、ＡＲＫを設計および実現する開発者には非可観性ではない。
【０１７７】
ブロック間のリンクもこのようなリンクのデータが存在または不在であっても、ブロックの実行を駆動も妨害もしない。ブロック実行は、実行オーダーリストによって制御されるのみである。この実行リストは、実行の前後のいずれかで作成され、実行の間に変化し得る。ＧＡＰの「ブロック間の動的接続にわたってフローするデータ」構造と「ブロック入力におけるデータの存在によって制御された実行」との間の著しい差異が存在する。ＧＡＰは、スケジューラブロック（または実行前の静的解析）によって作成された１つ以上のブロック実行オーダーリストに従うことによってブロックを実行する「エンベデッドアプリケーションレベルオペレーティングシステム」と似ている。
【０１７８】
ＧＡＰは、並列実行に対する例示的な設計者のための、明確に理解するために必要な開発者なしで有用な処理リソースを使用するために自動的におよび効率的に拡張するプログラムを書き込む能力を提供する。さらにＧＡＰは、リアルタイム指向の並列処理を提供する。これらは、他のプラットフォームおよびプログラム環境と比較するとＧＡＰの強力な利点および独特な利点である。
【０１７９】
（８．フレームワークアプリケーション）
図２０は、本発明による例示的なグラフィックアプリケーションの予備的な構造を示す。データのフローは、「表示解像度」とラベル付けされた区別されたブロックにおいて開始し、このシステムを介して入力デバイスおよび出力デバイスまで継続する。この図は、処理フェーズをラベル付けしないが、処理フェーズは、黒い輪郭のブロックにほぼ対応する。この図は、標準的なアクティブ領域（ａｃｔｉｖｅ　ｔｅｒｒａｉｎ）もオブジェクトモーフィングもヒューマン入力デバイス管理コンポーネントも含まない。
【０１８０】
（ＩＩＩ．アプリケーション開発）
（Ａ．アプリケーショングラフ）
アプリケーショングラフは、アプリケーションの基礎的表現および／またはアプリケーションリアルタイムカーネルの応用の一部である。ＡＲＫはこの図を使用して、データおよびグラフ中に説明された処理フローに基づいた仮想マシンであるかのようにアプリケーションを実行する。このアプリケーショングラフは、処理ブロック、データインターフェース、およびデータ接続からなる。このようにアプリケーションを編成することは、通常のオブジェクト指向のプログラミングモデルに直交する態様である。ＡＲＫは、アプリケーションにわたって使用されたデータ構造も処理しているコンポーネントのインプリメンテーションも命令しない。しかし、ＡＲＫは、開発者により多くのアプリケーションを明確に定義させ、それにより、カーネルにデータフローのメッセージおよびアプリケーションの処理（その全体においてアプリケーションを理解する際の多くの固有の最適化を作成する（設計のこのレベルにおいて））を管理させる。
【０１８１】
（Ｂ．コンポーネント）
さらにＡＲＫは、機能性をアプリケーショングラフに挿入する目的のために、パッケージングおよびランタイム管理セマンティックを定義する。このセマンティックは、コンポーネントの概念に基づく。コンポーネントは機能性の特性レベルパッケージングである。ＡＲＫは、実行することに対して責任を有する現在のアプリケーショングラフでなく、アプリケーションにおいて潜在的に使用され得る要素およびインターフェースを処理するランタイム定義辞書も含む。コンポーネントは、既存の定義を拡張することを可能にし、新しい定義にこのランタイム辞書を追加する。コンポーネントはまた、最終的にリソースを交渉するために使用され、その結果コンポーネントは、どのリソースがコンポーネントに対して利用可能であるかに基づいて、どのようにしてシステムにコンポーネント自身を挿入するかを制御し得る。これに対応して、ＡＲＫのランタイムリソース管理およびパフォーマンスモニタリングは、これらの同一の特性レベルのコンポーネントに基づいて破壊される。ＡＲＫは、リクエストを作成するコンポーネントリクエストに関する全てのリソースを割り当てる。さらにＡＲＫは、これらのリソース（メモリ、時間、処理、バス帯域幅等）のコンポーネント利用をトラッキングする。従って、カーネルに対して、コンポーネントが完全なオペレーティングシステムになるべきプロセスと酷似している（コンポーネントはリソース割り当て／モニタリングの粒度である）。しかし、コンポーネントがどのようにして相互作用する（アプリケーショングラフを介して）かについての知識のために、ＡＲＫカーネルは、より多くのインテリジェントコンポーネントとして動作し得る。ＡＲＫは、関連していないタスクの集合のほとんどない知識を有する代わりに、どれくらい多くのコンポーネントが特定の全体のアプリケーション構造にわたって適合するかについての非常に詳細な知識を有する。
【０１８２】
（Ｃ．コンポーネント辞書）
ＡＲＫは、モジュールに書かれて構成されたアプリケーションの全体の理解を維持しなければならないため、ＡＲＫは、アプリケーショングラフ概念の完全な辞書を維持する。この辞書は、ＡＲＫアプリケーショングラフを作成するいくつかの明瞭な構造に基づいてアプリケーションのセグメントを定義することができる。これらの構造は、処理ブロック、データインターフェース、データ接続、およびデータオブジェクトを含む。これらの構造の定義はその構造自体がモジュラーでなければならない。実際には、ＡＲＫベースのアプリケーションマシンの開発者は、抽象化「基礎」処理ブロック内のデータインターフェースおよび接続ポイントレイアウトすることによってそのアプリケーションを定義することを強く促進する。この種の設計および開発は、その部分的な定義、拡張、およびカプセル化は、その辞書が処理する必要があるキー概念であることを決定する。このＡＲＫは、構造的な定義、部分的な拡張、全体の拡張、および機能的置換の全てを明確に理解されたアプリケーショングラフ定義にアセンブルすることを可能にする必要がある。さらに、ＡＲＫは、これらのアプリケーション定義がアプリケーションランタイムにおいて関心のある態様で構成されることを必要とする。従って、辞書の動作は、シンプルなブロック、ブロックのためのデータインターフェース、インターフェースのようなブロックを接続する接続、コンパウンドブロック、および基礎ブロックを含む。
【０１８３】
（Ｄ．処理ブロック）
（１．一般的なブロック）
プロセッシングブロックは、アプリケーショングラフ内部に発生する原子的なプロセッシングを含む。プロセッシングブロックは、入力フィールド、内部格納フィールド、および出力フィールドを有する。一般的に入力フィールドは読み出し専用であり、ＡＲＫによって自動的に更新される。内部格納フィールドは、読み出し／書き込まれ、通常のｃ＋＋／ｃフィールドアクセスを介してブロック自体（一般的に）によってのみ更新される。出力フィールドは、入力フィールドまたは内部格納フィールドのいずれかのシャドウであるに過ぎない。その結果、ＡＲＫは、ブロックと直接相互作用することなく出力の伝達を管理し得る。ブロック間の通信のみがその入力およびその出力を介して存在する。しかし、ブロックはまた、ＡＲＫのリソースマネージャと相互作用し、ブロックにおいて使用されたリソースにわたって交渉することが可能である。このようなリソースは、ブロックプロセッシング時間、メモリ割り当て、バス利用、およびセマンティックな定義のリソースセクションにおいて定義される他のリソースを含む。
【０１８４】
ブロックはいくつかの関数インターフェースを定義する。主にこれらのインターフェースは、初期化、イニシャライズアウトプット（ｉｎｉｔｉａｌｉｚｅＯｕｔｐｕｔ）リセット、および評価関数からなる。ＡＲＫは初期化関数を使用して、ブロックをそのリソースに割り当てさせる。ＡＲＫは初期化出力関数を使用して、ブロックに、ＡＲＫ対して出力フィールドのストーレッジとしてＡＲＫに対して格納定義させる。ＡＲＫはリセットを使用して、ブロックの内部状態フィールドを十分に定義されたデフォルト値にリセットする。ＡＲＫは、評価関数を使用してブロックにそのプロセッシング（ブロックの入力および現在の内部状態フィールドに基づくプロセッシング）を実行させる。
【０１８５】
ブロックスケジューリングがＡＲＫによって実行される。このスケジュールは、簡単で決定論的である必要があるが、ポート／コネクタにおいて利用可能なデータに関連付けられ得る。ほとんどのブロックは、ブロックの入力が「十分な」データをリフレッシュした時はいつでも、現在のアプリケーショングラフ（階層的である）の入力からアプリケーショングラフを通ってスケジューリングブロックに単に直線的に移動することによってスケジューリングされる。「十分なデータ」の概念は、ブロックをグラフに挿入する場合、そのブロックの入力において利用可能なデータにブロックのスケジューリングを関連付けるコンポーネントを挿入することによって定義される。スケジューリングのレベルは、ループ構造物、大きなサイズのワークリスト、および実行による直線パスを可能にするが、反復またはスタックに基づくクロック実行に基づいて任意のスケジューリングを可能にしない。
【０１８６】
（２．シンプルなブロック）
シンプルなブロックは、アプリケーショングラフ階層におけるリーフプロセッシングノードである。シンプルなブロックは、ＡＲＫがブロックをスケジューリングする時はいつでも実行される評価関数を有する。シンプルなブロックは、単にそのブロックの入力および出力を通って流れるタイプのデータプロセッシングのためのポイントをスケジュールするに過ぎない。
【０１８７】
（３．コンパウンドブロック）
コンパウンドブロックは、１つのブロックにカプセル化されるアプリケーショングラフの内蔵セクションである。これは、このブロックがブロックに含まれたグラフの入力をその入力として有することを意味する。このブロックは、グラフに含まれたブロックの出力に対応する出力を有する。上記のレベルからコンパウンドブロックは、シンプルなブロックとしてスケジューリングされるのみであり得る（原子的に、ブロックの入力におけるデータ利用性に基づいて）。
【０１８８】
（４．基本コンパウンドブロック）
さらにコンパウンドブロックは名前空間を含む。この名前空間は、コンパウンドブロック内で流れるデータのためのデータヒッチポイントを生成するために使用される。これらのデータヒッチポイントは、コンパウンドブロック内部に命名され、コンポーネントに対してプラグイン機構を提供して、関数性を、所定の「基本」構造を有するブロックに追加する。任意のコンパウンドブロックは、命名されたコネクタをブロックのその内部に追加することによって基本ブロックになり得る。これらのコネクタは、データプロセッシングおよびプロセッシングフローの点からコンパウンドブロック自体についてのセマンティックを定義する場合、重要である。さらにこれらのコネクタは、プロセッシングの構成、スケジューリングの構成、およびプロセッシングブロック自体のインプリメンテーションおよび設計に大幅に直交する構成を作成する潜在的なバッファリングを提供する。ここで、このアイデアは、どのようにしてこのコンパウンドブロックを機能させるのか、およびどのタイプの拡張をコンパウンドブロックが処理するのかを定義する基本ブロックの元の開発者次第である。
【０１８９】
（５．フェーズ）
全体のアプリケーションに直接プラグインするコンパウンドブロック（最も高いレベルのコンパウンドブロック）がフェーズと呼ばれ、基本的なコンパウンドブロックのみ特化される。フェーズは、コンパウンドブロックのシステムにおいていくつかの理由のために選ばれる。第１に、フェーズは、全体のアプリケーションの所望の構成粒度のレベルを提供する。第２に、フェーズは、アプリケーションレベルの特性を拡張または置換するために望まれるコンポーネントのためにプラグイン粒度の所望のレベルを提供する。第３に、フェーズは、現在、ＡＲＫがスレッドを使用し得る粒度のレベルとして作用する（各フェーズは、必要であれば、個々のスレッドにマッピングするように構成され得る）。
【０１９０】
（６．ステージ）
ステージは、特定のスレッドにマッピングされるフェーズのグループ化である。ある極端な場合は、フェーズとステージとの間の一対一のマッピングであり、このマッピングは、利用可能なプロセッサおよび基本的なコンテキストスイッチングを最大限に使用する。他の極端な場合は、１つのみのアプリケーションステージ（このステージは、コンパウンドブロックについて定義された同一の簡単なスケジューリングアルゴリズムに基づいてアプリケーションフェーズの全てを実行する）が存在する。本質的には、ステージは、フェーズの同期化、通信、条件の実行のメインループを含む。
【０１９１】
（７．ブロックの要約）
ブロックは、ＡＲＫに基づくアプリケーションにおいて発生する原子的な（ａｔｏｍｉｃ）処理を説明するために使用される。この処理のスケジューリングは、ＡＲＫの意味に基づいて明示的に行われる。これは、現在のプログラミングシステムで開発された大抵のアプリケーションにおいて使用された制御フローに基づいた暗示的な協同スタックとはかなり異なる。ＡＲＫベースの処理の明示的な性質は、リアルタイム相互作用および性能の観点から、はるかに多くの決定論的なアプリケーションへと導く。さらに、このアプリケーションの目的の高いレベルの理解に基づくと、いくつかの最適化を可能にする。
【０１９２】
ブロックはＡＲＫの基本的な構築ブロックである。ブロックは、それ自体が階層的に定義される。この定義は、入力および出力を有する処理構造の再帰的なコンパウンドの表示としてアプリケーションの表示に作用する。このように、全体のアプリケーションは、入力および出力を有する１つの大きなコンパウンドブロックである。さらに、アプリケーションは十分に定義された相互接続（フェーズ）を用いて機能的分離可能な断片に分解される。これらの分離可能な断片がコンパウンドブロックであり、このブロック自体が興味深い態様で構成かつインスタンス化され得る。さらに、これらの分離可能な断片は、処理およびデータフローに関して定義された自体の構造を有するコンパウンドブロック自体である。
【０１９３】
（Ｅ．データインターフェース）
（１．一般的な説明）
ＡＲＫは、データインターフェースを明示的に定義することによって起こるアプリケーションとの全ての通信を説明する。これらのデータインターフェースは、大抵の現在のプログラミングシステムによって提供された機能的な通信メカニズムに基づくスタックとは実質的に異なる。データインターフェースは、型データにアクセスし、ただし、インターフェース上のデータの「プロバイダ」（処理ブロック）およびデータの「ユーザ」（別の処理ブロック）は、直接的にインタラクトしないか、または互いの認識を有しない。さらにこの「要約」にもかかわらず、データインターフェースブロックは、直接的に接続可能であり（インプリメンテーションでは）、仮想的または非仮想的な機能呼び出しを介して、スタック上でデータを処理することなく、内部データを露出することをしばしば可能にする。このタイプの高速な直接アクセスは、全体のグラフ内の処理ブロックのＡＲＫ認識およびスケジューリングのおかげでのみ管理可能である。
【０１９４】
ＡＲＫベースのアプリケーションを指定することは、そのデータインターフェースの定義から開始すべきである。通常の機能的プログラミングでは、コードモジュールが分解され、機能的プログラミングインターフェースは、この相互作用を抽象化するために定義される。オブジェクト指向のアプリケーションでは、この抽象化は、全体のアプリケーション内の個別の「オブジェクト」の性質、およびこれらのオブジェクトが、どのようにして互いに抽象的に相互作用し得るかに従ってさらに分解される。ＡＲＫアプリケーションでは、その機能的またはオブジェクト構造のみに基づくアプリケーションを定義するのではなく、アプリケーションが全体のアプリケーション構造における種々の位置において利用可能なデータインターフェースの点において説明される。これらのインターフェースは、システムの相互作用を表し、データフローを説明するが、インターフェースに接続する処理ブロックのための固有の構造を提供する。再び、このレベルの説明は、個々のシステムオブジェクトまたはモジュールの暗示的な領域からデータのフローを利用し（ｔａｋｅ）、その説明をより高いレベルで明示し、構成可能にする。実際、これらのインターフェースは、アプリケーションオブジェクト／モジュールがシステムの多くの異なる部分におけるインターフェースに接続することを可能にするが、全体のアプリケーション構造と意味的に一致する態様でさらに相互作用する。従って、データインターフェースは、全体のアプリケーションに対する全体の特性のドライバモデルを提供する。システムの個々のコンポーネントが、同意されたデータインターフェースを介して相互作用するが、データインターフェース自体のみを理解し、当該のブロックはまた、インターフェースの他の側上のブロックについて関心を持たない。
【０１９５】
（２．ピン）
このＡＲＫは、いくつかのレベルでアプリケーションデータインターフェースを定義する。データインターフェース定義の最も低いレベルはピンと呼ばれる。ピンは、ブロックによって送信または受信された（別のブロックから来るまたは別のブロックに行く）原子的なフィールドへのアクセスを表すように定義される。従って、ピンは、固有のオブジェクト（整数、浮動小数点、オブジェクト、ハンドル、ベクトル等）内のフィールドに直接的に対応するデータインターフェースを提供する。ピンは２つのタイプ（入力および出力）に分離される。入力ピンは、出力ピンに接続されなければならず、またはその値は定義されない。入力ピンは、ブロックの評価中に、内部フィールドのようにより多くアクセスされる。実際には、基本的な考えは、ＡＲＫが、ブロックが実行する場合、ブロックの入力ピンの全てが確かなデータを全て含むことを保証することである。しかし出力ピンは、わずかに異なる意味を有する。出力ピンは、オブジェクトに含まれるブロックまたはブロックの内の１つにおける対応するフィールドを有しなければならない。ＡＲＫは、ブロックからの相互作用なしで出力ピンの値を通過させることに対して責任がある。これは、ＡＲＫが各出力ピンに対してピンマッピングを出力するフィールドを有しなければならないことを意味する。要するに、ブロックが実行する場合、ＡＲＫは、ブロックの入力の全てを確定させかつ利用可能にする。ブロックが実行を終了する場合、ＡＲＫは、概念的に、ブロックの出力をブロックの出力に接続された他に入力にのせる。インプリメンテーションにおいては、これは、ＡＲＫが、このブロックの出力に接続された他のブロックが意味的に適切な時間においてデータ値をサンプルすることを可能にすることを意味する。
【０１９６】
（３．ポート）
ピンが共にグループ化されてポートと呼ばれるデータインターフェースのより高いレベルの説明を形成する。ポートは本質的には階層的であり、複雑なピングループ化に対して、ポリモルフィックタイプのシステムを提供する。ポートはピンのリストおよび他のポートとして定義される。ポートは、第１に、ポートのインスタンスが作成される前のポートタイプのシステムを介して定義される。これは、標準的なポートのタイプが、標準的なインターフェースを介して個々の処理ブロックを取り付けるようと努める複数の開発者によって定義され使用されることを可能にする。このポートタイプは、標準的なインターフェースのみならず、アプリケーションの標準的な点を有するようにコネクタ（以後定義される）によってさらに使用され得る。このアプリケーションでは、このインターフェースが存在し、特定の意味を有する。ポート定義はランタイムにおいて拡張可能であり、ポリモルフィックである。単にポートは、標準的な態様で階層的に共にグループ化されるピンの態様（ハードウエア世界における標準的なソケットを作成するように極めて類似しているもの）を表すに過ぎない。
【０１９７】
（４．ピン／ポート相互作用）
ピンおよびポートは通常簡単かつ自動的である。ＡＲＫは、データを出力ピン／ポートから接続された入力ピン／ポートに伝達させることに対して責任がある。通常、この伝達は、ＡＲＫの内部で自動的に発生し、そしてブロックの評価を含む内部ＡＲＫラッパー機能において、ＡＲＫが行う最小のセットアップが実行される。しかし、このＡＲＫは、定義されるべき「相互作用」ポート／ピンを可能にする。相互作用ポート／ピンは、ＡＲＫに、処理するための新しいデータインを「引き込む（ｐｕｔ）」か、または処理するためのデータアウトを「押し出す（ｐｕｓｈ）」ことを尋ねる。この相互作用押し出し／引き込みの意味は、この柔軟性がより細かいグレイン（ｇｒａｉｎ）の方法でアプリケーションまたは互いに相互作用するブロックを生成することを可能にする。相互作用ピン／またはポートは、特定のはるかにより高価なデータバッファリングを要求し、このセクションの以下に説明される特別なバッファリングされたコネクタに接続されたポートによって使用されるのみであり得ることに留意することは重要である。
【０１９８】
（５．データ接続）
データ接続は、１つのブロックの入力ピン／ポートと別のブロックの類似のタイプの出力ピン／ポートとの間の接続である。ＡＲＫは、接続の１つのタイプ（簡単な接続）を提供するだけである。簡単な接続は、２つのブロック間の抽象化インターフェースの安全な直接アクセスを提供する。簡単な接続は、２つのピン／ポート間の意味のある値のコピーを介した簡単なデータフローを表す。しかし、簡単な接続のインプリメンテーションは、電気的類似を用いてよりわかりやすく説明される。この類似では、実際に入力は別のブロックの出力に電気的に接続される。従って、ブロックＢの入力がブロックＡの出力に接続される場合、ブロックＢのポートは、その入力ピンをサンプリングする時に、ブロックＡの実際のデータを効率的にサンプリングする。これは、ブロックＡおよびＢが意味的に一致する態様で実行されるのみであり、そしてＡおよびＢが異なるスレッドで評価される場合にマルチバッファリングブロックＡのデータにさらなる配慮を払うことをそのＡＲＫが確実にさせる理由の場合のみ安全である。
【０１９９】
（６．データコネクタ）
（簡単なコネクタ）
コネクタはデータに対するハブ状のヒッチポイントである。２つのタイプのコネクタがある。簡単なコネクタは、コンパウンドブロックに接続させる任意のブロックから離れているコンパウンドブロックの内側に存在するデュアルサイドポートのように動作する。簡単なコネクタに関して重要なことは、簡単なコネクタは、独立して開発されるが、なおさらに相互作用するコンポーネントための予め定義された名前の空間を提供することである。コンポーネントが基本的なブロックを追加する場合、コンポーネントは、ブロックを挿入し、これらのブロックのポートを予め存在するコネクタに接続することによって機能的に追加する。従って、コネクタはコンパウンドブロックの全体の構造を提供し、本来の開発者が通信のために使用するインターフェースを定義する。
【０２００】
（バッファリングされたコネクタ）
バッファリングされたコネクタは、構造的な名前の空間ばかりではなく、コネクタを通過するデータフローについての追加の意味を提供する。バッファリングされたコネクタは、コネクタを通過するデータフローのファンインおよびファンアウトの両方を支援することが可能である。さらに、バッファリングされたコネクタは、ワークキューおよびデータルータとして使用され得る。バッファリングされたコネクタは、より多くのモジュール化かつ構成可能なアプリケーションコンポーネントを可能にするより多くの関心のあるデータハブ接続点を許容する。バッファリングされたコネクタもまた、ＡＲＫによって表現されたように、アプリケーションの構造に対してさらにより多くの定義を提供する。しかし、バッファリングされたコネクタは、ランタイムコストを有する。バッファリングされたコネクタは、コネクタがバッファリングするデータのための記憶装置を有しなければならない。さらに、バッファリングされたコネクタは、アプリケーションフェーズが関心のある方法で拡張、置換、および構成されることを可能にするように、いくつかの簡単なデータフィルタリングおよびルーティングオプションを支援しなければならない。バッファリングされたコネクタは、各データ要素をダウンストリームブロックに連続的に提供することによってファンインを可能にすることに対して有用である。さらにバッファリングされたコネクタが利用可能である。なぜならＡＲＫは、ブロックがコネクタのバッファにおいて利用可能な要素の数に基づいてスケジュールされることを可能にするためである。従って、簡単なループ構成は、作業／機能性のハイレベルな部分に対してインプリメントされ得る。これはまた、処理ブロックが簡略化されることを可能にし、入力のセットに関して作用する一方で、ＡＲＫは、現在の構成に基づいて利用可能な入力に基づいて繰り返して処理ブロックをスケジューリングする。バッファリングされたコネクタは、またイベント駆動マルチスレッド（クロスフェーズ）内部ブロック通信に対して特に利用可能である。
【０２０１】
（７．データインターフェースの要旨）
データインターフェースはＡＲＫにおいて基本的なものである。データインターフェースは、コードモジュールが抽象化インターフェースを用いてリアルタイムアプリケーションの内部に効率的に相互作用する。最低レベルのインターフェースは、ピンと呼ばれる原子的なフィールドインターフェースである。ピンは、ポートとして公知の階層的なタイプの構造にグループ化され得る。異なるブロックからのピンおよびポートは、簡単な接続を介して互いに接続され得る。接続が値を渡し接続として作用する点において、接続は意味的には簡単である。データインターフェースは、名前空間としてアプリケーションに別に存在し得る（このようなインターフェースは対称入力／出力タイプのデータを提供し、コネクタと呼ばれる）。特別なバッファリングされたコネクタは、処理ブロック間のより高度なデータ相互作用を可能にしつつ、なおアプリケーションの意図をＡＲＫに表現する。
【０２０２】
（Ｆ．オブジェクト設計言語（ＯＤＬ））
（１．ＯＤＬ概要）
本発明によるＯＤＬは、簡単で単純な態様で開発者に開発者のプログラムの構造を記述させる。このハイレベルな記述が使用されて、複数のハードウエアプラットフォームおよびソフトウエアプラットフォームに関するメインストリーム言語および関数よりもより高い性能を達成する態様でプログラムを実施し得る。
【０２０３】
ハードウエアプラットフォームおよびソフトウエアプラットフォームに含まれたライブラリ、アプリケーション、およびオブジェクトが、ＯＤＬで表現された。オブジェクト中のこの状態情報は、抽象的な態様で表現されるので、メモリおよびデータ転送が特定のプラットフォームのために調整される方法を用いて管理され得る。さらに、情報がＯＤＬを通じて提供され得、他の種類の最適化を可能にする。
【０２０４】
本明細書で説明された実施形態におけるＯＤＬは、スキームプログラミング言語の文法を用いる。なぜなら、ＯＤＬは、単純な方法で複雑な構造を任意に記述し得、新しい意味を用いて容易に拡張され、人間が読むことが可能になり（ＯＤＬが合理的にファーマットされた場合）、そして容易におよび迅速にコンピュータによって構文解析されるからである。あるいは、ＯＤＬは多くのプログラマにとって親しみやすくなり、ほとんどのテキストエディタによってサポートされる。
【０２０５】
（２．用語集）
このセクションでは用語のための用語集がここで提供される。
【０２０６】
オブジェクト：異なるタイプのカプセル化されたフィールドによって構成された状態情報を含むエンティティである。オブジェクトが含むフィールドのタイプに依存して、オブジェクトは他のオブジェクトに接続され、データフロープログラムにおいてオブジェクト間に流れ、そして手続型プログラムなど（Ｃ／Ｃ＋＋で書かれた）によって操作され得る。
【０２０７】
オブジェクト要素：オブジェクトの一部である。オブジェクト要素は、典型的には、名前を有し、所定のタイプの状態情報を保持する。異なる種類の要素は、以下に示される。
【０２０８】
インターフェース：オブジェクトへのデータの入力またはオブジェクトからのデータの出力のために使用される要素。
【０２０９】
フィールド：所定のタイプの状態情報を保持する要素。
【０２１０】
基礎：基礎として使用されるべきオブジェクト（「基礎オブジェクト」）を定義する要素または拡張のための基盤。このオブジェクトは、基礎オブジェクトの全ての要素を獲得する。
【０２１１】
拡張：追加されるべきオブジェクト（「拡張オブジェクト」）を定義する要素。オブジェクトは、拡張オブジェクトの全ての要素を獲得し、その接続を既存のコネクタにフックする。
【０２１２】
コネクタ：接続を行うための配置として作用する目的のみのために存在する要素。コネクタは、典型的には、基礎として使用され得るオブジェクト内部で使用される。その目的は、オブジェクトに接続するために拡張するための固定点を確立することである。
【０２１３】
接続：２つのオブジェクト間のデータ転送のための接続として役立つ要素。接続は、データのソース（フィールドまたはオブジェクト出力）をデータの消費者（オブジェクト入力）に接続する。
【０２１４】
直列：コネクタと直列に接続させる特殊な接続。この目的は、コネクタを介して流れるデータが複数の独立した態様で処理されることを可能にする。
【０２１５】
ブロック：少なくとも１つの入力および／または出力要素を有するオブジェクトであり、従ってデータフロープログラムにおける他のブロックに接続され得る。評価関数のみを含むブロックは、「簡単なブロック」と呼ばれる。他の全ては、「コンパウンドブロック」と呼ばれる。なぜなら、これらのブロックは、内部に他のブロックを含むためである。
【０２１６】
（３．データフローオブジェクト文法）
このセクションでは、中括弧はその中に満たされるべき値を表す。大括弧は、オプションのアイテムを表す。アスタリスクは、これに先行する０以上のアイテムを表す。
【０２１７】
（一般的文法）
全てのＯＤＬキーワードは、大文字と小文字の区別がない（ｃａｓｅ−ｉｎｓｅｎｓｉｔｉｖｅ）。しかし、オブジェクト名は大文字と小文字の区別がないことが保障されていない。なぜなら、いくつかの言語（特にＣおよびＣ＋＋）が独立しているためである。
【０２１８】
スキーム型コメントが支援される。セミコロンと以下の復帰文字との間の全ての文字からなる。
【０２１９】
（オブジェクト参照）
オブジェクト参照の２つのタイプがある。すなわち、制限された（通常の）オブジェクト参照（ＯｂｊｅｃｔＲｅｆ）および完全なオブジェクト参照（ＯｂｊｅｃｔＣＲｅｆ）である。
【０２２０】
ＯｂｊｅｃｔＲｅｆオペレータは、オブジェクト定義参照を別のオブジェクト定義にする。参照されたオブジェクトのパブリック要素だけがアクセスされ得る。参照オブジェクトのパブリック要素のみがアクセスされ得る。ＯｂｊｅｃｔＲｅｆへのパラメータは、任意の数の参照されたオブジェクトのプロパティを含み得る。ＯｂｊｅｃｔＲｅｆオペレータは、参照を回復し、参照自体をパラメータによって識別されたオブジェクト定義に置換する。
【０２２１】
以下の例は、ｉＡｄｄｅｒブロックを識別する。
【０２２２】
（ＯｂｊｅｃｔＲｅｆ（Ｂｌｏｃｋ（Ｎａｍｅ’ｉＡｄｄｅｒ）））
ＯｂｊｅｃｔＣＲｅｆオペレータは、ＯｂｊｅｃｔＣＲｅｆオペレータが、パブリック要素だけではなく、参照されたオブジェクトの全ての要素にアクセスすることを可能にすることを除いて、ＯｂｊｅｃｔＲｅｆのように作用する。これは、通常基礎および拡張要素と共に使用されるのみである。
【０２２３】
ＯｂｊｅｃｔＣＲｅｆオペレータは、この態様の基礎を再インプリメントし、拡張要素が復帰する場合、カプセル化を妨害し、恐らくカプセル化は将来なくなる。
【０２２４】
（タイプ識別子）
オブジェクトタイプ識別子は、ビルトインタイプまたはオブジェクト定義のいずれかを特定し得る。
【０２２５】
少数のビルトインタイプは、複雑なオブジェクトの構築に対して支援される。ビルトインタイプは、タイプオペレータを用いて特定される。
【０２２６】
（ｔｙｐｅ｛ｉＢｏｏｌ│ｉＩｎｔ│ｉＦｌｏａｔ│ｉＰｏｉｎｔｅｒ｝）いくつかの他のオブジェクトタイプに対して、オブジェクト定義が特定される。ほとんどのオブジェクト定義が１つの位置で定義され、識別子によって参照されるため、ＯｂｊｅｃｔＲｅｆオペレータが通常使用される。しかし、オブジェクト定義が１つの位置のみで使用される場合、オブジェクト定義は「インライン（ｉｎｌｉｎｅ）」のように見え得る。
【０２２７】
インラインオブジェクト定義がまだ十分に支援されていない。
【０２２８】
どのタイプのオブジェクトが使用されるかに独立して、タイプ識別子は、データがローカルまたはリモートに存在することを記述し得る。ローカルオブジェクトは、ローカルにインスタンスが作られたものである。リモートオブジェクトは、別の位置に存在し、参照されるオブジェクトである（例えば、別のオブジェクトの内側）。ピンオペレータは、任意のタイプの識別子をリモートにある識別子に変換し得る。
【０２２９】
リモートにアクセスされたオブジェクトは、典型的には、オブジェクトの入力、出力、およびコネクタ要素に使用される。
【０２３０】
（例）
整数
（Ｔｙｐｅ’ｉＩｎｔ）
ＯｂｊｅｃｔＲｅｆオペレータを用いるｉＡｄｄｅｒブロックは、
（ＯｂｊｅｃｔＲｅｆ（Ｂｌｏｃｋ（Ｎａｍｅ　’ｉＡｄｄｅｒ）））
インラインのｉＡｄｄｅｒブロックは、
（Ｂｌｏｃｋ（Ｎａｍｅ　’ｉＡｄｄｅｒ）（Ｉｎｐｕｔ（Ｎａｍｅ　’ｌｅｆｔ）（Ｔｙｐｅ　’ｉＩｎｔ））．．．）
リモートにアクセスされた整数は、
（Ｐｉｎ（Ｔｙｐｅ　’ｉＩｎｔ））
リモートにアクセスされたｉＡｄｄｅｒブロックは、
（Ｐｉｎ（ＯｂｊｅｃｔＲｅｆ（Ｂｌｏｃｋ（Ｎａｍｅ　’ｉＡｄｄｅｒ））））
（４．オブジェクト文法）
オブジェクトが含む要素に依存して、オブジェクトデータフロープログラムを通過して流れる簡単な状態コンテナにあり得るか、またはオブジェクトは、プログラムに接続され得るブロックであり得る。
【０２３１】
状態コンテナは、典型的には、フィールドまたは関数を含むが、一方ブロックは、入力、出力、内部ブロック、コネクタ等を含む。任意のオブジェクトは任意の要素を含むため、実際には、状態コンテナオブジェクトとブロックとの間に鋭い違いがない。
【０２３２】
ブロックのインプリメンテーションは、ワイヤおよび計算を実行し得る「評価」関数によって互いに接続された内部ブロックおよびフィールドのネットワークから形成され得る。さらにブロックは、直列接続（典型的には、拡張オブジェクトにおいて使用される）が接続され得るコネクタを含む。ブロックをインプリメントする２つの方法がある。第１の方法は、内部ブロック、フィールド、コネクタ、および接続の収集を明示的に特定することである。第２の方法は、基礎要素および０以上の拡張要素を使用することである。後者の場合、基礎オブジェクトの実現は、新しいインプリメンテーションを形成する拡張オブジェクトのインプリメンテーションと組み合わされる。
【０２３３】
さらに基礎要素が使用され、オブジェクトのプロパティの従来の継承をインプリメントし得る。より多くの情報については、以下の基礎セクションを参照のこと。
【０２３４】
（オブジェクトアイデンティティ）
全てのオブジェクト定義は、一意に定まる識別子のリストを含まなければならない。共に選択する場合、オブジェクト定義を一意に識別する。一意に定まる識別子のリストは、識別子のプロパティによって特定される。識別子のプロパティが存在しない場合、オブジェクトは、単に名前のプロパティによって識別されるだけである。
【０２３５】

（インターフェース：入力および出力）
入力および出力インターフェースは、ＩｎｐｕｔおよびＯｕｔｐｕｔプロパティによって特定される。入力および出力インターフェースのそれぞれは、タイプ識別子を有し、タイプ識別子は、入力に流れるかまたは出力から流れるデータのタイプを説明する。
【０２３６】
（フィールド）
状態情報は、フィールドに格納される。それぞれのフィールドは、タイプ識別子を有する。タイプ識別子は格納されたデータのタイプを説明する。
【０２３７】
Ｖａｌｕｅのプロパティは、フィールドの初期値を特定する。ビルトインデフォルト値を有さない基礎的なタイプ（ｉｎｔ、ｆｌｏａｔ等）を用いてのみ使用される。
【０２３８】
Ｏｗｎｅｄプロパティを内在的なオブジェクトであるフィールドに適用するのみである。真に設定する場合、オブジェクトは管理される（インスタンス化が作成される、削除される等）。デフォルトではオブジェクトは真に設定される。
【０２３９】
Ｒｅｓｅｔプロパティは、どのようにフィールドの値がリセットされるかを特定する。デフォルトがＶａｌｕｅである。これは、フィールドの値がリセットされる場合、フィールドの値がその初期値に設定されることを意味する。フィールドの値がゼロ（Ｎｏｎｅ）に設定された場合、その値をリセットするために何も行われない（他の設定がまだインプリメントされていない）。
【０２４０】
（評価関数）
評価関数のインプリメンテーションは、インプリメンテーションのプロパティを用いて特定される、このコードは、インライン（Ｃｏｄｅプロパティを用いて）またはファイルにおいて（Ｆｉｌｅプロパティを用いて）特定され得る。このファイルのプロパティが使用された場合、ファイル名はオプションである、名前が特定されない場合、この名前が自動的に作成される。ファイルが存在しない場合、このファイルが自動的に作成される。
【０２４１】
評価関数によって導き出された追加のコードは、ＯＤＬプログラムにおいて識別される必要はない。このコードは、ランタイム時にアクセス可能なライブラリにおいて存在する必要があるのみである。
【０２４２】
（コネクタ（Ｃｏｎｎｅｃｔｏｒ））
コネクタは、コネクタ（Ｃｏｎｎｅｃｔｏｒ）プロパティを用いて明記される。コネクタは、典型的には、ベースオブジェクトとして用いられることを意図されたブロックで用いられる。コネクタの目的は、ベースブロックのデータフロープログラムの正しい場所に拡張部分を自動的にコネクトすることを可能にすることである。
【０２４３】
データは、コネクタを通ってフローする。コネクタは、データのストリームを露出して、その結果、拡張部分は、データのストリーム内にタップ（ｔａｐ）し得る。データは、データが直列接続を用いてコネクタを通るときに修正され得る。（以下の一連のセクションを参照）
（内部ブロック（Ｉｎｔｅｒｎａｌ　Ｂｌｏｃｋ））
オブジェクトのインプリメンテーションの一部を作り上げる内部ブロックは、ブロック（Ｂｌｏｃｋ）オペレータを用いて明記される。フィールドと同様に、用いるオブジェクトのタイプを述べるために、タイプスペシファイア（ｓｐｅｃｉｆｉｅｒ）が必要とされる。
【０２４４】
（関数（Ｆｕｎｃｔｉｏｎ））
関数は、関数（Ｆｕｎｃｔｉｏｎ）オペレータを用いて明記される。
【０２４５】
現在、Ｃ＋＋関数のみが支援され、それらは、Ｃ＋＋コードでのみ呼出可能である。
【０２４６】
関数は、名前、言語、戻り値、任意の数のパラメータを有する。Ｃ＋＋関数にとって、パラメータの順序は、また、明記される必要がある。
【０２４７】
言語は、言語（Ｌａｎｇｕａｇｅ）オペレータを用いて明記される。デフォルト値は存在しないが、それぞれの関数は、言語プロパティを有する必要がある。支援言語は、Ｃ＋＋である。
【０２４８】
戻り値は、戻り（Ｒｅｔｕｒｎ）オペレータを用いて明記される。パラメータは、パラメータ（Ｐａｒａｍｅｔｅｒ）オペレータを用いて明記される。全てのパラメータおよび戻り値は、タイプのスペシファイアを有する必要がある。パラメータは、Ｃ＋＋関数のために名前を付けられる必要があり、戻り値は、名前を付けられなくてもよい。パラメータの順序は、パラメータオーダ（ＰａｒａｍｅｔｅｒＯｒｄｅｒ）オペレータを用いて明記される。
【０２４９】
例：
この関数は、二つの整数パラメータを取り、浮動小数の値を戻す。
（Ｆｕｎｃｔｉｏｎ　（Ｎａｍｅ　ＦｉｘｅｄＴｏＦｌｏａｔ）（Ｌａｎｇｕａｇｅ　Ｃ＋＋）
（Ｒｅｔｕｒｎ　（Ｔｙｐｅ　ｉＦｌｏａｔ））
（Ｐａｒａｍｅｔｅｒ　（Ｎａｍｅ　ＨｉｇｈＢｉｔｓ）（Ｔｙｐｅ　ｉＩｎｔ））
（Ｐａｒａｍｅｔｅｒ　（Ｎａｍｅ　ＬｏｗＢｉｔｓ）（Ｔｙｐｅ　ｉＩｎｔ））
（ＰａｒａｍｅｔｅｒＯｒｄｅｒ　ＨｉｇｈＢｉｔｓ　ＬｏｗＢｉｔｓ）
（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　（Ｆｉｌｅ））
（コネクション（Ｃｏｎｎｅｃｔｉｏｎｓ））
内部ブロックまたはコネクタ間の「ワイヤ」は、コネクション（Ｃｏｎｎｅｃｔｉｏｎ）プロパティを用いて明記される。ワイヤのプロパティ（ワイヤが何にコネクトするか）は、フロム（Ｆｒｏｍ）およびトゥー（Ｔｏ）プロパティを用いて明記される。
【０２５０】
フロム（Ｆｒｏｍ）プロパティは、ワイヤの入力端部がコネクトされる場所を明記する。データは、ワイヤのこの端部内にフローする。トゥー（Ｔｏ）プロパティは、ワイヤの出力端部がコネクトされる場所を明記する。データは、ワイヤのこの端部からフローする。
【０２５１】
フロム（Ｆｒｏｍ）およびトゥー（Ｔｏ）プロパティは、それぞれ、コネクトされるべきインタフェース要素の位置を明記する。それらは、互いに互換性が必要である。すなわち、それらは、同じデータタイプを運搬する必要がある。それらは、それぞれ、一つ、または、二つのいずれかのパラメータを有する。一つのパラメータのみが存在する場合、そのパラメータは、インタフェース要素（入力または出力）、あるいは、コネクションが属するブロックのコネクタを識別する。二つのパラメータが存在する場合、それらは、内部ブロックのインタフェース要素を明記する。第１のパラメータは、内部ブロックの名前であり、第２のパラメータは、インタフェースの名前である。
【０２５２】
コネクタが拡張部分内のコネクションのフロムまたはトゥープロパティに識別される場合、コネクタは、コネクタが拡張部分またはベースブロックのコネクタを識別するかどうかを明記する余分な要素を含む。これは、識別子の一般的なフォームに「（ベース（ｂａｓｉｓ））」または「（拡張部分（ｅｘｔｅｎｓｉｏｎ））」のいずれかを追加することによってなされる。以下の最後の例を参照。
【０２５３】
例：
この接続は、ブロックの左の入力を内部ブロックＡのＸ入力に結ぶ：
（Ｃｏｎｎｅｃｔｉｏｎ（Ｆｒｏｍ　’Ｌｅｆｔ）（Ｔｏ　’Ａ　’Ｘ））
このコネクションは、内部ブロックＡのＲ出力を内部コネクタＢの入力に結ぶ：
（Ｃｏｎｎｅｃｔｉｏｎ（Ｆｒｏｍ　’Ａ　’Ｒ）（Ｔｏ　’Ｂ））
このコネクションは、内部ブロックＣのＲＧＢ出力をブロックのカラー（Ｃｏｌｏｒ）出力に結ぶ：
（Ｃｏｎｎｅｃｔｉｏｎ（Ｆｒｏｍ　’Ｃ　’ＲＧＢ）（Ｔｏ　’Ｃｏｌｏｒ））
このコネクションは、拡張部分内に存在する。このコネクションは、拡張部分の内部ブロックＤのサム（Ｓｕｍ）出力をベースブロックのコネクタＣに結ぶ
（Ｃｏｎｎｅｃｔｉｏｎ（Ｆｒｏｍ　’Ｄ　’Ｓｕｍ）（Ｔｏ（（Ｎａｍｅ　’Ｃ）（Ｂａｓｉｓ））））
（直列接続（Ｓｅｒｉｅｓ　Ｃｏｎｎｅｃｔｉｏｎ））
直列接続は、コネクタと結び付いて用いられるコネクションの特定のタイプである。
【０２５４】
コネクタを通ってフローするデータに計算を実行することを望む場合、シリーズプロパティを用いて計算を明記し得る。計算は、コネクタのデータのフロー内に挿入され、その結果、コネクタ内にフローするデータが処理され、コネクタの出力で新規のデータを生成している。複数のシリーズ要素を用いて、任意の数の独立した計算（すなわち、互いの知識を有しない計算）は、コネクタのシリーズに挿入され得る。
【０２５５】
それらが挿入される順序は、それがまだ利用可能ではない情報（例えば、入力されたブロックのパフォーマンスの特徴）に依存し得るために、現在明記されない。
【０２５６】
シリーズプロパティは、３つの別個の要素を含む。
１．計算が実行されるべき場所でコネクタを識別するコネクタ（Ｃｏｎｎｅｃｔｏｒ）要素
２．新規のコネクタデータが由来する場所でデータソースを識別するフロム（Ｆｒｏｍ）要素
３．コネクタデータが与えられる場所内への入力を明記する任意の数のトゥー（Ｔｏ）要素
（ベース（Ｂａｓｉｓ））
ベース（Ｂａｓｉｓ）オペレータによって、別のオブジェクトの要素が得られ得る。ベース要素は、プロパティの従来の継承のために、拡張要素のための基礎として用いられ得る。
【０２５７】
（プロパティの従来の継承（Ｔｒａｄｉｔｉｏｎａｌ　Ｉｎｈｅｒｉｔａｎｃｅ　ｏｆ　Ｐｒｏｐｅｒｔｉｅｓ））
ベースオペレータによってオブジェクトが別のオブジェクトのプロパティを得ることができるために、ベースオペレータは、いくつかのオブジェクトがプロパティのセットを共有するときに用いられ得る。共有されたプロパティは、オブジェクトにおいて定義され、オブジェクトは、プロパティを共有する全てのオブジェクトにおいてベースとして用いられる。
【０２５８】
この目的のためのベースとして用いるために、ベース要素を名付けない。これにより、サブオブジェクトは、同じ名前を用いるベースオブジェクト要素を参照し得る。衝突を避けるために、ベース要素が名付けられると、ベースオブジェクト要素は、それらがサブオブジェクトによって得られるとき、余分な識別子を与えられる。
【０２５９】
注記：ベースの使用は、抽象化（ａｂｓｔｒａｃｔｉｏｎ）を形成しない。これは、ポリモーフィズム（ｐｏｌｙｍｏｒｐｈｉｓｍ）を可能にしない。ポリモーフィズムを可能にする従来の継承は、支援されない。代わりに、抽象化が、ブロックインタフェースの使用を通して生成される。
【０２６０】
（拡張部分の土台（Ｆｏｕｎｄａｔｉｏｎ　ｆｏｒ　Ｅｘｔｅｎｓｉｏｎｓ））
拡張要素で拡張する目的のためにベースを用いるために、ベース要素は、ベースオブジェクト要素が拡張オブジェクトのいくつかとの衝突を避けるように名前を与えられる必要がある。
【０２６１】
（拡張部分（Ｅｘｔｅｎｓｉｏｎｓ））
拡張部分（Ｅｘｔｅｎｓｉｏｎ）オペレータによって別のオブジェクトの要素が既存のコネクタまで得られ、かつ、フックされることが可能である。拡張部分のコネクション要素において名前を付けられるコネクタが存在しない場合、エラーが生じる。コネクタは、典型的にベース要素によって供給される。
【０２６２】
注記：入力および出力が拡張部分において支援されるべきかどうか明らかではない。この時点において、拡張部分は、入力または出力を含むべきではない。
【０２６３】
（シンタックスの要旨）
【０２６４】
【数１】

演算子は、現在、すべてのオブジェクトを定義するために用いられる。これは、おそらく、ただちに
【０２６５】
【数２】

に変更される。
【０２６６】
【数３】

（拡張子（Ｅｘｔｅｎｓｉｏｎ）シンタックス）
拡張子は、入力および出力以外のエレメントであるオブジェクトである。このコネクションは、この拡張子が用いられるオブジェクト内のコネクタを参照し得、コネクタが自動的にオブジェクトに接続されることを可能にする。この理由で、拡張オブジェクトは、孤立して用いられ得ない。オブジェクトが参照するこれらのコネクタは、外部に、通常、基底エレメントを介して供給されなければならない。
【０２６７】
コネクタが、拡張子内の接続のフロム（Ｆｒｏｍ）プロパティまたはトゥ（Ｔｏ）プロパティで識別される場合、コネクタは、コネクタを拡張子内で識別しているのか、またはこのコネクタが属するオブジェクト内で識別しているのかを特定するための追加的エレメントを含まなければならない。これは、識別子の一般的な形態の「（ｂａｓｉｓ）」または「（ｅｘｔｅｎｓｉｏｎ）」のどちらかが付加されることによってなされる。
【０２６８】
次節における例を参照されたい。
【０２６９】
（５．データフローオブジェクトの例）
（単純なブロック）
（ｉＡｄｄｅｒ）
図２１に示されるブロックは、２入力加算器であり、ｉＡｄｄｅｒと称される。この加算器は、単純なブロックである。なぜなら、この加算器の出力は、評価関数によって計算されるからである。２つの整数入力は、一緒に加算され、出力を生成する。
【０２７０】
ＯＤＬコードは、以下に示される。
【０２７１】
【数４】

ブロックの評価関数のインプリメンテーションが以下に示される。これは、別個のファイル内に常駐する。
【０２７２】
＿ｓｕｍＦｉｅｌｄ　＝　＿ｌｅｆｔ　＋　＿ｒｉｇｈｔ；
（複合ブロック）
（ｉＡｄｄｅｒ３）
図２２に示されるブロックは、３入力加算器であり、ｉＡｄｄｅｒ３と称される。これは、２つのｉＡｄｄｅｒブロックを用いてインプリメントされる。
【０２７３】
ＯＤＬコードは、以下に示される。
【０２７４】
【数５】

（基底（Ｂａｓｉｓ）および拡張（Ｅｘｔｅｎｓｉｏｎ）オブジェクト）
この例は、３つの異なったオブジェクトを含む。これらは、基底ブロックとして用いられる複合ブロック、この基底ブロックを拡張する拡張オブジェクト、および基底および拡張エレメントを用いることによって、これらの２つを組み合わせるブロックである。
【０２７５】
（ｉＦｏｒｍｕｌａ）
図２５に示される、この複合ブロックは、２つのコネクタ、ｍおよびｇを含み、これらのコネクタに拡張子が接続され得る。
【０２７６】
【数６】

（ｉＭｙＥｘｔｅｎｔｉｏｎ）
この拡張子の接続は、ｉＦｏｒｍｕｌａブロック内のコネクタを参照し、従って、このブロックを拡張するために用いられ得る。これは、図２４に示され、コネクタｍ内へ入り込み（ｔａｐ　ｉｎｔｏ）、コネクタｇと直列で挿入される単純なプログラムを含む。
【０２７７】
【数７】

（ｉＭｙＦｏｒｍｕｌａ）
このブロックは、ｉＦｏｒｍｕｌａブロックを基底ブロックとして用いる。この基底ブロックは、ｉＭｙＥｘｔｅｎｓｉｏｎ拡張を用いてそれを拡張する。
【０２７８】
【数８】

（ＩＶ．結論）
本発明の種々の実施形態が上に記載されたが、これらの実施形態は、限定としてではなく、例示として提供されたことが理解されるべきである。本発明の主旨および範囲から逸脱することなく、詳細な種々の変更が成され得ることが当業者に明らかである。従って、本発明は、上述の例示の実施形態のいずれかによって限定されるべきでないが、上記の請求項およびその同等物によってのみ定義されるべきである。
【図面の簡単な説明】
【図１】
図１は、伝統的な画像生成装置の要素を示す。
【図２】
図２は、ワークステーション画像生成装置、所与のランタイムソフトウエアの要素を示す。
【図３Ａ】
図３Ａは、Ｐｌａｙｓｔａｔｉｏｎ２のプラットフォームへの顧客専用化されたゲーム開発への従来の階層化アプローチを示す。
【図３Ｂ】
図３Ｂは、パーソナルコンピュータのプラットフォームへの顧客専用化されたゲーム開発への従来の階層化アプローチを示す。
【図４】
図４は、本発明の実施形態における、ゲーム内容を開発するためのプロセスを示す。
【図５】
図５は、本発明の実施形態における、ＧＡＰの構造を示す。
【図６】
図６は、本発明の実施形態における、ブロック内部構造の例を示す。
【図７】
図７は、本発明の実施形態における、構成要素の構造の例を示す。
【図８】
図８は、本発明の実施形態における、フレームワークの段階間のブロックの分布を示す。
【図９】
図９は、本発明の実施形態における、１つのスレッドプロセスで実行されるステージの例を示す。
【図１０】
図１０は、本発明の実施形態における、１つのＡＲＫスレッドマネージャおよびこの実行順序リストを示す。
【図１１】
図１１は、本発明の実施形態における、実行順序リストから成る多数のＡＲＫスレッドの同時実行を示す。
【図１２】
図１２は、本発明の実施形態における、ＧＡＰアーキテクチャを用いて開発された地球画像の例を示す。
【図１３Ａ】
図１３Ａは、本発明の実施形態における、多数のハードウエアプラットフォームにまたがって、ＧＡＰによって支援される実存機能のソフトウエア開発者の用途を示す。
【図１３Ｂ】
図１３Ｂは、本発明の実施形態における、多数のハードウエアプラットフォームにまたがって、ソフトウエア開発者によって追加されかつＧＡＰによって支援されるアプリケーションの特定の機能の用途を示す。
【図１４Ａ】
図１４Ａは、本発明の実施形態における、多数のゲームに対して、ハードウエアプラットフォームの利用を可能にしたＧＡＰによって支援される実存機能のハードウエア開発者の用途を示す。
【図１４Ｂ】
図１４Ｂは、本発明の実施形態における、ハードウエア開発者によって追加されかつＧＡＰによって支援される、ハードウエアの特定の機能のハードウエア開発者の用途を示し、これらは、多数のゲームに対して、これらの機能の利用を可能にする。
【図１５】
図１５は、本発明の実施形態における、シェーダのセットを示し、そしてここでは特定のシェーダがランタイムの時に選ばれる。
【図１６Ａ】
図１６Ａは、本発明の実施形態における、ＰｌａｙＳｔａｔｉｏｎ２に適応したＧＡＰアーキテクチャの実現例を示す。
【図１６Ｂ】
図１６Ｂは、本発明の実施形態における、ＯｐｅｎＧＬを実行させているパーソナルコンピュータプラットフォームに適応したＧＡＰアーキテクチャの実現例を示す。
【図１６Ｃ】
図１６Ｃは、本発明の実施形態における、Ｄｉｒｅｃｔ３Ｄを実行させているパーソナルコンピュータプラットフォームに適応したＧＡＰアーキテクチャの実現例を示し、そしてそこでは、パーソナルコンピュータプラットフォームは、３ｄｆｘおよびＮｖｉｄｉａグラフィックスハードウエアを含み、そしてＤｉｒｅｃｔ３Ｄマイクロコードは拡張を含む。
【図１６Ｄ】
図１６Ｄは、本発明の実施形態における、ＰｌａｙＳｔａｔｉｏｎ２のプラットフォームに適応したＧＡＰアーキテクチャの実現例を示し、そしてそこでＰＳＸ２マイクロコードは拡張を含む。
【図１６Ｅ】
図１６Ｅは、本発明の実施形態における、Ｎｉｎｔｅｎｄｏ　Ｄｏｌｐｈｉｎプラットフォームに適応したＧＡＰアーキテクチャの実現例を示す。
【図１７】
図１７は、本発明の実施形態における、ある例のゲームのプロセスフローのゲームアプリケーションのテンプレートを示す。
【図１８】
図１８は、本発明の論理的な図を示し、これは、アプリケーショングラフおよびシーングラフに関連した、ユーザ機能および標準のＧＡＰ機能を含む。
【図１９】
図１９は、本発明の実施形態における、別の構成要素の実現を示し、そしてこれは、関連のアプリケーションの条件および供給されるリソースを示す。
【図２０】
図２０は、本発明の実施形態における、フレームワークアプリケーションの例を示す。
【図２１】
図２１は、本発明の実施形態における、アプリケーション開発モデルに従って接続するブロックおよびグラフの例を示す。
【図２２】
図２２は、本発明の実施形態における、アプリケーション開発モデルに従って接続するブロックおよびグラフの例を示す。
【図２３】
図２３は、本発明の実施形態における、アプリケーション開発モデルに従って接続するブロックおよびグラフの例を示す。
【図２４】
図２４は、本発明の実施形態における、アプリケーション開発モデルに従って接続するブロックおよびグラフの例を示す。
【図２５】
図２５は、本発明の実施形態における、アプリケーション開発モデルに従って接続するブロックおよびグラフの例を示す。
【図２６】
図２６は、本発明の実施形態における、アプリケーション開発モデルに従って接続するブロックおよびグラフの例を示す。

Claims (15)

1. ランタイムプラットフォームに依存しないコンテンツの開発をサポートするための方法であって、
   コンテンツを定義するプロセッシングブロックを格納するステップと、
   該格納されたプロセッシングブロックと該格納されたプロセッシングブロック間のデータコネクティビティとの同一性を表現するアプリケーショングラフを格納するステップであって、該アプリケーショングラフは、ランタイムプラットフォーム上で適切なプロセッシングブロックを実行するためにランタイムにグラフィカルアプリケーションプラットフォームによって横断され得る、ステップと
   を包含する方法。
2. 前記コンテンツは、ゲームコンテンツを含む、請求項１に記載の方法。
3. 複数のハードウェアプラットフォームに依存しないコンテンツの開発をサポートするための方法であって、
   複数のハードウェアプラットフォームに依存しないコンテンツを定義するプロセッシングブロックを格納するステップと、
   標的のハードウェアプラットフォームを複数のハードウェアプラットフォームから選択するステップと、
   該選択された標的のハードウェアプラットフォームに基づいて該格納されたプロセッシングブロックと、該格納されたプロセッシングブロック間のデータコネクティビティとの同一性を表現するアプリケーショングラフを格納するステップと、
   ランタイムに該アプリケーショングラフを横断させるステップであって、該選択された標的ハードウェアプラットフォーム上で適切なプロセッシングブロックを生成することを含む、ステップと
   を包含する、方法。
4. 前記コンテンツは、ゲームコンテンツを含み、前記複数のハードウェアプラットフォームは、ゲームコンソールプラットフォームおよびパーソナルコンピュータプラットフォームの少なくとも一つを含む、請求項３に記載の方法。
5. ゲーム開発およびランタイムのシステムであって、
   ゲームアプリケーションが複数のハードウェアプラットフォームの任意上を実行することを可能にするグラフィカルアプリケーションプラットフォームを含む、システム。
6. 前記ゲームアプリケーションが標的のハードウェアプラットフォーム上を実行し得るように、開発者がアプリケーショングラフを定義することを可能にするオブジェクト定義ツールをさらに含む、請求項５に記載のシステム。
7. 前記オブジェクト定義ツールは、開発者がオブジェクト、オブジェクトエレメント、および接続を定義することをさらに可能にする、請求項６に記載のシステム。
8. アプリケーションソフトウェアおよびハードウェアプラットフォームの少なくとも一つにおいて独立して提供される能力を達成するためのグラフィカルアプリケーションプラットフォームであって、
   アプリケーション実時間カーネル（ＡＲＫ）と、
   実行可能な論理ブロックとしてインプリメントされる複数の標準機能と、
   データフローを該ブロック間にインプリメントする該ブロック間の接続と
   を含み、
   アプリケーションソフトウェアおよび該ハードウェアプラットフォームの少なくとも一つの能力は、追加的に対応するブロックおよび接続を追加することによってモジュール的にインプリメントされ得る、グラフィカルアプリケーションプラットフォーム。
9. 前記ＡＲＫは、少なくとも一つの中央プロセッシング装置上で実行する少なくとも一つのＡＲＫスレッドのそれぞれにおいて実行されるように前記ブロックを列挙するスケジューリングによるブロックを呼び出す論理であって、該論理は、ブロックを動的にロードおよびアンロードし、ブロックの実行をモニタし、および、スレッド管理、メモリ共有、相互排他、および同期化を容易にする、論理を含む、請求項８に記載のグラフィカルアプリケーションプラットフォーム。
10. 前記追加のブロックは、追加機能をインプリメントし、該追加機能は、マーケット指向の機能を含む、請求項８に記載のグラフィカルアプリケーションプラットフォーム。
11. 前記追加のブロックは、追加機能をインプリメントし、該追加機能は、アプリケーション特有の機能を含む、請求項８に記載のグラフィカルアプリケーションプラットフォーム。
12. 前記標準および追加のブロックは、コンポーネントに組織化され、各コンポーネントは、代替の機能インプリメンテーションを表わすブロックを含む、請求項８に記載のグラフィカルアプリケーションプラットフォーム。
13. 前記代替のインプリメンテーションのそれぞれは、
    ａ）該代替のインプリメンテーションに対応するブロックと、
    ｂ）該代替のインプリメンテーションによって必要とされるリソースの識別と、
    ｃ）該代替のインプリメンテーションによって提供されるリソースの識別と
    を含む、請求項１２に記載のグラフィカルアプリケーションプラットフォーム。
14. 所定のハードウェアプラットフォームに関してグラフィックスアプリケーションを予め処理する方法であって、
    ａ）一組の代替の機能インプリメンテーションの間から選択するステップと、
    ｂ）該選択されたインプリメンテーションに対応して、少なくとも一つのブロックを実行フェーズにマッピングするステップと、
    ｃ）該実行フェーズを実行ステージにマッピングするステップと、
    ｄ）該実行ステージに対応するブロック実行オーダーリストを生成するステップと、
    ｅ）該実行ステージを、該ステージの実行の管理のためのアプリケーション実時間カーネルに提示するステップと
    を包含する、方法。
15. 前記ステップａ）は、各代替のインプリメンテーションのリソース要求が、このようなリソース要求における変動のコストおよび利益と共に考慮されたネゴシエーションプロセスを包含し、これにより、インプリメンテーションの選択が可能になる、請求項１４に記載の方法。

Images