aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickrendertarget.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Set explicit default security level of all files with default securityJan Arve Sæther2025-09-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The files (folders) already processed are listed in each issue in epic QTBUG-134547 These files were processed half a year ago. In order to make it clear that all of these files are already processed, mark them with an explicit default security header. For the record, this was generated with this script: find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py in the folders listed in each subtask of QTBUG-134547 (add-cra-header.py only exist at my desktop, but it simply adds the default security header if it doesn't already have any existing security header) QUIP: 23 Fixes: QTBUG-134547 Pick-to: 6.10 6.9 6.8 Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* QQuickRenderTarget: pass QSize by value in the new named c-torsIvan Solovev2024-07-191-5/+5
| | | | | | | | | | | Amends b8f5a7848b019be68f0d0fba30fd82b4777a35e5. Found in Qt 6.8 API review. Pick-to: 6.8 Change-Id: Ib4edfce27c4aaa1a64195301d456e5701aaa538a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickRt: Support picking a D24S8 alternative also on the multiview pathLaszlo Agocs2024-06-281-1/+6
| | | | | | | | | | | | | The ideal alternative is 32-bit depth + 8 bit stencil (+24 bit unused) (a 64-bit format), but that has no equivalent in Qt 6.8. From 6.9 on we have D32FS8 in QRhiTexture::Format. Use D32F in 6.8, D32FS8 in 6.9. Won't make a difference given Quick 3D is not relying on stencil. Needs a dedicated patch for 6.8. Change-Id: I6c7625cce459b74ef6742b8c72b97ddaa9a17260 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: fix warnings and spelling in RhiItem and RenderTargetVolker Hilsheimer2024-06-151-1/+1
| | | | | | | | | | RhiItem::autoRenderTarget is not a property (the accessor functions are protected), so link to the getter explicitly when referring to the different behaviors that depend on it. Pick-to: 6.8 Change-Id: I792399b4361993a3b2e7b6990c0c3de1cb3d311c Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
* Use the correct format for custom depth texturesPaul Olav Tvete2024-06-111-1/+2
| | | | | | | | | | The user-supplied depth texture has a format that is known to be supported. We need to use the same format for the intermediate depth-stencil buffer we create when multi-sampling is used. Pick-to: 6.8 Change-Id: If8c68da14d305c32bde966b7bb4fb85c1a4e0cab Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add a way to set a custom depth texture on a QQuickRenderTargetLaszlo Agocs2024-04-051-8/+259
| | | | | | | Task-number: QTBUG-122292 Change-Id: I54efb4a8ca84b2f191169509bafadd78b2948ee7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QQuickRt: State the depthTexture is not to be written out when multiviewLaszlo Agocs2024-03-261-1/+2
| | | | | Change-Id: I6ce90480a372bd2bed4aa3a13df37b83234899d1 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Use new Qt configure feature for MetalTor Arne Vestbø2024-03-251-1/+1
| | | | | Change-Id: I603018d3f4c6a49c39f7daed25101c24edbbfc02 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* sg: QQuickRt: Fix enum class usage in Metal code pathLaszlo Agocs2024-03-151-3/+3
| | | | | | | And fix a doc argument tag. Change-Id: I3e4184f2af953dccd3101aacfbf26831b2f4cbb2 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QQuickRt: allow specifying a viewFormat where applicableLaszlo Agocs2024-03-151-584/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the fromXxxx static constructors now get a third (elsewhere, second) overload. This has all the Qt 6.8 new functionality merged into one to prevent the explosion of these functions. (arraySize for multiview, flags for multisample-resolve (and other future uses), and a viewFormat in addition to format) Also order everything in the logical way: first the Qt 6.0 era versions (that do not have a format argument), then the Qt 6.4 overloads with format, then the Qt 6.8 overload with the full set of features. With OpenGL we do not and will not do texture views. Hence no viewFormat argument. However, there is a version requirement: OpenGL ES 3.0 (or 2.0) is not sufficient for some of the new features. Given the main customer for these is Quick 3D XR with devices like the Quest 3 with OpenGL ES 3.2, this should not be a problem in practice. D3D11 has no multiview support, hence no arraySize argument. Also no viewFormat argument since casting is limited with D3D11 (would need typeless formats, which we do not do). The sRGB problem is still solvable by passing in a modified format (stripping _SRGB). The same goes for OpenGL, just adjust the format. D3D12 and Vulkan have full support for everything, although viewFormat requires Windows 1703 or newer to be functional. This should be fine nowadays. The Metal version also has all the arguments, even though viewFormat may be ignored for the time being, until support is implemented in the QRhi backend. Task-number: QTBUG-122288 Task-number: QTBUG-122614 Change-Id: Ia760ce785b72378aba26695db2a4d57e10eaac90 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Optimize QQuickRt behavior with implicitly created buffersLaszlo Agocs2024-02-221-53/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Creating a new depth-stencil, or with the new auto-resolving variants, a multisample color buffer on every setRenderTarget() is not ideal. (e.g. Quick 3D XR at the moment uses the convenient fromVulkanImage(), fromOpenGLTexture(), etc. constructors and then setRenderTarget(), on every frame (multiview) - or per eye per frame (non-multiview) - passing in the XrSwapchain-provided native image) As QQuickRenderTarget is merely a value class referencing some resources plus contains metadata, attempting to keep around QQuickRenderTarget instances on the user side is not effective; from the renderer's point of view every call to setRenderTarget() is effectively a full change, even though we might have used that QQuickRenderTarget before. At minimum, we should try keeping the already existing depth-stencil, multisample, and other implicit (auto-created) buffers if they are suitable for the new QQuickRenderTarget. (suitable = size matches, format matches, other relevant properties match) This is implemented in this patch. That is then suitable to speed up the vast majority of common cases, and will avoid creating new implicit buffers on every frame with Quick 3D XR for example. Those who want to continuously render with a different size is not helped by this, but it is not clear if there is such a use case in practice to begin with. Introducing pools and caches and such are not reasonable here, since keeping all sorts of depth-stencil buffers with various sizes around causes more problems than it solves. (who trims it, how much it can grow, etc.) Power users should anyway resort to managing their own QRhiRenderTarget objects and passing that in via fromRhiRenderTarget(). (this is something to be considered for Quick 3D XR as well later on; when using the API-specific QQuickRt constructors the QRhiTextureRenderTarget is still going to be remade after every setRenderTarget(), which is also not entirely ideal, although the details depend on the underlying 3D API as well) Change-Id: I5754a4809038e9688cbd5618324383886cea7010 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QQuickRt: support resolving into the provided native textureLaszlo Agocs2024-02-221-31/+541
| | | | | | | | | | | | | | | | | | | | | | | | | | | One might naively think multisample rendering in XR can be achieved in a portable manner by setting XrSwapchainCreateInfo::sampleCount to > 1, and then rendering with a multisample-enabled pipelines into the multisample textures (or multisample texture array, if multiview) that the XrSwapchain hands out. In practice this works with 1 out of 5 OpenXR platforms tested, the rest just claims the maxSampleCount is 1. Therefore, to implement MSAA in Quick 3D XR, we need to follow the classic approach of rendering into an intermediate multisample texture/renderbuffer and then setup resolving into the OpenXR-provided non-multisample texture at the end of the render pass. To facilitate this and to reduce a huge duplication of logic, add the appropriate functions to QQuickRenderTarget, and build in the support for setting up a color attachment (and an intermediate color buffer). Also fix some doc typos and incorrect overload tags. Change-Id: I5911c49b6a11d423f22a7cc8401a17b3d0310615 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* sg: Allow adopting foreign textures with GL_SRGB8_ALPHA8Laszlo Agocs2024-02-051-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do what the other (Vulkan, D3D) paths do: set the appropriate QRhiTexture flag while mapping to RGBA8. This has no visible effect, but it avoids flooding the debug output with warnings in Quick 3D XR applications on Android (Quest 3) when using OpenGL ES. (because it hits the 'default' case that prints a warning and continues with UnknownFormat; not having the correct enum value in QRhiTexture has no effect in typical Qt Quick / 3D apps, but nonetheless we should not hit that path) The usage of sRGB formats is an interesting case with VR compositors: with Vulkan and D3D12 we explicitly drop the _SRGB format in Quick 3D XR (e.g. we change VK_FORMAT_R8G8B8A8_SRGB to VK_FORMAT_R8G8B8A8_UNORM) before passing the native image object to Qt Quick, but there this is necessary since having a _SRGB format changes the behavior in shader writes (because the image/render target views inherit the QRhiTexture format in the QRhi backends), whereas Qt Quick 3D performs linearization and sRGB conversion at the end of the pipeline, so this would clash (like doing an additional unwanted linear-sRGB conversion on the already sRGB data) OpenGL is different, however, when it comes to the API: there is no implicit behavior unless the appropriate state is enabled (which we do not do), hence the OpenGL (ES) path in Quick 3D XR does not need to perform the format demotion, but then it is ideal if Qt Quick accepts those formats (which was missing until now for some reason unknown). Regardless, the demotion may still be implemented in Quick 3D XR separately later. In practice this should remove the "GL format 35907 is not supported" messages appearing in the Android logs on every frame or so with Quick 3D XR apps. Change-Id: I3e9135f790be0eda51d3b1d68f6d115eb1a21000 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Allow QQuickRt adopt a native texture array for multiview renderingLaszlo Agocs2024-01-151-0/+338
| | | | | | | | | | | | | | | | | | | | | | | Limiting multiview to fromRhiRenderTarget() is quite limiting, since in practice it often involves duplicating the convenience logic that is built into Qt Quick for fromVulkanImage() and similar. We should also support passing in a texture array object to from fromOpenGLTexture, fromVulkanImage, etc. The array size then implies the view count. We are also required to use a texture array for depth/stencil as well in this case. Add the necessary plumbing so that clients, such as an OpenXR integration, can continue to use fromXxxxx(), just the *MultiView variants, instead of forcing them to create a QRhiTextureRenderTarget themselves upfront. Task-number: QTBUG-119850 Task-number: QTBUG-114871 Change-Id: I79978e5ff5f154c8914afbe2478d002291219aaf Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* scenegraph: Add plumbing for enabling multiviewLaszlo Agocs2024-01-151-0/+31
| | | | | | | | | This will be used in RenderMode3D only in practice, where Qt Quick 3D is going to pass in multiple matrices to the QSGRenderer. Task-number: QTBUG-114871 Change-Id: Icae7f05958729d9e51948e1f38621ec4a541192d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix some copy constructor signaturesGiuseppe D'Angelo2023-10-261-7/+7
| | | | | | | | | | | These constructors weren't copy constructors. The implicitly-generated ones copied the atomic refcount without resetting it to 1, causing memory leaks. Pick-to: 6.6 6.5 Change-Id: I9fd8f4b7f9012e21128f5afd3986dfcdb517afb7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Adapt to the RHI API conceptLaszlo Agocs2023-05-221-4/+17
| | | | | | | | | | | | | | | Besides following the header naming changes, make the obvious API changes that are based on data that is already there but was hidden previously due to not wanting anything QRhi to shine through in the public API. This kind of hiding is no longer needed, even if qrhi.h and similar still cannot be included from a public header. Forward declarations are now perfectly fine however. Task-number: QTBUG-113331 Change-Id: I9a114082cf9218edc487df50956f5793d6b8bdb4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Enable D3D12Laszlo Agocs2023-02-141-3/+63
| | | | | | | | | | Windows continues to use D3D11 as the default. To use D3D12 it needs to be requested explicitly, for the time being, either via QSG_RHI_BACKEND=d3d12 or via the QSGRendererInterface enum. Change-Id: I6c63390e2548bc01a6a15b914d56afd644a1e41a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Replace usages of Q_CLANG_QDOC with Q_QDOCLuca Di Sera2022-10-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | To allow the user to customize the C++ code that QDoc sees, so as to be able to work-around some limitations on QDoc itself, QDoc defines two symbols: Q_QDOC and Q_CLANG_QDOC, both of which are "true" during an entire execution of QDoc. At a certain point in time, QDoc allowed the user the choice between a custom C++ parser and a Clang based one. The Q_QDOC symbol would always be defined while the Q_CLANG_QDOC symbol would be defined only when the Clang based parser was chosen. In more recent times, QDoc always uses a Clang based parser, such that both Q_CLANG_QDOC and Q_QDOC are always defined, making them equivalent. To avoid using different symbols, and the possible confusion and fragmentation that derives from it, all usages of Q_CLANG_QDOC are now replaced by the equivalent usages of Q_QDOC. Change-Id: I25a2fe3b870281b336d5eca1f887940a7961dc31 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* doc: Add missing since 6.4 tag to QQRT::fromPaintDeviceLaszlo Agocs2022-09-031-0/+2
| | | | | | | | Amends 43f705c3c01a7b78b94ea1db655c715ab2a54939 Pick-to: 6.4 Change-Id: I9439ac9c3b45e5bd501c40ff4b7efcd18fdec01d Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* sg: Prevent not supported format warnings when wrapping external texturesLaszlo Agocs2022-08-031-2/+2
| | | | | | | | | | | | | | | Amends 1df2cf6bad7207f16ddca17344cc1324e50f287e Clearly the intention is to continue using RGBA8 as the default when nothing is specified, but then the unknown/invalid value is not handled correctly in the conversion functions. As a result, when running f.ex. tst_qquickrendercontrol one gets warnings such as "VkFormat 0 is not supported". This is now avoided. Pick-to: 6.4 Change-Id: I0dd2cda3fefe24a1bdac075892df5a6eb8796181 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-111-38/+2
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Clean up overload docs in QQuickRenderTargetLaszlo Agocs2022-06-011-24/+92
| | | | | | | | Amends 1df2cf6bad7207f16ddca17344cc1324e50f287e Change-Id: Ica7142c5efa29f222a828bd672d60503f54f3822 Reviewed-by: JiDe Zhang <zhangjide@uniontech.com> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Allow specifies the native texture format on QQuickRenderTargetJiDe Zhang2022-05-311-13/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some overloaded function. If you need to use VkImage correctly, Must know the format it corresponds to the VkImage. In the QQuickRenderTarget, It's use the QRhi::newTexture get a QRhiTexture object, and use the QRhiTexture::createFrom to create texture use VkImage and VkImageLayout, on default, it's presume the texture format is QRhiTexture::RGBA8, but the VkImage is source from user, its format is indeterminate, so we should allow to specifies the format of VkImage from user. [ChangeLog][QtQuick] Added an overload for QQuickRenderTarget::fromOpenGLTexture to allow specifying the format of the OpenGL texture. [ChangeLog][QtQuick] Added an overload for QQuickRenderTarget::fromD3D11Texture to allow specifying the format of the D3D11 texture. [ChangeLog][QtQuick] Added an overload for QQuickRenderTarget::fromMetalTexture to allow specifying the format of the Metal texture. [ChangeLog][QtQuick] Added an overload for QQuickRenderTarget::fromVulkanImage to allow specifying the format of the Vulkan texture. Fixes: QTBUG-103216 Change-Id: I3b90be9bbd37439f906351782cf08c060d98cded Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add setMirrorVertically for QQuickRenderTargetJiDe Zhang2022-05-031-2/+39
| | | | | | | | | | | | Allow control the matrix transform of a render target in the QQuickWindowPrivate::renderSceneGraph. [ChangeLog][QtQuick][QQuickRenderTarget] Added QQuickRenderTarget::setMirrorVertically, Allowed to control the mirror vertically of render target. Task-number: QTBUG-102317 Change-Id: Ifc9aac77f28200594297ea15d07f41a864130f58 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Update QQuickRenderTarget docsLaszlo Agocs2022-04-211-4/+24
| | | | | Change-Id: Id8393ab4e9fcd2a3e4ffbb61988bb2a852e8e3ee Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Support to custom the render target on the software rendererJiDe Zhang2022-04-191-0/+32
| | | | | | | | | | | | | | Add QQuickRenderTarget::fromPaintDevice, aollow to get a QQuickRendererTarget from the QPaintDevice object. [ChangeLog][QtQuick] Added QQuickRenderTarget::fromPaintDevice, Allowed to set the render target of QQuickWindow on the software renderer. Task-number: QTBUG-94075 Change-Id: I4946c25d2a6315cd8f9c12a7ac7ac4cf71d95361 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add device pixel ratio property to QQuickRenderTargetVlad Zahorodnii2021-08-111-0/+38
| | | | | | | | | | | | | | | | | | Currently, in order to render a QtQuick scene in a HiDPI offscreen texture without a render window, one need to fight Qt, for example by returning a dummy window in QQuickRenderControl::renderWindowFor(). This change adds a device pixel ratio property to QQuickRenderTarget, which can be used by the QQuickWindow to calculate the logical size of the offscreen texture. The main motivation behind this change is to allow KWin to render some internal QtQuick scenes at HiDPI. Since kwin is the compositor, it does not have any windows that can be returned from the renderWindowFor() function. Change-Id: Iefa7046385e750e15ca0e53b398b51a8e0aabad2 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Allow targeting a (GL) renderbuffer object with the QQuickWindowLaszlo Agocs2021-05-211-23/+100
| | | | | | | | | | | | Relevant for OpenGL only. As an added bonus this cleans up the code path for wrapping an existing native texture as well, with better error handling and proper cleanup of resources when bailing out due to something failing. Fixes: QTBUG-92116 Change-Id: I3e83b9d69d2fdf115e8f32cc5b0d5b92a241d41f Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Purge renderpass refs from renderer when redirecting via QRhiRtLaszlo Agocs2020-11-241-0/+1
| | | | | | | | Pick-to: 6.0 Fixes: QTBUG-88761 Change-Id: Ia5df65a4a09a7554a7d0cca4533f766cb5abe97b Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Hide QQuickRenderTarget equality operators from ADLVolker Hilsheimer2020-10-311-20/+20
| | | | | | | | Also replace Q_DECL_NOTHROW with noexcept. Task-number: QTBUG-87973 Change-Id: I1471d65076ece5ab6d5efdf0e50b02751789d32b Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Follow QQuickGraphicsDevice changes in QQuickRenderTargetLaszlo Agocs2020-06-261-13/+136
| | | | | | | | | They are not strictly related of course, but the API pattern should be kept. We can also move away from the QSGTexture dependency which is good since that was never directly related. Change-Id: I9aedff5918443bda3d6e3ee1ea389071222d1ad7 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Follow QRhi create-destroy API updateLaszlo Agocs2020-06-021-3/+3
| | | | | Change-Id: I0bc2cbce373febcb9073f15067eebbc1723462ba Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Allow redirecting QRhi-based rendering via QQuickRenderControlLaszlo Agocs2020-04-111-0/+293
Implement the Qt 6 TODO for using an externally-provided render target when rendering the scene via QRhi. And say hello to QQuickRenderTarget. This class exists to allow potentially extending later what a "render target" consists of. Instead of hard-coding taking a single void * in the setRenderTarget() function, it takes a (implicitly shared, d-pointered) QQuickRenderTarget, which in turn can be created via static factory functions - of which new ones can be added later on. The new version of QQuickWindow::setRenderTarget() takes a QQuickRenderTarget. QQuickRenderControl gets a new initialize() variant, and a few extra functions (beginFrame(), endFrame()). This allows it to, by using QSGRhiSupport internally, create a QRhi under the hood. As a bonus, this also fixes an existing scenegraph resource leak when destroying the QQuickRenderControl. The qquickrendercontrol autotest is extended, with a QRhi-based test case that is executed for all of the QRhi backends that succeed to initialize. This is the internal verification. In addition, there is a Vulkan-based one that creates its own VkDevice, VkImage, and friends, and then uses Qt Quick with the same Vulkan device, targeting the VkImage. This test verifies the typical application use case. (sadly, life is too short to waste it on writing Vulkan boilerplate for an on-screen version of this, but we have the D3D11 example instead) What QQuickRenderControl loses, when used in combination with QRhi, is the grab() function. This never made much sense as a public API: QQuickWindow::grabWindow() call this when the window is associated with a rendercontrol, so as a public API QQuickRenderControl::grab() is redundant, because one gets the same result via the standard QQuickWindow API. It is now made private. More importantly, reading back the content is no longer supported, unless the 'software' backend is in use. The reasoning here is that, if the client of the API manages and provides the render target (as abstracted by QQuickRenderTarget), it is then expected to be capable of reading back the content in whatever way it sees fit, because it owns and manages the resource (e.g. the texture) in the first place. Providing fragile convenience functions for this is not reasonable anymore, and was questionable even with OpenGL, given that it is not future proof - what if the target is suddenly a floating point texture, for instance? The software backend case makes sense because that relies on private APIs - and has no render target concept either - so there the same cannot be achieved by applications by relying on public APIs only. Another new class is QQuickGraphicsDevice. This is very similar to QQuickRenderTarget, it is a simple container capable of holding a set of of native objects, mostly in the form of void*s, with future extensibility thanks to the static factory functions. (examples of native object sets would be a ID3D11Device + ID3D11DeviceContext, or a QOpenGLContext, or a MTLDevice + MTLCommandQueue, or a number of Vulkan device-related objects, etc.) This allows one to specify that the QRhi created under the hood (either by QQuickRenderControl or by the render loop) should use an existing graphics device (i.e. it is basically a public wrapper for values that go into a QRhi*InitParams under the hood). QQuickRenderTarget and QQuickGraphicsDevice are both demonstrated in a new example: rendercontrol_d3d11. We choose D3D11 because it is reasonably simple to set up a renderer with a window, and, because there is known user demand for Qt Quick - external D3D engine interop. Passing in the custom engine's own ID3D11Device and ID3D11DeviceContext is essential: the texture (ID3D11Texture2D) Qt Quick is targeting would not be usable if Qt Quick's QRhi was using a different ID3D11Device. Task-number: QTBUG-78595 Change-Id: I5dfe7f6cf1540daffc2f11136be114a08e87202b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-23 16:31:01 +0000