QQuickWindow::GraphicsStateInfo Struct
struct QQuickWindow::GraphicsStateInfobeginExternalCommands() が呼び出された時点における、RHIのグラフィック状態の一部について説明します。詳細...
パブリック変数
| int | currentFrameSlot |
| int | framesInFlight |
メンバ変数のドキュメント
int GraphicsStateInfo::currentFrameSlot
この変数は、フレームの記録中に現在のフレームスロットインデックスを保持します。
シーングラフが Vulkan や Metal などの低レベル 3D API を使用してレンダリングを行う場合、新しいフレームを開始する際に、CPU が GPU よりすでに一定数のフレーム分先行していることが判明したときは(フレーム番号current -FramesInFlight で送信されたコマンドバッファがまだ完了していないため)、ブロック処理を確実に行うのは Qt の責任となります。 OpenGLやDirect 3D 11などの他のグラフィックスAPIでは、このレベルの制御はAPIクライアントには公開されず、グラフィックスAPIの実装側で処理されます。
ひいては、バッファなどのリソースに対する適切なダブル(またはトリプル)バッファリングも、グラフィックス API クライアントが管理しなければならないことを意味します。 最も一般的なケースとして、フレーム間でデータが変化するユニフォームバッファの場合、次のフレームの記録を開始する時点でそのフレームがまだアクティブ(「処理中」)である可能性があるため、フレームを送信する際にその内容を単純に変更することはできません。 パイプラインの停滞を避けるための 1 つの方法は、内部で複数のバッファ(およびメモリ割り当て)を用意し、そのようなリソースに対して少なくともダブルバッファリングを実現することです。
Vulkan などのグラフィックス API を使用して直接レンダリングを行うアプリケーションでは、Qt レンダリングエンジンのフレーム送信プロセスと互換性のある方法で、独自のグラフィックスリソースに対して同様のダブルバッファリングまたはトリプルバッファリングを実行することが望ましい場合があります。 そのためには、処理中のフレームの最大数(通常は 2 または 3)と、現在のフレームスロットインデックス(0、1、…、FramesInFlight-1 の順で数えられ、その後ループして繰り返される数値)の値を知る必要があります。 前者はframesInFlight 変数で公開されています。後者、つまり現在のインデックスは、この値です。
これらの値を実際に使用する例については、{Scene Graph - Vulkan Under QML} および {Scene Graph - Vulkan Texture Import} のサンプルを参照してください。
int GraphicsStateInfo::framesInFlight
この変数には、フライト中に保持されるフレームの最大数が格納されます。
詳細については、currentFrameSlot を参照してください。
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.