vsg::Window event invalid when limited frame rate

[Brucewu998]

vsg::Window event will invalid when limited the frame rate in render loop, such as key ("ESC" close) or button(close button) event. The code like:

void renderLoop() {
  auto start = vsg::clock::now();
    while (continuousUpdate_) {
      auto interval =
          std::chrono::duration<float, std::chrono::milliseconds::period>(
              vsg::clock::now() - start)
              .count();
      if (interval > interval_ && viewer_->advanceToNextFrame()) {
        std::cout << "Frame Rate: " << 1000.0 / interval << " fps" << std::endl;
        viewer_->handleEvents();
        viewer_->update();
        viewer_->recordAndSubmit();
        viewer_->present();
        start = vsg::clock::now();
      }
    }
}

Anyone idea?

[robertosfield]

Your code is very awkward, and you explanation of what might be not working correctly leaves more questions.

Could you take a step back and tell us what you are trying to achieve, then we can suggest ways of implementing what you need.

[Brucewu998]

lol, I want to control the rendering frame rate to around 20hz in my program.
When I use the above code to implement it, the window cannot be closed normally.

[robertosfield]

Spinlocks are really not something you want in your code except for exceptional circumstances. The simplest way, and most power efficient, would be to add a sleep to the main loop:

while(viewer->advanceToNextFrame())
{
        viewer->handleEvents();
        viewer->update();
        viewer->recordAndSubmit();
        viewer->present();

        // just add a sleep 
        std::this_thread::sleep_for(std::chrono::milliseconds(40));
}

If you want to be more sophisticated you could measure how long you have left in the frame after doing all the viewer calls then sleep for the rest of the frame time you have left. You can be conservative with the sleep as vsync will cause the frame to sleep to a frame boundary.

[Brucewu998]

It work for me after add a sleep to the main loop.
The second method you provided seems to be a more precise frame control method, but it is more complex. I will try it in my program when necessary.
thx @robertosfield .