Fix accessing UID before first scan

[Hilderin]

• Fixes minimal project doesn't import errorless (main_scene uid) #101677
• Fixes [4.4.dev7] The Default Environment setting is reset after the "cold" project loading (res:// | uid:// issue) #100915

This PR should fix most of the issues where Godot tries to access an UID before the first scan is done and when the UID cache is missing, incomplete or invalid.

The idea is to execute a scan for UIDs on startup if an UID is used before the first scan. This scan is done a maximum of one time and, if executed, replaces the "normal" first scanning which loads the file structure of the project into first_scan_root_dir.

One potential problem with large project is that the scanning could take a while and the user has no feedback.

Also, the plugins are, maybe, not loaded when the scan of UIDs is executed. That means that it's possible that some custom loader will be missing, resulting in an impossibility to read some UIDs.

Tested with the MRP from #101677 and #100915.

[mihe]

One potential problem with large project is that the scanning could take a while and the user has no feedback.

For what it's worth, when testing this PR on a real-world project with thousands of resource files, I'm not seeing any noticeable regression in pure wall time when deleting uid_cache.bin and measuring from editor start to when all the various scan dialogs and progress bars are gone.

[Hilderin]

I did some tests this morning, and below are the added loading times for the editor when the UID cache is missing, and a UID is required before the first scan (e.g., run/main_scene project settings):

• 3000 files (without .import and .uid): 1.5 sec
• 60000 files (without .import and .uid): 48 sec

One way to improve this could be to avoid scanning the entire project when looking up a single UID and instead stop as soon as it is found. However, the challenge and potential drawback of this approach is that if multiple UIDs are needed, multiple rescans may be required.

That's why I suggest scanning everything. Technically, this "scan for UIDs" should not happen often, except in CI/CD environments where the UID cache will always be missing.

[mihe]

• 3000 files (without .import and .uid): 1.5 sec
• 60000 files (without .import and .uid): 48 sec

Right, yeah, the "real-world project" in question was definitely closer to 3k than 60k. A second here or there wasn't really what I was looking out for. :)

[KoBeWi]

Fixes the issues.

Tested with my big project and the scan was not noticeable. I tested by deleting uid_cache.bin and filesystem_cache10 and I assume the project is supposed to hang on splash screen.

However there is one error remaining - if your splash screen path is stored as UID, you will still get an error about unrecognized UID.

[Hilderin]

Thanks for the review and testing.

Fixing the boot splash screen will be a bit trickier. The problem is that the logo is loaded before the resources format importers are loaded. If I move ResourceUID::scan_for_uid_on_startup = EditorFileSystem::scan_for_uid; just before setup_boot_logo, the ResourceFormatImporter::get_singleton()->get_recognized_extensions returns no extensions. That causes to not be able to get the UID for extensions like .tscn.

Since the issue is not supposed to happen that often, I did a little check before callingResourceUID::ensure_path on the boot logo path to prevent printing errors.

The alternative could be to display the boot logo later in the start sequence or put the loading of the ResourceFormatImporter sooner, but I fear that could lead to serious side effects and this close to a release candidate, I think it's a bad idea for this small issue.

[KoBeWi]

Yeah, removing errors is enough.

[KoBeWi]

I did a little check before callingResourceUID::ensure_path on the boot logo path to prevent printing errors.

Did you test whether it fixes the errors? 🙃

If the UID is not available, it should make the path empty to fallback to default splash screen.

[Hilderin]

Really sorry about that, I went too fast! Tested correctly this time!