Improve render clock
VTKInteractorStyle::CreateRepeatingTimer would call
VTKInteractorStyle::OnTimer then sleep for the period
given in ms after calling OnTimer again. This isn't
adapted for rendering at a uniform frame rate, because
the time spent within the OnTimer function is not
taken into account in the sleep time.
By using OneShotTimer, we can manipulate when to
render the next frame: in (period - time spent) ms
if the time spent in OnTimer is smaller than the period
time, or right away (period of 0 ms) if the time spent
is over the target period (late frame).
An interface is added in the VTKInteractorStyle,
wrapped in the VTKViewer, to set the target frame rate.
Also added a commit to use DATA_DIR defined in the Sandbox example to easily change the data directory for each user on their own machine. Any local change to the DATA_DIR value should not be committed in the future.
Merge request reports
Merged by
(Apr 13, 2025 1:16am UTC)
Activity
@sreekanth-arikatla @NickMilef @HongLi @trudiQ could one/two of you review this when you get a chance? This is a small change.
48 49 // Update Camera 49 auto scene = m_simManager->getCurrentScene(); 50 m_simManager->getViewer()->getCurrentRenderer()->updateSceneCamera(scene->getCamera()); 50 m_simManager->getViewer()->getCurrentRenderer()->updateSceneCamera(m_simManager->getCurrentScene()->getCamera()); 51 51 52 52 // Update render delegates 53 53 m_simManager->getViewer()->getCurrentRenderer()->updateRenderDelegates(); 54 54 55 55 // Reset camera clipping range 56 if(this->CurrentRenderer != nullptr) 57 { 58 this->CurrentRenderer->ResetCameraClippingRange(); 59 } 56 this->CurrentRenderer->ResetCameraClippingRange(); 57 58 auto t = std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now()-m_pre).count(); -
This line is to find the time since the last frame. Below are lines to find the time the rendering itself took for the current frame. Could you maybe show me how to use the Timer class for it? It felt a little like an overkill for that purpose but I might not have been doing it right.
Edited by Alexis Girault
@alexis-girault Looks good! What's the reasoning behind using a fixed framerate?
Edited by Nicholas Milef-
@NickMilef thanks. What alternative is usually used for rendering? My assumption was that we wouldn't reach the target framerate when using the vtkTimers the way they were used, so this commit helps to reach that minimum.
Usually, there are two options:
- VSync for fixed framerate (prevents screen tearing but can kick down to a really low framerate if below the refresh rate)
- Render as fast as possible (lowest latency)
The reason why I ask is this: http://gaming.stackexchange.com/questions/221423/is-there-any-reason-to-limit-my-fps
Right now, if a user needs to enable VSync (which can be enabled through Nvidia Control Panel for instance to override VTK settings) or is using VR (when VSync is enabled by default I think), then you can have double the frame latency if the framebuffer completion time doesn't align with the monitor refresh rate (and will likely diverge over time).
On second thought, maybe it's a good idea to have it in for now in case someone is using a device that runs on batter power (and they want to run less that the refresh rate, maybe to simulate a real camera). But can we have an option for no wait?
Edit: Sorry this is getting really confusing. VTK I think only uses double buffering, so I think that should limit the power consumption with VSync turned on. But if you use triple buffering, I think you can still render as fast as possible while only displaying the frames with respect to the refresh rate. There's a lot of synchronization that goes on behind the scenes. Either way, it might be best to have an optional throttle. I'll have to handle much of this synchronization in the Vulkan renderer.
Edited by Nicholas Milef-
@NickMilef : right now it is possible to have 'no wait' by setting the fps to 0, so is it good enough for now, or would you like me to investigate something else to add up in there before merging? I could make the default value be 0 instead of 60 for no wait?
-
@buildbot test
Mentioned in commit c6298aa5
