aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/scenegraph/adaptations/software
diff options
context:
space:
mode:
authorLaszlo Agocs <[email protected]>2024-02-22 10:28:49 +0100
committerLaszlo Agocs <[email protected]>2024-02-22 17:10:23 +0100
commita15c3519209d4b2a4aae3a7621a1af6291b074ff (patch)
treebd1f96735d028c8e900e3d0d6cd6009a90d0256f /src/quick/scenegraph/adaptations/software
parent448a6ffe265915a3bcaa681aa3c21f0073a5868f (diff)
Optimize QQuickRt behavior with implicitly created buffers
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 <[email protected]>
Diffstat (limited to 'src/quick/scenegraph/adaptations/software')
-rw-r--r--src/quick/scenegraph/adaptations/software/qsgsoftwarecontext.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/quick/scenegraph/adaptations/software/qsgsoftwarecontext.cpp b/src/quick/scenegraph/adaptations/software/qsgsoftwarecontext.cpp
index ef43aa1012..4e07508ea0 100644
--- a/src/quick/scenegraph/adaptations/software/qsgsoftwarecontext.cpp
+++ b/src/quick/scenegraph/adaptations/software/qsgsoftwarecontext.cpp
@@ -201,7 +201,7 @@ void *QSGSoftwareContext::getResource(QQuickWindow *window, Resource resource) c
if (resource == PainterResource)
return window->isSceneGraphInitialized() ? static_cast<QSGSoftwareRenderContext *>(cd->context)->m_activePainter : nullptr;
else if (resource == RedirectPaintDevice)
- return cd->redirect.rt.paintDevice;
+ return cd->redirect.rt.sw.paintDevice;
return nullptr;
}