ゲーム画面の1フレームは、CPU と GPU の間をリレーのように渡り歩いて作られます。「いま見えている絵」は、実はゲームロジックが計算している最新フレームより数フレーム前のものです。なぜそうなるのか、CPU の Game Thread から GPU までの流れを、図と動きで追っていきましょう。
どんなゲームも、毎フレーム同じ4つの仕事を高速で繰り返しています。入力を読み、世界を1コマ進め、その状態を絵にし、画面に出す。この繰り返しを ゲームループ（game loop）と呼びます。60fps なら、この一周を 約16.6ミリ秒で回し続けているわけです。
素朴には「順番に4つやって1周」。でも実際のUEはこれを1本の直列処理では回していません — ここからが本題です。
もし1フレームを「Update が終わってから Render、終わってから GPU」と直列でやると、その間ほかの部品は遊んでしまいます。そこで UE は工場のライン（pipeline）のようにずらして並行させます。Game Thread が今のフレームを計算している間に、Render Thread は1つ前のフレームを、GPU はさらに前のフレームを処理している ── これが「表示が数フレーム遅れる」正体です。
1フレーム完成までフル4コマ。その間ほかの部品は遊んでいる → スループットが上がらない。
段が埋まれば 毎コマ1フレームずつ完成（スループット約4倍）。ただし最初の1枚が出るまで数コマ待つ ── この待ち分が「フレーム遅延」の正体です。
NOWの縦線を各段が下りていくのが1フレームの旅。同じ瞬間でも、下の段ほど「古いフレーム」を扱っています。（この図は分かりやすさ優先で1段=1フレーム遅延。実機のUEはRender/GPUが重なり、体感遅延はおよそ2フレームです）
4つは一方向のバトンリレーで動きます。前の段が作った成果物を、次の段が受け取って別の形に変換していく流れです。
矢印の上が「次の段へ渡す成果物」。前段の出力が次段の入力になり、少しずつGPUが分かる形へ翻訳されていきます。
下のカードをクリックすると、各担当の詳しい説明が開きます。
3つの段が並行して走るので、フレームにかかる時間は3つの合計ではなく最大値で決まります。スライダーで各段の処理時間を変えて、どこがボトルネックになるか確かめてみてください。「GPUバウンド」「ゲームスレッドバウンド」という言葉はこれを指します。
「今の画面を保存したい」— これは思ったより一手間かかります。絵は GPU 側のメモリ（Render Target）にあり、CPU から直接は読めません。GPU に「CPUが読める場所へコピーして」と頼み、それが終わるのをフェンス（fence）で待ってから読み出します。ステップをクリックすると詳細が開きます。
CPU は VRAM を直接読めません。だから「コピーして・待って・読む」の3手間になります。下の5ステップはこの地図を時間順に並べたものです。
要点：読み取れるのは GPU が今出した絵 ＝ ゲームスレッドより数フレーム前の状態。ReadPixels のように「今すぐ待って読む」とパイプラインが止まり (flush)、カクつきの原因になります。UE の高解像度スクリーンショットや SceneCaptureComponent2D は、この流れを裏でやっています。