Qt是目前最先進(jìn)、最完整的跨平臺C++開發(fā)工具。它不僅完全實現(xiàn)了一次編寫，所有平臺無差別運(yùn)行，更提供了幾乎所有開發(fā)過程中需要用到的工具。如今，Qt已被運(yùn)用于超過70個行業(yè)、數(shù)千家企業(yè)，支持?jǐn)?shù)百萬設(shè)備及應(yīng)用。

點(diǎn)擊下載Qt最新版

Qt 5.14新功能頁面提到：添加了獨(dú)立于圖形API的Scene Graph渲染引擎，這是第一個預(yù)覽版而且是一個可選功能。這使得Qt Quick應(yīng)用程序，除了OpenGL以外，還可以運(yùn)行在Vulkan、Metal或Direct3D 11上

這具體是什么意思？

Qt 6技術(shù)概覽一文中說過，Qt 6的一個主要目標(biāo)是避免在Qt的許多代碼中直接使用OpenGL，通過適當(dāng)?shù)某橄髞砑嫒莞嗟膱D形API，比如Vulkan、Metal和Direct3D。當(dāng)然，OpenGL（和OpenGL ES）仍然是一種選擇。這背后的主要動機(jī)不是提升性能，而是確保Qt Everywhere在未來仍然成立，未來可能運(yùn)行在不支持或不推薦使用OpenGL的平臺和設(shè)備上。同時，能有這樣一套先進(jìn)的、結(jié)構(gòu)簡單且清晰易懂的API還可以創(chuàng)造許多可能性，特別是對于那些需要提高性能的場景（比如，更少的API開銷實現(xiàn)更低的CPU占用率），以及在Qt Quick背后的渲染引擎和其他模塊中增加新的功能，比如最近公布的Qt Quick 3D。

此外，能夠使用平臺首選的、支持最好的圖形API來渲染用戶界面，這對于那些使用Qt來呈現(xiàn)UI，同時還用到原生API寫的2D或3D圖形的應(yīng)用程序來說是個好消息。在這種應(yīng)用中，一般Qt無法決定使用何種圖形API：例如，一個macOS上的桌面應(yīng)用程序希望使用Metal去渲染自己的3D內(nèi)容，同時依靠Qt Quick去呈現(xiàn)2D UI元素，此時如果Qt Quick也使用Metal渲染會大有好處。對于那些過去關(guān)注Qt 5.x時代圖形部分變化的人來說，這一點(diǎn)很熟悉：概念上，這和當(dāng)時Qt Quick渲染引擎引入對OpenGL core profile上下文的操作的支持一樣 —— Qt Quick本身并不需要關(guān)心這個，但是為了能夠集成使用了core profile的外部渲染代碼，Qt Quick必須顧及和它們協(xié)同的能力。所以從這個角度看，這是Qt 5的自然延續(xù)，現(xiàn)在擴(kuò)展到OpenGL之外的其他圖形API。

到這里，有兩個顯而易見問題：

• 這為什么與Qt 5.x有關(guān)？這不都是Qt 6的內(nèi)容嗎?
• 為什么不直接使用<某種圖形API>轉(zhuǎn)化為<標(biāo)準(zhǔn)API>的圖形API轉(zhuǎn)換方案呢？

那么Qt 5.14中有什么?

對Qt所有(或至少大部分)有關(guān)圖形渲染的部分進(jìn)行全面的檢查確實是Qt 6的目標(biāo)。然而，停止支持Qt 5.x，然后試圖設(shè)計、開發(fā)和重構(gòu)一切，并指望一切都能變好，并不現(xiàn)實。正如Qt開發(fā)者過去、現(xiàn)在仍會提及的，任何API剛開始迭代時都可能不是最優(yōu)的。因此，我們采用并行開發(fā)的方法，先專注于Qt中的一種特定的UI技術(shù)：Qt Quick。

Qt 5.14將發(fā)布使用全新渲染方法的Qt Quick預(yù)覽版。默認(rèn)情況下，不啟用新的渲染方法，因此對應(yīng)用程序來說不需要任何特殊的更改——會像在以往版本中一樣，內(nèi)部使用相同的直接基于OpenGL的渲染路徑。但是，那些希望嘗試新方法的人可以選擇通過設(shè)置環(huán)境變量或使用main()中的C++ API啟用新的渲染路徑。我們希望盡早得到反饋，我們好繼續(xù)迭代和演進(jìn)，而不必等到Qt 6.0的發(fā)布。

并不是所有的應(yīng)用程序都能直接使用QSG_RHI環(huán)境變量運(yùn)行。在Scene Graph節(jié)點(diǎn)中執(zhí)行OpenGL調(diào)用、或在自定義材質(zhì)中使用GLSL著色器代碼定制的QQuickItem實現(xiàn)，就不能啟用RHI渲染。這同樣適用于帶有GLSL代碼的ShaderEffect元件。其實有更好的自定義材質(zhì)和效果的辦法，但是這些需要對應(yīng)用程序進(jìn)行移植。在Qt 5.14和Qt 5.15之間我們會嘗試做一些適配，但是在Qt 6.0之前，不會進(jìn)行大范圍的推廣和移植。另一方面，許多現(xiàn)有的QML應(yīng)用程序應(yīng)該可以正常工作，即使底層渲染引擎使用完全不同的API（如Vulkan或Metal）。

為什么不采用XYZ類型的轉(zhuǎn)換層？

首先，需要說明的是，盡管不能總是實現(xiàn)開箱即用，使用API和著色器轉(zhuǎn)換層（如MoltenVK、MoltenGL、ANGLE、Zink等）的可能性仍然存在。例如，MoltenVK允許基于Vulkan在macOS上渲染Qt Quick的UI。如果Qt Quick應(yīng)用程序希望只使用Vulkan，并且仍然希望在macOS上運(yùn)行，就也可以采用MoltenVK。（只要用戶系統(tǒng)中安裝了正確配置的Qt庫，MoltenVK也已經(jīng)就緒，那就可以運(yùn)行）

把這個轉(zhuǎn)換層變成一個強(qiáng)制性的依賴，并基于此將它和Qt一起部署，情況就完全不一樣了。

• 顯然，將“Qt Everywhere ”改為“Qt Only Where External Dependencies Allow”是不切實際的。Qt面對的平臺和環(huán)境比我們想象的還要復(fù)雜得多。它只能依賴那些強(qiáng)制性安裝、可以在各種各樣環(huán)境中運(yùn)行\(zhòng)而且對于特定的需求可以輕松適配的第三方庫。（想想Integrity、QNX和定制的嵌入式Linux環(huán)境，圖形棧有bug的或正在開發(fā)中的系統(tǒng)，偶爾需要適應(yīng)專有的數(shù)據(jù)和模塊，或者有時必須與各種圖形或復(fù)雜的API進(jìn)行交互，也許是以廠商自己定制的非標(biāo)準(zhǔn)形式，也許是早已過時的API，所有這些都需要Qt渲染軟件棧中的每個層級都具備靈活性和可伸縮性）。
• 運(yùn)行時在各種著色器語言之間轉(zhuǎn)換（或者使用中間格式）不是一個好主意。Qt 6中的著色器管道設(shè)計將會專注于離線緩存能力，或者至少在應(yīng)用程序編譯時進(jìn)行預(yù)緩存。在中間插入轉(zhuǎn)換層，隱藏各種實現(xiàn)（用了什么API，用了哪種著色器語言），之前的努力就白費(fèi)了。因為我們不可能為真正底層API準(zhǔn)備或者使用字節(jié)碼。
• 之前提到的一些選項也沒用了，因為目前實際情況是：在可預(yù)見的未來，OpenGL（ES）在大多數(shù)設(shè)備上仍舊是工作主力。因此如果繼續(xù)堅持只使用一種API，那么只能是OpenGL，或者一個能兼容OpenGL的轉(zhuǎn)換層（它也要在低性能設(shè)備上性能表現(xiàn)良好）。
• 有一種特殊情況，客戶自己擴(kuò)展Qt渲染引擎的功能，底層的渲染代碼往往需要使用相同的API才能完美配合。當(dāng)然如果轉(zhuǎn)換層允許訪問底層原生對象（比如Qt 5在Windows上使用ANGLE實現(xiàn)了Qt Quick 到Direct3D的轉(zhuǎn)換，它就可以擴(kuò)展EGL extensions），那這也不是一種阻礙。但是不是每次都可以成功的，而且過程中可能產(chǎn)生新的麻煩。
• 還有許可方面的問題。可以認(rèn)為Apache 2.0與GPLv2不兼容。在任何情況下，依靠純商業(yè)解決方案都是不現(xiàn)實的。
• 從經(jīng)驗來看（有些是從ANGLE來的，有些是從MoltenVK來的），使用這樣的解決方案絕不像人們最初希望的那樣簡單。在某種程度上，保持所有選項正常運(yùn)行所需要的工作可能會變得過于繁重——那么最好還是把這些精力用到對的方向：直接使用原生的API。這些API轉(zhuǎn)換方案中的某些依賴于平臺的特性也不是很理想——如果說我們需要為每個Qt的目標(biāo)平臺引入一個不同的API，這很快就會變得難以忍受。

因此，Qt沒有采用依賴低級API轉(zhuǎn)換程序的方法，而是自己定義了3D圖形的高級抽象（內(nèi)部使用，暫時不向應(yīng)用程序開放）。抽象層的后端有許多針對特定API的實現(xiàn)，這和許多Qt組件的模式差不多。有些后端和操作系統(tǒng)平臺是固定搭配（Metal，D3D），而其他后端可以對應(yīng)多個平臺（Vulkan，OpenGL）。有一個新開發(fā)的著色器管理單元來實現(xiàn)不同后臺的切換，它用到了一些第三方庫，比如glslang和SPIRV-Cross。更多細(xì)節(jié)將在之后的博文中詳述?，F(xiàn)在，讓我們的視線轉(zhuǎn)向稍高層面，看看它會給Qt 5.14中的Qt Quick帶來什么。

真的會有效嗎？

讓我們來看一個例子，即QUIt Coding著名的Qt5 Cinematic Experience演示程序。我們使用的是稍作修改的版本，其中少數(shù)Shader Effect Item被更新為同時可以使用兩種Qt Quick Scene Graph渲染路徑的格式。該版本可在這里找到。

正常啟動應(yīng)用程序，設(shè)置QSG_INFO=1，得到：

就像在調(diào)試輸出中打印的日志一樣，這是在Linux桌面的OpenGL上運(yùn)行的：

qt.scenegraph.general: threaded render loop
qt.scenegraph.general: Using sg animation driver
qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms
qt.scenegraph.general: opengl texture atlas dimensions: 2048x1024
qt.scenegraph.general: GL_VENDOR: X.Org
qt.scenegraph.general: GL_RENDERER: AMD Radeon (TM) R9 M360 (VERDE, DRM 3.23.0, 4.15.0-62-generic, LLVM 8.0.1)
qt.scenegraph.general: GL_VERSION: 4.5 (Compatibility Profile) Mesa 19.2.0-devel (git-08f1cef 2019-07-25 bionic-oibaf-ppa)
qt.scenegraph.general: GL_EXTENSIONS: ...
qt.scenegraph.general: Max Texture Size: 16384
qt.scenegraph.general: Debug context: false

如果我們設(shè)置QSG_RHI=1，會發(fā)生什么變化?

qt.scenegraph.general: Using QRhi with backend OpenGL
  graphics API debug/validation layers: 0
  QRhi profiling and debug markers: 0
qt.scenegraph.general: threaded render loop
qt.scenegraph.general: Using sg animation driver
qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms
qt.rhi.general: Created OpenGL context QSurfaceFormat(version 4.5, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile)
qt.rhi.general: OpenGL VENDOR: X.Org RENDERER: AMD Radeon (TM) R9 M360 (VERDE, DRM 3.23.0, 4.15.0-62-generic, LLVM 8.0.1) VERSION: 4.5 (Compatibility Profile) Mesa 19.2.0-devel (git-08f1cef 2019-07-25 bionic-oibaf-ppa)
qt.scenegraph.general: MSAA sample count for the swapchain is 1. Alpha channel requested = no.
qt.scenegraph.general: rhi texture atlas dimensions: 2048x1024

乍一看差別不大。它似乎還在使用OpenGL。然而，內(nèi)部沒有直接使用OpenGL，也沒有Qt Quick Scene Graph中各處穿插的GLSL著色器源碼。相反，會使用QRhi（即QtGui模塊中的一個私有API，全稱為Qt Rendering Hardware Interface）進(jìn)行渲染。

讓我們把它變得更有趣一點(diǎn)。設(shè)置QSG_RHI_BACKEND=vulkan：

qt.scenegraph.general: Using QRhi with backend Vulkan
  graphics API debug/validation layers: 0
  QRhi profiling and debug markers: 0
qt.scenegraph.general: threaded render loop
qt.scenegraph.general: Using sg animation driver
qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms
WARNING: radv is not a conformant vulkan implementation, testing use only.
qt.rhi.general: Physical device 0: 'AMD RADV CAPE VERDE (LLVM 8.0.1)' 19.1.99
qt.rhi.general:   using this physical device
qt.rhi.general: queue family 0: flags=0xf count=1
qt.rhi.general: queue family 1: flags=0xe count=2
qt.rhi.general: 55 device extensions available
qt.scenegraph.general: MSAA sample count for the swapchain is 1. Alpha channel requested = no.
qt.scenegraph.general: rhi texture atlas dimensions: 2048x1024
qt.rhi.general: Creating new swapchain of 3 buffers, size 1280x720, presentation mode 2

處理的很好。顯然它現(xiàn)在正在通過Vulkan渲染。甚至更奇異的Qt Quick特性，如distance field text渲染、著色器效果和粒子效果都如預(yù)期的那樣存在。

在RenderDoc中運(yùn)行應(yīng)用程序并捕獲幀，結(jié)果如下所示。Qt Quick確實正在構(gòu)建Vulkan管道狀態(tài)對象和命令緩沖區(qū)，著色器代碼以SPIR-V字節(jié)碼格式提供。

就這些了。在本系列的第二篇博文中，我們將研究Qt 5.14為macOS和Windows提供了什么。在那之后，我們將繼續(xù)研究所有這些是如何在底層工作的，以及對需要自定義材質(zhì)和特效的應(yīng)用程序有什么影響。

想要購買Qt正版授權(quán)的朋友可以點(diǎn)擊""哦~~~