Qt Quick シーン グラフ デフォルト レンダラー

このドキュメントでは、デフォルトのシーン グラフ レンダラーが内部でどのように動作するかを説明し、パフォーマンスと機能の両方で最適な方法でそれを使用するコードを記述できるようにします。

良いパフォーマンスを得るためにレンダラーの内部を理解する必要はありません。しかし、シーングラフと統合するときや、グラフィックチップから最大限の効率を引き出せない理由を解明するときに役立つかもしれない。

QMLシーンのQt Quick アイテムは、QSGNode インスタンスのツリーを構成します。一度作成されたこのツリーは、あるフレームがどのようにレンダリングされるべきかを完全に記述したものです。このツリーには、Qt Quick アイテムへの参照は一切含まれておらず、ほとんどのプラットフォームでは、別のスレッドで処理され、レンダリングされます。レンダラーはシーングラフの自己完結した部分で、QSGNode ツリーをトラバースし、QSGGeometryNode で定義されたジオメトリと、QSGMaterial で定義されたシェーダー ステートを使用して、グラフィックス ステートを更新し、描画コールを生成します。

必要に応じて、内部シーングラフバックエンドAPIを使用して、レンダラーを完全に置き換えることができる。これは主に、非標準のハードウェア機能を利用したいプラットフォーム・ベンダーにとって興味深い。大半のユースケースでは、デフォルトのレンダラーで十分です。

デフォルトのレンダラーは、レンダリングを最適化するために2つの主要な戦略に重点を置いている：描画呼び出しのバッチ処理と、GPU でのジオメトリの保持です。

バッチ処理

QPainter や Cairo、Context2D などの伝統的な 2D API は、フレームごとに何千もの個別の描画コールを処理するように記述されていますが、OpenGL やその他のハードウェアアクセラレーション API は、描画コールの数が非常に少なく、状態の変更が最小限に抑えられている場合に、最高のパフォーマンスを発揮します。

次のユースケースを考えてみよう：

このリストの最も単純な描画方法はセル単位である。まず、背景が描画される。これは特定の色の矩形である。OpenGLの用語では、これはベタ塗りを行うシェーダープログラムを選択し、塗りつぶしの色を設定し、xとyのオフセットを含む変換行列を設定し、例えばglDrawArrays 、矩形を構成する2つの三角形を描画することを意味します。次にアイコンが描画される。OpenGLの用語では、これはテクスチャを描画するシェーダープログラムを選択し、使用するアクティブなテクスチャを選択し、変換行列を設定し、アルファブレンディングを有効にし、そして例えばglDrawArrays 、アイコンの外接矩形を構成する2つの三角形を描画することを意味します。セル間のテキストと区切り線も同様のパターンに従う。このプロセスはリスト内のすべてのセルに対して繰り返されるため、リストが長くなると、OpenGLの状態変更や描画呼び出しによって発生するオーバーヘッドは、ハードウェアアクセラレーションAPIを使用することで得られるメリットを完全に上回ります。

各プリミティブが大きい場合、このオーバーヘッドは無視できますが、典型的なUIの場合、小さなアイテムがたくさんあるので、かなりのオーバーヘッドになります。

デフォルトのシーングラフ・レンダラはこの制限の中で動作し、まったく同じ視覚的結果を維持しながら、個々のプリミティブをバッチにマージしようとします。その結果、OpenGLの状態変化が少なくなり、描画呼び出しが最小限に抑えられるため、パフォーマンスが最適化されます。

不透明プリミティブ

レンダラーは、不透明プリミティブとアルファブレンディングを必要とするプリミティブを区別します。OpenGLのZバッファを使用し、各プリミティブに固有のZ位置を与えることで、レンダラーは、不透明プリミティブの画面上の位置や重なっている他の要素を考慮せずに、自由に順序を変更できます。各プリミティブのマテリアルの状態を見ることで、レンダラーは不透明なバッチを作成します。Qt Quick のコア アイテム セットには、不透明な色を持つ長方形アイテムや JPEG や BMP などの完全に不透明な画像が含まれます。

不透明のプリミティブを使用するもう1つの利点は、不透明のプリミティブはGL_BLEND を有効にする必要がないことで、特にモバイルや組み込み GPU ではかなりのコストがかかります。

不透明プリミティブは、glDepthMask とGL_DEPTH_TEST を有効にして、フロントツーバック方式でレンダリングされます。内部的に early-z チェックを行う GPU では、これは、不明瞭なピクセルやピクセルのブロッ クに対してフラグメントシェーダを実行する必要がないことを意味します。レンダラはまだこれらのノードを考慮する必要があり、バーテックスシェーダはまだこれらのプリミティブのすべての頂点に対して実行されるので、アプリケーションが何かが完全に隠されていることを知っている場合は、Item::visible またはItem::opacity を使用して明示的に非表示にするのが最善の方法です。

アルファブレンドされたプリミティブ

不透明プリミティブが描画されると、レンダラーはglDepthMask を無効にし、GL_BLEND を有効にして、すべてのアルファブレンド プリミティブをバックツーフロント方式でレンダリングします。

アルファブレンドされたプリミティブをバッチ処理すると、アルファブレンドが正しく見えるように、重なっている要素を正しい順序でレンダリングする必要があるため、レンダラーに少し手間がかかります。Zバッファだけでは不十分です。レンダラは、アルファブレンドされたすべてのプリミティブに対してパスを行い、マテリアルの状態に加えてバウンディング矩形を見て、どの要素がバッチ処理可能で、どの要素がバッチ処理不可能かを判断します。

一番左のケースでは、青い背景は1回の呼び出しで描画でき、2つのテキスト要素は別の呼び出しで描画できます。一番右のケースでは、「アイテム4」の背景が「アイテム3」のテキストに重なっているので、この場合は背景とテキストをそれぞれ別の呼び出しで描画する必要がある。

Z方向では、アルファプリミティブは不透明ノードとインターリーブされ、利用可能な場合はearly-zをトリガーすることがありますが、Item::visible をfalseに設定すると常に速くなります。

3Dプリミティブとの混合

シーングラフは、擬似3Dと適切な3Dプリミティブをサポートすることができます。たとえば、ShaderEffect を使って「ページカール」エフェクトを実装したり、QSGGeometry とカスタムマテリアルを使ってバンプマップされたトーラスを実装したりできます。その際、デフォルトのレンダラーがすでに深度バッファを使用していることを考慮する必要があります。

レンダラは、QSGMaterialShader::vertexShader() から返された頂点シェーダを修正し、モデルビューと投影行列が適用された後に頂点の z 値を圧縮し、z に小さな平行移動を追加して正しい z 位置に配置します。

圧縮は、z値が0から1の範囲にあると仮定します。

テクスチャアトラス

アクティブなテクスチャは一意のOpenGLステートであり、これは異なるOpenGLテクスチャを使用する複数のプリミティブをバッチ処理できないことを意味します。このため、Qt Quick シーングラフでは、複数のQSGTexture インスタンスをより大きなテクスチャの小さなサブ領域として割り当てることができます。

テクスチャアトラスの最大の利点は、複数のQSGTexture インスタンスが同じOpenGLテクスチャインスタンスを参照するようになったことです。これにより、Image アイテム、BorderImage アイテム、ShaderEffect アイテム、またテクスチャを使用するQSGSimpleTextureNode やカスタム QSGGeometryNodes などの C++ タイプなど、テクスチャを使用した描画呼び出しもバッチ処理できるようになります。

アトラスベースのテクスチャは、QQuickWindow::TextureCanUseAtlas をQQuickWindow::createTextureFromImage() に渡すことで作成されます。

シーングラフはヒューリスティックを使って、アトラスのサイズと、アトラスに入るためのサイズのしきい値を決定します。異なる値が必要な場合は、環境変数QSG_ATLAS_WIDTH=[width],QSG_ATLAS_HEIGHT=[height],QSG_ATLAS_SIZE_LIMIT=[size] を使って上書きすることが可能です。これらの値を変更することは、ほとんどの場合、プラットフォームベンダーにとって興味深いことでしょう。

バッチルーツ

互換性のあるプリミティブをバッチにマージするだけでなく、デフォルトのレン ダラは、フレームごとに GPU に送信する必要のあるデータ量を最小限に抑え ようとします。デフォルトのレンダラーは、一緒に属するサブツリーを識別し、これらを別々のバ ッチに入れようとします。バッチが識別されると、それらはマージされ、アップロードさ れ、頂点バッファオブジェクトを使って GPU メモリに保存されます。

トランスフォームノード

各Qt Quick アイテムは、その x、y、スケールまたは回転を管理するために、シーングラフ ツリーにQSGTransformNode を挿入します。子アイテムは、このトランスフォームノードの下に配置されます。デフォルトのレンダラーは、フレーム間のトランスフォームノードの状態を追跡し、サブツリーを見て、トランスフォームノードが一連のバッチのルートになる良い候補かどうかを判断します。フレーム間で変化し、かなり複雑なサブツリーを持つトランスフォーム ノードは、バッチ ルートになる可能性があります。

バッチルートのサブツリー内の QSGGeometryNodes は、CPU 上でルートに対して事前変換されます。その後、GPU にアップロードされ、保持されます。変換が変更されると、レンダラーが更新する必要があるのはルートの行列だけで、個々のアイテムは更新されないため、リストとグリッドのスクロールが非常に高速になります。連続するフレームでは、ノードが追加または削除されない限り、リストのレンダリングは実質的に無料です。新しいコンテンツがサブツリーに入ると、それを取得するバッチが再構築されるが、それでも比較的高速である。グリッドやリストをパンする場合、ノードが追加または削除されるフレームごとに、変更されないフレームがいくつかあるのが普通です。

トランスフォーム ノードをバッチ ルートとして識別するもう 1 つの利点は、レンダラーがツリーの変更されていない部分を保持できることです。たとえば、UI がリストとボタン行で構成されているとします。リストがスクロールされ、デリゲートが追加および削除され ても、UI の残りの部分であるボタン行は変更されず、GPU にすでに保存されているジオメトリを使用して描画できます。

変換ノードがバッチルートになるためのノードと頂点のしきい値は、環境変数QSG_RENDERER_BATCH_NODE_THRESHOLD=[count] とQSG_RENDERER_BATCH_VERTEX_THRESHOLD=[count] を使ってオーバーライドできます。これらのフラグをオーバーライドすることは、主にプラット フォーム・ベンダーにとって有用です。

クリッピング

Item::clip を true に設定すると、ジオメトリに矩形を含むQSGClipNode が作成されます。デフォルトのレンダラーは、OpenGL のシザリングを使用してこのクリップを適用します。アイテムが 90 度以外の角度で回転する場合は、OpenGL のステンシル バッファが使用されます。 Qt Quick アイテムは QML では矩形しかクリップに設定できませんが、シーングラフ API やデフォルトレンダラでは任意の形状をクリップに使用できます。

サブツリーにクリップを適用する場合、そのサブツリーは固有の OpenGL ステートでレンダリングされる必要があります。つまり、Item::clip が true の場合、そのアイテムのバッチ処理はその子に限定されます。ListView 、GridView のように子アイテムが多い場合や、TextArea のように複雑な子アイテムがある場合は問題ありません。しかし、より小さな項目でclipを使うと、バッチ処理ができなくなるので、注意が必要です。これには、ボタンラベル、テキストフィールド、リストデリゲート、テーブルセルが含まれます。Flickable（またはアイテムビュー）のクリップは、不透明なアイテムがFlickableの周りの領域をカバーするようにUIを配置することで、多くの場合回避できます。

Item::clip をtrue に設定すると、QQuickItem::ItemIsViewport フラグも設定されます。QQuickItem::ItemObservesViewport フラグが設定された子アイテムは、ビューポートを大まかなプリクリッピングのステップに使用できます。たとえば、Text は、ビューポートの完全に外側にあるテキストの行を省略します。シーングラフノードの省略やvertices の制限は最適化であり、QMLでItem::clip を設定するのではなく、C++でflags を設定することで実現できます。

カスタムアイテムでQQuickItem::updatePaintNode （）を実装する場合、大きなジオメトリ領域で多くの詳細をレンダリングできるのであれば、グラフィックをビューポートに限定することが効率的かどうかを考える必要があります。そうであれば、ItemObservesViewport フラグを設定し、QQuickItem::clipRect （）から現在露出している領域を読み込むことができます。その結果、updatePaintNode()が頻繁に呼び出されるようになります（通常、コンテンツがビューポート内で移動するときは、1フレームにつき1回）。

頂点バッファ

各バッチは頂点バッファオブジェクト（VBO）を使って GPU にデータを保存 します。この頂点バッ ファはフレーム間で保持され、シーングラフの一部が変更されると更新されま す。

デフォルトでは、レンダラーはGL_STATIC_DRAW を使用してデータを VBO にアップロードします。環境変数QSG_RENDERER_BUFFER_STRATEGY=[strategy] を設定することで、異なるアップロード戦略を選択することができます。有効な値はstream とdynamic です。この値を変更することは、主にプラットフォームベンダーにとって有用である。

アンチエイリアス

シーングラフは2種類のアンチエイリアシングをサポートしています。デフォルトでは、矩形や画像のようなプリミティブは、プリミティブのエッジに沿って頂点を追加することで、エッジが透明になるようにアンチエイリアスされます。私たちはこの方法を頂点アンチエイリアシングと呼んでいます。ユーザーがマルチサンプルOpenGLコンテキストを要求する場合、QQuickWindow::setFormat （）を使用して、0 より大きいサンプルでQSurfaceFormat を設定することにより、シーングラフはマルチサンプルベース・アンチエイリアス（MSAA）を優先します。この2つの技法は、レンダリングが内部的にどのように行われるかに影響し、異なる制限があります。

また、環境変数QSG_ANTIALIASING_METHOD をvertex またはmsaa に設定することで、使用するアンチエイリアシング手法を上書きすることも可能です。

頂点アンチエイリアシングは、2つのエッジが数学的に同じであっても、隣接するプリミティブのエッジ間に継ぎ目を生じさせます。マルチサンプル・アンチエイリアシングでは発生しません。

頂点アンチエイリアス

頂点アンチエイリアシングは、Item::antialiasing プロパティを使用して、アイテムごとに有効/無効にできます。これは、基礎となるハードウェアが何をサポートしているかに関係なく動作し、通常のレンダリングプリミティブと、例えばShaderEffectSource タイプを使用してフレームバッファオブジェクトにキャプチャされたプリミティブの両方に対して、より高品質なアンチエイリアシングを生成します。

頂点アンチエイリアシングを使用することの欠点は、アンチエイリアシングを有効にした各プリミティブをブレンドしなければならないことです。バッチ処理に関しては、これはプリミティブをバッチ処理できるかどうかを判断するためにレンダラーがより多くの作業を行う必要があることを意味し、シーン内の他の要素とのオーバーラップにより、バッチ処理が少なくなり、パフォーマンスに影響する可能性があります。

また、ローエンドのハードウェアでは、ブレンディングにかなりのコストがかかるため、画面の大部分をカバーする画像や丸みを帯びた長方形の場合、これらのプリミティブの内部に必要なブレンディングの量は、プリミティブ全体をブレンディングしなければならないため、大幅なパフォーマンスの低下を招く可能性があります。

マルチサンプル・アンチエイリアス

マルチサンプル・アンチエイリアシングは、ハードウェアがプリミティブのピクセルごとにカバレッジ値を計算するハードウェア機能です。あるハードウェアは非常に低いコストでマルチサンプルすることができますが、他のハードウェアはフレームをレンダリングするために、より多くのメモリとより多くのGPUサイクルの両方を必要とするかもしれません。

マルチサンプルアンチエイリアスを使用すると、丸みを帯びた長方形や画像要素などの多くのプリミティブは、アンチエイリアスを適用しても、シーングラフでは不透明であることができます。これは、レンダラーがバッチを作成するときに仕事がしやすくなり、過剰描画を避けるためにearly-zに頼ることができることを意味します。

マルチサンプル・アンチエイリアスが使用される場合、フレームバッファオブジェクトにレンダリングされるコンテンツは、フレームバッファのマルチサンプリングをサポートするための追加拡張が必要です。通常、GL_EXT_framebuffer_multisample とGL_EXT_framebuffer_blit 。ほとんどのデスクトップチップにはこれらの拡張がありますが、組み込みチップではあまり一般的ではありません。フレームバッファのマルチサンプリングがハードウェアで利用できない場合、フレームバッファオブジェクトにレンダリングされたコンテンツは、ShaderEffectSource のコンテンツも含めて、アンチエイリアスがかかりません。

パフォーマンス

冒頭で述べたように、良いパフォーマンスを得るためにレンダラーの細かい詳細を理解する必要はありません。これは、一般的なユースケースに最適化するように書かれており、ほとんどどのような状況下でも非常に優れたパフォーマンスを発揮します。

• 良好なパフォーマンスは、ジオメトリをできるだけ少なくして何度もアップロードする、効果的なバッチ処理から生まれます。環境変数QSG_RENDERER_DEBUG=render を設定することで、レンダラはバッチングがどの程度うまくいったか、いくつのバッチが使用されたか、どのバッチが保持され、どれが不透明でどれが不透明でないかなどの統計を出力します。最適なパフォーマンスを追求する場合、アップロードは本当に必要なときだけにし、バッチは10未満にし、少なくとも3～4は不透明にすべきである。
• デフォルトのレンダラーは、CPU側のビューポートクリッピングもオクルージョン検出も行いません。表示されるべきでないものは、表示されるべきではない。描画されるべきでないアイテムには、Item::visible: false 。このようなロジックを追加しない主な理由は、追加コストがかかるため、うまく動作するように気を配っているアプリケーションにも支障が出るからです。
• テクスチャアトラスが使用されていることを確認してください。ImageとBorderImage の項目は、画像が大きすぎない限り、それを使用します。C++ で作成されたテクスチャの場合、QQuickWindow::createTexture() を呼び出すときにQQuickWindow::TextureCanUseAtlas を渡します。環境変数QSG_ATLAS_OVERLAY を設定することで、すべてのアトラステクスチャがカラー化され、アプリケーション内で簡単に識別できるようになります。
• 可能な限り不透明なプリミティブを使用してください。不透明プリミティブはレンダラーでの処理が速く、GPU での描画が速くなります。たとえば、PNGファイルは、各ピクセルが完全に不透明であっても、アルファチャンネルを持つことがよくあります。JPGファイルは常に不透明です。QQuickImageProvider に画像を提供するときや、QQuickWindow::createTextureFromImage() で画像を作成するときは、可能な限り画像にQImage::Format_RGB32 を持たせてください。
• 上図のような重なり合った複合アイテムは、バッ チできませんので注意してください。
• クリッピングはバッチングを壊します。項目ごと、テーブルセル内、項目デリゲートなどでは決して使わないでください。テキストをクリッピングする代わりに、エライディングを使う。画像をクリッピングする代わりに、切り取った画像を返すQQuickImageProvider を作成する。
• バッチ処理は 16 ビット・インデックスに対してのみ機能します。すべての組み込みアイテムは 16 ビット インデックスを使用しますが、カスタム ジオメトリは 32 ビット インデックスを使用することもできます。
• いくつかのマテリアルフラグはバッチングを妨げますが、最も制限的なものはQSGMaterial::RequiresFullMatrix で、これはすべてのバッチングを妨げます。
• モノクロの背景を持つアプリケーションでは、トップレベルの Rectangle アイテムを使用するのではなく、QQuickWindow::setColor() を使用して設定する必要があります。QQuickWindow::setColor() はglClear() への呼び出しで使用され、より高速になる可能性があります。
• Mipmapped Imageアイテムはグローバルアトラスに配置されず、バッチされません。
• フレームバッファオブジェクト（FBO）のリードバックに関連する OpenGL ドライバのバグにより、レンダリングされたグリフが破損する可能性があります。QML_USE_GLYPHCACHE_WORKAROUND 環境変数を設定すると、Qt はグリフの追加コピーを RAM に保持します。これは、以前に描画されていないグリフを描画するとき、Qt が CPU 経由で追加のコピーにアクセスするため、パフォーマンスがわずかに低下することを意味します。また、グリフキャッシュが 2 倍のメモリを使うことになります。品質はこの影響を受けません。

アプリケーションのパフォーマンスが悪い場合は、レンダリングがボトルネックになっていることを確認してください。プロファイラを使ってください！環境変数QSG_RENDER_TIMING=1 は多くの有用なタイミングパラメータを出力し、問題がどこにあるかを突き止めるのに役立ちます。

視覚化

シーングラフのデフォルトレンダラーの様々な側面を視覚化するために、QSG_VISUALIZE 環境変数を、以下の各セクションで詳述する値のいずれかに設定することができます。以下のQMLコードを使って、いくつかの変数の出力例を示します：

import QtQuick 2.2

Rectangle {
    width: 200
    height: 140

    ListView {
        id: clippedList
        x: 20
        y: 20
        width: 70
        height: 100
        clip: true
        model: ["Item A", "Item B", "Item C", "Item D"]

        delegate: Rectangle {
            color: "lightblue"
            width: parent.width
            height: 25

            Text {
                text: modelData
                anchors.fill: parent
                horizontalAlignment: Text.AlignHCenter
                verticalAlignment: Text.AlignVCenter
            }
        }
    }

    ListView {
        id: clippedDelegateList
        x: clippedList.x + clippedList.width + 20
        y: 20
        width: 70
        height: 100
        clip: true
        model: ["Item A", "Item B", "Item C", "Item D"]

        delegate: Rectangle {
            color: "lightblue"
            width: parent.width
            height: 25
            clip: true

            Text {
                text: modelData
                anchors.fill: parent
                horizontalAlignment: Text.AlignHCenter
                verticalAlignment: Text.AlignVCenter
            }
        }
    }
}

左のListView では、そのclip プロパティをtrue に設定します。また、右側のListView については、クリッピングがバッチングに与える影響 を説明するために、各デリゲートのclip プロパティをtrue に設定しています。

オリジナル

バッチの視覚化

QSG_VISUALIZE をbatches に設定すると、レンダラーでバッチが視覚化されます。マージされたバッチは実線で描画され、マージされていないバッチは斜線パターンで描画されます。固有の色が少ないということは、良いバッチであることを意味します。マージされていないバッチは、個々のノードを多く含んでいるとよくありません。

QSG_VISUALIZE=batches

クリッピングの視覚化

QSG_VISUALIZE をclip に設定すると、シーンの上にクリッピングを示す赤い領域が描かれます。Qt Quick アイテムはデフォルトではクリッピングしないので、通常クリッピングは視覚化されません。

QSG_VISUALIZE=clip

変更の視覚化

QSG_VISUALIZE からchanges を設定すると、レンダラーの変更が視覚化されます。シーングラフの変更は、ランダムな色の点滅オーバーレイで視覚化されます。プリミティブ上の変更はベタ塗りで視覚化され、マトリックスや不透明度の変更などの祖先の変更はパターンで視覚化されます。

オーバードローの視覚化

QSG_VISUALIZE をoverdraw に設定すると、レンダラーでオーバードローが視覚化されます。3D のすべてのアイテムを視覚化して、オーバー ドローを強調表示します。このモードは、ビューポートの外にあるジオメトリをある程度検出するためにも使用できます。不透明なアイテムは緑の色合いでレンダリングされ、半透明のアイテムは赤の色合いでレンダリングされます。ビューポートのバウンディングボックスは青でレンダリングされます。不透明なコンテンツは、シーングラフが処理しやすく、通常、レンダリングが速くなります。

上のコードのルート矩形は、ウィンドウも白いので余計であり、この場合、矩形の描画はリソースの無駄であることに注意してください。この矩形をアイテムに変更すると、パフォーマンスが少し向上します。

QSG_VISUALIZE=overdraw

Qt レンダリングハードウェアインタフェースによるレンダリング

Qt 6.0 以降では、デフォルトの適応は常にグラフィックスの抽象化レイヤである Qt Rendering Hardware Interface (RHI) を介してレンダリングされます。 Qt GUIモジュールによって提供されます。つまり、Qt 5とは異なり、シーングラフが直接OpenGLを呼び出すことはありません。むしろ、RHI APIを使用してリソースと描画コマンドを記録し、RHI APIがコマンドストリームをOpenGL、Vulkan、Metal、またはDirect 3Dの呼び出しに変換します。シェーダー処理も、シェーダーコードを一度書いてからSPIR-Vにコンパイルし、さまざまなグラフィックスAPIに適した言語に変換することで統一されています。

動作を制御するために、以下の環境変数を使用することができる：

常に単一のグラフィックスAPIで実行したいアプリケーションは、C++でもこれを要求できます。たとえば、main() の初期に、QQuickWindow を構築する前に、以下の呼び出しを行うと、Vulkan の使用が強制されます（そうでない場合は失敗します）：

QQuickWindow::setGraphicsApi(QSGRendererInterface::Vulkan);

QSGRendererInterface::GraphicsApi を参照してください。列挙値OpenGL,Vulkan,Metal,Direct3D11,Direct3D12 は、QSG_RHI_BACKEND を同等の文字列キーに設定して実行するのと実質的に同等です。

すべてのQRhi バックエンドは、QSG_RHI_PREFER_SOFTWARE_RENDERER やQT_D3D_ADAPTER_INDEX やQT_VK_PHYSICAL_DEVICE_INDEX のようなバックエンド固有の変数で上書きされない限り、システムデフォルトの GPU アダプタまたは物理デバイスを選択します。

Qt 6.5 から、以前は環境変数としてのみ公開されていた設定の一部が、QQuickGraphicsConfiguration の C++ API として利用できるようになりました。例えば、QSG_RHI_DEBUG_LAYER を設定することと、setDebugLayer(true) を呼び出すことは等価です。