QOpenGLWidget CPU usage is high when using a high refresh rate
-
wrote on 17 Aug 2022, 14:13 last edited by
I am using QOpenGLWidget to draw some animation effects. In order to make the animation look smoother, I have increased the frequency of update usage. When I set Update 18ms to refresh once, the CPU usage is only 0.4%. However, when the update 16ms is set to refresh once, the CPU usage reaches about 7.5%, and in this case, even after deleting all the code in paintGL(), the CPU usage does not decrease. What is the reason for the high CPU usage? Is there any way to do this without reducing the refresh frequency? Reduce CPU usage?
-
Hi and welcome to devnet,
It will depend on what computations you do on the CPU side that will run more frequently. Also, what else does you application do which regard to GUI ?
-
A typical monitor has a refresh rate of 60Hz, meaning it will display 60 frames a second. This also means you've got 16.66ms to draw and present each frame.
When you set a frequency of 16ms your CPU effectively presents 60 frames a second.
When you change it to 18ms you're basically late by about 1.33ms for first refresh, 2.66ms for second and so on, meaning you're missing about half the refresh points and your CPU only does half the work presenting them. Animation at that frequency will be extremely choppy not only due to lower present rate but also because frames at irregular intervals will be actually presented and the rest is lost.Here's an idea to try out. Since at 18ms half of the frames are lost anyway you might try to actually embrace it. Draw at 33ms frequency. You'll present roughly similar amount of frames as at 18, but they will have regular intervals (new present every 2 frames). Your CPU usage should go down even more and animation smoothness will be better than at 18ms. It won't be as good as at 16ms, but maybe good enough.
In any case, unless your target are only high refresh displays (144Hz or above, usually monitors targeted at gaming) you should stick to updates equal divisions of 60Hz refresh rate: 8.33ms(120FPS), 16.66ms (60FPS), 33.33ms (30FPS), 66.66ms(15FPS). Anything between those values will make animations extra choppy.
-
wrote on 17 Aug 2022, 15:54 last edited by
Thanks to the moderator for your answer, I think I have a solution
-
A typical monitor has a refresh rate of 60Hz, meaning it will display 60 frames a second. This also means you've got 16.66ms to draw and present each frame.
When you set a frequency of 16ms your CPU effectively presents 60 frames a second.
When you change it to 18ms you're basically late by about 1.33ms for first refresh, 2.66ms for second and so on, meaning you're missing about half the refresh points and your CPU only does half the work presenting them. Animation at that frequency will be extremely choppy not only due to lower present rate but also because frames at irregular intervals will be actually presented and the rest is lost.Here's an idea to try out. Since at 18ms half of the frames are lost anyway you might try to actually embrace it. Draw at 33ms frequency. You'll present roughly similar amount of frames as at 18, but they will have regular intervals (new present every 2 frames). Your CPU usage should go down even more and animation smoothness will be better than at 18ms. It won't be as good as at 16ms, but maybe good enough.
In any case, unless your target are only high refresh displays (144Hz or above, usually monitors targeted at gaming) you should stick to updates equal divisions of 60Hz refresh rate: 8.33ms(120FPS), 16.66ms (60FPS), 33.33ms (30FPS), 66.66ms(15FPS). Anything between those values will make animations extra choppy.
wrote on 17 Aug 2022, 16:05 last edited by@Chris-Kawa But I still have a question, why does 16.66MS refresh take up a lot of CPU, especially when I haven't done any drawing work, it's just a simple refresh, is there some complicated work being done at the bottom?
-
I'm in the guessing territory here, as I don't know Qt's internals exactly, but "just a simple refresh" is not as simple as you might think. Qt does some work to combine QPainter painting (which happens on the CPU) with a GPU backed surface of QOpenGLWidget and then uploads that to GPU and instructs it to be presented. The drawing you do in paintEvent is just on top of that work, but I imagine even empty paintEvent will cause composition and GPU upload happen, which is probably that bit of CPU work you see. Apart from that there's also the work OS has to do for composition of your OpenGL window onto desktop, so that might add a little.
-
I'm in the guessing territory here, as I don't know Qt's internals exactly, but "just a simple refresh" is not as simple as you might think. Qt does some work to combine QPainter painting (which happens on the CPU) with a GPU backed surface of QOpenGLWidget and then uploads that to GPU and instructs it to be presented. The drawing you do in paintEvent is just on top of that work, but I imagine even empty paintEvent will cause composition and GPU upload happen, which is probably that bit of CPU work you see. Apart from that there's also the work OS has to do for composition of your OpenGL window onto desktop, so that might add a little.
wrote on 17 Aug 2022, 16:15 last edited by@Chris-Kawa Well, thank you very much to the moderator for your answer. I have benefited a lot. Now I can mark it as solved
1/7