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

setFrameRate on lwjgl3 leads to too slow frame rate #1455

Closed
richardTingle opened this issue Dec 30, 2020 · 5 comments · Fixed by #1406
Closed

setFrameRate on lwjgl3 leads to too slow frame rate #1455

richardTingle opened this issue Dec 30, 2020 · 5 comments · Fixed by #1406
Assignees
Milestone

Comments

@richardTingle
Copy link
Member

Issue
When running JME with jme3-lwjgl3 the AppSettings#setFrameRate method call does not work correctly, causing far lower frame rates that requested. My application, when unlimited runs at around 60 fps, but when limited runs as follows:

Requested Actual
60 30
120 37
240 45
2400 55
No limit 60

This only occurs with jme3-lwjgl3, jme3-lwjgl works fine

Investigation so far
I've had a look in the debugger at what's going on in LwjglWindow#runLoop and on line 564 I see it trying to figure out how long to sleep for:

final double sleep = frameSleepTime - (timer.getTimePerFrame() / 1000.0)

However, timer.getTimePerFrame() appears to always return zero, leading to it always sleeping for the full 1/frameRate. Meaning if the application is under any sort of load that brings it close (or worse below) to the requested frame rate it slows the application way below the requested rate.

This appears to be because Timer#update is never called (a different times update method is called, but not the one in LwjglWindow

Environment

I'm running 3.3.2-stable but I've also checked out and run against the V3.3 branch and it behaves the same (master looks like it would have the same problem but crashes for me)

@richardTingle
Copy link
Member Author

There are some other problems in runLoop, timer.getTimePerFrame() is in seconds so it should be multiplied by 1000, not divided. But the bigger problem is that even if corrected it still runs at the wrong frame rate, as on frame 1 it detects and corrects the problem, then on frame 2 there is (as far as it sees) no problem, so it doesn't sleep. Meaning every other frame runs too fast.

jme3-lwjgl's version of this seems much more complicated (necessarily so) calling Sync.sync which runs a longer average thereby avoiding the problem

@riccardobl
Copy link
Member

This is fixed by this unmerged patch:

2f62afc

from pr #1406

@richardTingle
Copy link
Member Author

Awesome! I'll stop investigating in that case.

Should this issue be closed or should it stay open till the PR is merged?

@stephengold
Copy link
Member

I'm fine leaving this open. It might help someone solve a similar issue. And it's not like we're going to clear out the backlog anytime soon...

@stephengold stephengold added this to the LWJGLv3 Issues milestone Dec 30, 2020
@stephengold stephengold modified the milestones: LWJGLv3 Issues, v3.4.0 Mar 13, 2021
@stephengold stephengold linked a pull request Mar 20, 2021 that will close this issue
@stephengold
Copy link
Member

richtea reported this issue fixed in 3.4.0-beta1:

https://hub.jmonkeyengine.org/t/engine-v3-4-0-beta-testing/44507/5

@stephengold stephengold modified the milestones: LWJGLv3 Issues, v3.4.0 Dec 6, 2021
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

Successfully merging a pull request may close this issue.

3 participants