[bug?] Timer time_left decreases unexpectectly when started as soon as the scene is initialized

I have the following situation: A Timer (wait_time = 1second) is started as soon as the scene initializes (e.g. with _ready() or with a signal emitted as soon as the scene initializes). This causes the timer to last significantly less than 1 second.

After some testing it seems like the frame after the signal is emitted the wait_time is significantly smaller than it should (see code below). Is this a bug or am I doing something wrong?

Minimal reproduction project: Single Timer node with the following script

extends Timer

func _ready():
	wait_time = 1
	start()

func _process(delta):
	print(time_left)

The output is:

0.935927
0.93333333333333
0.92407566666667
0.92328091666864
0.91494758333531
0.90828091666864
0.89994758333531

I want to highlight that the same occurs when the timer is started with a signal (like on_area/mouse_entered) if the signal is emitted as soon as the scene is initialized.

What happens if you try this?

extends Timer

func _ready():
	wait_time = 1
	start()
	print(Time.get_unix_time_from_system())

func _on_timeout() -> void:
	print(Time.get_unix_time_from_system())

I find it gives more accurate results than relying on _process which doesn’t have any guarantee of how often it’s called.

For example I get:

Godot Engine v4.2.stable.official.46dc27791 - https://godotengine.org
Vulkan API 1.3.271 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 3070 Laptop GPU
 
1723190876.444
1723190877.426
1723190878.426
1723190879.426
1723190880.426
1723190881.426
1723190882.426
--- Debugging process stopped ---

As you can see in your output, the problem remains.

Note that your first print (when the timer starts) and the second one (when _on_timeout is called for the first time) differ by 0.982. As for me, when I run your script I get

Godot Engine v4.2.1.stable.official.b09f793f5 - https://godotengine.org
Vulkan API 1.3.262 - Forward Mobile - Using Vulkan Device #0: AMD - AMD Radeon RX 6650 XT
 
1723208356.287
1723208357.232

which gives a first difference of 0.945.

Seems like the magnitude of the issue is hardware-dependent, but the error is always noticeable.

The first couple of seconds could be off anyway, although the scene is up and running there could still be some background initialisation occuring. I get what you’re saying though. The best thing you could do is open it as a bug on github and see what happens.

1 Like