The mythical GDExtension to decouple input from rendering

mayormaynotbeacat · April 30, 2026, 3:40am

Godot Version

4.6.2

Question

I have heard repeatedly from multiple online sources that input in Godot could be decoupled from rendering with a GDExtension.

Does this extension exist?
Is there something built in to Godot that would do the same thing as this extension?

I just don’t want to spend hours looking this up or figuring out how to wrangle Google Search into displaying what I want to know.

normalized · April 30, 2026, 4:00am

What do you mean by “decouple”? In what way is rendering coupled with input in Godot and what purpose would this “decoupling” serve?

mayormaynotbeacat · April 30, 2026, 4:20pm

github.com/godotengine/godot-proposals

Separate input polling from render thread

opened 07:22AM - 01 Aug 20 UTC

iBoonie

topic:input

I thought this deserved a mention https://github.com/godotengine/godot/issues/26…828 coming from a FPS background, it drives me insane when there is any input delay. **Describe the project you are working on:** FPS project. **Describe the problem or limitation you are having in your project:** No problem, but having fluid input 100% of the time would be very nice. **Describe the feature / enhancement and how it helps to overcome the problem or limitation:** If input is polled in the render thread and the game lags at all, it introduces input lag. Unity, Unreal, Source and all major engines have this problem (although it's being fixed in Unity https://github.com/Unity-Technologies/InputSystem). If a user can't reach high enough frame-rates, they will have input lag. Polling in a separate thread would eliminate this problem. Instead of getting input lag, you would just get visual frame skip when moving your mouse (which is still present when you poll at lower rates anyway). The advantage of this is it will make input feel snappy all the time (for both mouse and keyboard input). Example: If the input was polled in a separate thread and a person flicked their mouse the same distance at 15fps and 300 fps, it would land in the same spot at the exact same time (although the 15 fps player would skip/chunk a lot of frames). More info: https://www.epicgames.com/unrealtournament/forums/unreal-tournament-discussion/ut-development-bug-reports-qa/3209-mouse-input-issues-concerns-and-what-will-be-done-about-it https://www.epicgames.com/unrealtournament/forums/unreal-tournament-discussion/ut-development-bug-reports-qa/16532-mouse-input-investigation https://www.reddit.com/r/GlobalOffensive/comments/6y47m8/ https://www.reddit.com/r/reflex/comments/499s68/ https://www.reddit.com/r/Competitiveoverwatch/comments/6xet7k/ **Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:** It's possible to implement this using GDNative or using a Module, but having it directly in the engine would be best. **If this enhancement will not be used often, can it be worked around with a few lines of script?:** If implemented, everyone would be using it. **Is there a reason why this should be core and not an add-on in the asset library?:** Everyone deserves fluid input, it would make the user experience better for everyone (especially people on lower spec machines). Having it in engine while most others don't would be a nice step above.

github.com/godotengine/godot-proposals

Add OS time to InputEvent (input timestamp)

opened 04:12AM - 04 Mar 20 UTC

supagu

topic:input

**Describe the project you are working on:** I am working on a real time stra…tegy game **Describe the problem or limitation you are having in your project:** I am attempting to detect mouse wheel acceleration so I can zoom the camera in and out smoothly. **Describe the feature / enhancement and how it helps to overcome the problem or limitation:** I would like to see InputEvent include a time value which is populated with the time the OS says the input event occurred. Currently Godot accumulates input events and fires them all off at the same time, so I loose the precise timing of when the events actually occurred (according to the OS) making it impossible to determine intervals between input events when the frame rate is low (< 20fps) **Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:** Here is a patch file that adds linux support: [input_time.zip](https://github.com/godotengine/godot-proposals/files/4284993/input_time.zip) The proper solution should map the OS time into the godot time somehow. **If this enhancement will not be used often, can it be worked around with a few lines of script?:** No there is no way to work around this. **Is there a reason why this should be core and not an add-on in the asset library?:** This is not possible to be done as a plugin.

In particular, that second one mentions that timestamped input polling could be done in a GDExtension. It would be really nice for the game idea I have for either of these to happen.

normalized · April 30, 2026, 5:33pm

Are you sure you need this?

mayormaynotbeacat · April 30, 2026, 6:49pm

I am planning to make a rhythm game, so it would be really nice to have, since it would mean that FPS != polling rate. However, I could also just keep the effects down, crank up the engine’s FPS, and tell the user about that piece of jank. I’m also planning to open source it, so chances are if the game gets popular enough someone might be pissed enough to make it for me.

Taking care of it now would be nice, but I can move forward without it.

normalized · April 30, 2026, 6:55pm

You can have a lot of effects and still run at 60 or even 120 fps.

Doing it via an extension would likely require getting the input directly from the os or some low level library. I’m not aware of existence of such an extension though.

mayormaynotbeacat · April 30, 2026, 7:34pm

You can have a lot of effects and still run at 60 or even 120 fps.

Unfortunately, my goal is 250+ min FPS on a 780M, since that is what I would consider to be the bare minimum acceptable polling rate. The good news is I shouldn’t need that many FX to make it work, but I’d need to make a working prototype first.

Doing it via an extension would likely require getting the input directly from the os or some low level library. I’m not aware of existence of such an extension though.

I think Godot uses SDL to do input polling, so any solution would, in theory, be OS agnostic. The extension would literally be just spinning off another thread to get input from the OS at about 1000Hz, though the hard part would be communicating the inputs to the main thread.

normalized · April 30, 2026, 7:42pm

Why? If they’re properly timestamped there’s no problem whatsoever. The real question is what’s the use of that granularity for the main rendering thread running at say 60 fps.

OleNic · April 30, 2026, 8:31pm

And super fast humans can’t react at 100hz with any sustained rhythm.

The average being much closer to 10hz

mayormaynotbeacat · April 30, 2026, 9:22pm

It would be nice for a song going at, say, 337.5 bpm, since if someone is on beat there will be some significant jitter and input banding due to frame timings, but now that I think about it I think most people who would be playing at 60hz nowadays would probably also have 125hz keyboards, so maybe I’m overthinking this.

Maybe I’ll revisit this if it becomes a real issue. (It could be that Godot’s CPU reqs precludes graphics that are old enough to make separating input polling from rendering a good thing.)