Waveforms needs some optimization/caching

[xorik]

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.

[Daniel Schürmann (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.
https://blueprints.launchpad.net/mixxx/+spec/tiling-waveform

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.

[xorik (xor29a)]

Other waveforms is ~20-40% of my CPU on 30 FPS.

>you could make a pure GL HSV version
I think MOST part of CPU using not for the drawing, but for the calculations (it is easy to check, just comment the drawing code and compare CPU usage).

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?

[xorik (xor29a)]

sorry, i mean "If song is paused", not "is"

[RJ Skerry-Ryan (rryan)]

Hey Xorik,

In fact, it's the opposite! We pre-calculate the entire waveform during
analysis. All of the CPU usage you are seeing is from the drawing code.
(There is some glue code that helps the drawing figure out what to draw,
though).

On Tue, Jun 25, 2013 at 9:00 AM, xorik <email address hidden> wrote:

> Other waveforms is ~20-40% of my CPU on 30 FPS.
>
> >you could make a pure GL HSV version
> I think MOST part of CPU using not for the drawing, but for the
> calculations (it is easy to check, just comment the drawing code and
> compare CPU usage).
>
> 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?
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1194456
>
> Title:
> Waveforms needs some optimization/caching
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1194456/+subscriptions
>

[Daniel Schürmann (daschuer)]

> I think MOST part of CPU using not for the drawing, but for the calculations (it is easy to check, just comment the drawing code and compare CPU usage).

Can't believe, have you mad the posit check, just comment the calculation code?

We have also a nice benchmark feature in Mixxx.
If you start Mixxx with --developer, you can use ScopedTimer in src/util/timer.h for measurements.

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.

[xorik (xor29a)]

Hmmm... ok, I will try to test calculation and draw time soon...

[xorik (xor29a)]

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?
Why so big difference?

[jus (jus)]

I found that "filtered - GL" wasted much time during color conversation from HSL to RGB, if the selected skin.xml does not provide a color for <SignalHighColor>, <SignalMidColor>, <SignalLowColor> ) like in Deere & Latenight skins.

In waveformsignalcolor.cpp, the fallBackFromSignalColor uses the HSL color space, which is converted to RGB in glwaveformrendererfilteredsignal.cpp .

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7084