diff options
author | Laszlo Agocs <[email protected]> | 2025-04-08 14:10:35 +0200 |
---|---|---|
committer | Laszlo Agocs <[email protected]> | 2025-05-02 23:21:45 +0000 |
commit | 30d2b91fb48c2a28188f75d3e87311a2a6aba5d8 (patch) | |
tree | 4d08f1e95fbaa054004ae30a16fbf22945d0deba /src/qml/jsruntime | |
parent | 01b315661000469ed6a95324fd7f55f630eb3621 (diff) |
Port QSGDepthStencilBuffer in a slightly changed form from Qt 5.
Two layers in the same scene can use the same single depth-stencil
buffer, instead of creating a dedicated one for each. As long as the
size and sample count is the same. The render passes are recorded
sequentially, and there is no need for the depth-stencil content once
a render pass is done.
The catch is having to deal with changing sizes, e.g. a window resize
often leads to changed sizes for the layers of the scene. We do not
want to end up cached renderbuffer objects with sizes that will
possibly never be needed again. The Qt 5 approach solves this with
reference counting and QShared/WeakPointers. Continue with that
approach.
If there is actually a depth-stencil buffer that is fully physically
backed, that is a different question. With Vulkan for instance,
on some GPU architectures we expect that the depth-stencil images will
be transient + lazily allocated + no store, so it may matter little
how many images we have. Similar things might happen in GLES
implementations on tiled GPU architectures.
However, generally it is ideal if the Qt 5 behavior is kept, so that
no confusion arises from an extra renderbuffer or two showing up when
counting and comparing resources in frame captures between Qt 5 and 6.
Fixes: QTBUG-135813
Pick-to: 6.9 6.8
Change-Id: I238dc53600f4a00e6ee2f7ccc97ac33ff189e3c5
Reviewed-by: Andy Nichols <[email protected]>
Diffstat (limited to 'src/qml/jsruntime')
0 files changed, 0 insertions, 0 deletions