Skip to content

Fix ProgressDialog errors during first scan.#108893

Merged
Repiteo merged 1 commit intogodotengine:masterfrom
mounirtohami:editor-wayland
Jul 25, 2025
Merged

Fix ProgressDialog errors during first scan.#108893
Repiteo merged 1 commit intogodotengine:masterfrom
mounirtohami:editor-wayland

Conversation

@WhalesState
Copy link
Copy Markdown
Contributor

@WhalesState WhalesState commented Jul 23, 2025

Note: On Windows, minimizing the window while loading the project no longer throw errors, other issues can't be reproduced since users have reported that it happens randomly and I think they have minimized the window during loading without noticing it was the main reason.

@WhalesState WhalesState requested review from a team as code owners July 23, 2025 05:55
@WhalesState WhalesState requested a review from a team July 23, 2025 05:55
Window *current_window = SceneTree::get_singleton()->get_root()->get_last_exclusive_window();
ERR_FAIL_NULL(current_window);
reparent(current_window);
callable_mp((Control *)this, &Control::reparent).call_deferred(current_window, true);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't use reparent during first scan.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering whether it's worth deferring all the reparent and show calls just to fix an issue that only affects the first scan. These calls work fine with all other tasks.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the issue is that current_window is setting up children at the time, you can use is_ready() to check if you can reparent immediately.

command_palette->register_shortcuts_as_command();

callable_mp(this, &EditorNode::_begin_first_scan).call_deferred();
EditorNode::_begin_first_scan();
Copy link
Copy Markdown
Contributor Author

@WhalesState WhalesState Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First scan should be called as soon as possible after entering tree, delaying it causes issues when flushing the MessageQueue.

Copy link
Copy Markdown
Contributor Author

@WhalesState WhalesState Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: This line was added here #64610, so i will test with editor startup benchmark to make sure it doesn't cause any further issues.

Edit:
Benchmarks still work without any issues.

@WhalesState WhalesState changed the title Fix Editor wayland first scan task error. Fix ProgressDialog error during first scan. Jul 23, 2025
@WhalesState WhalesState changed the title Fix ProgressDialog error during first scan. Fix ProgressDialog errors during first scan. Jul 23, 2025
@Calinou Calinou added this to the 4.5 milestone Jul 23, 2025
@KoBeWi
Copy link
Copy Markdown
Member

KoBeWi commented Jul 24, 2025

I think they have minimized the window during loading without noticing it was the main reason.

I don't think it's safe to assume that for both issues, but indeed, this is what triggers the error. Specifically, editor checks for can_draw() here (false when minimized):

godot/editor/editor_node.cpp

Lines 5621 to 5623 in e0603ae

if (!DisplayServer::get_singleton()->window_can_draw()) {
OS::get_singleton()->benchmark_begin_measure("Editor", "First Scan");
EditorFileSystem::get_singleton()->scan();

And then here for cmdline_mode:

godot/editor/editor_node.cpp

Lines 5357 to 5359 in e0603ae

} else if (singleton->cmdline_mode) {
print_line_rich(vformat("[ 0%% ] [color=gray][b]%s[/b] | Started %s (%d steps)[/color]", p_task, p_label, p_steps));
progress_total_steps = p_steps;

This inconsistency is what's causing the errors, but not sure if this is the only way to trigger them.

current_window->set_disable_input(window_is_input_disabled);

show();
callable_mp((CanvasItem *)this, &CanvasItem::show).call_deferred();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this needs to be deferred?

Copy link
Copy Markdown
Contributor Author

@WhalesState WhalesState Jul 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid showing the dialog before reparent, is it ok to make it visible first then changing its parent ? I just have tried to avoid any further issues that may happen because of this.

previously the reparent happened before showing the dialog and i tried to keep it the same as before.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Showing it earlier shouldn't cause problems, but deferring makes sense.
It would be nice if the 2 deferred calls were done together, either just moved to be one after another, or as part of a separate method (like _reparent_and_show() which would then be deferred instead).

@WhalesState
Copy link
Copy Markdown
Contributor Author

WhalesState commented Jul 24, 2025

I think they have minimized the window during loading without noticing it was the main reason.

I don't think it's safe to assume that for both issues, but indeed, this is what triggers the error. Specifically, editor checks for can_draw() here (false when minimized):

I have found that the main issue was because first scan is deferred then MessageQueue::flush is called from SceneTree::physics_process at the same frame where the dialog is trying to show the first scan task progress, so i wonder if it's also what makes can_draw return false because it's solved with the current changes and I was unable to reproduce the same issue again.

Copy link
Copy Markdown
Member

@KoBeWi KoBeWi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some code comments, but otherwise works correctly.

Co-authored-by: Tomasz Chabora <kobewi4e@gmail.com>
@WhalesState
Copy link
Copy Markdown
Contributor Author

WhalesState commented Jul 24, 2025

Some code comments, but otherwise works correctly.

Applied the changes from the comments and rebased, Thank you.

@Repiteo Repiteo merged commit 0dd9178 into godotengine:master Jul 25, 2025
20 checks passed
@Repiteo
Copy link
Copy Markdown
Contributor

Repiteo commented Jul 25, 2025

Thanks!

@mihe
Copy link
Copy Markdown
Contributor

mihe commented Jul 26, 2025

This PR seems to have broken headless imports: #108990.

I'd guess headless exports as well, but I haven't checked.

@WhalesState

This comment was marked as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

5 participants