Skip to content
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

allshader RGB,Filtered and Stacked using textures for waveform data #13151

Merged
merged 7 commits into from
May 20, 2024

Conversation

m0dB
Copy link
Contributor

@m0dB m0dB commented Apr 21, 2024

This adds the waveforms for RGB, Filtered and Stacked that use textures to transfer the waveform data to the shader.

This uses the code from the legacy GLSL waveforms, but in combination with the rest of the allshader waveform layers.

(There is code duplication, but since we are planning on removing the legacy ones, I don't care about this)

I added an indicator "waveform texture data" (in addition to the existing indicators GLSL and legacy) to show in the waveform combobox which waveforms use textures to transfer the waveform data to the shader.

@JoergAtGithub
Copy link
Member

Filtered GLSL waveform appears in RGB colors now. Otherwise it works as intended.

@m0dB
Copy link
Contributor Author

m0dB commented Apr 21, 2024

Filtered GLSL waveform appears in RGB colors now.

Yes, but that is not due to this PR, it was already the case.
Edit: But I will fix that (renaming to Stacked) and add Filtered that mimics the legacy.
Edit 2: DONE.

@ywwg
Copy link
Member

ywwg commented May 9, 2024

this looks fantastic to me -- a good step towards solving #12641 though we still have the curve-at-analyze-time problem to work on

const auto lastVisualIndex = static_cast<GLfloat>(
m_waveformRenderer->getLastDisplayedPosition() * trackSamples / audioVisualRatio / 2.0);

// const int firstIndex = int(firstVisualIndex+0.5);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove comment cruft?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just copied this as-is from the legacy code.

@ywwg
Copy link
Member

ywwg commented May 9, 2024

curve-at-analyze-time problem

oh sounds like this may be already solved

@acolombier
Copy link
Member

It feels like this PR is going against the effort to reduce the number of "same" waveform type: from a user perspective, they don't care whether "RGB" is achieved with texture of GLSL and adding another type (even if we eventually retire the legacy one) will still keep the confusion. Could we replace the other allshader instead of adding 3 more type to the existing 13?

@m0dB
Copy link
Contributor Author

m0dB commented May 9, 2024

I think this would better be discussed in Zulip. I personally prefer the non-textured ones over the textured ones. I don’t think there is a problem with having multiple options, it’s about how to present those options in a useful way.

@ywwg
Copy link
Member

ywwg commented May 10, 2024

I posted a comparison in Zulip showing why I prefer textured. I do think we can reduce some of the options, but I would strongly prefer to find a way to keep the extra data that the textured approach shows. (I will maintain my own custom fork if I have to, it makes that much of a difference in my ability to perform)

@m0dB m0dB force-pushed the allshaders-waveform-data-texture branch from 9298a96 to 9a5c616 Compare May 11, 2024 21:40
@m0dB
Copy link
Contributor Author

m0dB commented May 12, 2024

I have deprecated the fixed function pipeline OpenGL widgets and the waveform data texture based widgets that combined with QPainter (replaced with waveform data texture + allshader layers). I put the code in folders waveform/widgets/deprecated and waveform/renderers/deprecated and don't list them in the UI, leaving the preferences dropdown like this:

Screenshot 2024-05-12 at 01 58 34

@ywwg @acolombier maybe we can merge this first, and then merge Antoine's software fallback waveforms, and finally do the waveform preferences reorganisation?

@m0dB m0dB requested a review from ywwg May 12, 2024 10:41
@acolombier
Copy link
Member

acolombier commented May 12, 2024

Ideally, I would prefer merging #13220 first so the AllShaderFilter can implement the Option enum directly, and reduce the number of independent waveform widget

Also worth to mention that the combox box is longer on non-apple platform IIRC (3 more waveform widget excluded by pre processor).

@ywwg
Copy link
Member

ywwg commented May 12, 2024

I agree with @m0dB to merge this first and clean up the preferences later. Either way there will be a little pain but it feels right to get the backend stuff (waveform algorithms) figured out before cleaning up the UX.

@acolombier is that ok?

@ywwg
Copy link
Member

ywwg commented May 12, 2024

deprecated

are we planning to delete them in the future? (Are these the legacy waveforms?) If we are going to remove them, I don't see a big point in moving them to a "deprecated" folder in the meantime. It will make the git history messier, and calling things "legacy" (like the skin parser) and "deprecated" is tempting fate that they will never actually be removed :)

@m0dB
Copy link
Contributor Author

m0dB commented May 12, 2024

The mean idea behind leaving them for now was for the sake of comparison. But I guess one might as well run 2.4 and 2.5 side by side for that.

I am okay with removing them, but I didn’t want to make that decision.

@m0dB
Copy link
Contributor Author

m0dB commented May 12, 2024

@acolombier the advantage of merging this first is that it removes all the renderers and widgets that will not be used anymore, so that might make things a bit easier to comprehend.

@ywwg
Copy link
Member

ywwg commented May 12, 2024

I am ok with keeping them for now, but I don't think it's worth the trouble to move the files around unless that does something I haven't realized. If we mark them in the UI as deprecated in the next version (2.6, since 2.5 is already cut), and then delete them in 2.7.

@acolombier
Copy link
Member

I guess it doesn't really matter. As I mentioned on Zulip, integrating these changes in #13220 will require removing a significant amount of changes added by this PR so it felt more natural the other way around.

Either way there will be a little pain but it feels right to get the backend stuff (waveform algorithms) figured out before cleaning up the UX.

The problem is #13220 makes significant amount of changes on the backend itself (factory, allshader renderer)

FWIW, I'm keen to get either merge ASAP so we can move to the next step, as I will soon not have much time to spend on Mixxx anymore.

@m0dB
Copy link
Contributor Author

m0dB commented May 19, 2024

Do you think anything is missing from this PR, or can we merge it?

@ywwg
Copy link
Member

ywwg commented May 20, 2024

Do you think anything is missing from this PR, or can we merge it?

we're going to talk about this at the meeting in a few minutes :)

Copy link
Member

@ywwg ywwg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been running this patch and it works great. LGTM!

Comment on lines 173 to 179
template<class T_Renderer, typename T_Arg>
inline T_Renderer* addRenderer(T_Arg arg) {
T_Renderer* renderer = new T_Renderer(this, arg);
m_rendererStack.push_back(renderer);
return renderer;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats the difference between this template and the one above? This shouldn't even compile IMO because its ambiguous which should be chose in the one parameter case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are absolutely right, I somehow missed that the above allowed for arguments.

// shaders
bool m_shadersValid;
Type m_type;
const QString m_pFragShader;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a pointer

Suggested change
const QString m_pFragShader;
const QString m_fragShader;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not my code.

default:
break;
}
assert(false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoid segfault during set. Use QString if ur returning a QString, otherwise it'll unnecessary do a utf8 to 16 conversion and allocation.

Suggested change
assert(false);
DEBUG_ASSERT(false);
return QStringLiteral(":/shaders/rgbsignal.frag");

Comment on lines +96 to +102
ConstWaveformPointer pWaveform = m_waveformRenderer->getWaveform();
if (pWaveform) {
dataSize = pWaveform->getDataSize();
if (dataSize > 1) {
data = pWaveform->data();
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

declare variables at point of use, prefer early returns when it doesn't make sense to continue (this is not the linux kernel ;) )

Suggested change
ConstWaveformPointer pWaveform = m_waveformRenderer->getWaveform();
if (pWaveform) {
dataSize = pWaveform->getDataSize();
if (dataSize > 1) {
data = pWaveform->data();
}
}
ConstWaveformPointer pWaveform = m_waveformRenderer->getWaveform();
if (!pWaveform) {
return false;
}
int dataSize = pWaveform->getDataSize();
// is this condition correct? should it actually be just be dataSize == 0?
if (dataSize <= 1) {
return false;
}
const WaveformData* data = pWaveform->data();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not my code.

Comment on lines +190 to +192
// We create a frame buffer that is 4x the size of the renderer itself to
// "oversample" the texture relative to the surface we're drawing on.
constexpr int oversamplingFactor = 4;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is that different from multisampling?

@m0dB
Copy link
Contributor Author

m0dB commented May 20, 2024

@Swiftb0y I see you are commenting on the waveformrenderertextured.cpp code. This is not my code. I just took the legacy GLSL renderer code and made the minimum changes in order to use it in combination with the allshader renderer layers.

I am all for cleaning up this code, and I am willing to do so in future PRs, but I don't think that just moving existing code should come with the obligation to clean it up. The improvement here is using this GLSL based renderer in combination with all the other GLSL based allshader layers instead of in combination with QPainter based layers.

@Swiftb0y
Copy link
Member

@Swiftb0y I see you are commenting on the waveformrenderertextured.cpp code. This is not my code.

I'm sorry, that wasn't clear so I was just treating it as new code. Disregard my comments for now then, but please leave them open so they're easy to revisit later.

Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@Swiftb0y
Copy link
Member

Merging now to keep the velocity. Thank you all for your patience. I'm looking forward to the future cleanup PRs.

@Swiftb0y Swiftb0y merged commit 5e7f149 into mixxxdj:main May 20, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants