-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Cache and interpolate resolutions when drawing sample waveforms #7574
Conversation
Pretty decent performance! Though I'm seeing some bugs The sample zoom jitter is still there: Screencast.From.2024-11-11.11-00-59.mp4Some sample shape artifacts when zooming: Screencast.From.2024-11-11.11-30-13.mp4Waveform not being drawn in SlicerT (or you haven't drawn it yet): Incorrect rendering in AFP: Screencast.From.2024-11-11.11-02-52.mp4Also iirc, this one also uses more ram, but it's not a big problem. Have you tested how this compares to my implementation? |
If you don't mind, I'll push some fixes |
Yeah, that's fine with me. |
Co-authored-by: Dalton Messmer <[email protected]>
@khoidauminh, I tested your PR. I don't remember the implementation being that good, wow. I think I might close this PR actually and continue contributing to what you have over there. And the ideas we did here are the same, at least in terms of caching, but I'm shocked at how the continuous scrolling is that fast with your PR. |
@sakertooth Damn thank you Though I think my PR is only faster because I clipped rendering to the visible region This PR did make me realize how messy my code still is lol. I'll see what I can clean up |
This PR is meant to improve performance when drawing sample waveforms by:
That's about it. I do want to note that when stretching sample clips vertically and using continuous scrolling, there is still a major drop in performance due to the drawing that's being done on the CPU. In the future, we should migrate such drawing to be done by the GPU using something like OpenGL.
Below is an attachment for the results of
perf
when sampling cycles in the scenario stated above: as shown, most of the overhead in this case lies within the Qt library itself, more specifically its software rasterization that is done on the CPU.I have also omitted RMS calculations from the waveform visualization since most DAWs (and now even Audacity when using default settings) don't consider this, and I wanted to prioritize more performance.