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

Disable frame limiter dropdown when deemed appropriate #30481

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

frenzibyte
Copy link
Member

The tooltip text may sound a little too vague, I'm not sure if I have to go as deep as to mention "Metal" and "single-threaded mode".

@Joehuu
Copy link
Member

Joehuu commented Nov 10, 2024

While this fixes the UX for single thread mode, in the issue most people are complaining with multithreading mode (because that's the default). What they see is the draw fps being the same regardless of limiter (in the osu! fps counter).

We need to better convey that the limiter only affects update fps (currently unintuitive because it's x4 draw fps on vsync and x2 on other limiters).

Maybe the first step is keeping the draw fps green when around the refresh rate regardless of the "update" frame limiter and maybe show the update fps.

@frenzibyte
Copy link
Member Author

I confused myself there for a moment, I did not realise none of the issue threads were complaining about single-thread mode. I totally agree with fixing the frame counter to not show false red on macOS, but I don't know about replacing the draw FPS with update FPS, feels weird to have the frame counter represent one thing on one specific platform and another thing on all other platforms, I don't know.

@Joehuu
Copy link
Member

Joehuu commented Nov 11, 2024

I was talking about having draw and update show at the same time, but that will have ambiguity if they are not labelled (which takes up more space and makes the osu! fps counter not simple anymore).

Probably just a notice for the frame limiter setting may be enough.

@frenzibyte
Copy link
Member Author

@peppy need your input here, do you consider the direction of this PR (disabling frame limiter when running on Metal + single thread) to be valid? or should I close this series and just leave a notice on the frame limiter stating that Metal generally behaves different.

I know you still want to rewrite frame limiters to be more user friendly (like stable), so maybe it's a better idea to go with a notice and drop this?

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.

Disable frame limiter setting on macOS/metal (where it isn't useful)
3 participants