Qt Quick 씬 그래프

의 씬 그래프 Qt Quick

Qt Quick 2의 씬 그래프는 전용 씬 그래프를 활용하며, 이 그래프는 OpenGL ES, OpenGL, Vulkan, Metal 또는 Direct 3D와 같은 그래픽 API를 통해 탐색 및 렌더링됩니다. 기존의 명령형 페인팅 시스템(QPainter 등) 대신 그래픽스에 씬 그래프를 사용하면, 렌더링될 씬을 프레임 간에 유지할 수 있으며 렌더링 시작 전에 렌더링할 프라이미티브의 전체 집합을 미리 파악할 수 있습니다. 이를 통해 상태 변경을 최소화하기 위한 배치 렌더링이나 가려진 프라이미티브 제거와 같은 다양한 최적화가 가능해집니다.

예를 들어, 사용자 인터페이스에 각 항목마다 배경색, 아이콘, 텍스트를 가진 10개의 항목 목록이 있다고 가정해 봅시다. 전통적인 드로잉 기법을 사용하면 30회의 드로잉 호출과 그에 상응하는 양의 상태 변경이 발생하게 됩니다. 반면, 씬 그래프를 사용하면 렌더링할 프리미티브를 재구성하여 모든 배경을 한 번의 호출로, 그 다음 모든 아이콘을, 마지막으로 모든 텍스트를 순차적으로 그리도록 할 수 있어, 총 드로우 호출 횟수를 단 3회로 줄일 수 있습니다. 이와 같은 배치 처리 및 상태 변경 감소는 일부 하드웨어에서 성능을 크게 향상시킬 수 있습니다.

씬 그래프는 Qt Quick 2.0과 밀접하게 연동되어 있으며, 단독으로는 사용할 수 없습니다. 씬 그래프는 ` QQuickWindow ` 클래스에 의해 관리 및 렌더링되며, 사용자 정의 `Item` 유형은 ` QQuickItem::updatePaintNode()` 호출을 통해 씬 그래프에 그래픽 프리미티브를 추가할 수 있습니다.

씬 그래프는 Item 씬을 그래픽으로 표현한 것으로, 모든 아이템을 렌더링하는 데 필요한 충분한 정보를 포함하는 독립적인 구조입니다. 일단 설정되면, 아이템의 상태와 독립적으로 조작 및 렌더링될 수 있습니다. 많은 플랫폼에서, GUI 스레드가 다음 프레임의 상태를 준비하는 동안 씬 그래프는 전용 렌더링 스레드에서 렌더링되기도 합니다.

Qt Quick 씬 그래프 구조

씬 그래프는 각각 고유한 목적을 수행하는 여러 사전 정의된 노드 유형으로 구성됩니다. 이를 씬 그래프라고 부르지만, 더 정확한 정의는 노드 트리입니다. 이 트리는 QML 씬 내의 QQuickItem 유형으로 구축되며, 내부적으로는 씬을 렌더링하는 렌더러에 의해 씬이 처리됩니다. 노드 자체에는 활성 렌더링 코드나 가상 ` paint() ` 함수가 포함되어 있지 않습니다.

노드 트리는 대부분 기존 Qt Quick QML 유형에 의해 내부적으로 구축되지만, 사용자는 3D 모델을 나타내는 서브트리를 포함하여 자체 콘텐츠를 가진 완전한 서브트리를 추가할 수도 있습니다.

노드

사용자에게 가장 중요한 노드는 QSGGeometryNode 입니다. 이 노드는 기하 구조와 재질을 정의하여 사용자 정의 그래픽을 구현하는 데 사용됩니다. 지오메트리는 ` QSGGeometry `를 사용하여 정의되며, 그래픽 프리미티브의 모양이나 메쉬를 설명합니다. 이는 선, 사각형, 다각형, 서로 연결되지 않은 여러 사각형, 또는 복잡한 3D 메쉬일 수 있습니다. 머티리얼은 이 모양 내의 픽셀이 어떻게 채워지는지를 정의합니다.

노드는 자식 노드를 무제한으로 가질 수 있으며, 지오메트리 노드는 부모 노드가 자식 노드 뒤에 위치하도록 자식 순서대로 렌더링됩니다.

사용 가능한 노드는 다음과 같습니다:

사용자 정의 노드는 ` QQuickItem::updatePaintNode()`을 상속하고 ` QQuickItem::ItemHasContents ` 플래그를 설정하여 씬 그래프에 추가됩니다.

자세한 내용은 ‘씬 그래프 - 사용자 정의 지오메트리’를 참조하십시오.

전처리

노드에는 QSGNode::preprocess()라는 가상 함수가 있으며, 이 함수는 씬 그래프가 렌더링되기 전에 호출됩니다. 노드의 하위 클래스는 QSGNode::UsePreprocess 플래그를 설정하고 QSGNode::preprocess() 함수를 재정의하여 노드의 최종 준비 작업을 수행할 수 있습니다. 예를 들어, 베지어 곡선을 현재 스케일 계수에 맞는 적절한 디테일 레벨로 분할하거나 텍스처의 일부를 업데이트하는 작업이 있습니다.

노드 소유권

노드의 소유권은 생성자가 명시적으로 지정하거나, ` QSGNode::OwnedByParent` 플래그를 설정하여 씬 그래프가 자동으로 할당합니다. 씬 그래프가 GUI 스레드 외부에 존재할 때 정리 작업을 단순화할 수 있으므로, 씬 그래프에 소유권을 할당하는 것이 일반적으로 더 바람직합니다.

머티리얼

머티리얼은 QSGGeometryNode 내 지오메트리의 내부 공간이 어떻게 채워지는지를 정의합니다. 머티리얼은 그래픽 파이프라인의 정점 및 프래그먼트 단계를 위한 그래픽 셰이더를 포함하며, 구현 가능한 기능에 있어 상당한 유연성을 제공합니다. 다만 Qt Quick 에 소개된 대부분의 항목 자체는 단색 채우기나 텍스처 채우기와 같은 매우 기본적인 머티리얼만을 사용합니다.

단순히 QML 항목 유형에 사용자 정의 셰이딩을 적용하고자 하는 사용자의 경우, ShaderEffect 유형을 사용하여 QML에서 직접 이를 수행할 수 있습니다.

다음은 머티리얼 클래스의 전체 목록입니다:

편의 노드

씬 그래프 API는 저수준이며, 편의성보다는 성능에 중점을 둡니다. 가장 기본적인 것이라도 사용자 정의 지오메트리와 머티리얼을 처음부터 작성하려면 상당한 양의 코드가 필요합니다. 이러한 이유로, API에는 가장 일반적인 사용자 정의 노드를 쉽게 사용할 수 있도록 몇 가지 편의 클래스가 포함되어 있습니다.

• QSGSimpleRectNode - 단색 머티리얼을 적용한 직사각형 지오메트리를 정의하는 ` QSGGeometryNode `의 서브클래스.
• QSGSimpleTextureNode - 텍스처 머티리얼을 적용한 직사각형 지오메트리를 정의하는 ` QSGGeometryNode `의 서브클래스입니다.

씬 그래프 및 렌더링

씬 그래프의 렌더링은 QQuickWindow 클래스 내부에서 이루어지며, 이에 접근할 수 있는 공개 API는 없습니다. 그러나 렌더링 파이프라인의 몇몇 지점에서는 사용자가 애플리케이션 코드를 연결할 수 있습니다. 이를 통해 사용자 정의 씬 그래프 콘텐츠를 추가하거나, 씬 그래프에서 사용 중인 그래픽 API(OpenGL, Vulkan, Metal 등)를 직접 호출하여 임의의 렌더링 명령을 삽입할 수 있습니다. 이러한 통합 지점은 렌더 루프에 의해 정의됩니다.

씬 그래프 렌더러의 작동 방식에 대한 자세한 내용은 ‘Qt Quick 씬 그래프 기본 렌더러’를 참조하십시오.

사용 가능한 렌더 루프 변형은 basic 와 threaded 두 가지가 있습니다. basic 는 단일 스레드 방식인 반면, threaded 는 전용 스레드에서 씬 그래프 렌더링을 수행합니다. Qt는 플랫폼과 사용 중인 그래픽 드라이버를 고려하여 적합한 루프를 선택하려고 시도합니다. 이 결과가 만족스럽지 않거나 테스트 목적으로 특정 루프의 사용을 강제하려면 환경 변수 ` QSG_RENDER_LOOP `를 사용할 수 있습니다. 현재 사용 중인 렌더 루프를 확인하려면 ` qt.scenegraph.general `( logging category)를 활성화하십시오.

스레드 기반 렌더 루프('threaded')

많은 구성에서 씬 그래프 렌더링은 전용 렌더 스레드에서 수행됩니다. 이는 멀티코어 프로세서의 병렬 처리를 강화하고, 차단되는 스왑 버퍼 호출을 기다리는 것과 같은 대기 시간을 더 효율적으로 활용하기 위함입니다. 이를 통해 성능이 크게 향상되지만, 씬 그래프와의 상호작용이 발생할 수 있는 시점과 위치에 일정한 제한이 따릅니다.

다음은 스레드 기반 렌더 루프와 OpenGL을 사용하여 프레임이 렌더링되는 과정을 간략히 설명한 것입니다. OpenGL 컨텍스트의 세부 사항을 제외하면, 이 단계들은 다른 그래픽 API에서도 동일하게 적용됩니다.

1. QML 씬에서 변경 사항이 발생하여 ` QQuickItem::update() `가 호출됩니다. 이는 예를 들어 애니메이션이나 사용자 입력의 결과일 수 있습니다. 새로운 프레임을 시작하기 위해 렌더 스레드에 이벤트가 게시됩니다.
2. 렌더 스레드는 새로운 프레임을 그릴 준비를 하고, GUI 스레드에서 블록을 시작합니다.
3. 렌더 스레드가 새 프레임을 준비하는 동안, GUI 스레드는 QQuickItem::updatePolish()를 호출하여 항목이 렌더링되기 전에 최종 마무리 작업을 수행합니다.
4. GUI 스레드는 차단됩니다.
5. QQuickWindow::beforeSynchronizing() 신호가 방출됩니다. 애플리케이션은 Qt::DirectConnection 를 사용하여 이 신호에 직접 연결함으로써 QQuickItem::updatePaintNode() 호출 전에 필요한 준비를 수행할 수 있습니다.
6. QML 상태를 씬 그래프로 동기화합니다. 이는 이전 프레임 이후 변경된 모든 항목에 대해 QQuickItem::updatePaintNode() 함수를 호출하여 수행됩니다. 이때가 QML 항목과 씬 그래프의 노드가 상호 작용하는 유일한 순간입니다.
7. GUI 스레드 잠금이 해제됩니다.
8. 씬 그래프가 렌더링됩니다:
   1. QQuickWindow::beforeRendering() 신호가 발산됩니다. 애플리케이션은 이 신호에 직접 연결( Qt::DirectConnection 사용)하여 사용자 정의 그래픽 API 호출을 사용할 수 있으며, 이 호출 결과는 시각적으로 QML 장면 아래에 중첩됩니다.
   2. QSGNode::UsePreprocess 를 지정한 항목의 경우, 해당 항목의 QSGNode::preprocess() 함수가 호출됩니다.
   3. 렌더러는 노드를 처리합니다.
   4. 렌더러는 상태를 생성하고 사용 중인 그래픽 API에 대한 드로우 호출을 기록합니다.
   5. QQuickWindow::afterRendering() 신호가 발산됩니다. 애플리케이션은 이 신호에 직접 연결( Qt::DirectConnection 사용)하여 사용자 정의 그래픽 API 호출을 발행할 수 있으며, 이 호출은 QML 장면 위에 시각적으로 중첩됩니다.
   6. 이제 프레임이 준비되었습니다. 버퍼가 교체되거나(OpenGL), 프레젠트 명령이 기록되고 명령 버퍼가 그래픽 큐로 제출됩니다(Vulkan, Metal). QQuickWindow::frameSwapped() 신호가 방출됩니다.
9. 렌더링 스레드가 렌더링을 수행하는 동안, GUI는 애니메이션을 진행하거나 이벤트를 처리하는 등의 작업을 자유롭게 수행할 수 있습니다.

스레드 기반 렌더러는 현재 Windows에서 Direct3D 11을 사용할 때, opengl32.dll을 사용하는 OpenGL 환경에서, Mesa llvmpipe를 제외한 Linux에서, Metal을 사용하는 macOS에서, 모바일 플랫폼에서, EGLFS를 사용하는 임베디드 Linux에서, 그리고 플랫폼에 관계없이 Vulkan을 사용할 때 기본적으로 사용됩니다. 이 모든 사항은 향후 릴리스에서 변경될 수 있습니다. 환경에 QSG_RENDER_LOOP=threaded 을 설정하여 스레드 기반 렌더러의 사용을 강제할 수 있습니다.

비스레드형 렌더 루프('기본')

비스레드형 렌더 루프는 현재 시스템의 표준 opengl32.dll을 사용하지 않는 Windows의 OpenGL, macOS의 OpenGL, WebAssembly, 그리고 일부 드라이버를 사용하는 Linux에서 기본적으로 사용됩니다. 후자의 경우, OpenGL 드라이버와 윈도우 시스템의 모든 조합이 테스트된 것은 아니기 때문에 이는 주로 예방 차원의 조치입니다.

macOS 및 OpenGL의 경우, XCode 10(10.14 SDK) 이상으로 빌드할 때는 스레드 기반 렌더 루프가 지원되지 않습니다. 이는 macOS 10.14에서 레이어 기반 뷰가 기본으로 활성화되기 때문입니다. 레이어 백킹을 비활성화하려면 Xcode 9(10.13 SDK)로 빌드할 수 있으며, 이 경우 스레드 기반 렌더 루프를 사용할 수 있고 기본적으로 적용됩니다. Metal의 경우 이러한 제한이 없습니다.

웹 플랫폼은 메인 스레드 이외의 스레드에서 WebGL을 사용하는 기능과 메인 스레드를 차단하는 기능에 대한 지원이 제한적이기 때문에, WebAssembly에서는 스레드 기반 렌더 루프가 지원되지 않습니다.

스레드 기반이 아닌 렌더 루프를 사용하는 경우에도, 마치 스레드 기반 렌더러를 사용하는 것처럼 코드를 작성해야 합니다. 그렇지 않으면 코드의 이식성이 떨어지게 됩니다.

다음은 비스레드형 렌더러에서 프레임 렌더링 순서를 단순화하여 설명한 것입니다.

애니메이션 구동

위 다이어그램에서 ‘ Advance Animations ’는 무엇을 의미합니까?

기본적으로 Qt Quick 애니메이션(예: NumberAnimation)은 기본 애니메이션 드라이버에 의해 구동됩니다. 이는 QObject::startTimer()와 같은 기본 시스템 타이머에 의존합니다. 이 타이머는 일반적으로 16밀리초 간격으로 실행됩니다. 이 방식은 절대적으로 정확할 수는 없으며 기본 플랫폼의 타이머 정확도에 따라 달라지기도 하지만, 렌더링과 독립적이라는 장점이 있습니다. 디스플레이의 재생 빈도나 디스플레이의 수직 동기화(VSync)와의 동기화 여부와 관계없이 일관된 결과를 제공합니다. 이것이 바로 basic 렌더 루프에서 애니메이션이 작동하는 방식입니다.

렌더 루프 설계(단일 스레드이든 다중 스레드이든)와 무관하게 더 정확한 결과를 제공하고 화면 끊김 현상을 줄이기 위해, 렌더 루프는 자체적인 맞춤형 애니메이션 드라이버를 구현하여 타이머에 의존하지 않고 advancing 의 동작을 직접 제어할 수 있습니다.

이것이 바로 threaded 렌더 루프가 구현하는 방식입니다. 사실, 이 렌더 루프는 애니메이션 드라이버를 하나가 아니라 두 개를 설치합니다. 하나는 GUI 스레드에( NumberAnimation 와 같은 일반 애니메이션을 구동하기 위해), 다른 하나는 렌더 스레드에(렌더 스레드 애니메이션, 즉 Animator 유형의 애니메이션(예: OpacityAnimator 또는 XAnimator)을 구동하기 위해) 설치됩니다. 이 두 가지 모두 프레임 준비 과정에서 진행되며, 즉 애니메이션이 이제 렌더링과 동기화됩니다. 이는 기본 그래픽 스택에 의해 프레젠테이션이 디스플레이의 수직 동기화(VSYNC)에 맞춰 조절되기 때문에 타당한 방식입니다.

따라서 위의 threaded 렌더 루프 다이어그램에서는 두 스레드 모두에 명시적인 ` Advance animations ` 단계가 존재합니다. 렌더 스레드의 경우, 이는 사소한 문제입니다. 스레드가 vsync에 맞춰 제한되므로, 각 프레임에서 마치 16.67밀리초가 경과한 것처럼 애니메이션( Animator 유형)을 진행시키는 것이 시스템 타이머에 의존하는 것보다 더 정확한 결과를 제공합니다. (vsync 타이밍으로 제한될 때—60Hz 재생률 기준 1000/60 밀리초—이전 프레임에서 동일한 작업이 수행된 이후 대략 그 정도의 시간이 지났다고 가정하는 것이 타당합니다.)

이 같은 접근 방식은 GUI(메인) 스레드의 애니메이션에도 적용됩니다: GUI 스레드와 렌더링 스레드 간의 필수적인 데이터 동기화 덕분에, GUI 스레드는 렌더링 스레드와 동일한 속도로 효과적으로 제한되지만, 수행해야 할 작업량이 적어지는 이점을 여전히 누릴 수 있습니다. 이제 렌더링 준비 작업의 상당 부분이 렌더링 스레드로 오프로드되므로, 애플리케이션 로직을 위한 여유 공간이 더 많이 확보됩니다.

위의 예제에서는 초당 60프레임을 사용했지만, ` Qt Quick `는 다른 재생 빈도에도 대응할 수 있도록 설계되었습니다. 재생 빈도는 ` QScreen `와 플랫폼에서 조회됩니다. 예를 들어, 144 Hz 화면의 경우 간격은 6.94 ms입니다. 동시에, vsync 기반 스로틀링이 예상대로 작동하지 않을 경우 바로 이 점이 문제를 일으킬 수 있습니다. 렌더 루프가 인식하는 상황과 실제 상황이 일치하지 않으면 애니메이션 속도가 부정확해지기 때문입니다.

요약하자면, ‘ threaded ’ 렌더 루프는 다음 조건이 충족되는 한 더 부드러운 애니메이션을 제공하고 끊김 현상을 줄여줄 것으로 기대됩니다:

• 화면에 정확히 하나의 창( QQuickWindow 에서와 같이)만 표시되어 있어야 합니다.
• VSync 기반 스로틀링이 기본 그래픽 및 디스플레이 스택에서 예상대로 작동합니다.

보이는 창이 없거나 두 개 이상인 경우에는 어떻게 될까요?

예를 들어 QQuickWindow 가 최소화되어 있거나(Windows) 완전히 가려져 있는(macOS) 경우처럼 렌더링 가능한 창이 없을 때는 프레임을 표시할 수 없으므로, 스레드가 화면 재생 빈도와 ‘동기화’되어 작동한다고 가정할 수 없습니다. 이 경우, threaded 렌더 루프는 애니메이션을 구동하기 위해 자동으로 시스템 타이머 기반 방식으로 전환됩니다. 즉, 일시적으로 basic 루프가 사용하는 메커니즘으로 전환되는 것입니다.

화면에 QQuickWindow 인스턴스가 두 개 이상 있을 때도 마찬가지입니다. 렌더 스레드와의 동기화를 통해 GUI 스레드에서 애니메이션을 진행하는 데 사용되던 앞서 설명한 모델은, 이제 여러 렌더 스레드(창당 하나씩)와 관련된 여러 동기화 지점이 존재하기 때문에 더 이상 적합하지 않습니다. 이 경우 시스템 타이머 기반 접근 방식으로 되돌아가는 것이 필요해집니다. GUI 스레드가 얼마나 오랫동안, 얼마나 자주 차단될지는 이제 다음과 같은 여러 요인에 따라 달라지기 때문입니다. 창 내의 콘텐츠 (애니메이션이 실행 중인가? 업데이트 빈도는 어느 정도인가?)와 그래픽 스택의 동작(‘wait-for-vsync’ 상태에서 두 개 이상의 스레드가 프레젠테이션을 수행할 때 정확히 어떻게 처리되는가?) 등 여러 요인에 따라 달라지기 때문입니다. 창의 프레젠테이션 속도(애초에 어떤 창을 말하는 것일까요?)에 맞춰 안정적이고 크로스 플랫폼 방식으로 스로틀링될 것이라고 보장할 수 없기 때문에, 애니메이션 진행은 렌더링에 기반할 수 없습니다.

이러한 애니메이션 처리 메커니즘의 전환은 애플리케이션에 투명하게 이루어집니다.

vsync 기반 스로틀링이 제대로 작동하지 않거나, 전역적으로 비활성화되었거나, 애플리케이션이 직접 비활성화한 경우에는 어떻게 될까요?

threaded 의 렌더 루프는 스로틀링을 위해 그래픽 API 구현 및/또는 윈도우 시스템에 의존합니다. 예를 들어, OpenGL(GLX, EGL, WGL)의 경우 스왑 간격을 1로 요청하거나, Direct 3D의 경우 간격을 1로 설정하여 Present()를 호출하거나, Vulkan의 경우 프레젠테이션 모드 FIFO 를 사용하는 방식입니다.

일부 그래픽 드라이버는 사용자가 이 설정을 재정의하여 비활성화할 수 있게 하여, Qt의 요청을 무시하기도 합니다. 이에 대한 예로는, vsync와 관련하여 애플리케이션 설정을 재정의할 수 있는 그래픽 드라이버의 시스템 전체 제어판이 있습니다. 또한 그래픽 스택이 적절한 vsync 기반 스로틀링을 제공하지 못하는 경우도 발생할 수 있는데, 이는 일부 가상 머신에서 발생할 수 있습니다(주로 OpenGL 또는 Vulkan의 소프트웨어 래스터화 기반 구현을 사용하기 때문입니다).

스왑/프레젠트 작업(또는 기타 그래픽 작업)에서 차단이 발생하지 않으면, 이러한 렌더 루프는 애니메이션을 너무 빠르게 진행시킬 수 있습니다. 이는 항상 시스템 타이머에 의존하는 ` basic ` 렌더 루프의 경우에는 문제가 되지 않습니다. ` threaded`의 경우, 동작은 Qt 버전에 따라 달라질 수 있습니다:

• 시스템이 vsync 기반 스로틀링을 제공할 수 없는 것으로 알려진 경우, Qt 6.4 이전에는 애플리케이션을 실행하기 전에 환경에서 QSG_RENDER_LOOP=basic 을 수동으로 설정하여 basic 렌더 루프를 사용하는 것이 유일한 방법이었습니다.
• Qt 6.4부터는 QSG_NO_VSYNC 환경 변수를 0이 아닌 값으로 설정하거나, 창의 QSurfaceFormat::swapInterval()를 0 로 설정하는 방법 모두 이 문제를 완화할 수 있습니다: 실제 효과가 있든 없든 vsync 기반 차단 기능을 명시적으로 비활성화하도록 요청함으로써, threaded 렌더 루프는 애니메이션 구동에 vsync에 의존하는 것이 무의미하다는 것을 인식하게 되며, 창이 두 개 이상일 때와 마찬가지로 시스템 타이머를 사용하는 방식으로 전환하게 됩니다.
• 더욱 좋은 점은, Qt 6.4부터 시네그래프(scenegraph)가 간단한 휴리스틱을 통해 프레임이 "너무 빠르게" 표시되고 있음을 인식하려고 시도하며, 필요하다고 판단될 경우 자동으로 시스템 타이머로 전환한다는 것입니다. 이는 대부분의 경우 별도의 조치가 필요 없으며, 기본 렌더 루프가 threaded 인 경우에도 애플리케이션이 애니메이션을 예상대로 실행할 것임을 의미합니다. 이 과정은 애플리케이션 측에서는 투명하게 처리되지만, 문제 해결 및 개발 목적으로는 QSG_INFO 또는 qt.scenegraph.general 가 활성화되었을 때 "Window 0x7ffc8489c3d0 is determined to have broken vsync throttling ..." 메시지가 출력되어 기록된다는 점을 알아두면 유용합니다. 이 방식의 단점은 평가할 데이터를 먼저 수집해야 하므로 소량의 프레임이 지난 후에야 비로소 활성화된다는 점입니다. 즉, QQuickWindow 를 열 때 애플리케이션이 짧은 시간 동안 여전히 지나치게 빠른 애니메이션을 표시할 수 있습니다. 또한, 가능한 모든 vsync 비동기 상황을 포착하지 못할 수도 있습니다.

그러나 설계상 이러한 조치들은 렌더링 스레드 애니메이션( Animator 유형)에는 도움이 되지 않는다는 점을 기억하십시오. vsync 기반 차단이 없는 경우, animators 는 기본적으로 예상보다 빠르게, 즉 잘못된 속도로 진행되며, 이는 일반 animations 에 대한 해결책이 활성화된 상황에서도 마찬가지입니다. 이로 인해 문제가 발생하면 QSG_USE_SIMPLE_ANIMATION_DRIVER 를 설정하여 대체 애니메이션 드라이버를 사용하는 것을 고려해 보십시오.

QQuickRenderControl을 사용한 렌더링 사용자 지정 제어

QQuickRenderControl 를 사용할 경우, 렌더링 루프를 구동하는 책임은 애플리케이션으로 이전됩니다. 이 경우 내장된 렌더링 루프는 사용되지 않습니다. 대신, 적절한 시점에 폴리싱, 동기화 및 렌더링 단계를 호출하는 것은 애플리케이션의 몫입니다. 위에서 보여준 것과 유사한 스레드 기반 또는 비스레드 기반 동작을 구현할 수 있습니다.

또한, 애플리케이션에서는 QQuickRenderControl 와 함께 자체 QAnimationDriver를 구현하고 설치할 수도 있습니다. 이를 통해 Qt Quick 애니메이션을 완전히 제어할 수 있는데, 이는 화면에 표시되지 않는 콘텐츠의 경우 특히 중요할 수 있습니다. 이러한 콘텐츠는 프레임이 표시되지 않기 때문에 렌더링 빈도와는 전혀 무관하기 때문입니다. 이는 선택 사항이며, 기본적으로 애니메이션은 시스템 타이머에 따라 진행됩니다.

QRhi 기반 및 네이티브 3D 렌더링을 통한 씬 그래프 확장

씬 그래프는 애플리케이션에서 제공하는 그래픽 명령을 통합하기 위한 세 가지 방법을 제공합니다:

• 씬 그래프 자체의 렌더링 직전 또는 직후에 QRhi 기반 명령어나 OpenGL, Vulkan, Metal, Direct3D 명령어를 직접 실행하는 방법입니다. 이는 사실상 메인 렌더 패스 앞에 또는 뒤에 일련의 드로우 호출을 추가하는 효과를 냅니다. 추가적인 렌더 타겟은 사용되지 않습니다.
• 텍스처로 렌더링하고 씬 그래프 내에 텍스처 노드를 생성하는 방법입니다. 이 경우 추가적인 렌더 패스와 렌더 타깃이 필요합니다.
• 씬 그래프 내에서 QSGRenderNode 의 서브클래스를 인스턴스화하여 씬 그래프의 자체 렌더링과 inline으로 드로우 콜을 실행하는 방법입니다. 이는 첫 번째 접근 방식과 유사하지만, 사용자 정의 드로우 콜이 씬 그래프의 명령 스트림에 효과적으로 주입됩니다.

언더레이/오버레이 모드

QQuickWindow::beforeRendering() 및 QQuickWindow::afterRendering() 시그널에 연결함으로써, 애플리케이션은 QRhi 또는 네이티브 3D API 호출을 씬 그래프가 렌더링하는 것과 동일한 컨텍스트 내에서 직접 수행할 수 있습니다. Vulkan이나 Metal과 같은 API를 사용하면, 애플리케이션은 QSGRendererInterface 을 통해 씬 그래프의 커맨드 버퍼와 같은 네이티브 객체를 조회하고, 필요에 따라 해당 객체에 커맨드를 기록할 수 있습니다. 신호 이름에서 알 수 있듯이, 사용자는 Qt Quick 장면 아래에서 또는 그 위에 콘텐츠를 렌더링할 수 있습니다. 이러한 방식으로 통합할 때의 장점은 렌더링을 수행하는 데 추가적인 렌더 타깃이 필요하지 않으며, 비용이 많이 들 수 있는 텍스처링 단계가 제거된다는 점입니다. 단점은 사용자 정의 렌더링이 Qt Quick 자체 렌더링의 시작 또는 끝 부분에서만 실행될 수 있다는 것입니다. QQuickWindow 신호 대신 QSGRenderNode 를 사용하면 이러한 제한을 어느 정도 완화할 수 있지만, 어느 경우든 3D 콘텐츠 및 깊이 버퍼 사용과 관련해서는 주의를 기울여야 합니다. 깊이 테스트에 의존하거나 깊이 쓰기(depth write)가 활성화된 상태에서 렌더링할 경우, 사용자 정의 콘텐츠와 Qt Quick 콘텐츠의 깊이 버퍼 사용이 서로 충돌하는 상황이 쉽게 발생할 수 있기 때문입니다.

Qt 6.6부터 QRhi API는 반공개(semi-public)로 간주됩니다. 즉, 호환성 보장은 제한적이지만 애플리케이션에 제공되며 문서화되어 있습니다. 이를 통해 씬 그래프 자체가 사용하는 것과 동일한 그래픽 및 셰이더 추상화를 활용하여 이식성이 뛰어난 크로스 플랫폼 2D/3D 렌더링 코드를 작성할 수 있습니다.

'Scene Graph - RHI Under QML' 예제는 QRhi 를 사용하여 언더레이/오버레이 방식을 구현하는 방법을 보여줍니다.

'씬 그래프 - QML 기반 OpenGL' 예제는 OpenGL을 사용하여 이러한 신호를 활용하는 방법을 보여줍니다.

'씬 그래프 - QML 기반 Direct3D 11' 예제는 Direct3D를 사용하여 이러한 신호를 활용하는 방법을 보여줍니다.

'QML 기반 씬 그래프 - Metal' 예제는 Metal을 사용하여 이러한 신호를 사용하는 방법을 보여줍니다.

'QML 기반 씬 그래프 - Vulkan' 예제는 Vulkan을 사용하여 이러한 신호를 사용하는 방법을 보여줍니다.

Qt 6.0부터, 기본 그래픽 API를 직접 사용하는 경우 QQuickWindow::beginExternalCommands() 및 QQuickWindow::endExternalCommands() 호출로 둘러싸야 합니다. 이 개념은 QPainter::beginNativePainting()에서 익숙할 수 있으며, 유사한 목적을 수행합니다. 즉, 애플리케이션 코드가 기본 그래픽 API를 직접 조작하여 변경했을 가능성이 있으므로, Qt Quick 시나리오 그래프가 현재 기록된 렌더 패스(있는 경우) 내의 캐시된 상태 및 상태에 대한 가정이 더 이상 유효하지 않음을 인식할 수 있게 해줍니다. 이는 QRhi 을 사용할 때는 적용되지 않으며 필요하지도 않습니다.

사용자 정의 OpenGL 렌더링을 씬 그래프와 혼합할 때는, 애플리케이션이 버퍼가 바인딩된 상태, 속성이 활성화된 상태, z-버퍼나 스텐실-버퍼에 특수 값이 포함된 상태 등으로 OpenGL 컨텍스트를 남겨두지 않는 것이 중요합니다. 그렇게 할 경우 예측할 수 없는 동작이 발생할 수 있습니다.

사용자 정의 렌더링 코드는 애플리케이션의 GUI(메인) 스레드에서 실행된다고 가정해서는 안 된다는 점에서 스레드 인식적이어야 합니다. ` QQuickWindow ` 시그널에 연결할 때, 애플리케이션은 ` Qt::DirectConnection `를 사용해야 하며, 연결된 슬롯이 (존재할 경우) 씬 그래프의 전용 렌더링 스레드에서 호출된다는 점을 이해해야 합니다.

텍스처 기반 접근 방식

텍스처 기반 방식은 애플리케이션이 Qt Quick 장면 내에서 사용자 정의 3D 렌더링의 “평면화된” 2D 이미지를 필요로 할 때 가장 유연한 접근 방식입니다. 또한 이를 통해 메인 렌더 패스에서 사용하는 버퍼와 독립적인 전용 깊이/스텐실 버퍼를 사용할 수 있습니다.

OpenGL을 사용할 때, 레거시 편의 클래스인 QQuickFramebufferObject 를 사용하여 이를 구현할 수 있습니다. QRhi 기반 사용자 정의 렌더러와 OpenGL 이외의 그래픽 API도 이 접근 방식을 따를 수 있지만, QQuickFramebufferObject 에서는 현재 이를 지원하지 않습니다. 기본 API를 사용하여 텍스처를 직접 생성하고 렌더링한 다음, 사용자 정의 ` QQuickItem` 내에서 ` Qt Quick ` 씬에 이 리소스를 래핑하여 사용하는 방법은 다음 예제에서 확인할 수 있습니다:

씬 그래프 - RHI 텍스처 항목 예제.

씬 그래프 - Vulkan 텍스처 임포트 예제.

씬 그래프 - Metal 텍스처 임포트 예제.

인라인 방식

QSGRenderNode 를 사용하면 사용자 정의 드로우 콜이 씬 그래프의 렌더 패스 기록의 시작이나 끝이 아니라, 씬 그래프의 렌더링 과정 중에 삽입됩니다. 이는 QSGRenderNode 의 인스턴스를 기반으로 하는 사용자 지정 QQuickItem 를 생성함으로써 달성되며, 이 노드는 QRhi 또는 OpenGL, Vulkan, Metal, Direct 3D와 같은 네이티브 3D API를 통해 그래픽 명령을 발행할 수 있도록 특별히 존재하는 씬 그래프 노드입니다.

'씬 그래프 - 사용자 정의 QSGRenderNode' 예제에서 이 접근 방식을 확인할 수 있습니다.

QPainter를 사용하는 사용자 정의 항목

QQuickItem 는 QQuickPaintedItem 라는 하위 클래스를 제공하며, 이를 통해 사용자는 QPainter 를 사용하여 콘텐츠를 렌더링할 수 있습니다.

로깅 지원

씬 그래프는 다양한 로깅 범주를 지원합니다. 이러한 기능은 Qt 기여자들에게 도움이 될 뿐만 아니라, 성능 문제와 버그를 추적하는 데에도 유용할 수 있습니다.

• qt.scenegraph.time.texture - 텍스처 업로드에 소요된 시간을 기록합니다
• qt.scenegraph.time.compilation - 셰이더 컴파일에 소요된 시간을 기록합니다
• qt.scenegraph.time.renderer - 렌더러의 다양한 단계에서 소요된 시간을 기록합니다
• qt.scenegraph.time.renderloop - 렌더 루프의 다양한 단계에서 소요된 시간을 기록합니다. threaded 렌더 루프를 사용할 경우, 이를 통해 GUI 스레드와 렌더 스레드 모두에서 다양한 프레임 준비 단계 사이에 경과한 시간을 파악할 수 있습니다. 따라서 이는 문제 해결 도구로도 유용할 수 있습니다. 예를 들어, vsync 기반 스로틀링이나 ` QWindow::requestUpdate()`와 같은 기타 저수준 Qt 활성화 기능이 렌더링 및 표시 파이프라인에 어떤 영향을 미치는지 확인하는 데 사용할 수 있습니다.
• qt.scenegraph.time.glyph - 거리 필드 글리프 준비에 소요된 시간을 기록합니다.
• qt.scenegraph.general - 씬 그래프 및 그래픽 스택의 다양한 부분에 대한 일반 정보를 기록합니다
• qt.scenegraph.renderloop - 렌더링에 관련된 다양한 단계에 대한 상세한 로그를 생성합니다. 이 로그 모드는 주로 Qt 작업을 하는 개발자에게 유용합니다.

기존의 QSG_INFO 환경 변수도 사용할 수 있습니다. 이 변수를 0이 아닌 값으로 설정하면 qt.scenegraph.general 범주가 활성화됩니다.

씬 그래프 백엔드

공개 API 외에도, 씬 그래프에는 하드웨어별 최적화를 수행할 수 있도록 구현을 개방하는 적응 계층이 있습니다. 이는 문서화되지 않은 내부 전용 플러그인 API로, 하드웨어 최적화 팀이 해당 하드웨어의 성능을 최대한 활용할 수 있게 해줍니다. 여기에는 다음이 포함됩니다:

• 사용자 정의 텍스처: 특히 ` QQuickWindow::createTextureFromImage `의 구현과 ` Image ` 및 ` BorderImage ` 유형에서 사용하는 텍스처의 내부 표현.
• 사용자 정의 렌더러: 이 최적화 계층을 통해 플러그인은 씬 그래프의 탐색 및 렌더링 방식을 결정할 수 있으며, 이를 통해 특정 하드웨어에 맞게 렌더링 알고리즘을 최적화하거나 성능을 향상시키는 확장 기능을 활용할 수 있습니다.
• 텍스트 및 폰트 렌더링을 포함하여, 많은 기본 QML 유형에 대한 사용자 정의 씬 그래프 구현.
• 사용자 정의 애니메이션 드라이버; 애니메이션 시스템이 저수준 디스플레이 수직 갱신 주기에 연동되어 부드러운 렌더링을 얻을 수 있게 합니다.
• 사용자 정의 렌더 루프: QML이 여러 창을 처리하는 방식을 더 잘 제어할 수 있습니다.