Problem with .visible change

Question

My android game has only one scene. Under one Node2D (/root/Game/Node2D) I have all the game play itself, under another Node2D (/root/Game/Node2D) I have a GameOver screen. The GameOver screen is static, it has 2 sprites and a label with a tween to animate the scale and a sound.
When it's game over, my game sends a "gameover" signal, and the game over function picks the signal, changes the game Node2D.visible to false and the GameOver Node2D.visible to true.
Running this on a fast phone is immediate. If I run this on a older phone, the game freezes the image and I start to hear the sound. When the image finally changes to the Game Over screen, the tween animation is almost done and the sound it's complete.
I thought this could be related to resources, yet, the game is doing solid 60fps and, what's more strange, when I play again (2nd run on the same load) it doesn't freeze at all - looks like it cached something. But I load nothing for the GameOver screen, everything is defined in the editor.
I've tried using direct function call instead of signals, it's the same behaviour. I've tried threads, I've tried having a "while" loop in the GameOver function to do nothing while the game's Node2D is visible - but the property changes immediately to visible = false although it continues to show, preventing my game over screen to appear.
I'm out of ideas. Can someone please help?

Comments

Have you looked into using the call_deferred() function? Maybe the game over scene has to wait for some other processes to finish before appearing.

---

I think everything is "behaving properly" before passing control to Game Over - I'm having the game nodes using a queue_free method when they receive the game over signal. I've traced the game, step by step with the debugger and can't understand what is halting the execution, especially because it's only the first time, on the second it doesn't even blink.
Anyway, I'm changing the code to be scene-oriented, where I'll have a scene for the gameplay, a scene for the gameover bit, and a scene for the menus. If this doesn't solve the problem, at least it may stop the gameover sound effect to play before the letters show up.

---

Changed things around and implemented different scenes. The result is the same. The singleton changes the gameplay scene and loads the gameover scene. While the sound of the newly loaded gameover scene plays, the image of the gameplay scene is still (for over 1 second) on screen. I didn't knew it was possible to have both scenes running at once, even after unloading one and loading another.
Almost two months of Godot and I guess I'm still around with the basics :-(

---

This is the graph of my problem.
Can this data help to explain my problem? Does this provide any clues to where the bottleneck might be?
Is it the code? Is it the audio? (I find this value for audio strange, since I'm just stoping the music and start playing a sound. Since that is defined in the editor, doesn't that mean that the audio files are cached already by this time?) Where can I look more to find whats causing this huge freeze?

Answer 1

Solved

After some days of guessing and trying, I've finally solved the freeze problem with my game transitioning to Game Over.
The problem was a tween with a font using outline. For some reason, the engine would just freeze in the current frame while calculating the tween. That is why the sound and code execution carried on but not the image - the frame was stuck :-)
As soon as I removed the outline and shadow from my GameOver label that had scaling with the tween, the performance was great.
To maintain the visual effect I took a screenshot of the letters as I liked them and made a tween with the image - same effect, acceptable performance - as show above.
I don't know if this situation with tweening outlined fonts completely messing the performance is a bug or not. Anyway, I leave this message as a way to eventually help other people faced with this kind of weird problems.

Comments

If you animate or tween a DynamicFont parameter that requires re-rendering the font, it will be very slow. In general, it's not recommended to animate parameters that only accept integer values anyway (as it won't look smooth).