QOpenGLWidget, high CPU usage from update()
-
wrote on 24 Jan 2020, 17:37 last edited by
I'm using QPainter to draw bunch of images on the OpenGL widget. Right now, OpenGLWidget is taking 25-30% of my CPU (Intel i5). Adding images doesn't change the CPU usage, however removing
update()
frompaintGL()
event does help and CPU usage is down to 2%.
Using QPainter to draw these images.
Here is how it looks like, that lighter gray area is OpenGL widget.
As you can see, there are 2 Buttons which use the same image. Each Button size can be changed so the image is stretching (using 9-Slice function). Maybe I should change from QPainter to pure OpenGL? Not sure as CPU usage doesn't change if there are some images or there is none at all. It's something with thatupdate()
. -
wrote on 25 Jan 2020, 11:43 last edited by Oen44
Even if I call update when mouse is pressed and moved (which doesn't create any stuttering), CPU usage still goes up. So it doesn't matter if I call it in
paintGL
or anywhere else. The only advantage is that when nothing is touched, there is only 3% usage.
I feel like I should drop that OpenGL widget and do something else to achieve same results as now.Edit
So I just reused QTimer and it worked. 2-3% CPU usage, 60FPS.
QTimer *pTimer = new QTimer(this); connect(pTimer, SIGNAL(timeout()), this, SLOT(update())); pTimer->start(1000 / 60.0);
-
Hi,
Out of curiosity, why reproduce a widget like interface in OpenGL ?
Why not use standard widgets ?
Maybe QtQuick depending on your application goal. -
Hi,
Out of curiosity, why reproduce a widget like interface in OpenGL ?
Why not use standard widgets ?
Maybe QtQuick depending on your application goal.wrote on 24 Jan 2020, 21:03 last edited by Oen44@SGaist said in QOpenGLWidget, high CPU usage from update():
Hi,
Out of curiosity, why reproduce a widget like interface in OpenGL ?
Why not use standard widgets ?
Maybe QtQuick depending on your application goal.I found that OpenGL is what I need to draw and manipulate things. That is drawing a lot of images, adding outlines, pivots to control resizing, moving images by dragging etc.
Here is the source code (and example video of how the app works) https://github.com/Oen44/OTUIEditorWhat do you think should I change to then?
-
No problem with doing stuff in OpenGL ! I was just wondering why also add all the work for clickable buttons and such stuff directly in OpenGL.
But I may have missed the end goal of your designer application.
-
No problem with doing stuff in OpenGL ! I was just wondering why also add all the work for clickable buttons and such stuff directly in OpenGL.
But I may have missed the end goal of your designer application.
wrote on 24 Jan 2020, 21:54 last edited byPositioning and resizing is why. Each button, windows and all that stuff is saved in memory (position, size etc. matters) and then based on that, OTUI code is generated.
It's just crazy how that CPU usage is so high and I would like to fix this, even if that means dropping OpenGL. -
Positioning and resizing is why. Each button, windows and all that stuff is saved in memory (position, size etc. matters) and then based on that, OTUI code is generated.
It's just crazy how that CPU usage is so high and I would like to fix this, even if that means dropping OpenGL.Why would you call update in
paintGL
to begin with? -
wrote on 24 Jan 2020, 23:03 last edited by Oen44
@kshegunov Where should I call it then? Tried
paintEvent
already but that didn't help. Even QTimer inside constructor orinitializeGL
didn't change anything, well, setting timer to 1000 helps but I need at least 30FPS. -
@kshegunov Where should I call it then? Tried
paintEvent
already but that didn't help. Even QTimer inside constructor orinitializeGL
didn't change anything, well, setting timer to 1000 helps but I need at least 30FPS.@Oen44 said in QOpenGLWidget, high CPU usage from update():
Where should I call it then?
Everywhere else, basically when something's changed. What you're doing now is flooding the event loop with paint requests - while you process one (in
paintGL
) you issue a new one.but I need at least 30FPS.
Eh, why? Is this some kind of game?
-
@Oen44 said in QOpenGLWidget, high CPU usage from update():
Where should I call it then?
Everywhere else, basically when something's changed. What you're doing now is flooding the event loop with paint requests - while you process one (in
paintGL
) you issue a new one.but I need at least 30FPS.
Eh, why? Is this some kind of game?
wrote on 25 Jan 2020, 00:04 last edited by Oen44@kshegunov said in QOpenGLWidget, high CPU usage from update():
Eh, why? Is this some kind of game?
No, but there is dragging using mouse involved. Please check this video https://www.youtube.com/watch?v=CQBn6jFqhlI
Imagine using Photoshop with 1FPS. -
Calling update() explicitly somewhere is not needed in a normal use case. Don't do it.
-
wrote on 25 Jan 2020, 11:43 last edited by Oen44
Even if I call update when mouse is pressed and moved (which doesn't create any stuttering), CPU usage still goes up. So it doesn't matter if I call it in
paintGL
or anywhere else. The only advantage is that when nothing is touched, there is only 3% usage.
I feel like I should drop that OpenGL widget and do something else to achieve same results as now.Edit
So I just reused QTimer and it worked. 2-3% CPU usage, 60FPS.
QTimer *pTimer = new QTimer(this); connect(pTimer, SIGNAL(timeout()), this, SLOT(update())); pTimer->start(1000 / 60.0);
1/11