JP2016212874A - アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 - Google Patents

アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 Download PDF

Info

Publication number
JP2016212874A
JP2016212874A JP2016093158A JP2016093158A JP2016212874A JP 2016212874 A JP2016212874 A JP 2016212874A JP 2016093158 A JP2016093158 A JP 2016093158A JP 2016093158 A JP2016093158 A JP 2016093158A JP 2016212874 A JP2016212874 A JP 2016212874A
Authority
JP
Japan
Prior art keywords
application program
rendering
graphic
texture
parameter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2016093158A
Other languages
English (en)
Inventor
林修平
Hsiu-Ping Lin
蔡弘毅
Hung-I Tsai
呉齊人
Chi-Jen Wu
石鴻賓
Hung-Pin Shih
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FIISER Inc
Original Assignee
FIISER Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/707,008 external-priority patent/US20160044139A1/en
Application filed by FIISER Inc filed Critical FIISER Inc
Publication of JP2016212874A publication Critical patent/JP2016212874A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Controls And Circuits For Display Device (AREA)
  • Digital Computer Display Output (AREA)
  • Image Generation (AREA)

Abstract

【課題】アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法の提供。【解決手段】アプリケーションプログラムのグラフィック(graphic)をレンダリング(rendering)する方法において、アプリケーションプログラムはサーバーにおいて執行され、しかもグラフィックをユーザーエンドでレンダリングする。該方法は以下のステップを含む。サーバーはレンダリングコマンド、パラメーター及び/或いはテクスチャー(texture)を受け取り、レンダリングコマンド、パラメーター及び/或いはテクスチャーを、ユーザーエンドのドライバープログラムに伝送し、ユーザーエンドのグラフィクス処理ユニット(GPU)により、グラフィックをレンダリングする。【選択図】図2C

Description

本発明はユーザーによるインプット、或いはハードウエアによるインプットを通してユーザーインターフェースを生じるシステムと方法で、特にバーチャルマシンに接続するアプリケーションプログラムにユーザーインターフェース或いはスクリーン画面を生じさせるアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法に関する。
アプリケーションプログラムArowser(以下「ArowserTM」と呼称)は、特許文献1で初めて開示された。その名称は「METHODS AND SYSTEMS FOR IN-APPS SEARCH AND APP BROWSERS」で、2013年10月7日に申請されている。
それは、アプリケーションプログラムをリモートエンドサーバーにおいて執行し、しかも該アプリケーションプログラムのスクリーン画面はその後、該リモートエンドサーバーからユーザーエンドへと伝送或いはストリームされ、ユーザーエンドインターフェース上に表示される(例えば、ArowserTMに表示される)。ArowserTM技術の協力により、ユーザーは、ストリームスクリーン画面とのインタラクティブにより、アプリケーションプログラムをリモート操作し、ローカルエンドにおいて、該アプリケーションプログラムをインストール必要はない。
従来は、リモートエンドサーバーは通常、グラフィクス処理ユニット(GPU)を備えなければ、レンダリングし、イメージストリーム方式により、ユーザーエンドのapp画面に伝送しアウトプット(screen output)することはできなかった。しかし、これでは、リモートエンドサーバーは、ディスプレイカード(display card)を搭載しなければならない。これにより、ハードウエアのコストが拡大するばかりか、GPUはリモートエンドサーバー上の他のハードウエアパーツに比べ、作動時により多くのエネルギーを消費するため、電力消費或いは散熱の面でも大きな問題を抱えている。
米国特許(仮出願)第61862967号明細書
前記先行技術には、リモートエンドサーバーがディスプレイカードを搭載しなければならず、これによりハードウエアのコストが拡大し、さらにGPUはリモートエンドサーバー上の他のハードウエアパーツに比べ、作動時により多くのエネルギーを消費するため、電力消費或いは散熱の面でも大きな問題があるという欠点がある。
本発明はアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法に関する。
本発明によるアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法のもう一つの実施形態は、アプリケーションプログラムのグラフィック(graphic)をレンダリング(rendering)する方法を提供する。該アプリケーションプログラムは、サーバーにおいて執行され、しかも該グラフィックをユーザーエンドでレンダリングする。
該方法は以下のステップを含む。
該サーバーは、レンダリングコマンド、パラメーター及び/或いはテクスチャー(texture)を受け取る。
該レンダリングコマンド、該パラメーター及び/或いは該テクスチャーを、該ユーザーエンドのドライバープログラムに伝送し、該ユーザーエンドのグラフィクス処理ユニット(GPU)により、該グラフィックをレンダリングする。
本発明によるアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法のさらにもう一つの実施形態は、第一アプリケーションプログラムを提供する。
それはユーザーエンドにおいて執行され、サーバーの第二アプリケーションプログラムにおいて執行され、グラフィックをレンダリングする。
該第一アプリケーションプログラムは、レシーバーを有する。
該レシーバーは、該サーバーの一レンダリングコマンド、パラメーター及び/或いはテクスチャーを受け取り、しかも該レンダリングコマンド、該パラメーター及び/或いは該テクスチャーを、該ユーザーエンドのグラフィクス処理ユニットと関連するドライバープログラムに伝送し、該レンダリングコマンド、該パラメーター及び/或いは該テクスチャーに基づき、該グラフィックをレンダリングする。
本発明のアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法は、リモートエンドサーバーがディスプレイカードを搭載しなければならず、これによりハードウエアのコストが拡大し、さらにGPUはリモートエンドサーバー上の他のハードウエアパーツに比べ、作動時により多くのエネルギーを消費するため、電力消費或いは散熱の面でも大きな問題があるという公知技術に存在する欠点を解決できる。
従来のモバイルオペレーションシステムの模式図である。 従来のモバイルオペレーションシステムのレンダリングモジュールの模式図である。 従来のモバイルオペレーションシステムをレンダリングに用いるパーツの模式図である。 本発明のアプリケーションプログラムがバーチャルマシンとコミュニケーションをとり、ユーザーインターフェースを生じる一実施形態の模式図である。 図2Aのレンダリングコマンドの模式図である。 本発明のアプリケーションプログラムとバーチャルマシンのコミュニケーションシステムの模式図である。 本発明のアプリケーションプログラムとバーチャルマシンのコミュニケーションシステムの模式図である。 本発明のアプリケーションプログラムとバーチャルマシンのコミュニケーションシステムの別種の実施形態の模式図である。 本発明のアプリケーションプログラムとバーチャルマシンのコミュニケーションシステムの別種の実施形態の模式図である。 図3Aと図3Bのアプリケーションプログラムがバーチャルマシンにコミュニケーションする一実施形態の模式図である。 図3Aと図3Bのアプリケーションプログラムがバーチャルマシンにコミュニケーションする別種の実施形態の模式図である。 本発明のアプリケーションプログラムがバーチャルマシンにコミュニケーションする方法のフローチャートである。
図1Aは、Android(登録商標)オペレーションシステムのアーキテクチャーの模式図である。モバイルオペレーションシステム(モバイルオペレーションシステムは、Android(登録商標)、iOS(登録商標)、Windows(登録商標)等)を有し、スマート型デバイス上(スマートフォン等)で作動する。
該技術領域の習熟者は理解できるように、Android(登録商標)とは異なるランタイム(runtime)を備えるいくつかのモバイルオペレーションシステム(Android(登録商標)のランタイムは、Dalvikバーチャルマシン或いはコアライブラリーを含み、異なるオペレーションシステムは、他のライブラリー或いはバーチャルマシンを有する)以外は、他のモバイルオペレーションシステムも、図1Aの記述及び表示に類似の機能/構造を備える。
いくつかのモバイルオペレーションシステムは、異なるハードウエア設計に対して特殊化したハードウエア抽象化レイヤー(HAL)を含まないかも知れない。該項技術領域への習熟者は理解できるように、これらモバイルオペレーションシステムの間の差異は、本発明が主張する特許請求の範囲に影響しない。
従来は、アプリケーション層(図1Aでは「アプリケーションプログラム」)中のモバイルアプリケーションプログラム(ダウンロード、ネイティブ、Webバージョン或いは混合バージョンモバイルアプリケーションプログラムなど。以下では「App」と呼称)は、アプリケーションプログラムを使用し、インターフェース(API)を設計発展させて、スマート型デバイスのハードウエアリソースから、データを取得する。アプリケーションプログラムはインターフェースを設計発展させ、ユーザーのニーズ或いはインプットに基づき、ファイル或いはデータを産生し、ハードウエアデバイス(例えば、チップ、センサー或いはハードウエアモジュール)に送る。
本説明では、ハードウエアデータとは、ハードウエアリソースからの任意のデータ、或いはアプリケーションプログラムが設計発展させたインターフェースが産生しハードウエアリソースに送った任意のデータである。例えば、ユーザーは、スマート型デバイスのタッチスクリーン或いは他のインプット方式を通して、スマート型デバイスにおいて、Appをインストール/執行/ラン/操作(以下では操作と総称)する。いわゆる他のインプット方式とは、ドライバープログラムインヴォーク(invoke)を通して、対応するハードウエアデバイスの方式を言う。
Appを操作すると、スマートフォンのカメラモジュールは、カメラAppを使用する。つまり、ハードウエアデバイスをインヴォーグする実施形態である。ユーザーがシャッターボタンをタッチ或いは押すと、カメラAppは、スマート型デバイスのカメラモジュールにイメージを取得する(例えば、raw、jpg、jpeg、png或いは他のイメージフォーマット等のバイナリフォーマットイメージを産生する)よう指示する。しかも、イメージを、メモリ中(例えば、ランダム・アクセス・メモリ、フラッシュメモリ、キャッシュ、SDカード或いはクラウド等の他の保存空間)に保存する。
図1Bは、グラフィックをレンダリング時にハードウエアデバイス(例えば、表示デバイス或いはグラフィクス処理ユニット)をインヴォーグする別種の実施形態の模式図である。1個のAppがグラフィックのレンダリングを執行している時、アプリケーションプログラムの開発者が、どの種のAPI(或いはレンダリングAPI)を使用していようが、イメージは画素データのバッファーにレンダリングされる。
これを「レイヤー」と呼ぶ。
従来は、Appが他の内容をレンダリングすると、Android(登録商標)の1個のレイヤーは、1個のオフスクリーンバッファー(off-screen buffer)に対応する。
Android(登録商標)プラットフォームで作られたすべてのウィンドウは、1個のレイヤーにより復位(backed)される。
正確に言えば、各ウィンドウはすべて1個のレイヤーの表示結果(ウィンドウを形成するすべての画素は、レイヤー/バッファーの保存される)。
すべての可視のレイヤーは、レンダリングを経て、SurfaceFlingerを通して、ディスプレイ上に統合される。
SurfaceFlingerは、Android(登録商標)のレイヤー統合の管理に用いる一種のシステムサービス(或いはAndroid(登録商標)フレームに常駐する一種の全システムレイヤー統合機能)である。
SurfaceFlingerは、異なるAppからデータ(つまり、レイヤー)を取り出す。
これらデータは、2D或いは3Dである。
それは統合を経た後、主要レイヤーを取得し、メモリ(フレームメモリを含み、或いはフレームメモリを含むよう設定することができる)をフィードインする。
この他、SurfaceFlingerは、オーバーラップしたパラメーターなどを計算でき、OpenGL ESをインヴォークする。
1個のAppの観点から見ると、各Appは、少なくとも1個の図形化インターフェースに対応でき、しかも各インターフェースは、その位置、容量、内容及び他の要素を備える1個のレイヤーとして見られる。
Android(登録商標) 3.0の紹介を見ると、そのCanvas APIに対するハードウエア加速は、OpenGLRendererと呼ばれる新式ドローイングライブラリーを採用している。
該ドローイングライブラリーは、Canvasの操作を、OpenGLの操作に転換できるため、図形化処理ユニット(例えば、ハードウエアに加速されるCanvas)において執行される。
現在、OpenGL ES 2.0を支援する図形化処理ユニットハードウエアは、信託管理され、これによりAndroid(登録商標)デバイスはAndroid(登録商標) 4.0或いはそのアップグレードバージョンを執行することができる。
Android(登録商標)は、Android(登録商標).openglパッケージ中で、OpenGL ESインターフェースを提供する。
これにより、App開発者は、標準開発キット(SDK)或いはAndroid(登録商標)ネイティブ開発キット(NDK)が提供するネイティブAPIを利用し、これを開発者のGL実装中に呼び出すことができる。
図1Cに示す通り、グラフィックレンダリングに関わるパーツは、イメージストリームプロデューサー(image stream producer)、イメージストリームコンシューマー(image stream consumer)、サーフェイステクスチャー、ウィンドウマネージャー(windows manager)、ハードウエアコンポーザー(hardware composer)及びGrallocを有する。
イメージストリームプロデューサーは、可包含一OpenGL ESゲーム、メディアサーバーからのビデオバッファ、1個のCanvas2Dアプリケーションプログラム、或いは産生されたグラフィックを緩衝消費できる任意の他の物件を有する。
最もよく見られるイメージストリームのコンシューマーは、SurfaceFlingerで、それは可視レイヤーを消費し、ウィンドウマネージャーが提供する情報を使用し、可視レイヤーをディスプレイに統合する。
他のOpenGL ES Appも、イメージストリームを消費でき、例えば前記のカメラAppは、カメラプレビューイメージストリームの消費に用いられる。
サーフェイステクスチャーが含むロジックは、イメージストリームプロデューサーとイメージストリームコンシューマーをまとめ、しかも以下の三部分により構成される。
それは、サーフェイステクスチャーユーザーエンド(SurfaceTextureClient)、Iサーフェイステクスチャー(ISurfaceTexture)及びサーフェイステクスチャー(SurfaceTexture)である(本実施形態では、サーフェイステクスチャーは、C++の実際のカテゴリー名称で、すべてのアセンブリの名称ではない)。
上述の三部分は、イメージプロデューサー(サーフェイステクスチャーユーザーエンド等)、合成(binder)(Iサーフェイステクスチャー等)、及びイメージコンシューマー(サーフェイステクスチャー等)等のサーフェイステクスチャー構成部材の作動を助ける。
例えば、Gralloc(ハードウエア抽象化レイヤーの一部分)からメモリ空間、プログラムの境界を跨ぎメモリ空間をシェア、同期にバッファーにアクセス、及び適したコンシューマーとプロデューサーの組合せを提供するよう請求する。
サーフェイステクスチャーは、同期と非同期の二つのモードで同時に操作することができる。
非同期モード中では、イメージプロデューサーはブロッキングされず、しかもイメージコンシューマーはフレームを放棄或いは無視することができる。
同期モード中では、イメージプロデューサーは、ブロッキングされ、これによりイメージコンシューマーはテクスチャー処理を許される。
いくつかの例において、イメージプロデューサーは、カメラのハードウエア抽象化レイヤーを通して、産生されたプレビュー、或いは一種のOpenGL ESゲームである。
ウィンドウマネージャーは、Android(登録商標)システムサービスで、ウィンドウのライフサイクル、インプットとフォーカスイベント、スクリーンガイド方向、トランジション、動画、位置、転換、Z-オーダー、及びウィンドウの他の多くの方向(容器の角度により検視)をコントロールする。
1個のウィンドウは、いつも1個のレイヤーによりセットオフされ、ウィンドウマネージャーはすべてのウィンドウのメタデータ(metadata)をSurfaceFlingerに発送する。
SurfaceFlingerはこうして、それらデータを採用し、いかにしてレイヤーをディスプレイ上に統合するかを推測する。
ハードウエアシンセサイザーは、ディスプレイサブシステムに対してハードウエアアブストラクション(hardware abstraction)とする(それは、ハードウエア抽象化レイヤーの一部分)。
SurfaceFlingerは、オーバーラップと2Dブリッター(blitter)をアブストラクションでき、一部の統合作業を、ハードウエアシンセサイザーに委託し、OpenGLとグラフィクス処理ユニットからの作業をアンインストールする。
これは、SurfaceFlingerを使用し、すべてのミッションを執行するより、統合は迅速である。
この他、Grallocは、グラフィックバッファーにメモリを分配する。
それは以下の二部分に分けられる。
一つは、pmemインターフェースが連続を担当するメモリを提供する。
もう一つは、フレームバッファーのリフォームを処理する。
このフレームバッファーは、ユーザーインターフェースが実質的にフレーム緩衝データを置く位置である。
SurfaceFlingerは、新表示ハードウエアのクリエイト作業を執行し、ローカルウィンドウフレームバッファーを確立し、データアウトプットデバイスインターフェースを決定する。
初期化OpenGLは、合成フレーム緩衝データのようで、及びすべてのレイヤーを合併することで、主要レイヤーをクリエイトする。
バーチャルマシンは、モバイルAppを信託管理できるモバイルオペレーションシステム上において執行される。
一般的に、モバイルオペレーションシステムで作動されるバーチャルマシンは、図1A或いは図1Bのスマート型デバイスが、パーソナルコンピューター或いはサーバーにより作動されるバーチャルマシンに置換されない限り、図1A或いは図1Bに相同か、或いは近似したオペレーションシステムアーキテクチャーを有する。
よって、ハードウエアデータと関連するライブラリー或いはAPIは、モバイルオペレーションシステムが支援するリアルハードウエアに接続しない。
一実施形態中では、グラフィクス処理ユニット(図3Aと図3Bに示すハードウエアデバイス12或いはGPU12’参照)の使用を通して、第一計算デバイス100上のユーザーインターフェース218において、グラフィック226をレンダリングし、しかも相互に対応するグラフィック126を、ユーザーインターフェース118に表示し、これによりユーザーはリモートエンドにおいて第二App 2を操作する。
本実施形態では、第二計算デバイス200或いはバーチャルマシン212は、グラフィクス処理ユニットを備えず、或いはグラフィクス処理ユニットを備える(図2Cと図2Dに示すグラフィクス処理ユニット22)。
但し、バーチャルマシン212或いは第二App 2を執行するモバイルオペレーションシステムからのレンダリングコマンドは、該グラフィクス処理ユニットとは互換性がない。
例えば、第二App 2がAndroid(登録商標)アプリケーションプログラムで、しかもバーチャルマシン212が、Android(登録商標)バーチャルマシンとして実施されれば、第二App 2は、ライブラリー206を通して、OpenGL ESコマンド(例えば、レンダリングコマンド)をグラフィクス処理ユニットに賛成する。
例えば、EGL/GLインターフェース206g(本発明の実施形態において、EGL/GLインターフェース206gはハードウエア抽象化レイヤー208の一部分)或いはGLESライブラリー(図示なし)である。
しかし、第二計算デバイス200(或いはサーバー)のグラフィクス処理ユニットは、OpenGLコマンドだけを受け入れられ、OpenGL ESコマンドではないため、OpenGL ESは、ローカルエンドグラフィクス処理ユニットに、グラフィックのレンダリングを直接指示することはできない。
図2C或いは図2Dに示す通り、レンダラー28(バーチャルマシン212或いは第二計算デバイス200上で実施されるが、バーチャルマシン212外部に位置する)は、ライブラリー206からのOpenGL ESコマンド(該コマンドはEGL/GLインターフェース206g或いはlibGLES_FIISER.so 206iからで、受け取られ/ピックアップされ/取り戻される)を、レンダリングする。
これにより、OpenGLコマンドに変わり、ローカルエンドグラフィクス処理ユニット22は、OpenGL ESコマンドに基づき、3Dグラフィックをレンダリングする。
一実施形態において、グラフィクス処理ユニット22所レンダリングした3Dグラフィック可被保存在メモリ20中(部分メモリ20在本実施形態中可為フレームバッファー),しかもフレームバッファー中の3Dグラフィック可能接続地被TSRプログラム26所アクセス,並伝送至第一App 1,しかも以アプリケーションプログラムストリームの形式而表示在ユーザーインターフェース118上,或いは者是表示於第一App 1のスクリーン画面,図2Cに示したとおりである。
別種の実施形態において、レンダリングした3Dグラフィックは、2Dグラフィックと共に同じ位置に保存される。
例えば、モジュールのコア210においては、「/dev/graphics/fb0 210b」と呼ばれる。
本実施形態においては、図2Dに示す通り、TSRプログラム26は相同位置に保存され、2Dグラフィックと3Dグラフィックをユーザーエンドへと同時にストリームする。
図2Cと図2Dに示す実施形態では、アプリケーションプログラムストリーム(2D及び/或いは3Dグラフィックを含む)ユーザーエンドに伝送する時には、より広い帯域幅が必要である。
図2Bに示す通り、第二App 2のグラフィックをレンダリングする時、レンダリングコマンドは第一計算デバイス100に伝送され、第一App 1により、インターネットを通して受け取られる。
続いて、第一App 1は、レンダリングコマンドをローカルエンド(第一計算デバイス100)の図形処裡ユニット12’(或いはレンダリングコマンドを、ローカルエンド図形処裡ユニット12’と互換性のあるフォーマットに転換可能)に発送し、フレームバッファー10’(少なくともメモリ10の一部分)上で、該レンダリングコマンドのグラフィックにレンダリング対応する。
詳細な実施形態は、図3A、図3B、図3C或いは図3Dに示す後続の実施形態に示す通り、本実施形態において、グラフィックは、第一計算デバイス100に表示される。
一実施形態において、レンダリングコマンドは、レンダリングを待つグラフィックのメモリ(フレームバッファー)アドレス/エリア、値、カラーコード或いは物件の深度、或いはレンダリングする該グラフィックのエリア/位置/長さ/幅などのパラメーターと組み合わされる。
別種の実施形態において、グラフィックのレンダリングに用いるテクスチャーは、第一App 1に伝送される。
Android(登録商標)オペレーションシステムにおいて、レンダリングを指令されるグラフィック/フレームは、図2Bに示す部分をサンプルとすることができる。
そのうちの「glBindTexture」は、レンダリングコマンド(本実施形態中では、1個のOpenGL ESコマンド)で、しかも第21行の「0x00000de1」と「6」はパラメーターである。
この他、第二パラメーター「6」を、一種のテクスチャーのレンダリング指示に用いる時には、第一パラメーター「0x00000de1」は、「ターゲット」の指示に用いる。
この技術領域における習熟者なら分かるように、単一のグラフィック、物件或いはフレームをレンダリングする時、複数のレンダリングコマンドを処理しなければならないことがある(図2Bに示す通り、グラフィック/物件/フレームのレンダリングのみを執行可能)。
よって、本発明では、グラフィックのレンダリングについて、一個のレンダリングコマンドのみの使用に限定しな。
上述と図2B(及び/或いは図3A、図3B或いは図3C)関連の実施形態において、レンダリングコマンド及び/或いはパラメーター/テクスチャーだけが、ユーザーエンドに伝送されるため、第二App 2のユーザーインターフェース/スクリーン画面全体をユーザーエンドにレンダリングする時、必要な帯域幅は、図2C或いは図2Dに示す実施形態より少ない。
一実施形態において、レンダリングコマンドは、ハードウエア設定中に含まれ(図3A或いは図3Bに示すハードウエア設定モジュール214により産生される)、或いはそのものは伝送されて、第一App 1のハードウエア設定とされる。
ここにおいて、ハードウエア設定(或いはレンダリングコマンド)が受け入れられれば、第一App 1は、ハードウエア関連モジュール(図3Cに示すレンダリングモジュール17’)をディスパッチし、該ハードウエア設定(或いはレンダリングコマンド)に基づき、レンダリングミッションを執行する。
本実施形態では、第二App 2のスクリーン画面を、ユーザーインターフェース118/第一App 1のスクリーン画面に表示するため、複数のレンダリングコマンドの処理に用いるハードウエア関連モジュール(例えば、レンダリングモジュール17’)は、該各レンダリングコマンドに基づき、グラフィックをレンダリングする必要がある。
別種の実施形態において、レンダリングコマンドが、EGL/GLインターフェース206g(或いはlibGLES_FIISER.so 206i)に産生されると、ハードウエア設定モジュール214は、ハードウエア設定の産生に用いられ、該ハードウエア設定と該レンダリングコマンド(必要時にはパラメーター/テクスチャーをさらに含む)をTSRプログラム26に発送し、第一App 1に伝送する。
本実施形態では、該ハードウエア設定(及び/或いはパラメーター/テクスチャー)を受け取った後、第一App 1は、ハードウエア関連モジュール(レンダリングモジュール17’等)をディスパッチし、第一計算デバイス100の図形処理ユニット12’に接続させ、レンダリングコマンド(及び/或いはパラメーター/テクスチャー)を処理する。
第一App 1は、レンダリングコマンド(及び/或いはパラメーター/テクスチャー)を、そのローカルエンド図形処理ユニット12’へと発送し、グラフィック126(それは対応し、第二App 2のユーザーインターフェース218のグラフィック116に表示される)をレンダリングする。
本発明は、図形処理ユニット12’により、グラフィック126を表示し、フレーム緩衝においてレンダリングする必要はなく、或いはバーチャルマシン212において、ユーザーインターフェース218及びグラフィック226を表示し、或いは第二計算デバイス200に表示する。
ユーザーと第一計算デバイス100のスクリーン上のユーザーインターフェース118(例えば、タッチスマートフォンのスクリーン)がインタラクティブである時には、ユーザーが、スクリーン/ユーザーインターフェース118にタッチする座標は、第一App 1によりTSRプログラム26に伝送される。
一実施形態において、TSRプログラム26は、対応インプットイベントを、バーチャルマシン212に産生する。
別種の実施形態において、TSRプログラム26は、それが受け取った座標を、バーチャルマシン212に発送し、しかもバーチャルインプットアウトプットモジュール/インターフェース(図3A、図3B、図3A或いは図3Bに示すvr_io_int 210c等)は、対応インプットイベントを第二App 2に産生する。
一実施形態において、vr_io_int 210cは、伝送/受け取り/緩衝一般インプット/アウトプットまで/第二App 2からに用いることができる。
この他、一般インプット/アウトプットは、イメージ、音声或いは他のハードウエアデータを含む。
別種の実施形態において、vr_io_int 210cは、擬似ドライバー(pseudo driver)である。
続いて、第二App 2は、インプットイベントを受け取り、該インプットイベントに反応する(例えば、座標に基づき、シャッターボタン216が押されたとの通知を受け取り、バーチャルマシン212のカメラAPIを使用して撮影する)。
こうして、第一計算デバイス100の第一App 1を通した、バーチャルマシン212/サーバー上の第二App 2のリモートエンド操作を達成する。
ユーザーエンドにおけるグラフィックのレンダリング。
図3A或いは図3Bに示す通り、図中のシステムは、第一App 1とサーバー或いはバーチャルマシン212とを通信させ、ユーザーエンドのハードウエア設備(つまり、ハードウエアデバイス12或いは図形処理ユニット12’)を使用して、サーバー或いはバーチャルマシン212上の第二App 2のグラフィックをレンダリングする。
図3A(図1Bを合わせて参照)に示す通り、ネイティブAndroid(登録商標)オペレーションシステムが、第一計算デバイス100において作動すると、レンダリングドライバープログラム及び/或いはインターフェースは、以下の通り表示される。
ドライバープログラム111’及び/或いは「libGLES_GPUNAME.so」(「.so」のコマンドは、スマート型デバイスによって異なる)106iは、図形処理ユニット12’を駆動し、レンダリングコマンド(OpenGL ESコマンド等)に基づき、グラフィックをレンダリングし、Android(登録商標)オペレーションシステムラン上において、Appの使用を執行する(つまり、ローカルエンドグラフィクス処理ユニットを利用しレンダリングを行う)。
第二計算デバイス200にはグラフィクス処理ユニットがなく、第二計算デバイス200(或いはバーチャルマシン212)が産生したレンダリングコマンド(OpenGL ESコマンド等)を理解できないため、1個のlibGLES_FIISER.so 206iは、レンダリングドライバープログラムの性格を代わって担うことができる。
しかも、ローカルエンドグラフィクス処理ユニットが存在しない、或いはレンダリングと互換性がないため、libGLES_FIISER.so 206iは、TSRプログラム26の方向をガイドし、レンダリングコマンドを、第一App 1に伝送し(インターネット経由で)、レンダリングコマンドを、ローカルエンドグラフィクス処理ユニットに伝送するのではない。
図3Aに示す通り、レンダリングコマンド(OpenGL ESコマンド等)は、EGL/GLインターフェース206g或いはlibGLES_FIISER.so 206iにおいて、キャプチャー/インターセプト/リード/レシーブされる。
一実施形態においては、該レンダリングコマンドのパラメーター及び/或いはテクスチャーに対応し、EGL/GLインターフェース 206g或いはlibGLES_FIISER.so 206iにおいて、キャプチャー/インターセプト/リード/レシーブされる。
本発明が属する技術領域の習熟者なら分かるように、レンダリングコマンド或いはパラメーター/テクスチャーは、第二App 2、他の部分のライブラリー206(例えば、第二App 2がOpenGL API等を使用して、或いはグラフィック中の物件を描く、或いはコントロールする)或いは他の部分のコア210から、キャプチャー/インターセプト/リード/レシーブされ得る。
本発明の特許請求の範囲が主張するアーキテクチャーは、レンダリングコマンド及び/或いはパラメーター/テクスチャーがキャプチャー/インターセプト/リード/レシーブされる位置を限定しない。
レンダリングコマンド及び/或いはパラメーター/テクスチャーは、TSRプログラム26に発送され、しかもTSRプログラム26は、このコマンドを第一App 1に伝送する。
図3Bに示す通り、第一App 1とサーバー(第二計算デバイス200或いはバーチャルマシン212)の通信システムは、TSRプログラム26がバーチャルマシン212に設置できる他は図3Aに示す実施形態に近似する。
一実施形態において、TSRプログラム26は、ライブラリー206に配置される。
別種の実施形態において、TSRプログラム26は、コア210に配置される。
本発明が属する技術領域の習熟者なら分かるように、TSRプログラム26は、第二計算デバイス200中に配置され、或いは他のバーチャルマシン212に接続する計算デバイス(サーバー或いはクラウド等)は、レンダリングコマンドを受け取り、及び/或いはvr_io_int 210cと第一App 1とを通信させる。
レンダリングコマンド及び/或いはパラメーター/テクスチャーを受け取った後、第一App 1は、このコマンドを、EGL/GLインターフェース106g(及び/或いはlibGLES_GPUNAME.so 106i)に発送し、或いはドライバープログラム111’に発送する。
こうして、図形処理ユニット12’を利用し、グラフィックをレンダリングする。
本発明が属する技術領域の習熟者なら分かるように、Android(登録商標)システム以外のApp或いはモバイルオペレーションシステムには、EGL/GLインターフェース106gのようなインターフェースがない可能性がある。
だが、ユーザーエンドを駆動するグラフィクス処理ユニットのライブラリー或いはドライバープログラムが本発明を実現可能であるため、本発明は、EGL/GLインターフェース106gを通した、グラフィックのレンダリングに限定されない。
図3Cは、第一App 1と第二計算デバイス200或いはバーチャルマシン212の、本発明一実施形態に基づく通信アーキテクチャーを示す。
図3Cに示す通り、それは図3Cに近似し、第一App 1は、レシーバー13、ディスパッチャー15、トランスミッター19及び複数のハードウエア関連モジュール17を有する。
複数ハードウエア関連モジュール17のうちの一つは、レンダリングモジュール17’である。
レシーバー13は、インターネットを通して、レンダリングコマンド(OpenGL ESコマンド等)及び/或いはパラメーター/テクスチャーを受け取ることができる。
同原理で、ディスパッチャー15は、ハードウエア関連モジュール17のうちの一つ(本実施形態のレンダリングモジュール17’等)をディスパッチでき、受け取ったレンダリングコマンドに基づき、グラフィックをレンダリングする。
レンダリングモジュール17’は、TSRプログラム26からAPIを呼び出すレンダリングコマンドにおいてマップ(map)に用いることができる。
しかも、1個のマップのAPIを産生して呼び出し、レンダリングAPI(OpenGL ES 1.0/1.1 APIパッケージ、OpenGL ES 2.0 APIパッケージとOpenGL ES 3.0/3.1 APIパッケージ等)を使用して、グラフィックのレンダリングを行う。
言い換えれば、レンダリングモジュール17’は、レンダリングAPI及び複数のAPIの呼び出しに結合使用され、しかも任意のAPI呼び出しは、特定のレンダリングコマンド(TSRプログラム26から受け取る)と対応する。
本実施形態では、TSRプログラム26からのレンダリングコマンドは、新しいレンダリングコマンド(必要時にはパラメーター及び/或いはテクスチャーを組み合わせる)と相同或いは近似しており、レンダリングモジュール17’において、それが受け取るレンダリングコマンドに基づき、レンダリング呼び出し/APIを選択後、ユーザーエンドにおいて産生される。
ユーザーエンドにおいて産生されるレンダリングコマンドは、ドライバープログラム111’に伝送され(第一App 1がAndroid(登録商標) App、或いはモバイルオペレーションシステムがAndroid(登録商標)であれば、EGL/GLインターフェース106g及び/或いはlibGLES_GPUNAME.so 106i等を通すことができる)、ローカルエンドの図形処理ユニット12’等のハードウエアデバイスを駆動し、グラフィックをレンダリングする。
本実施形態では、TSRプログラム26からのレンダリングコマンドを一旦受け取ると、レンダリングモジュール17’は、これに基づき、ユーザーエンドのレンダリングAPIを選択し、レンダリングAPIを使用し、第一計算デバイス100の図形処理ユニット12’を通して、グラフィックをレンダリングする。
図3Dに示す通り、本発明の一実施形態において、第一App 1’は、第二計算デバイス200(サーバー)或いはバーチャルマシン212とコミュニケートする。
図3Dに示す通り、第一App 1’は、レシーバー13’を有し、TSRプログラム26からレンダリングコマンドを受け取る。
一実施形態において、第一App 1’或いはレシーバー13’は、ネイティブエンコードライブラリー(或いは複数のネイティブエンコードライブラリー)を含み、EGL/GLインターフェース106g或いはlibGLES_GPUNAME.so 106iのレンダリング方法/アプリケーションプログラムをディスパッチし、インターフェースを設計発展させて、グラフィックをレンダリングする。
本実施形態では、第一App 1’(或いはレシーバー13’)は、TSRプログラム26からのレンダリングコマンドを受け取った後、レンダリングコマンドを、(EGL/GL インターフェース106g或いはlibGLES_GPUNAME.so 106i等を通して)ドライバープログラム111’に伝送する。
しかも、該グラフィックは、図形処理ユニット12’により、このレンダリングコマンド基づき、レンダリングされる。
第一App 1’(レシーバー13’或いはネイティブエンコードライブラリー)は、ディスパッチャー(図3Dには図示なし)を有し、レンダリングコマンドに基づき、対応する部分EGL/GLインターフェース106gをディスパッチする。
ディスパッチャーのソースコードは、例えば以下の通りである。
…… (ここ及び以下の「……」は、一部のソースコードは無視しても良いという意味である)
bool init_gl2_dispatch()
{const char *libName = getenv("ANDROID(登録商標)_GLESv2_LIB");
if (!libName) libName = DEFAULT_GLES_V2_LIB;
//
// Load the GLES library
s_gles2_lib = osUtils::dynLibrary::open(libName);
if (!s_gles2_lib) return false;
//
// init the GLES dispatch table
s_gl2.initDispatchByName( gl2_dispatch_get_proc_func, NULL );
s_gl2_enabled = true;
return true;}
void *gl2_dispatch_get_proc_func(const char *name, void *userData)
{if (!s_gles2_lib) {return NULL;}
return (void *)s_gles2_lib->findSymbol(name);}
一実施形態において、ディスパッチに用いるソースコードテンプレートが対応する一部のEGL/GLインターフェース106gは、レンダリングコマンドに基づき、グラフィック(或いは一部のグラフィック)をレンダリングする。
例えば、“glBindTexture,”は以下の通りである。
……
size_t gl2_decoder_context_t::decode(void *buf, size_t len, IOStream *stream)

size_t pos = 0;
if (len < 8) return pos;
unsigned char *ptr = (unsigned char *)buf;
bool unknownOpcode = false;
……
break;
case OP_glBindTexture:

this->glBindTexture(*(GLenum *)(ptr + 8), *(GLuint *)(ptr + 8 + 4));
pos += *(int *)(ptr + 4);
ptr += *(int *)(ptr + 4);

……
この実施形態において、レンダリングコマンド(「glBindTexture」等)、ターゲットと関連するパラメーター(つまり、「*(GLenum *)(ptr + 8)」はターゲットがフレームバッファー或いはメモリ10中でアクセスされる位置に定位される)或いはテクスチャーと関連(つまり、「*(GLunit *)(ptr + 8 + 4),」はターゲットがフレームバッファー或いはメモリ10中でアクセスされる位置に定位される)はディスパッチされ、続いてEGL/GLインターフェース106gに伝送され、グラフィックをレンダリングする。
一実施形態において、ネイティブエンコードライブラリーは、Android(登録商標)ネイティブ開発キットを使用して、第一App 1’のアプリケーションプログラムパッケージファイル(.apk)において推進/執行される。
別種の実施形態において、ネイティブエンコードライブラリーは、別のアプリケーションプログラムパッケージファイル(以下ネイティブエンコードライブラリーapkと呼称)で推進/執行され、しかもネイティブエンコードライブラリーを含むアプリケーションプログラム(以下ネイティブエンコードライブラリーappと呼称)は、アプリケーションプログラムパッケージファイルにおいて、第一計算デバイス100をインストール後、第一計算デバイス100上に形成される。
本実施形態では、2個のアプリケーションプログラムパッケージを共に、第一計算デバイス100にインストールすると、第一App 1は、レンダリングコマンドを受け取り、ネイティブエンコードライブラリーappに伝送する(例えば、第一App 1とネイティブエンコードライブラリーappとの間のクロスプログラム通信或いは他の通信)。
続いて、ネイティブエンコードライブラリーappは、レンダリングコマンドを、EGL/GLインターフェース106gに伝送し、図形処理ユニット12’を利用してレンダリングを行う。
よって、本発明が属する技術領域の習熟者なら分かるように、ネイティブエンコードライブラリーは、第一App 1’のアプリケーションプログラムパッケージファイルにおける推進/執行に制限されない。
同じ原理で、タッチスクリーンイベントを一旦受け取ると、第一App 1(或いは1’)は、タッチスクリーンイベントの座標(或いはタッチスクリーンイベントを直接伝送)をTSRプログラム26に伝送する。
しかも、第二App 2は、バーチャルインプットアウトプットモジュール/インターフェース(vr_io_int 210c等)を通して、タッチスクリーンイベントに基づき、反応する。
一実施形態において、第一App 1(或いは1’)は、表示グラフィックを第一App 1(或いは1’)のスクリーン画面のイベントにおいてさらに有する。
一実施形態において、レンダリングしたグラフィックの画素は、フレームバッファー10’(或いはメモリ10)に保存される。
一実施形態において、第二App 2が、サーバー或いはバーチャルマシン212上のレンダリングAPIに使用され、グラフィックをレンダリングする時には、少なくとも1個のレンダリングコマンド、パラメーター及び/或いはテクスチャーをリード/キャプチャーできる。
この他、トランスミッター19は、TSRプログラム26からのインプットイベント(タッチスクリーンイベント等)の座標を伝送でき、第一App 1は受け取る。
この他、本発明が属する技術領域の習熟者なら分かるように、第二計算デバイス200或いはサーバーは、モバイルオペレーションシステムを作動させる(例えば、Android(登録商標)オペレーションシステム)計算デバイスを執行できる。
本実施形態では、上述のモバイルオペレーションシステムのドライバープログラム或いはライブラリーは、第二計算デバイス200中で作動させられるため、バーチャルマシン212は必須ではなくなる。
図4は、本発明の別種の実施形態における、第一App 1とサーバー或いはバーチャルマシン212との通信の方法を示す。
本実施形態では、該方法は、ユーザーエンドの第一App 1’を利用し、第二App 2のグラフィックをレンダリングし、該第二App 2は、サーバー或いはバーチャルマシン212において執行される。
図5Cに示す通り、ステップ628中では、レシーバー13’は、少なくとも1個のレンダリングコマンド(OpenGL ESコマンド等)、対応パラメーター(RGB数ュネ/カラーコード、深度等)及び/或いはサーバー(第二計算デバイス200、バーチャルマシン212或いはTSRプログラム26等)のテクスチャーを受け取る。
ステップ630中では、レシーバー13’は、レンダリングコマンド、パラメーター及び/或いはテクスチャーを、ユーザーエンドのドライバープログラム111’に伝送し、図形処理ユニット12’を利用して、グラフィックをレンダリングする。
一実施形態において、レンダリングコマンド、パラメーター及び/或いはテクスチャーインターセプトは、バーチャルマシン212よりインターネットを通して第一App 1’に伝送される。
別種の実施形態においては、レンダリングコマンドをライブラリー206i或いは擬似ドライバー(図示はないが、ライブラリー206iに接続)に伝送する前に、レンダリングコマンド及び/或いはパラメーターをブロッキングすることができる。
さらに一実施形態において、バーチャルマシン212外において、レンダリングコマンド及び/或いはパラメーターをブロッキングできるが、これはサーバー内でブロッキングを行う。
例えば、もしサーバーが、グラフィクス処理ユニットを有するなら、レンダリングコマンド及び/或いはパラメーターを、グラフィクス処理ユニットに発送する前に、レンダリングコマンド及び/或いはパラメーターをインターセプトすることができる。
一実施形態において、第一App 1’は、レンダリングモジュール17’をさらに有する。
レンダリングモジュール17’は、一機能或いは一レンダリング方法である。
レンダリングモジュール17’は、C或いはC++によりコーディングされるネイティブエンコードライブラリーで、.soファイルにコンパイルされ、第一App 1’のアプリケーションプログラムパッケージファイル中に封入され、レシーバー13’が受け取ったレンダリングコマンドに基づき、一部のレンダリングインターフェース(EGL/GLインターフェース106g等)をディスパッチし、図形処理ユニット12’を駆動して、グラフィックをレンダリングする。
本実施形態において、レンダリングモジュール17’は、複数のハードウエア関連モジュール17のうちの一つである。
別種の実施形態において、第一App 1’は、複数のハードウエア関連モジュール17とディスパッチャー15をさらに有し、レンダリングコマンドを受け取った時には、ディスパッチャー15は複数のハードウエア関連モジュール17中から、レンダリングモジュール17’をディスパッチすることができる。
一実施形態において、レンダリングモジュール17’は、ユーザーエンドのレンダリングAPI(如 OpenGL ES API)に使用され、レンダリングコマンドに基づきグラフィックをレンダリングする。
レンダリングコマンド及び/或いはパラメーター/テクスチャーは、ドライバープログラム111’へと伝送され、しかもドライバープログラム111’は、図形処理ユニット12’を駆動し、これに基づき、コマンドグラフィックをレンダリングする。
一実施形態において、該グラフィックは先ずフレームバッファー10’に保存され、次に表示デバイスに表示される(第一計算デバイス100と表示するが、集積回路或いは一般回路とでき、第一計算デバイス100のスクリーンをコントロールする)。
本実施形態では、該方法は、表示ユーザーエンドのスクリーン画面のステップをさらに含み、該スクリーン画面は、レンダリングしたグラフィックを含む。
別種の実施形態では、レンダリングコマンド或いはパラメーターに関連するテクスチャーは、サーバーから発送され、しかもレシーバー13’は、該サーバーからのこのテクスチャーを受け取ることができる。
本実施形態において、レンダリングをディスパッチする方法は、ユーザーエンドのレンダリングAPIを使用でき、レンダリングコマンドに少なくとも1個の対応パラメーターとテクスチャーを組み合わせて、グラフィックをレンダリングする。
一実施形態において、第二App 2において、バーチャルマシン212のレンダリングAPI(例えば、EGL/GLインターフェース206gを通して)の使用を試し、グラフィックをレンダリングする時、少なくとも1個のレンダリングコマンドと対応パラメーターを取り戻す。
別種の実施形態において、レンダリングコマンド及び相互に対応するパラメーターの他に、テクスチャーは、第二App 2において、レンダリングAPI使用時に取り戻される。
一実施形態において、バーチャルマシン212は、TSRプログラム26に接続される。
本実施形態において、ユーザーインターフェース118或いは第一App 1のスクリーン画面(其可能包含グラフィックをレンダリングする)の一点がユーザーによりタッチされると、対応するタッチ点の座標は、TSRプログラム26に伝送される。
続いて、座標に関連するインプットイベントは産生され、第二App 2にインプットされる。
本発明実施形態を説明する過程において、本説明書は本発明の方法及び/或いは過程ステップの特定の順序を記載した。
しかし、該方法或いは過程は、本文が述べるステップの特定順序に依頼するものではなく、該方法或いは過程は、ステップ記載の特定順序に制限されない。
本技術領域において通常の知識を持つ者なら理解できるように、ステップは他の順序により行うこともできる。
よって、本説明書が記載するステップ特定順序は、特許請求の範囲を制限するものではない。
さらに、本発明の特許請求の範囲において記載する方法とステップは、その記載の順序により本発明の実現を制限するものではなく、しかも本技術領域において通常の知識を持つ者なら理解できるように、順序の均等変化と修飾は、本発明の特許請求の範囲内に含まれる。
前述した本発明の実施形態は本発明を限定するものではなく、よって、本発明により保護される範囲は後述される特許請求の範囲を基準とする。
1 第一アプリケーションプログラム
2 第二アプリケーションプログラム
10 メモリ
10’ フレームバッファー
11 表示デバイス
12 ハードウエアデバイス
12’ 図形処理ユニット
13 レシーバー
15 ディスパッチャー
17 ハードウエア関連モジュール
17’ レンダリングモジュール
19 トランスミッター
20 メモリ
22 グラフィクス処理ユニット
26 TSRプログラム
28 レンダラー
100 第一計算デバイス
102 アプリケーションプログラム層
104 アプリケーションプログラムフレーム
106 ライブラリー
108 ハードウエア抽象化レイヤー
110 コア
111、111’ ドライバープログラム
116 ボタン
118 ユーザーインターフェース
126 グラフィック
200 第二計算デバイス
202 アプリケーションプログラム層
204 アプリケーションプログラムフレーム
206 ライブラリー
208 ハードウエア抽象化レイヤー
210 コア
210c vr_io_int
212 バーチャルマシン
214 ハードウエア設定モジュール
216 ボタン
218 ユーザーインターフェース
226 グラフィック

Claims (11)

  1. アプリケーションプログラムグラフィックのレンダリング方法において、アプリケーションプログラムは、サーバーにおいて執行され、ユーザーエンドにより、前記アプリケーションプログラムのグラフィックを表示し、
    前記方法のステップは、以下を含み、
    前記サーバーからのレンダリングコマンド、パラメーター及び/或いはテクスチャーを受け取り、
    前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーを、前記ユーザーエンドのドライバープログラムに伝送し、前記ユーザーエンドのグラフィクス処理ユニット(GPU)により、前記グラフィックをレンダリングすることを特徴とするアプリケーションプログラムグラフィックのレンダリング方法。
  2. 前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーを、前記ユーザーエンドの前記ドライバープログラムに伝送るステップは、以下をさらに含み、
    前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーに基づき、レンダリングアプリケーションプログラムを使用し、インターフェース(API)を設計発展させ、前記グラフィックをレンダリングすることを特徴とする請求項1に記載のアプリケーションプログラムグラフィックのレンダリング方法。
  3. 前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーは、前記アプリケーションプログラムにおいて、前記サーバー上でレンダリングアプリケーションプログラムを使用し、インターフェースを設計発展して、前記グラフィックをレンダリングする時、キャプチャーされることを特徴とする請求項1に記載のアプリケーションプログラムグラフィックのレンダリング方法。
  4. 前記ステップは、以下をさらに含み、
    座標を前記サーバーに伝送し、
    前記座標と関連するインプットイベントは産生され、前記アプリケーションプログラムにインプットされることを特徴とする請求項1に記載のアプリケーションプログラムグラフィックのレンダリング方法。
  5. 前記ステップは、以下をさらに含み、
    前記ユーザーエンド上で、前記アプリケーションプログラムのスクリーン画面を表示し、
    前記スクリーン画面は、前記表示グラフィックを含むことを特徴とする請求項1に記載のアプリケーションプログラムグラフィックのレンダリング方法。
  6. 第一アプリケーションプログラム,其は、ユーザーエンドにおいて執行され、第二アプリケーションプログラムのグラフィックをレンダリングし、前記第二アプリケーションプログラムは、サーバー上で執行され、
    前記第一アプリケーションプログラムは、レシーバーを含み、
    前記レシーバーは、前記サーバーのレンダリングコマンド、パラメーター及び/或いはテクスチャーを受け取り、前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーを、ドライバープログラムに伝送し、前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーに基づき、前記グラフィックをレンダリングし、前記ドライバープログラムは、前記ユーザーエンドのグラフィクス処理ユニットに関連することを特徴とする第一アプリケーションプログラム。
  7. 前記レシーバーは、ネイティブエンコードライブラリーを含み、前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーを前記ドライバープログラムに伝送することを特徴とする請求項6に記載の第一アプリケーションプログラム。
  8. 前記第一アプリケーションプログラムは、さらに以下を含み、
    レンダリングモジュールは、前記ユーザーエンドのレンダリングアプリケーションプログラムを使用し、インターフェースを設計発展させ、前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーに基づき、前記グラフィックをレンダリングすることを特徴とする請求項6に記載の第一アプリケーションプログラム。
  9. 前記第一アプリケーションプログラムはさらに、前記レンダリングモジュールを含む複数のハードウエア関連モジュール、ディスパッチャーをさらに含み、
    前記ディスパッチャーは、前記レンダリングコマンド、前記パラメーター及び/或いはテクスチャーに基づき、前記レンダリングモジュールをディスパッチし、前記グラフィックをレンダリングすることを特徴とする請求項8に記載の第一アプリケーションプログラム。
  10. 前記レンダリングコマンド、前記パラメーター及び/或いは前記テクスチャーは、前記サーバー上で、レンダリングアプリケーションプログラムを使用し、インターフェースを設計発展させ、前記グラフィックをレンダリングする時キャプチャーされることを特徴とする請求項6に記載の第一アプリケーションプログラム。
  11. 前記第一アプリケーションプログラムはさらに、トランスミッターを含み、
    前記トランスミッターは、座標を前記サーバーに伝送し、
    前記座標と関連するインプットイベントは産生され、前記第二アプリケーションプログラムにインプットされることを特徴とする請求項6に記載の第一アプリケーションプログラム。
JP2016093158A 2015-05-08 2016-05-06 アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 Pending JP2016212874A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/707,008 US20160044139A1 (en) 2014-08-07 2015-05-08 Methods and systems for communications between apps and virtual machines
US14/707,008 2015-05-08

Publications (1)

Publication Number Publication Date
JP2016212874A true JP2016212874A (ja) 2016-12-15

Family

ID=57569852

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016093158A Pending JP2016212874A (ja) 2015-05-08 2016-05-06 アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法

Country Status (1)

Country Link
JP (1) JP2016212874A (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020504890A (ja) * 2016-12-27 2020-02-13 深▲せん▼前海達闥雲端智能科技有限公司Cloudminds (Shenzhen) Robotics Systems Co., Ltd. マルチオペレーティングシステム用の表示方法、装置及び電子設備
CN110825467A (zh) * 2018-08-09 2020-02-21 北京微播视界科技有限公司 渲染方法、装置、硬件装置和计算机可读存储介质
JP2020507146A (ja) * 2016-12-27 2020-03-05 深▲せん▼前海達闥雲端智能科技有限公司Cloudminds (Shenzhen) Robotics Systems Co., Ltd. 映像表示方法、装置、電子機器及びコンピュータプログラム製品
CN113254228A (zh) * 2021-03-26 2021-08-13 西安神鸟软件科技有限公司 一种图像或视频数据分发方法及终端设备
CN113313804A (zh) * 2021-06-23 2021-08-27 深圳Tcl新技术有限公司 一种图像渲染方法、装置、电子设备和存储介质
CN114756334A (zh) * 2022-06-14 2022-07-15 海马云(天津)信息技术有限公司 服务器与基于服务器的图形渲染方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014067311A (ja) * 2012-09-26 2014-04-17 Fujitsu Ltd システム、端末装置および画像取得方法
JP2014203121A (ja) * 2013-04-01 2014-10-27 株式会社ソニー・コンピュータエンタテインメント 描画処理装置、描画処理システム、および描画処理方法
WO2015038429A1 (en) * 2013-09-10 2015-03-19 Qualcomm Incorporated Fault-tolerant preemption mechanism at arbitrary control points for graphics processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014067311A (ja) * 2012-09-26 2014-04-17 Fujitsu Ltd システム、端末装置および画像取得方法
JP2014203121A (ja) * 2013-04-01 2014-10-27 株式会社ソニー・コンピュータエンタテインメント 描画処理装置、描画処理システム、および描画処理方法
WO2015038429A1 (en) * 2013-09-10 2015-03-19 Qualcomm Incorporated Fault-tolerant preemption mechanism at arbitrary control points for graphics processing

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020504890A (ja) * 2016-12-27 2020-02-13 深▲せん▼前海達闥雲端智能科技有限公司Cloudminds (Shenzhen) Robotics Systems Co., Ltd. マルチオペレーティングシステム用の表示方法、装置及び電子設備
JP2020507146A (ja) * 2016-12-27 2020-03-05 深▲せん▼前海達闥雲端智能科技有限公司Cloudminds (Shenzhen) Robotics Systems Co., Ltd. 映像表示方法、装置、電子機器及びコンピュータプログラム製品
JP7058658B2 (ja) 2016-12-27 2022-04-22 深▲せん▼前海達闥雲端智能科技有限公司 映像表示方法、装置、電子機器及びコンピュータプログラム製品
CN110825467A (zh) * 2018-08-09 2020-02-21 北京微播视界科技有限公司 渲染方法、装置、硬件装置和计算机可读存储介质
CN110825467B (zh) * 2018-08-09 2023-10-24 北京微播视界科技有限公司 渲染方法、装置、硬件装置和计算机可读存储介质
CN113254228A (zh) * 2021-03-26 2021-08-13 西安神鸟软件科技有限公司 一种图像或视频数据分发方法及终端设备
CN113313804A (zh) * 2021-06-23 2021-08-27 深圳Tcl新技术有限公司 一种图像渲染方法、装置、电子设备和存储介质
CN113313804B (zh) * 2021-06-23 2024-03-12 深圳Tcl新技术有限公司 一种图像渲染方法、装置、电子设备和存储介质
CN114756334A (zh) * 2022-06-14 2022-07-15 海马云(天津)信息技术有限公司 服务器与基于服务器的图形渲染方法

Similar Documents

Publication Publication Date Title
JP2016212874A (ja) アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法
US10096083B2 (en) Media content rendering method, user equipment, and system
WO2018050003A1 (zh) 3D canvas网页元素的渲染方法、装置及电子设备
EP3111318B1 (en) Cross-platform rendering engine
TW201706834A (zh) 應用程式與虛擬機器通訊連接的系統與方法
US8629878B2 (en) Extension to a hypervisor that utilizes graphics hardware on a host
EP3138006B1 (en) System and method for unified application programming interface and model
CN107743636B (zh) 用于高效实时渲染预先不知道的图形的图形引擎和环境
US20220398059A1 (en) Multi-window display method, electronic device, and system
EP2756481B1 (en) System and method for layering using tile-based renderers
CN101896940A (zh) 用于硬件资源的动态配置的框架
AU2008311755A1 (en) Methods and systems for remoting three dimensional graphical data
JP2014135013A (ja) 画像転送方法、サーバ機器及びプログラム
CN104704468A (zh) Web应用程序的跨系统安装
US9542715B2 (en) Memory space mapping techniques for server based graphics processing
CN106714920B (zh) 对媒体内容的智能流传输
US20190080017A1 (en) Method, system, and device that invokes a web engine
US20170358055A1 (en) Texture not backed by real mapping
EP2924563A1 (en) Methods and systems for communications between apps and virtual machines
US20140156736A1 (en) Apparatus and method for managing threads to perform divided execution of software
CN114924837A (zh) 数据处理方法、电子设备和可读存储介质
CN114090010A (zh) X11系统的移植方法、装置、电子设备及可读存储介质
US10678553B2 (en) Pro-active GPU hardware bootup
CN116982069A (zh) 用于灵活图形增强和执行的方法和系统
CN111813404B (zh) 基于混合图形显示的应用方法、介质及客户端

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170424

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170509

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20171128