-
-
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
Too many waveform options #11615
Comments
We could discuss hiding the non-all-shader versions behind a flag. I don't think it makes sense to remove them outright in case we don't discover all issues with the all-shaders before the stable release. |
We have already removed the waveforms that have performance issues. So I don't think the user does crucial decision. If you have issue with one particular waveform please report that separate. |
Even with all the background information I am overwhelmed with the multitude of choices. Mixxx should offer only 2 or 3 alternatives that provide different views. Users should not be bothered with all the technical implementation details. |
As I said, fully agreed and something we should definitely enforce once we can be sure that the all-shaders approach works for everyone (which I'm fairly certain about but you never know with GPUs and their drivers). |
I don't even have a clue what "all-shaders" means. This term should not appear in the UI. |
As a user I might be able to guess that non-accelerated could be used a fallback if accelerated as the default doesn't work for me. But that's all what I want to see. Anything else is confusing. That would be my opinion as a product manager. |
The distinction between RGB and RGB R/L should be removed first. Make a decision and choose one, but please don't bother the user with such details. |
Bug Description
As a regular user without a technical background I would no be able to choose the right waveform for my system. Especially on macOS this selection is crucial.
I suggest to delete all non-essential renderers that don't add value for users or that need to be deprecated (soon) anyway for the migration to Qt 6. Doing so would also reduce the maintenance burden.
Version
2.4
OS
No response
The text was updated successfully, but these errors were encountered: