-
-
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
allshader RGB,Filtered and Stacked using textures for waveform data #13151
Conversation
Filtered GLSL waveform appears in RGB colors now. Otherwise it works as intended. |
Yes, but that is not due to this PR, it was already the case. |
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove comment cruft?
There was a problem hiding this comment.
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.
oh sounds like this may be already solved |
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 |
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. |
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) |
…he waveform data to the shader (like to legacy GLSL waveforms)
9298a96
to
9a5c616
Compare
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: @ywwg @acolombier maybe we can merge this first, and then merge Antoine's software fallback waveforms, and finally do the waveform preferences reorganisation? |
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). |
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? |
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 :) |
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. |
@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. |
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. |
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.
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. |
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 :) |
There was a problem hiding this 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!
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; | ||
} | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a pointer
const QString m_pFragShader; | |
const QString m_fragShader; |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
assert(false); | |
DEBUG_ASSERT(false); | |
return QStringLiteral(":/shaders/rgbsignal.frag"); |
ConstWaveformPointer pWaveform = m_waveformRenderer->getWaveform(); | ||
if (pWaveform) { | ||
dataSize = pWaveform->getDataSize(); | ||
if (dataSize > 1) { | ||
data = pWaveform->data(); | ||
} | ||
} |
There was a problem hiding this comment.
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 ;) )
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(); |
There was a problem hiding this comment.
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.
// 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; |
There was a problem hiding this comment.
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?
@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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Merging now to keep the velocity. Thank you all for your patience. I'm looking forward to the future cleanup PRs. |
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.