QOpenGLWidget, high CPU usage from update()

Oen44

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() from paintGL() 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.
screenshot
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 that update().

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);

SGaist

Hi,

Out of curiosity, why reproduce a widget like interface in OpenGL ?

Why not use standard widgets ?
Maybe QtQuick depending on your application goal.

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/OTUIEditor

What do you think should I change to then?

SGaist

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.

Oen44

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.

kshegunov

Why would you call update in paintGL to begin with?

Oen44

@kshegunov Where should I call it then? Tried paintEvent already but that didn't help. Even QTimer inside constructor or initializeGL didn't change anything, well, setting timer to 1000 helps but I need at least 30FPS.

kshegunov

@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

@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.

Christian Ehrlicher

Calling update() explicitly somewhere is not needed in a normal use case. Don't do it.

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);