Add support for drawing sample waveforms in viewports

[sakertooth]

This PR was originally a refactor PR, but since the performance would get slower than what is currently there (i.e., current master skips some samples when rendering to save on performance, while the refactor didn't), I decided to go through with an overhaul.

Changes:

• Added support for drawing sample waveforms in viewports - The number of samples to render can be limited to the visible region, giving a bunch of performance.
• Removed RMS - Most users did not care for it. Can add it back if necessary
• Add anti aliasing - Makes the waveforms look nicer

[szeli1]

It seems while you removed the std::vector that seemingly caused the memory corruption, but (I think) you didn't fix the underlying issue that is accessing SampleFrames outside of the buffer.

Lastly I think you improved the code quality so that is nice.

[sakertooth]

Thank you for the review @szeli1 👍

[szeli1]

While you closed the conversation, I still believe 52533 isn't correct. If the size is 52532, then end() will be begin() + 52532, just like when the size was 730, the end was begin() + 730 and not 731.

[sakertooth]

I reopened the conversation. It seems that there was an error somewhere.

[sakertooth]

Thoughts @khoidauminh?

[khoidauminh]

@sakertooth I'm seeing the code take a considerably longer time to draw big samples. However I've also tested on smaller projects and the performance is pretty decent. The memory usage and bug potential is greatly improved so I hope we can further optimize this.

Maybe we can switch out RMS and reuse a value so that we don't have compute it again? IMO I haven't seen the significance of the RMS in drawing the waveform.

[sakertooth]

@khoidauminh I am mostly okay with performance issues as we are doing work to fix that. I think anything without use of some kind of waveform caching + partial rendering will result in bad performance no matter how you look at it. This brings us some stability in the mean time until the sample thumbnail PR is ready. It also simplifies the implementation a bit, which is something I've been wanting to do.

When it comes to RMS, I don't think it's that crucial either IMO. Audacity stopped drawing RMS by default, and most DAWs don't draw it either I believe.

[khoidauminh]

I tried removing the RMS while testing. The improvement is not much, so I'm not sure if it's worth it, but it's up to you.

Besides that, I'm also Ok with the compromise so this PR looks good to me

[szeli1]

I approve the main changes, I believe the original memory corruption is fixed.

I found a problem while testing: the slightly transparent black square that is drawn over the sample doesn't scale when the track's height is changed resulting in a clear line between the original widget's size (darker) and the new size.

[sakertooth]

I approve the main changes, I believe the original memory corruption is fixed.

I found a problem while testing: the slightly transparent black square that is drawn over the sample doesn't scale when the track's height is changed resulting in a clear line between the original widget's size (darker) and the new size.

Any chance you could demonstrate this with a video or screenshot? I'm not sure I completely follow.

[szeli1]

Any chance you could demonstrate this with a video or screenshot? I'm not sure I completely follow.

This might be intentional but it looked wrong

[sakertooth]

@szeli1 Can you confirm if this same problem exists on master? It might be out of scope fixing the issue here.

[sakertooth]

Closing in favor of #7366. I originally was planning to split the optimizations into different PRs, but the contrary might be easier since it is closely tied to the waveform generation code (which was already being overhauled in that PR). That being said, #7366 applies this optimization already and fixes the original bug (though, maybe we should change the name of that PR to something more general since it encompasses optimizations other than just adding sample thumbnails).