-
-
Notifications
You must be signed in to change notification settings - Fork 21.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
Restructure and reimplement v-sync options #48622
Restructure and reimplement v-sync options #48622
Conversation
I can confirm it works on Linux + NVIDIA: Testing project: test_vsync_disable.zip |
c5c3224
to
e896526
Compare
c229cac
to
4aa4a33
Compare
Rebased and partly restructured, What is the plan for vsync_via_compositor in 4.0? The code regarding vsync_via_compositor is currently dead in master. |
I think it would be better to remove it, as it doesn't work correctly for everyone. It causes the framerate to halve unexpectedly on some setups. Physics step interpolation, syncing frame delta after draw, fixing negative delta values and frame delta smoothing will likely be enough to provide a good experience regardless of potential compositor issues. |
4aa4a33
to
079f65f
Compare
079f65f
to
e6ca83b
Compare
Ok, I removed the V-Sync via Compositor option entirely, now its ready for review :) |
Looks interesting, but is this not just a reimplementation of #36862? See this comment #36862 (comment) for reduz' response to that PR. I echo reduz' concern and I am not certain that just grabbing the first available V-sync format is the proper way to expose vsync to users. Can you elaborate why this is the best approach for exposing v-sync? Please pardon my ignorance if it is something obvious. |
It is a reimplementation of #36862, but moved to DisplayServer as requested by reduz. In addition I removed the broken vsync via compositor option. |
I'm not certain what the best way to expose the vsync settings to the user is. I don't think falling back to I think one option may be to have a toggle (between on and off, if That being said, I'm not sure that it makes sense to do it like that, for android it looks like |
Ok, I will look into that. By digging through the codebase I found out that it is more work than I initially thought, so I should change this PR to a draft as there are still some things to decide, restructure and implement. Maybe I should ask reduz if he has concrete plans for v-sync atm. |
@Geometror that is a good idea. Reduz typically has some ideas for this kind of stuff, and it is important to work on soon as we are approaching alpha. |
5f41303
to
bea4958
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good!
e5f2cba
to
c635d3d
Compare
ea9b5f5
to
3c8bae7
Compare
@Geometror I think it is best for each PR to do one thing. My preference is to merge this PR first and then look at Calinou's PR after. |
-Add a v-sync mode setting which allows to choose between DISABLED, ON, ADAPTIVE and MAILBOX -Removed the V-Sync via Compositor option
3c8bae7
to
043ae91
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally with this PR rebased against the latest master
branch. All options seem to work as expected on Linux + NVIDIA.
Edit: Tested on a Windows 10 + Intel IGP setup, it works as expected there too.
Thanks! |
@@ -1114,6 +1114,7 @@ ProjectSettings::ProjectSettings() { | |||
|
|||
// Keep the enum values in sync with the `DisplayServer::ScreenOrientation` enum. | |||
custom_prop_info["display/window/handheld/orientation"] = PropertyInfo(Variant::INT, "display/window/handheld/orientation", PROPERTY_HINT_ENUM, "Landscape,Portrait,Reverse Landscape,Reverse Portrait,Sensor Landscape,Sensor Portrait,Sensor"); | |||
custom_prop_info["display/window/vsync/vsync_mode"] = PropertyInfo(Variant::STRING, "display/window/vsync/vsync_mode", PROPERTY_HINT_ENUM, "Disabled,Enabled,Adaptive,Mailbox"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed this is a string enum rather than an integer enum. I think using an integer enum would be better as it's more Godot-y overall. (We're trying to move away from string usage when possible in 4.0 onwards.)
Also, in places where we use a string enum (such as the stretch mode project setting), we use snake_case strings instead of PascalCase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume I just copied how it was done for the screen orientation (which was before you changed it to an integer enum). But you are right, an integer enum is cleaner as it wouldn't need that ugly if-elseif construct in main.cpp. I will open a PR soon to change that.
virtual void window_set_vsync_mode(DisplayServer::VSyncMode p_vsync_mode, WindowID p_window = MAIN_WINDOW_ID) override; | ||
virtual DisplayServer::VSyncMode window_get_vsync_mode(WindowID p_vsync_mode) const override; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class didn't have override
before this, so now Clang complain about the others that are missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the use of override
desired? If so, I could add it where it should be (only display_server_iphone and display_server_osx use it currently), otherwise I could open a PR to remove the keyword from all display_server classes except osx and iphone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the use of
override
desired?
Yes, it is. I'm not sure why it wasn't used in those classes before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened a PR for this: #50513
This PR is a complete reorginization of the v-sync related code for DisplayServers with the changes discussed here and on IRC. So it's no longer a reimplementation of PR #36862, altough @giarve's work was very helpful.
-> can be modified via project settings or via code at runtime [for Windows, Linux and OSX]
-> fallback to VK_PRESENT_MODE_FIFO_KHR if the desired mode is not supported
-> No engine restart is required for a change of the vsync-mode setting