godotengine
Disable creating RD projects in project manager if RD is not supported
This is a proof of concept to help alleviate the problem for new users with devices that don't support Vulkan/D3D12/Metal.
This works as a stopgap measure if we want. But I think it would be better to address a couple of things before merging:
- Is disabling the button really an appropriate UX? Or should we hide the buttons altogether with a message to the user?
- This will attempt to create an RD context every time the ProjectManager is opened which will significantly slow down project opening on some devices. We should avoid doing this unless we need to.
- Should we abstract the RD checking functionality into another place? This code will fail on macOS once the Metal renderer is added. A helper function could be used in other places like https://github.com/godotengine/godot/pull/91150 and in the lightmapper
Screenshot of this working, but it might be confusing for users
Is disabling the button really an appropriate UX? Or should we hide the buttons altogether with a message to the user?
I'd take a middle ground: keep the radio buttons clickable but disable the "Create & Edit" button itself, along with a warning message.
Is disabling the button really an appropriate UX? Or should we hide the buttons altogether with a message to the user?
I'd take a middle ground: keep the radio buttons clickable but disable the "Create & Edit" button itself, along with a warning message.
I like that. We could also defer validation until the new Project Dialog is opened so we don't slow down opening the project manager
This will be helpful to implement https://github.com/godotengine/godot-proposals/issues/8006. We might want to extract this to a standard location and perhaps set a variable that can be fetched with a getter method, so projects can know whether Vulkan/D3D12 are supported on the current device (even if the project is running with Compatibility).
This will also be helpful for LightmapGI baking when using the Compatibility rendering method, so the node configuration warning can be displayed only when relevant.
Regarding startup performance issues, can the RD context be created in a non-blocking manner on startup? The "RD is supported" variable can be set once it's done being created.
This is ready to review again! I made the changes suggested by riteo and calinou
Regarding startup performance issues, can the RD context be created in a non-blocking manner on startup? The "RD is supported" variable can be set once it's done being created.
I don't think so. But I measured the cost and it appeared to be minimal (5 ms) . So it might not be worth worrying about
