CPU load on internal windows when buttons are hidden (Windows only)

[DeRobyJ]

When a window size is changed (on Song Editor, Piano-roll, automation editor and project notes), buttons that don't fit it are hidden and accessible via an arrow button.

If that happens, the cpu goes to max for the LMMS process (25%)
(I'm on a quad core, and one of the cores goes to around 70%, while the others are normal)

I'm on Windows 7 64bit, and I'm using the third RC from Tres' fork (1.1.90-g33d8c44), which is in qt5
Seems fine on linux

[tresf]

@DeRobyJ confirmed on Windows at least. This seems to happen with any collapsible toolbar.

This may be a Qt5 + Windows bug. If you get the Song-Editor and drag it smaller so that the dropdown-toolbar menu appears, it also utilizes an unreasonably high amount of CPU.

Edit: Wine experiences a similar problem. CPU spikes from 12% to 25% when the toolbar is collapsed.

Tagging @michaelgregorius since this new toolbar feature was added in #2287.

[DeRobyJ]

Yup, seems Windows only.
Tested in KXStudio 14.04, lmms 1.1.90-g268ddb2

Re-writing issue~

[michaelgregorius]

Does the high CPU load persist as long as the toolbar is collapsed or is it "only" a spike?

@tresf Do we have a recent Windows release build with debug information (RelWithDebInfo) that we can send through a profiler like Very Sleepy to check where the time is consumed?

[tresf]

@tresf Do we have a recent Windows release build with debug information (RelWithDebInfo) that we can send through a profiler like Very Sleepy to check where the time is consumed?

Negative. We've never done well in this regard. It think we attempted to enable debug symbols when built win32/win64 from Linux, but I'm certain we never succeeded with Msys2 (well, technically curlymorphic claimed to have gotten a single Msys2 build fired with debug flags, but I never was able to... I can try to hunt down the Linux + mingw build flag changes if needed).

[tresf]

Does the high CPU load persist as long as the toolbar is collapsed or is it "only" a spike?

From my quick testing, it remains until it's no longer collapsed. It's persistent so as long as it is collapsed.

[michaelgregorius]

@tresf I think for g++ you only need to pass -g when compiling the release version.

[tresf]

@michaelgregorius If your comment is in regards to a debug build... I'd be happy to add debug instructions to our build process, but when I had originally tried this it was under the assumption we had a version of gdb running directly inside Windows (for the particular bug that inspired msys2 support -- Zyn 2.5 crashing , winegdb wasn't a candidate) but the msys2 build process is extremely unorthodox. It fetches Toby's mingwppa for the dll files but needs to use native msys2 version of the exe files, so we do a bunch of clobbering of build tools before we compile. Troubleshooting the environment is a mess and we never got development flags to build successfully directly on Windows.

If we can document a build flag to mingw on Linux, that would be better than what we have now. AFAIK Dave and I improved this in #2205 but I haven't extensively tested it yet.

[michaelgregorius]

@tresf My intention is to use a release build with debug information to let it run in Very Sleepy to find out where the time is spent and whether it's really spent in Qt's code. The debug information would be needed so that the symbols can be resolved. However, come to think of it, if it in fact spends most of the time in Qt a release with debug info build won't help anyway because Qt would also need to be built as a release with debug information as well. So perhaps a normal release build will do as long as it tells us that most of the time is spent in symbols from Qt's DLLs.

Can you provide me with a Windows release build (preferably one that can simply be unzipped and does not need to be installed) so I can give it a spin with Very Sleepy?

An alternative might be to try to reproduce the problem in a minimal Qt application under Windows.

[tresf]

An alternative might be to try to reproduce the problem in a minimal Qt application under Windows.

Yeah that might be quicker through QtCreator. I'd be happy to make a debug build of LMMS however I'd rather not spend the time of compile an uploading unless we know it will work.

I think for g++ you only need to pass -g when compiling the release version.

Can you be more specific from a cmake perspective? For example, is this just a CXX flag? Can it be provided on command line?

[tresf]

So I installed QtCreator and now apparently I need a compatible MSVC compiler to match. This is gross. Ugh..

http://stackoverflow.com/questions/31897847/can-not-configure-compiler-and-build-kit-for-qt-5-5

[liushuyu]

@tresf You could download a community version of Visual Studio to get the compilers and other necessary tools. It might take around 10 GB of disk space.

[tresf]

@liushuyu yeah thanks. I had it installed but was missing some stuff. Posted the steps here: http://stackoverflow.com/questions/32413617/setting-up-qt5-with-visual-studio-2015#comment61886529_32413617.

Next step, getting a toolbar added. 👍

[liushuyu]

I had it installed but was missing some stuff

So what went wrong with your installation?

[tresf]

So what went wrong with your installation?

It's explained in the stack overflow article, but MSVC 2015 (Visual C++) wasn't bundled with MSVS (Visual Studio) 2015. I opened it up (30 day trial had expired, signed in with a hotmail account), tried creating a C++ project and Visual Studio prompted to install MSVC 2015. Once that was done, QtCreator was fine.

[liushuyu]

Once that was done, QtCreator was fine.

So you are good to go now?

I opened it up (30 day trial had expired, signed in with a hotmail account),

BTW, there's a community version available, which is free to use with open source projects. And it bundles everything from Windows development to Android deployment.

[tresf]

BTW, there's a community version available, which is free to use with open source projects. And it bundles everything from Windows development to Android deployment.

Yes, that's what I was on (well, the non-bundled version apparently), but it forces you to sign into a Microsoft account after 30 days. 😈

[liushuyu]

And I've noticed that some projects that compiles well with gcc just fails when compiling with M$VC's cl compiler, but since Visual Studio 2015, you can choose clang as preferred compiler. And I suggest to do that.

[tresf]

@michaelgregorius,

I cannot reproduce on QtCreator/Qt5 but I don't think it's a 1:1 comparison...

• LMMS uses the QToolBar in the QMdiSubWindow container, which QtCreator doesn't seem to have direct support for in the GUI designer.
• On the contrary, by default QtCreator places QToolBar directly in the QMainWindow instance.
• A side note, I did force the Fusion theme to be safe, since we do that in LMMS.

Also, I tried to reproduce this bug using the new QToolBar but on Windows + Qt4 and it is not present in LMMS, only with Windows + Qt5 (and I've only tested on 64-bit Windows). This is a pretty specific bug.

Another item worth noting/investigating is that we have custom buttons/widgets added to the QToolBar which may have inefficiencies in the paint() methods that this bug is bringing to light.

Off topic, but I also noticed the .ui file references the subwindow as just a standard QWidget object.

[liushuyu]

Another item worth noting/investigating is that we have custom buttons/widgets added to the QToolBar which may have inefficiencies in the paint() methods that this bug is bringing to light.

So, to really figure out the problem, a timing debugging should be done. I'd like to test this out, but I don't know if we could fire a complete debug build on Windows.

I don't know what will happen if I run the debug on release build.

[liushuyu]

Hi, guys, I've done a quick Very Sleepy timing profile (with release build unfortunately), and found something interesting. I've done the test under Windows 10, however I captured the screenshot under Linux (via Wine).

And I also attach the sample Very Sleepy timing capture here, in case you are curious to see the whole complete report (which I've profiled for only 60 seconds)

lmms.sleepy.zip

Just rename lmms.sleepy.zip to lmms.sleepy (because the file itself is a zip file, and GitHub only allow me to upload the file with zip extension)

[musikBear]

can this issue be recreated on win32?
I cant.
CPU is 100% stable no matter how any widget-window is sized, minimized, top-placed, in or out of focus.
Same CPU load on all situations.
(1.1.90-g33d8c44 on xp)

maby x64 specific? maby im just wrong, again.

[liushuyu]

maybe x64 specific? maybe im just wrong, again.

Emm, maybe this issue is tied to higher version of Windows?

IMO, we can test if this problem exist on Windows 7 box

[tresf]

CPU is 100% stable

WTF is 100% stable?

[liushuyu]

WTF is 100% stable?

He meant to say CPU was in normal state

[tresf]

He meant to say CPU was in normal state

I cannot confirm. Qt5 test results:

• 🔵 Ubuntu 12.04: Normal CPU utilization
• 🔴 Windows 10 x64: High CPU utilization
• 🔴 Windows 7 x64: High CPU utilization
• 🔴 Windows XP x32: High CPU utilization

[liushuyu]

My Arch Linux x64 seems to be fine as well...
So it seems to be a Windows specific problem

[liushuyu]

@tresf I've done a timing above, hoping we can figure out some potential causes

[tresf]

(1.1.90-g33d8c44 on xp)

@musikBear this is a Qt4 build, it won't experience the bug. This isn't immediately obvious when you fire up LMMS, but if you're using a build from my branch, I've explicitly tagged releases for Qt5 in the file name.

Edit: Correction, it is Qt5. Not sure why it affects my VM but it won't affect @musikBear.

The way to know with these older builds is the QMdiSubWindow decorations are black. Modern builds won't be as easily distinguishable and you'll have to go to About, LMMS to know for sure.

Original bug report:

I'm on Windows 7 64bit, and I'm using the third RC from Tres' fork (1.1.90-g33d8c44), which is in qt5

Next post:

This may be a Qt5 + Windows bug.

[liushuyu]

@musikBear Download here: https://github.com/tresf/lmms/releases/download/v1.2.0-RC1.2/lmms-1.1.90-win32-qt5.exe

[tresf]

@liushuyu that's the one he's using. My mistake it is Qt5 after-all. Not sure why it affects my VM but it won't affect @musikBear.

[liushuyu]

@tresf No, I've edited comment...

[DeRobyJ]

@musikBear on my system, one of the cores was around 70%, while the others were normal.
It might be possibile that on a 32bit system the bugged process takes over the whole cpu.
How many logical cores do you have?

[tresf]

It might be possibile that on a 32bit system the bugged process takes over the whole cpu.

Single-core system, yes. The single-core/single-cpu VMs I'm testing in deadlock when this bug happens. 32-bit is behaving the same as 64-bit in my tests.

[musikBear]

No its my mistake. If i use a cpu monitor, there is a rise, it is just not big enough to make a change on lmms' cpu-monitor, but it increases to ~40, and it does indeed drop to ~2 if the window is maximized. Sorry for confusing the issue, should have used cpu-monitor, not just relied on the lmms cpu-monitor.
@DeRobyJ

How many logical cores do you have?

I have 2 cores:
Intel Core 2 Duo E6750, 2.667GHz, 1333SB 1.116,00
Both rises to ~40% and both drop when window is maximized

[tresf]

@DeRobyJ can you please re-test with this build? No changes have been made specifically but I'm having a hard time reproducing the problem now and want reconfirmation.

[tresf]

We've had multiple reports that this build no longer suffers the problem. Closing.

[DeRobyJ]

Yup, I confirm it's fixed

[musikBear]

Confirming for 1.2.0-rc2 on XP
Good job! 👍