Postponing of the release of custom rendering resources does not respect framesInFlight.

It is said here https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/scenegraph/vulkanunderqml/vulkansquircle.cpp?h=6.6#n89:

// The safe way to release custom graphics resources is to both connect to
// sceneGraphInvalidated() and implement releaseResources(). To support
// threaded render loops the latter performs the SquircleRenderer destruction
// via scheduleRenderJob(). Note that the VulkanSquircle may be gone by the time
// the QRunnable is invoked.

But it turns out it is not a kind of a safe way, because QRunnable::run called at best at the next frame no matter which QQuickWindow::RenderStage is specified to QQuickWindow::scheduleRenderJob.

Every time subclass of QQuickItem is destroyed I get the next Vulkan Validation Layers Error:

 VUID-vkDestroyPipeline-pipeline-00765 ] Validation Error   | Objects: {} | Queues: {} | CommandBuffers: {} | MessageID = 0x6bdce5fd | Validation Error: [ VUID-vkDestroyPipeline-pipeline-00765 ] | MessageID = 0x6bdce5fd | vkDestroyPipeline():  can't be called on VkPipeline 0xa75a02000000952d[rasterization] that is currently in use by VkCommandBuffer 0x7fff9c8c4510[Qt command buffer]. The Vulkan spec states: All submitted commands that refer to pipeline must have completed execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyPipeline-pipeline-00765)

QQuickItem subclass instance is constructed as Component in Loader (and destroyed also here).

Qt API gives a current frame slot and number of frames in flight: https://github.com/qt/qtdeclarative/blob/dev/src/quick/items/qquickwindow.h#L106-L108. Implementation calls vkWaitForFences for previous frame in the same slot (submitted framesInFlight frames ago): https://github.com/qt/qtbase/blob/dev/src/gui/rhi/qrhivulkan.cpp#L1929. beforeFrameBegin signal (https://doc.qt.io/qt-6/qquickwindow.html#beforeFrameBegin) is emitted (https://github.com/search?q=repo%3Aqt%2Fqtdeclarative%20beforeFrameBegin&type=code) right before that vkWaitForFences. So slot connected to any before* or after* signals of QQuickWindows, except beforeFrameBegin, can be used in order to release resources. But this approach is suitable only for synchronous manual resource release, not for "end of component life" case.

Subclass I made is here https://github.com/tomilov/sah_kd_tree/blob/develop/src/viewer/viewer.cpp#L215. It can be created and destroyed many times per QQuickWindow lifespan.