JavaScript callback for web export fails if physics off and key is held down.

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By zaphara

We run python in our web application and this communicates with Godot web export.

To keep python code and godot synchronized we allow godot to run physics for a set number of times and then we shut physics off using:

PhysicsServer.set_active(false)

We wait until we get the next update from our python code and then turn physics back on. This seems to work perfectly fine and we get a well-defined behavior for our RigidBody physics.

Python sends godot a callback via JavaScript.create_callback to inform godot that the next python cycle is ready.

Now the bug:

On some windows machines if the user presses and holds any key godot stops receiving the callback. This seems to happen right when the OS triggers the key repeat event (not when the key is initially pressed).

This only happens if we have our locks turning physics on/off. If we keep physics always running the problem does not occur. The mystery is why the input issue is related to the physics engine at all?

So it would seem that somewhere godot says some logic like this:

if anykey==repeating and physics==false:
    ignore_callbacks = true

On a Mac I don’t see the blocking behavior but I can measure a performance hit for key down events even though we are not using the key for anything. I am guessing the performance hit seen on a Mac is related to the blocking behavior we see on windows. Some other windows machines have shown no problem at all though.

I hope for some insight or perhaps someone can point us to the code in godot that might cause this behavior. If I can learn about it we can fix it or work around the issue. Many thanks.

Also if the key is released the callbacks then continue normally.

But perhaps more importantly, if any other key is pressed and released, that will also clear the issue and callbacks resume, even if the original key is still held down.

So it would seem Godot is waiting for any key up event before resuming callbacks.

zaphara | 2023-02-09 20:54

We continue to learn more about the issue:

This is not a windows specific issue. On a Mac I have set the system key repeat to the maximum. Then when holding a key we see the performance rate for the JavaScript callback falling significantly once key repeat begins (not the original key press).

However if we press any other key and release (while still holding the original key) the action of releasing the key completely clears the performance problem. JavaScript callbacks are now processing fine even though the original key is still down.

So on a Mac I see low performance for the callback and on Windows I see it get completely jammed - but the action of releasing any other key (triggering a key up event) causes the same effect on both. It clears the issue. So for this reason I feel confident it’s not platform specific code.

Also the connection to the physics manager being on/off always suggested it was not platform specific.

zaphara | 2023-02-11 12:05

So we are trying to simulate the key up with:

get_tree().input_event(event)

That call seems to give us a fairly low level entry point. A real event calls

parse_input_event
_parse_input_event_impl
input_event

We miss a little bit of code. So we have tried:

Input.set_use_accumulated_input(false)

Also we tried in various places:

flush_buffered_events()

But we had not luck yet. It’s unclear what distinguishes the real event from our simulated event. Perhaps the different location in the main loop cycle.

Probably we will need to build our own godot, setup new exports, and add some debugging logs. The mystery is still why this is connected to the JavaScript callback handling and why this is connected to the physics manager being turned on/off.

zaphara | 2023-02-11 12:15