diff options
author | Laszlo Agocs <[email protected]> | 2024-02-22 10:28:49 +0100 |
---|---|---|
committer | Laszlo Agocs <[email protected]> | 2024-02-22 17:10:23 +0100 |
commit | a15c3519209d4b2a4aae3a7621a1af6291b074ff (patch) | |
tree | bd1f96735d028c8e900e3d0d6cd6009a90d0256f /src/quick/scenegraph/adaptations/software | |
parent | 448a6ffe265915a3bcaa681aa3c21f0073a5868f (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.cpp | 2 |
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; } |