running multiple QVulkanWindows and QVulkanWindowRenderers in a QSplitter in parallel
-
wrote on 28 May 2024, 19:39 last edited by
Basically, I have a multi camera stream (for instance, say 3 cameras that generate a stream of 3 synchronized images, sort of like a stereo camera) that I want to display in a
QSplitter. I have it setup such that there are threeQVulkanWindows which have an overwrittenQVulkanWindowRenderer. The intent is to display the image stream for now and at some point render things on the images as well.My issue is I noticed the
overridedstartNextFrame()method (which essentially just copies the image buffer to a vulkan image and creates/populates the command buffer) runs serially for eachQVulkanWindowRenderer. So if I put astd::this_thread::sleep_for(std::chrono::milliseconds(1000));instartNextFrame()it will basically cause a three second delay in rendering a frame in each window, but they can pretty much be done in parallel without a lot of issue.So my questions are:
- Is this the right approach to do this sort of thing?
- Is there an easy way to make startNextFrame() for each QVulkanWindow run in parallel? Or should I focus on just trying to minimize the time spent in
startNextFrame()?
-
Basically, I have a multi camera stream (for instance, say 3 cameras that generate a stream of 3 synchronized images, sort of like a stereo camera) that I want to display in a
QSplitter. I have it setup such that there are threeQVulkanWindows which have an overwrittenQVulkanWindowRenderer. The intent is to display the image stream for now and at some point render things on the images as well.My issue is I noticed the
overridedstartNextFrame()method (which essentially just copies the image buffer to a vulkan image and creates/populates the command buffer) runs serially for eachQVulkanWindowRenderer. So if I put astd::this_thread::sleep_for(std::chrono::milliseconds(1000));instartNextFrame()it will basically cause a three second delay in rendering a frame in each window, but they can pretty much be done in parallel without a lot of issue.So my questions are:
- Is this the right approach to do this sort of thing?
- Is there an easy way to make startNextFrame() for each QVulkanWindow run in parallel? Or should I focus on just trying to minimize the time spent in
startNextFrame()?
@blaberj said in running multiple QVulkanWindows and QVulkanWindowRenderers in a QSplitter in parallel:
std::this_thread::sleep_for(std::chrono::milliseconds(1000))
Why do you need this?
If you want to do something after curtain time interval use QTimer. -
@blaberj said in running multiple QVulkanWindows and QVulkanWindowRenderers in a QSplitter in parallel:
std::this_thread::sleep_for(std::chrono::milliseconds(1000))
Why do you need this?
If you want to do something after curtain time interval use QTimer.wrote on 29 May 2024, 11:41 last edited by blaberj@jsulm the sleep call was just to simulate work. Was just messing around to see what would happen. My primary concern is if theres an operation in there that takes some time it will end up taking 3x longer since there are 3 vulkan windows and the update is done in serial rather than parallel.
But before I go off trying to prematurely optimize was wondering if the approach I'm taking is even the right way to go about things.
It does seem to work for the toy example I'm using (just loading an image from disk to display) but that image load operation takes 10ms, and since its done 3 times it ends up taking 30ms per update which will actually start impacting framerates and kind of
concerns me. In reality the app will use a camera stream which will be faster with a set framerate so might not be as big of an issue though.Another thing too is most examples I've seen have just used a single QVulkanWindow, but for my case it seems like using multiple would make things much easier since each window has its own independently managed swap chain and I'd be able to use a QSplitter to make one window larger than the other.
3/3