Godot: VSync does not work anymore on macOS

[DarkMarmot]

Comparing game engines and running the simple demo projects that ship with Godot 3.1 alpha 3, I was horrified to see that they nearly maxed the cpu on my high end mac laptop, kicking it into space heater mode.

It took months before I read a comment somewhere that this was related to an unbound render loop. I can't say I feel that that is anything but crazy in terms of how it will affect perception of the engine's general performance, which thus comes across as abysmal.

As someone who ardently supports open source, please, please consider changing the defaults so others don't come to this mistaken impression.

[DarkMarmot]

(to clarify the months comment, I kept checking this engine out sporadically to see if new builds improved the 'performance' ...)

[akien-mga]

Vsync should limit FPS to 60. Are your drivers configured to bypass application Vsync and force it off?

Otherwise there might be a bug in the way Godot's Vsync is implemented on macOS.

[Calinou]

V-Sync is enabled by default, so the FPS should be capped to the monitor's refresh rate (unless your graphics driver forcibly disables it, which is never the case by default).

However, if you disable V-Sync, FPS will be uncapped, which is usually the desired behavior as it results in the lowest possible input lag. You can cap the FPS by setting debug/settings/fps/force_fps to a non-zero value in the Project Settings.

[Zireael07]

not funny, mafiesto :/

[girng]

Comparing game engines and running the simple demo projects that ship with Godot 3.1 alpha 3, I was horrified to see that they nearly maxed the cpu on my high end mac laptop, kicking it into space heater mode.

which demos max cpu usage? prob the tps demo might.. not sure about others

[DarkMarmot]

It happened on all of the ones I tried.
Running Mojave 10.14.2.

I opened the 'Hexagonal Game' demo just now, it does default to 'vsync on' but it doesn't appear to be taking effect on my system. Adding a force_fps to 60 in the project settings makes my laptop much happier.

I haven't intentionally done anything to my graphics drivers -- but this is a development machine so it's always possible I've got something strange installed that is causing weirdness :(

[DarkMarmot]

And I just found that there are vsync issues with OSX it seems -- here's a workaround:
https://hg.libsdl.org/SDL/rev/73f3ca85ac0e

Taken from: https://github.com/glfw/glfw/issues/1337

[DarkMarmot]

Apologies for my first post -- I didn't realize this was not an intended setting and mac specific strangeness....

[starry-abyss]

IMHO, the framerate should be capped even without v-sync, and uncapped framerate is only useful for measurement in "bunnymarks".

However, if you disable V-Sync, FPS will be uncapped, which is usually the desired behavior as it results in the lowest possible input lag.

Input should be taken in _physics_process(), which has a separate cap, not tied to visual frame rate.
Also it's not like playing Counter-Strike, a game's controls should be designed with the input lag in mind (usually with framerate capped to either 60 or 30).

Also current fps options are confusing. One is in "debug" which allows to change the value. But fps capping shouldn't be a debug-specific thing. And other is in "global", which is just "fps" flag (what does it do at all?). If they are related, they should be near each other.

[starry-abyss]

Please also see my investigations in the related thread: https://github.com/godotengine/godot/issues/19783#issuecomment-455858284

[reduz]

Something smells rotten in Macosburg, so it's time to take action...

[BastiaanOlij]

Chiming in after talking about this with Reduz on IRC. Can also confirm that vsync is broken. The buzz all around the internet is that vsync in NSOpenGLContext (and the underlying CGL API) is broken. Metal is unaffected and with Apple deprecating OpenGL this is unlikely to be resolved any time soon, if ever.

Had a look at SDLs solution to the problem. What they do is use CVDisplayLink to be informed by MacOSX when a display refresh is starting. It requires a bit of thread magic but I think it is adoptable. Does mean we need to handle our own vsync right before calling [context update] which is going to require a few changes.

I'll see if I can work through it tomorrow.

[reduz]

Please test #25443, which implements an attempt to fix this problem.