間違っている場合は修正してください。私の理解では、Mac OS X には、すべてのアプリケーションのウィンドウを合成し、最終的な合成イメージを画面に描画する WindowServer プロセスがあります。問題は、WindowServer プロセスが他のアプリケーションの "Windows データ" (ビットマップなどの形式) をどこで取得するかです。アプリケーションと WindowServer プロセス間の共有メモリ メカニズムを介して実装されていますか? これに関する情報やポインタ/ドキュメントは役に立ちます!
また、iOSはこの点に関して同様に実装されていますか?
ありがとう！
ウィンドウのビットマップが WindowServer プロセスにマーシャリングされるメカニズムは、文書化されていない実装の詳細であり、事実上「不透明」であるため、現在どのように機能するかを理解しようとしても、リリースごとに変わる可能性があります。それは言った...
それがどのように機能するかを推測する必要がある場合、各ウィンドウを支援する共有メモリのブロックがあり、ウィンドウがビュー階層を描画するときに、[NSGraphicsContext currentContext]支援される CGContext を指すように設定されていると思います。その共有メモリのブロックによって。ウィンドウ描画シーケンスが終了すると、1 つ以上のマッハ メッセージがプロセスから WindowServer プロセスに送信され、描画されたばかりのフレームを表示する時間になったことを伝えると思います。
iOS では、Springboard プロセスがウィンドウ サーバーの役割を果たしているようで、同様に機能すると思いますが、これらの詳細はすべて文書化されていない実装の詳細であるため、不透明です。CoreGraphics は OSX と iOS の両方に存在するため、メカニズムが似ているのは当然です。
vmmapデバッガー (または dtrace)を使用すると、この仮説の証拠を見つけることができます。mmapたとえば、仮想メモリ領域をプロセス ( 、など)にマップできるさまざまな関数すべてにブレークポイント (または dtrace プローブ) を設定し、新しいウィンドウを開く操作全体vm_allocateで出力の前後比較を行うことができます。 vmmap. プロセスにマップされた新しい VM リージョンがあることがわかりますが、ブレークポイント/dtrace プローブに対応するヒットは見られません (つまり、プロセスには何もありません)。これらの地域をマッピングしました)。これは、ウィンドウ サーバー プロセスが共有メモリの領域をプロセスにマップした証拠です。これらのリージョンに関するメタ情報は、マッハ メッセージを使用してプロセスに伝達されます (ほとんどの場合)。簡単なサンプル アプリケーションでこれを試し、新しいウィンドウを開いてvmmap出力の違いを確認すると、この領域が最近作成したウィンドウのバッキング ストアである可能性が非常に高いことがわかります。
CG backing stores 00000001c73f2000-00000001c74cc000 [ 872K] rw-/rw- SM=SHM