app using "excessive" CPU

JonB

@mzimmers
Try not running your application, or switch the machine off ;-)

Given that this is running on Windows, I can't use the profiler built into Creator

Does your MSVC/MinGW compiler come with a usable profiler, nothing to do with Qt?

In your paintEvent() override @mrjj had in mind for you to try a debugger breakpoint there and look at the stack trace. You will doubtless need to perhaps put a delay/count on the breakpoint, or set it while the app is in the middle of running. I don't actually know whether paint events will show anything interesting on the stack.

You can use the top-level eventFilter() to examine most of what's going on, if you have to :( Debug every event's type to file/debug output window for a couple of seconds into your "idle". Search the output, you're probably interested in what you see just before the updating starts, or as it goes along.

mzimmers

@JonB using MinGW, and I don't think it has a profiler. I could look at 3rd party products, but it's probably easier just to have a co-worker build this on Linux, and then run the profiler. (Hopefully the problem will occur on Linux!)

Here's the stack trace you mentioned:

Maybe you can see something useful in it; I can't.

JonB

@mzimmers
An expert may have something to say about the traceback. All I know is it would be nice to know which the QWidget is. Wait, this code is yours for Widget? So which of your widgets is it? If you break more than once, is it always the same widget?

I can see QCoreApplication::sendSpontaneousEvent(). You sure you're not "wiggling"? :)

(Hopefully the problem will occur on Linux!)

Nope... ;-)

mzimmers

@JonB yes Widget is my oh-so-creative name for my main QWidget class, which is the only QWidget the app uses (unless you push one of the buttons). So yeah, it's always the same Widget.

Someone else mentioned wiggling, but I'm not sure I know what it means. The problem occurs even when the app loses focus, though.

And, if you're confident this won't happen on Linux, then maybe the problem isn't in my code space...

JonB

@mzimmers said in app using "excessive" CPU:

And, if you're confident this won't happen on Linux, then maybe the problem isn't in my code space...

Noooo, I put a wink --> ;-) <--
I absolutely do not know whether it will repro under Linux, if you're lucky it will, I just meant sod's law it won't!

mrjj

@mzimmers
Hi
That stack trace is for

starting app
2: add break point
3: let it loose focus to see the issue

and not just set at startup so we ssee the first paint when it becomes visible?
Just asking to be sure. Not seeing anything special besides maybe the sendSpontaneousEvent

mzimmers

@mrjj I'm not sure I follow you, but I modified my routine:

void Widget::paintEvent(QPaintEvent *event)
{
    static int count = 0;
    if (event->spontaneous())
    {
        //qDebug() << "spontaneous event" << count++;
    }
    else
    {
        QWidget::paintEvent(event);
    }
}

I put a breakpoint on QWidget::paintEvent...and it never, EVER hits. (Also, with this change, CPU usage remains the same.)

This just gets weirder and weirder.

fcarney

I am sorry this is such a struggle. I don't have anything more to add except a sarcastic example of wiggling:
https://media.giphy.com/media/xT9KVjBI3W2283URdm/source.mp4

mrjj

@fcarney
hehe that the sorts you want to debug with a flame thrower...

mrjj

@mzimmers

well i just asked if it was not as in first run stack trace.
but i think you are doing as i think reading your last post.

Its very odd. Indeed.
Does
//qDebug() << "spontaneous event" << count++;
trigger alow when testing then ?

mzimmers

@mrjj I just realized something -- from the docs:

bool QEvent::spontaneous() const
Returns true if the event originated outside the application (a system event); otherwise returns false.

The return value of this function is not defined for paint events.

So, I think this exercise was a waste of time.

mrjj

@mzimmers

Well i find it very odd you see many paint events for the widget (with event filter) but
its not constantly Hitting the break point in paintEvent. ??
Or did i misunderstood something ?

mzimmers

@mrjj you understand it perfectly, and "odd" is a mild term for it.

I seriously don't know what to look at here. I'm afraid that the profiler we run tomorrow won't show anything in my code space.

mrjj

@mzimmers
Do you have any timers or threads ?
Something scanning for those devices you show ?

Also, just for test. a plain normal GUI project with say a ListWidget on it does not show this
cpu usage, right?

It must somehow be related to your code ?

JonB

@mzimmers said in app using "excessive" CPU:

I'm afraid that the profiler we run tomorrow won't show anything in my code space.

Always with the negative waves https://www.youtube.com/watch?v=KuStsFW4EmQ Have a little faith, baby!

mzimmers

Well, my associate hasn't yet built the app on Linux, but I discovered the source (if not the cause) of the problem: my logo.

I have a small (201x59 pixel) PNG in the upper left of my widget. When I remove it from my .qrc file, the CPU usage disappears.

Any ideas on this one?

fcarney

@mzimmers said in app using "excessive" CPU:

my logo

Wow! That is all I can say.
🍿

mzimmers

I suspect it has something to do with this line:

painter.drawPixmap(rect(), pixmap()->scaled(size(), Qt::KeepAspectRatio, Qt::SmoothTransformation));

I don't need to scale it; what do I replace the call to scaled() with?

mrjj

@mzimmers said in app using "excessive" CPU:

painter.drawPixmap(rect(), pixmap()->scaled(size(), Qt::KeepAspectRatio, Qt::SmoothTransformation));

painter.drawPixmap(rect(), pixmap());
actaully scale it to rect so @Bonnie version is correct.

to draw it at original size.

or you can simply scale it once outside paintEvent and reuse the scaled version.

Bonnie

To not scale at all, should not use a rect as parameter (unless the rect size is the same as the pixmap size).

painter.drawPixmap(0, 0, pixmap());

(0, 0) is the draw position.