Problem is, this has potential issues down the line. For example, if one pops up a QQuickWindow afterwards, also with Vulkan, and wants to do things like enabling the debug layer (QSG_RHI_DEBUG_LAYER and similar), that will not work since the instance is already up. In absence of better solutions, drop a warning as well and keep this undocumented for now. On the plus side, this allows applications to implement things like enumerating adapters with Vulkan and then launching a QQuickWindow with the selected adapter. With other APIs (D3D) this is a breeze, but is impossible here due to the very unfortunate concept of Vulkan instances, and handles such as a VkPhysicalDevice being tied to the instance. An application has no way of knowing what VkInstance Qt Quick will create/use, unless the developer does the extra boilerplate to provide their own, which is an overkill in this case. So offer some way to make this work, even if there are some pitfalls. Pick-to: 6.9 Change-Id: I1fc11f90cd1bf3fdac945ed5a7221f596368d30e Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
…
…
Description
Languages
C++
84.3%
HTML
4.9%
C
3.9%
CMake
3.6%
Objective-C++
2%
Other
0.8%