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

Vsync and frame limit hurt performance #90

Closed
cpm9 opened this issue Nov 12, 2021 · 6 comments
Closed

Vsync and frame limit hurt performance #90

cpm9 opened this issue Nov 12, 2021 · 6 comments

Comments

@cpm9
Copy link

cpm9 commented Nov 12, 2021

I know vsync caps fps to your monitors refresh rate, and I know the frame limit caps to the limit you set. However, when comparing performance it seems that the vsync and frame limit hurt performance.

If fps is always above 200 with vsync off and frame limit unlimited but you turn on vsync on a 144hz monitor it will go to 144 fps but half the time it will be between 100-144 fps. And the same for a 144 frame limit. So compared to the always above 200 on vsync off unlimited the performance is lesser.

Maybe something in the vsync and frame limit code could be improved to fixx this? I hope my explanation makes sense. Can anyone replicate this problem?

magnesium-1.4.1.1.jar

@Quinteger
Copy link

That's how vsync and frame limiting work. They are essentially just timers that fire based on how much time did it take to render last frames. If you got a difficult frame, you will get a performance dip.
Goes without saying that it's not related to sodium.

@cpm9
Copy link
Author

cpm9 commented Nov 13, 2021

That's how vsync and frame limiting work. They are essentially just timers that fire based on how much time did it take to render last frames. If you got a difficult frame, you will get a performance dip. Goes without saying that it's not related to sodium.

So you're telling me that when I am getting above 200fps then I turn on vsync or frame limit to 144 but it goes to 100 that is normal? Why does vsync/frame caps not work like this in other games?

@Quinteger
Copy link

That's how vsync and frame limiting work. They are essentially just timers that fire based on how much time did it take to render last frames. If you got a difficult frame, you will get a performance dip. Goes without saying that it's not related to sodium.

So you're telling me that when I am getting above 200fps then I turn on vsync or frame limit to 144 but it goes to 100 that is normal? Why does vsync/frame caps not work like this in other games?

Yes.
FPS is not a metric you can calculate instantly. You need some time period to calculate it against and different games can pick different periods.
If on a 60 fps vsync you got a difficult frame which took more than 1/60s, but less than 2/60s to render, you can say that your fps during short period was 30, but a different game that measures FPS over a 100ms period will report to you something like 50 for example.

@cpm9
Copy link
Author

cpm9 commented Nov 25, 2021

Okay I have done more investigation and found what I think is good proof of what I've reported. In these screenshots I've used the lowest settings and 2 render distance to try to best demopnstrate the problem. Tested with Magnesium 1.5

@Quinteger

Number one: vsync off and frame rate unlimited. Average fps is ~1600 and 1% low and 0.1% low are ~700
unlimited

Number two: vsync on frame rate unlimited. Average fps is 144 (like monitor refresh) but 1% low is 117 and 0.1% low is 43 this microstutter makes it feel a lot less smooth and was not present without vsync. There is also the fact that the current fps drops below 144 to 143 or lower every few seconds. I don't understand how this makes sense considering the huge fps numbers when unlimited and the huge 1% and 0.1% lows.
vsync 143

Number three: vsync off and frame rate set to 145. Same as above.
145 cap 143

@cpm9
Copy link
Author

cpm9 commented Dec 22, 2021

comparison

@cpm9
Copy link
Author

cpm9 commented Feb 4, 2022

I think this is a limitation of minecraft itself and not specific to Magnesium

@cpm9 cpm9 closed this as completed Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants