Deprecate the pointless unsafe threading model for rendering

[RandomShaper]

The "single-unsafe" thread model for rendering wasn't actually honored in Godot 4, as there's no way it can work despite user's best efforts. Therefore, this PR finally removes the option, or rather deprecates it.

The project setting is remodeled so it looks like the counterpart settings for physics. The takeaway is that projects that were using separate-thread rendering need to change the setting again. It's still considered experimental, so I don't think that's a big issue as long as the fact is documented in the release notes.

[clayjohn]

Couldn't we do this without breaking compatibility? Just change the project setting to only the two choices, and then if we run into a project file set to use single unsafe, just automatically promote it to single safe internally?

I'm not sure if this is worth breaking compatibility over.

[RandomShaper]

My point is that separate-thread rendering was experimental anyway, so the compat breakage doesn't even deserve such a name. Moreover, CLI args remain compatible. This will only affect the (expectedly tiny) set of users which have opted-in for the experimental feature. I guess those can just change the setting when upgrading to 4.4 if they still want to use it.

That said, it's not that I'm super strongly leaning towards that, so if you think the risk is not worth it, I can make this fully backwards compatible.

[Mickeon]

The experimental hint is fairly obvious even for Project Settings, so long as the user actually reads before changing advanced settings like these. I think breaking compatibility should be... okay, although it's really weird to me that the experimental note has been referring to the whole setting, instead of the one specific value that is experimental.

[clayjohn]

My point is that separate-thread rendering was experimental anyway, so the compat breakage doesn't even deserve such a name. Moreover, CLI args remain compatible. This will only affect the (expectedly tiny) set of users which have opted-in for the experimental feature. I guess those can just change the setting when upgrading to 4.4 if they still want to use it.

That said, it's not that I'm super strongly leaning towards that, so if you think the risk is not worth it, I can make this fully backwards compatible.

To me it's not about taking a risk. It's about annoying users with a compatibility breakage that doesn't benefit them or us.

Personally, I would prefer removing this option without breaking compatibility, and I'm fairly sure that is possible.

[Mickeon]

It is indeed possible, and much easier to do so than transferring both options into a boolean.

[RandomShaper]

I'm not sure how I could tweak the enumerated setting.

If only I could do something like this (note the made up =1 syntax):

#ifdef DISABLE_DEPRECATED
custom_prop_info["rendering/driver/threads/thread_model"] = PropertyInfo(Variant::INT, "rendering/driver/threads/thread_model", PROPERTY_HINT_ENUM, "Single-Safe=1,Multi-Threaded");
#else
custom_prop_info["rendering/driver/threads/thread_model"] = PropertyInfo(Variant::INT, "rendering/driver/threads/thread_model", PROPERTY_HINT_ENUM, "Single-Unsafe (deprecated),Single-Safe,Multi-Threaded");
#endif

How would you recommend me approaching this?

[Mickeon]

PROPERTY_HINT_ENUM's hint string supports suffixing : followed by an integer to denote a specific value. If not specified it increments the value by 1 for the next option.

"Single-Safe:1,Multi-Threaded"

[RandomShaper]

OK. Please tell me what you think now. The approach is keeping it compatible to the outside (project setting, CLI args) with the internals refactored to account for the actual functionality.

[Mickeon]

Is the experimental note in the class reference still relevant, then?

"This setting has several known bugs which can lead to crashing, especially when using particles or resizing the window. Not recommended for use in production at this stage."

[RandomShaper]

Separate thread model is still not considered stable, so I think so.

[RandomShaper]

Is this OK now?

[Repiteo]

Thanks!