1

グラフィックスコンテキストという用語は、少し抽象的である場合があります。それらは実際にはシステムリソースですか、ファイルハンドルがハードドライブまたは任意の永続ストレージデバイスからのシステムリソースであるのと同じように、グラフィックカードからのリソースですか？

ファイルハンドルに読み取り専用か読み取り/書き込み用か、および次の読み取り操作の現在の位置に関するいくつかの状態があるのと同じように、グラフィックスコンテキストには、現在のストロークの色、ストローク幅、または関連データ。（更新：書き込みモードでは、グラフィックスコンテキストのキャンバスがあり、その上に物を描画するのと同じように、200MBのファイル内の任意の場所に移動してデータを変更できます）

したがって、グラフィックスコンテキストは、実際にはグローバルなシステム全体のリソースです。ファイルまたはファイルハンドルが（必然的に）アプリケーションシングルトンの一部ではないのと同じように、これらはアプリケーションシングルトンなどの一部ではありません。

また、強力なグラフィックカードがない場合（またはグラフィックカードのリソースがすでに不足している場合）、オペレーティングシステムは、グラフィックカードに処理させる代わりに、ビットマップを使用した低レベルのグラフィックルーチンを使用してグラフィックコンテキストをシミュレートできます。

これは、iOSやその他の一般的なOS全般で、グラフィックスコンテキストが実際にどのように機能するかを示していますか？

4

2 に答える 2

3

グラフィックス コンテキストを特定のシステム リソースの観点から考えない方がよいと思います。私の知る限り、グラフィックス コンテキストは、もちろんメモリを除いて、クラスの「オブジェクト」よりも特定のリソースに対応していません。実際、グラフィックス コンテキストは、コア グラフィックス関数が動作するための「キャンバス」を提供するように設計されています。実のところ、グラフィック コンテキストが内部でどのように機能するかについて、Apple は具体的な詳細を提供していません。しかし、それについてわかっていることがいくつかあります。

  1. グラフィックス コンテキストは、基本的に何よりも「状態」です。特定の一連の描画ルーチンについて、ストローク/塗りつぶしの色、線幅などの情報を保持します。

  2. GPU では処理されません。代わりに、CPU で処理 (すべての描画を行います) し、結果の画像 (ビットマップの何らかの形式) を表示/アニメーションのために GPU に「渡します」(実際には、画像を GPU のバッファに直接レンダリングします)。これが、新しい iPad 3 で「renderInContext」メソッドがうまく機能しない理由 です。renderInContext最初にイメージが提供されます。これには、イメージのレンダリングとコピーが含まれます。それを表示したい場合は、それを Core Graphics に渡す必要があります。Core Graphics は画像を書き戻します。iPad 3 では、これは (ビューのサイズに応じて) 大量のメモリを必要とし、バッファを簡単にオーバーフローさせる可能性があります。

  3. UIView の 'drawRect' メソッドに与えられるグラフィック コンテキストは、可能な限り効率的なコンテキストを提供するように設計されています。これが、コンテキスト外のビューに何も描画できない理由であり、ビューが描画する独自のコンテキストを作成することもできません。実際の描画は実行ループで処理されます。これが、このメソッドを使用してフラグを立てる理由です描画する必要がある UIView: [view setNeedsDisplay].

  4. UIView のグラフィック コンテキストはメイン スレッドで描画され、やはり CPU で処理されます。これは、過度に複雑な図面がメイン アプリケーションを拘束する可能性があることを意味しますが、マルチコア プロセッサを使用する現在ではそれほど問題にはなりません。

  5. グラフィックス コンテキストを作成できますが、画像に描画するためだけに作成できます。これは、画面に描画したりアニメーション化したりするのではなく、ユーザーが使用することを意図していることを除いて、UIView コンテキストが行うこととまったく同じです。iOS 4 以降、これらのイメージ コンテキストを他のスレッド (メイン スレッド以外) で処理できます。

    GPU 描画を行う場合、これを行う唯一の方法は、iOS を使用している場合は OpenGL を使用することだと思います。MacOS を使用している場合は、QuartzGL を使用して GPU で実際に Quartz (コア グラフィックス...同じこと) の描画を有効にできると思います。しかし、努力する価値はないかもしれません。次の記事を参照してください: Mac QuartzGL (グラフィック カード上の 2D 描画) のパフォーマンス

アップデート

以下のコメントでわかるように、特にビューが GPU バッファーに直接描画されるため、Apple が Quartz 描画に対して持っている現在の配置がおそらく最適です。視覚的な処理はすべて GPU で行うべきだと考えがちですが、実際には、GPU はベクター描画用に設計されていません。これらは、大規模な変換、ライティング、テクスチャ マッピングなどを処理するように設計されています。CPU を使用してベクター描画を処理し、それ以外はすべて GPU に任せることで、Apple はグラフィックス処理を適切に分割しました。さらに、Quartz は GPU のバッファーに直接描画するため (面倒な memcpy を回避します)、CPU と GPU 間のデータ転送の効率を失うことはありません。

于 2012-05-27T18:29:01.667 に答える
1

グラフィックス コンテキストという用語は、少し抽象的である場合があります。

はい、意図的にそうします。Quartz は、汎用の描画システムである抽象化を目的としています。内部的にグラフィックハードウェアでいくつかの最適化を実行する場合と実行しない場合がありますが、それをあまり可視化することはできません. また、それが行う最適化の種類は、時間の経過とともに、またさまざまな種類のグラフィックス ハードウェアによって変化する可能性があります。

それらは実際にはシステムリソースですか、しかしそれらはグラフィックカードからのリソースです

いいえ、絶対に違います。Quartz はソフトウェア レンダラーです。グラフィック ハードウェアが存在しない場合でも機能し、グラフィック ハードウェアが役に立たない PDF などに描画できます。

内部的には、Quartz (および OS の残りの部分とのそのインターフェイス) には、状況によっては GPU を利用するいくつかの「高速パス」がある場合があります。しかし、それは決して一般的なケースではありません。

ファイル ハンドルが読み取り専用か読み取り/書き込みか、および次の読み取り操作の現在の位置に関するいくつかの状態をファイル ハンドルが持つのと同様に、グラフィックス コンテキストは現在のストロークの色、ストロークの幅、または関連データ。

正解です。

したがって、グラフィックス コンテキストは実際にはグローバルでシステム全体のリソースです。

いいえ。Quartz は、アプリ内でコードを実行する単なるライブラリです。新しい CGContext を作成すると、アプリだけが影響を受けます。これは、コードが独自のクラスの 1 つの新しいインスタンスを作成した場合とまったく同じです。

また、強力なグラフィックス カードがない場合 (またはグラフィックス カードのリソースが既に不足している場合)、オペレーティング システムは、グラフィックス カードに処理させる代わりに、ビットマップを使用した低レベルのグラフィックス ルーチンを使用してグラフィックス コンテキストをシミュレートできます。

2 つのケースが反転しています。一般に、Quartz はビットマップを使用してソフトウェアで動作します。いくつかのケースでは、GPU を使用して、すべてが正確に整列されていれば、画面上でこれらのビットマップをより高速に取得できます。

于 2012-05-27T18:30:38.377 に答える