Make the behavior of rendering/rendering_device/driver consistent with --rendering-device

[scgm0]

Currently, the --rendering-device command supports direct switching between d3d12, vulkan, and opengl3, among others. Although the rendering/rendering_device/driver setting in the configuration file can also be set to opengl3, doing so may cause rendering bugs in child windows:

Through examining the source code, I discovered that this occurs because when reading --rendering-device, if rendering_driver is set to opengl3, it automatically sets rendering_method to gl_compatibility. However, reading from the configuration file does not trigger this behavior, so I added it manually.
This is not the conventional usage of rendering/rendering_device/driver, but I'd like to allow users to switch rendering APIs via override.cfg in my project. Whether it's d3d12, vulkan, or opengl3, different users have reported rendering issues with each. Previously, users could only switch APIs using --rendering-device, which wasn't very convenient. Enabling rendering/rendering_device/driver to be properly set to opengl3 would be much more user-friendly (sparing users the need to simultaneously change both rendering/renderer/rendering_method and rendering/rendering_device/driver).

[Calinou]

Code looks good to me.

[clayjohn]

Has anyone had trouble with this, or are we just making this change because we can?

To me to seems incredibly confusing to give the users the option to set a rendering driver that we know doesn't exist.

It's different with command line arguments because we can't give immediate feedback. With project settings, we can immediately tell the user that the value they input is invalid if the property accepts a string, or not provide the option if we can provide a fixed list.

[scgm0]

Has anyone had trouble with this, or are we just making this change because we can?

To me to seems incredibly confusing to give the users the option to set a rendering driver that we know doesn't exist.

It's different with command line arguments because we can't give immediate feedback. With project settings, we can immediately tell the user that the value they input is invalid if the property accepts a string, or not provide the option if we can provide a fixed list.

As I mentioned, it's not a conventional usage. In my own application, I provide a fixed list, but certain edge cases require users to manually modify the configuration file (for example, using d3d12 in wine—the application runs, but the screen remains entirely black, which doesn't trigger a fallback to the rendering driver). If users choose to edit the configuration file manually, they should know what they're doing, and even if they make a mistake, they still have a chance to correct it. (Note: The users here are not Godot users but rather users of the application I developed using Godot.)

Even without this PR, the valid options still include opengl3_x, just as RenderingServer.get_current_rendering_driver_name() would return opengl3_x. However, directly setting rendering/rendering_device/driver to opengl3_x would cause a bug due to an incorrect rendering/renderer/rendering_method.

Currently, it indeed lacks a check. I can add one—should I?

[Calinou]

or not provide the option if we can provide a fixed list.

Note that the engine currently doesn't provide this list for projects to use, but #109247 makes it possible.

[scgm0]

@clayjohn How to promote the merging of this PR?

[clayjohn]

@clayjohn How to promote the merging of this PR?

You can make a proposal and see if other people have the same use-case as you.

[scgm0]

@clayjohn How to promote the merging of this PR?

You can make a proposal and see if other people have the same use-case as you.

However, I believe this PR also falls under bug fixes. Currently, rendering/rendering_device/driver allows users to freely switch between vulkan, d3d12, or opengl3_x. When set to opengl3_x, the main window can render normally, but because rendering/renderer/rendering_method does not change to gl_compatibility, it causes rendering issues with child windows.