replace qstylepainter with qpainter in vumeterlegacy, use by default #11722
Conversation
|
I tested this PR on Windows11 and first struggled to reproduce the lag as @NotYourAverageAl in the previous PR. I found out that it doesn't occur with every buildenv version. Luckily windows_buildenv.bat creates backup files of old CMakeSettings.json and I could restore the affected state. The result of my testing is, that this PR with works smooth and flawless on my Windows11 system if I start mixxx.exe without further options. If I set --enable-vumetergl I see the lag again. Furthermore I noticed, that using vumetergl always increase the CPU load and the GPU load significiantly. Therefore my conclusion is, that this PR is the right thing for Windows 11. But how does it perform for Linux and especially macOS users? |
|
Does all this also apply to the 2.3 branch? (I am currently building this on Ubuntu Focal) |
|
macOS ARM seems to run pretty well too, though admittedly I couldn't notice a big difference in performance/responsiveness between default and |
|
Do you see a difference in CPU or GPU load? |
|
Very slightly perhaps, but then only negligibly so.
|
|
First of all, all configurations are running smooth. The noise in the value is at the same magnitude as the difference, so these values can only show a tendency. On Ubuntu Focal I see with "intel_gpu_top" and "top" four decks playing with --enable-vumetergl plain 2.4 2.4 with --disable-vumeter plain 2.3 2.3 with --disable-vumeter Are these measures reasonable? Conclusion this one give the best performance over all! Thank you. |
|
Than let's merge this! Proved on all three platforms equal or better than with VUMeterGL. |
|
With 2.3 with --disable-vumeter has the opposite effect on windows and macOS compared to what we see here. How is the situation on Windows? Is there anything to do on the windows 2.3 branch? |
|
On macOS and 2.3 VUMeterGL is reported to be much faster. But not on Windows, there some users see UI lag. |
But that is, as far as I have seen with 2.4, because of the use of QStylePainter. It could be interesting to try 2.3 with the --disable-vumetergl and replacing QStylePainter with QPainter as done in this PR. But I don't know if that's worth the hassle. The real improvement is 2.4 anyway. |
Great! It's been an interesting ride: the GL based VU meter being the first step in improving performance on macOS and now that we have the QOpenGLWindow/GLSL based waveforms and spinnies, being able to go back to the original VU meters (with a small tweak). Full circle :-) |
It is definitely not worth to spend hours of refactoring. The only thing is IMHO worth to check if "--disable-vumeter" should be the default on Windows. |
|
Tested on MacBookPro 14,3 Intel mac. Could not spot a big difference in performance comparing a recent main build and todays 2.4 beta build. 2.5 main: |
The GL-based vumeters reportedly cause lag on Windows, but also on macOS I notice they take relatively a lot of time (maybe QOpenGLWindow doesn't play nice with multiple small windows?)
This PR reenables the legacy VuMeter by default, replacing the command line option --disable-vumetergl with --enable-vumetergl. It has one important change which improved it's behaviour on macOS drastically: using QPainter instead of QStylePainter. The background color is determined in the same way as the GL VuMeter.
Also on macOS this seem to behave better than when using the GL-based VuMeter. At least not worse. If we confirm this works well for everyone on all platforms, I propose to remove the GL VuMeter code altogether, as well as the command line option.