-
-
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
Waveforms needs some optimization/caching #7084
Comments
Commented by: daschuer I agree that there is much space for Improvements. But I do not agree that caching isn't hard to code. We have already a blueprint for this. If you want to adopt parts of this issue, a first step is to create a new page at www.mixxx.org/wiki link it to the blueprint and outline your ideas there. I have currently a waveform dejerk branch in progress with also some CPU savings. Filtered Qt and HSV are not well optimized. What are your results of the GL waveforms? An other first step: you could make a pure GL HSV version. |
Commented by: xorik Other waveforms is ~20-40% of my CPU on 30 FPS.
I think we can create arrays in memory for needed song parts (which visible in this moment) e.g. each array contain 1second of song's waveform data. Is song is paused, we don't need to do the calculations, but if song is playing, we will be calculate every 1 second of song, when we need. I think this saves big amount of CPU%. What you think about this? |
Commented by: xorik sorry, i mean "If song is paused", not "is" |
Commented by: daschuer
Can't believe, have you mad the posit check, just comment the calculation code? We have also a nice benchmark feature in Mixxx. Your idea is not bad, but I would prefer a balanced CPU solution where only the part is calculated or redawn, that is new for every frame. |
Commented by: rryan Hey Xorik, In fact, it's the opposite! We pre-calculate the entire waveform during On Tue, Jun 25, 2013 at 9:00 AM, xorik wrote:
|
Commented by: xorik Hmmm... ok, I will try to test calculation and draw time soon... |
Commented by: xorik You was right! Drawing is used most part of CPU, not calculations :) But why "simple - GL" waveform is used 22 percent, and "filtered - GL" is 65 percent CPU? |
Commented by: esbrandt
In waveformsignalcolor.cpp, the fallBackFromSignalColor uses the HSL color space, which is converted to RGB in glwaveformrendererfilteredsignal.cpp . |
Reported by: xorik
Date: 2013-06-25T11:38:11Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1194456
Tags: waveform
Hi all!
I think mixxx need to optimize waveform display code, beacuse it uses many percents of CPU at now.
I have Intel(R) Celeron(R) CPU E3400 @ 2.60GHz GenuineIntel and x86_64 gentoo linux. I'm use "top" in terminal for measuring CPU percents.
I load 2 tracks into decks and paused them and set waveform FPS limit to 30
Empty waveform: 18% CPU
Filtered - Qt: 57% CPU
HSV: 45% CPU
If I increase FPS limit, the numbers will be much bigger (70-80% CPU for HSV and filtered waveform).
I think this is because of many calculations, while drawing waveform, without caching. I thing caching isn't hard to code, but saves many CPU percents (and battery life) when mixing.
The text was updated successfully, but these errors were encountered: