OpenGLWindow vertical refresh rate of LCD
-
https://doc.qt.io/qt-5/qopenglwindow.html contains this snippet:
"...in the modern OpenGL world it is a much better choice to rely on synchronization to the vertical refresh rate of the display." I cannot seem to find the "vertical refresh rate" of my LCD display. Is that the same as the 5ms response time? -
Response time is the lag i.e. the time it takes for a signal that reaches the monitor to be physically visible. Refresh rate is how many frames can your monitor display per second (known as FPS in games). Those are not the same thing.
The vast majority of usual consumer grade LCDs have a refresh rate of 60Hz, with some high end models, usually marketed for gaming, going up to 120, 144 or in rare cases over 200. Depending on your operating system you can usually find your current value in the display settings panel. Standalone displays also usually have an info section in their built in menu that shows current resolution and refresh rate.
-
Response time is the lag i.e. the time it takes for a signal that reaches the monitor to be physically visible. Refresh rate is how many frames can your monitor display per second (known as FPS in games). Those are not the same thing.
The vast majority of usual consumer grade LCDs have a refresh rate of 60Hz, with some high end models, usually marketed for gaming, going up to 120, 144 or in rare cases over 200. Depending on your operating system you can usually find your current value in the display settings panel. Standalone displays also usually have an info section in their built in menu that shows current resolution and refresh rate.
@Chris-Kawa Thank you for your courteous reply. The monitor is 1920x1080@60Hz, but do I need to synchronize to some signal? I only ran across QOpenGLWindow because the QVulkanWindow doc suggests it is like OpenGL. I suspect "vertical sync" is a vestige of cathode ray monitors. If I just send frames to the display at, say, 30fps, will it take care of synchronization? Do I need to wait for some signal to fire before tossing a frame at the monitor?
-
@Chris-Kawa Thank you for your courteous reply. The monitor is 1920x1080@60Hz, but do I need to synchronize to some signal? I only ran across QOpenGLWindow because the QVulkanWindow doc suggests it is like OpenGL. I suspect "vertical sync" is a vestige of cathode ray monitors. If I just send frames to the display at, say, 30fps, will it take care of synchronization? Do I need to wait for some signal to fire before tossing a frame at the monitor?
I think I found the answer to my question. The kernel driver takes care of buffer flips, the vertical scanout, vblank and all. I just have to worry about queueing frames faster than the eye can detect and let the kernel module do the busy work. Thank you for your help!
-
Do I need to wait for some signal to fire before tossing a frame at the monitor?
I talked about how it works some time ago here. It was about QPainter, but it's similar with OpenGL or Vulkan. As for synchronization, depending on your OS, graphics card and driver this can be controlled or set up at many different points. There's bunch of knobs and switches in the OS, driver and in your app through Qt or directly in OpenGL that you can play with. In the simplest case you just draw to the back buffer and OS takes care of a synced flip of the back buffer at your monitor's rate.
With QOpenGLWindow this behavior is the default. See the documentation for setSwapInterval() and the paragraph about swapping buffers in QOpenGLWindow Detailed Description.
I just have to worry about queueing frames faster than the eye can detect and let the kernel module do the busy work.
Well no, that's not entirely true. For smoothest experience you should try to produce frames at the rate of your monitor. Not slower but also not faster. It's not immediately obvious but producing more frames than the display can actually display is not just wastful but, more importantly, produces jaggy result. I touched on this a bit with example here. That post is a bit dated and there are some pretty cool new techniques to get the smoothest results, but I think it gives a bit of a baseline on what to do or not do.
