-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve UI performance with QOpenGLWidget. #1974
Conversation
Mixxx CPU usage in safe mode with all VuMeter tags commented out in Deere goes down to 8% with Xwayland at 2% (compared to 25% and 15% with VuMeters). I wonder if we could improve performance by making WVuMeter a QOpenGLWidget? |
Thank you for testing! I wasn't really aware anyone used the non-GLSL renderers :P. Just force pushed a new revision that implements rendering for all the QOpenGLWidget renderers. Something to try, since it's a change from master on Linux: set swapInterval back to 0 here. |
Yea, we should try this. VU meter rendering isn't too slow itself, but it seems to trigger a re-render of the entire skin. I get much smoother performance when disabling WNumberPos and WVUMeter creation in legacyskinparser.cpp. BTW, you can set |
The latest commit does not build:
|
Another thing to play around with:
|
Doh, forgot to add files. |
Oh cool, I can reproduce with Deere but not Tango. |
With the latest commit using the RGB GL renderer on Linux, CPU use jumps to 100% for Mixxx but Xwayland CPU use is ~3%. Strangely the RGB GLSL renderer is not available but the Filtered GLSL renderer is. The GUI remains responsive and I probably wouldn't notice the extreme CPU use if I wasn't watching htop. |
None of those make a noticeable difference for me using the GL renderer. In every case CPU usage is around 100% for Mixxx, the framerate reported in the Waveform preferences is ~50-55 FPS, and there is subtle jerking (as there always has been). |
CPU use drops down to ~60% (from 100%) with RGB GL renderer when commenting both those out. |
Is mouse input for knobs and sliders okay now if you comment out the WidgetRenderTimer hacks? |
I tested other skins and yes this only happens for me with Deere. Deere uses some ugly hacks in its spinny template. I do not know why the distorted spinnies are not square considering all the sizes in that template are fixed size squares. 😕 |
No :(, still very laggy. |
What audio buffer size do you use and what's the "system reported latency" in the preferences? |
Interesting. IIRC @sgielen reported that mouse input wasn't laggy with knobs/faders when using QOpenGLWidget and building with macOS SDK 10.14. You're building with macOS SDK 10.13, correct? |
23.2 ms with ALSA. "System reported latency" is 23.22 ms. Going down to 1.45 ms doesn't change the subtle jerking of the waveforms or make the GUI less responsive. Look at htop, I still see a Mixxx thread taking 100% CPU but with a lower latency I now see another Mixxx thread taking ~17% CPU, which I presume is the audio thread. |
Yep, 10.13 SDK. I'll give 10.14 a shot. |
Gotcha. The VisualPlayposition code uses the audio buffer size, which is potentially incorrect (because if you ask for 10ms and portaudio can only get you 20ms, then it calls the engine with a 10ms buffer twice in quick succession). But in your case the audio buffer size is equal to the latency, so that isn't it. Does 90 ms latency also have subtle jerking? |
Yes, and it also occurs with JACK. |
Hm, sounds like I need to do some testing with X and Wayland.
Turns out QOpenGLWidget::resizeEvent wasn't getting run (and it has logic that's important). Fixed in dda5096.
Ah yea, what it's currently showing is the OpenGL profile Mixxx requests, which is a 2.1 compatibility profile. That's not showing the maximum supported OpenGL version anymore. |
I tried setting the requested OpenGL version in WaveformWidgetFactory::setDefaultVersion higher. I tried 4.5, 4.3, and 3.0, and every time that made the waveforms only render the beatgrid. |
I'm on a new Dell XPS 13 (9370) running Ubuntu 18.10 with Wayland, and almost identical output of glxinfo except Mesa 18.2.2 instead of 18.2.6. I don't have any of the performance issues @Be-ing is reporting. I can run 4 decks at a time non-keylocked and use about 40% cpu. There are occasional frame drops but nothing major. LateNight skin, 10ms latency, GLSL RGB This is with GNOME 3 desktop environment. |
I encountered that bug too.
I think that would be consistent with my observation that waveforms are much smoother with a small window than expanding to the full width of my screen. |
I re-added the "beta blocker" tag to indicate we must have this for 2.4. |
I have work in progress |
@daschuer What's the status on this? |
I have made a tiny progress since last comment. To many other loose ends. |
Any news on this? |
No, my work has stalled due to GSoC. |
More up-to-date versions of Qt have major performance problems with QGLWidget. This will not be fixed for Mixxx 2.3: mixxxdj/mixxx#1974
More up-to-date versions of Qt have major performance problems with QGLWidget. This will not be fixed for Mixxx 2.3: mixxxdj/mixxx#1974
This PR is marked as stale because it has been open 90 days with no activity. |
Removed the "blocker" label because we're currently doing a release without this :D |
Thank you very much for working on this difficult issue @rryan. Your work helped us understand the extent of our technical debt and the requirements for moving Mixxx forward. We have decided to reimplement the whole GUI in QML instead of continue with this. |
Music to my ears 😊
…On Thu, Jul 1, 2021, 7:03 PM Be ***@***.***> wrote:
Closed #1974 <#1974>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1974 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGPH7RDSVRBY5A7TGY3SDTVTX35ANCNFSM4GM3Q73Q>
.
|
There will be a few more major releases until the QML implementation is finished. |
AFAIK QOpenGLWidget is supported in Qt6, just QGLWidget is dropped. I agree with @ronso0 that it may be worthwhile to use this for the transition, unless it's an extreme amount of work to integrate. |
It would be an extreme amount of work to integrate. There are fundamental architectural issues in this branch which we do not know how to solve. |
Opening a new PR to make discussion and viewing the diff easier.
Successor to #1863, greatly improves lp:1810099.
116fb61 contains a prototype of my proposed new approach to handling waveform rendering.
Summary of the changes and some background:
aboutToCompose
: When the backing store is about to composite this widget, blitting its offscreen framebuffer to the Mixxx framebuffer.frameSwapped
: When the backing store has rendered the widget's offscreen framebuffer to the Mixxx framebuffer.QWidget::update
on all QOpenGLWidgets and sets a flag that they should render themselves on the nextaboutToCompose
signal.QGLFormat::swapInterval
to 1, so every call to swapBuffers was waiting for a new vsync. This means that we waited for a vsync for every QGLWidget in the app (4 decks, 4 spinnies -> 8 vsync intervals at 60 Hz, 133 ms per second spent swapping 😱 ).aboutToCompose
andframeSwapped
signals all the time (e.g. in response to VU meters, knobs, WOverview, etc. re-rendering). We only render on theaboutToCompose
signal directly afterVsyncThread
triggers a render. QOpenGLWidget preserves the contents of its framebuffer from the last render, so we do not need to re-render until we choose to.Backported this change to 2.2 in #1994:
I also discovered something very weird. Using QStylePainter in WSpinny causes all QOpenGLWidgets (not just WSpinnys) to take 3 ms to render instead of 300 us -- a 10x slowdown. I've removed QStylePainter -- I think where we relied on QSS for WSpinny we should find another way because that's a heavy price to pay. Not sure if it's macOS-specific, or QOpenGLWidget-specific.With the changes in this PR, performance on macOS is significantly improved. With 4 decks, 4 spinnies, 60 FPS waveforms and 1.4ms latency, fullscreen on a 15" retina (2880 x 1800) display:
Setting latency to 90ms, the waveforms are still smooth, which suggests that the VisualPlayPosition interpolation based on the swap interval is working.