Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

queue_redraw triggers redraw immediately multiple times per frame without queuing #99443

Closed
anthonyronda opened this issue Nov 19, 2024 · 3 comments · Fixed by #97328
Closed

Comments

@anthonyronda
Copy link

anthonyronda commented Nov 19, 2024

Tested versions

Tested versions

  • Reproducible in 4.3.stable
  • Not reproducible in 4.2.2.stable

System information

Godot v4.3.stable - macOS 14.6.1 - Vulkan (Forward+) - integrated Apple M1 - Apple M1 (8 Threads)

Issue description

Calling queue_redraw() somewhere in the callstack of a node script's _draw() function caused it to redraw continuously, hanging the game on frame 0.

Although queue_redraw()'s documentation says a redraw is triggered only once per frame even when you call it multiple times, that is evidently not the case in 4.3.stable.

When inserting a workaround provided in another issue where there was a queuing regression #88953 (comment), the redraw is forced to wait a frame and the problem went away.

Steps to reproduce

Run MRP project. Test in both 4.2.2.stable and 4.3.stable to see the difference. Uncomment the workaround provided in the project.

  • In 4.2.2.stable, the TextureRect starts with a green border. When you hover over it, it has a red border. When mouse_exit is triggered, you have a blue border.
  • Note that in 4.3.stable, the print statement is printing the current frame 0 thousands of times. You probably will crash and not load properly.
  • In the provided commented out workaround, redraw is only called after the current frame is processed, and so the game loads and runs normally.

Minimal reproduction project (MRP)

queue_redraw-triggers-redraw-immediately-without-waiting-1-frame.zip

@AThousandShips
Copy link
Member

AThousandShips commented Nov 19, 2024

This sounds like:

And is solved by:

If you are able to test please confirm, but should be that bug

The referenced deferred call bug is a different issue, this is caused by issues when specifically entering the first frame, see the PR for details on why this is the case

@anthonyronda
Copy link
Author

anthonyronda commented Nov 20, 2024

Confirming that #97328 works in my MRP and in my game, thanks :)

@AThousandShips
Copy link
Member

Thank you for confirming! Linked my PR to this as a solution

@AThousandShips AThousandShips added this to the 4.4 milestone Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants