Save progress popup's content is too small #92971
Labels
Milestone
Comments
|
Bisecting points to #92645 as the culprit:
|
CardboardCarl
pushed a commit
to CardboardCarl/godot
that referenced
this issue
Jun 25, 2024
When Container::queue_sort() is called, pending_sort is set to true to indicate when a call to _sort_children() is queued, to avoid queueing multiple calls. Container::_sort_children() sets pending_sort back to false when finished, but did not do this when the container was not inside the tree. This would allow cases where queue_sort() could be called just before removing from the tree, causing _sort_children() to never reset pending_sort, preventing any future queue_sort() calls from queueing again. One case where this happened was with the "Saving Scene" progress bar in the editor - when saving for the first time (or the first time the progress bar popup otherwise appeared in the editor), _sort_children() would be called successfully. After the progress bar popup was hidden, then shown again on future saves, _sort_children() would not be called again, resulting in the progress bar not taking up as much space as it should. This issue used to be avoided by setting pending_sort to false immediately on NOTIFICATION_ENTER_TREE - however, this would allow multiple calls to be queued at the same time when entering the tree (godotengine#92644). The multiple calls was fixed recently by removing this assignment, but this also made possible the case where pending_sort is never reset. This change sets pending_sort back to false in _sort_children() whether or not it's in the tree. Since this is done in a deferred call, it should still avoid the previous issue of multiple calls being queued at once on entering the tree. Fixes godotengine#92971
RadiantUwU
pushed a commit
to RadiantUwU/godot
that referenced
this issue
Jun 27, 2024
When Container::queue_sort() is called, pending_sort is set to true to indicate when a call to _sort_children() is queued, to avoid queueing multiple calls. Container::_sort_children() sets pending_sort back to false when finished, but did not do this when the container was not inside the tree. This would allow cases where queue_sort() could be called just before removing from the tree, causing _sort_children() to never reset pending_sort, preventing any future queue_sort() calls from queueing again. One case where this happened was with the "Saving Scene" progress bar in the editor - when saving for the first time (or the first time the progress bar popup otherwise appeared in the editor), _sort_children() would be called successfully. After the progress bar popup was hidden, then shown again on future saves, _sort_children() would not be called again, resulting in the progress bar not taking up as much space as it should. This issue used to be avoided by setting pending_sort to false immediately on NOTIFICATION_ENTER_TREE - however, this would allow multiple calls to be queued at the same time when entering the tree (godotengine#92644). The multiple calls was fixed recently by removing this assignment, but this also made possible the case where pending_sort is never reset. This change sets pending_sort back to false in _sort_children() whether or not it's in the tree. Since this is done in a deferred call, it should still avoid the previous issue of multiple calls being queued at once on entering the tree. Fixes godotengine#92971
Crashim03
pushed a commit
to Crashim03/godot
that referenced
this issue
Jun 29, 2024
When Container::queue_sort() is called, pending_sort is set to true to indicate when a call to _sort_children() is queued, to avoid queueing multiple calls. Container::_sort_children() sets pending_sort back to false when finished, but did not do this when the container was not inside the tree. This would allow cases where queue_sort() could be called just before removing from the tree, causing _sort_children() to never reset pending_sort, preventing any future queue_sort() calls from queueing again. One case where this happened was with the "Saving Scene" progress bar in the editor - when saving for the first time (or the first time the progress bar popup otherwise appeared in the editor), _sort_children() would be called successfully. After the progress bar popup was hidden, then shown again on future saves, _sort_children() would not be called again, resulting in the progress bar not taking up as much space as it should. This issue used to be avoided by setting pending_sort to false immediately on NOTIFICATION_ENTER_TREE - however, this would allow multiple calls to be queued at the same time when entering the tree (godotengine#92644). The multiple calls was fixed recently by removing this assignment, but this also made possible the case where pending_sort is never reset. This change sets pending_sort back to false in _sort_children() whether or not it's in the tree. Since this is done in a deferred call, it should still avoid the previous issue of multiple calls being queued at once on entering the tree. Fixes godotengine#92971
MewPurPur
pushed a commit
to MewPurPur/godot
that referenced
this issue
Jul 11, 2024
When Container::queue_sort() is called, pending_sort is set to true to indicate when a call to _sort_children() is queued, to avoid queueing multiple calls. Container::_sort_children() sets pending_sort back to false when finished, but did not do this when the container was not inside the tree. This would allow cases where queue_sort() could be called just before removing from the tree, causing _sort_children() to never reset pending_sort, preventing any future queue_sort() calls from queueing again. One case where this happened was with the "Saving Scene" progress bar in the editor - when saving for the first time (or the first time the progress bar popup otherwise appeared in the editor), _sort_children() would be called successfully. After the progress bar popup was hidden, then shown again on future saves, _sort_children() would not be called again, resulting in the progress bar not taking up as much space as it should. This issue used to be avoided by setting pending_sort to false immediately on NOTIFICATION_ENTER_TREE - however, this would allow multiple calls to be queued at the same time when entering the tree (godotengine#92644). The multiple calls was fixed recently by removing this assignment, but this also made possible the case where pending_sort is never reset. This change sets pending_sort back to false in _sort_children() whether or not it's in the tree. Since this is done in a deferred call, it should still avoid the previous issue of multiple calls being queued at once on entering the tree. Fixes godotengine#92971
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tested versions
4.3 beta 32eba1e
Not happening in 4.3 beta1.
System information
Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 (NVIDIA; 31.0.15.4633) - Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 Threads)
Issue description
godot.windows.editor.dev.x86_64_DkOuuniywW.mp4
Happens every time.
Steps to reproduce
Minimal reproduction project (MRP)
N/A
The text was updated successfully, but these errors were encountered: