Strange delay of keyboard input
-
Hi all!
I noticed that the app has significant input lag, more than in other apps.
I created a test example on Qwindow with the OpenGL context. Use the arrow keys to change the size and number of circles to create a load. Pressing Esc displays the time in milliseconds since the program started: the first number is the value from the event timestamp, the second is the time value obtained in the handler. You can see that the second is delayed by one frame.There may be a slight discrepancy because the starting time (stored in the constructor) may not be exactly the same as the one used by the event mechanism. But it's clear that the handler is always 1 frame behind the timestamp. This is understandable, but it's just the top of the iceberg. Actual response to a keypress lags by 4 or 5 frames.
So, for example, you can add a load with arrow keys so that the frame takes, say, 400 ms to draw, and then press Esc—the program responds not after the expected 400 ms, but after about 2 seconds. So, four whole frames pass without a response. Under low loads, this four-frame delay is also present.
I tried receive keystrokes through winapi (GetAsyncKeyState) instead of events, directly in the rendering function, just before drawing. Basically, it's the same! And the same four-frame delay.
It seems like the frames themselves are queued up before being displayed and aren't drawn immediately. This is despite the fact that I have a gaming monitor with zero input lag. I also tried enabling low-latency mode in the video card settings—it had no effect.
-
Zip file with test project: https://drive.google.com/file/d/1RKtHNyAXhCSQpAEb5EYlq_UGMsqLGKLu/view?usp=sharing
Is any ways to remove this input delay?
-
After spending about 20 minutes rewriting your code and .pro file so that it compiles: you are stepping on the keyPressEvent handler with a less strict event() handler. You already have the timer updating the render for you. why are you trapping a generic event to trigger render() too?
-
Hi all!
I noticed that the app has significant input lag, more than in other apps.
I created a test example on Qwindow with the OpenGL context. Use the arrow keys to change the size and number of circles to create a load. Pressing Esc displays the time in milliseconds since the program started: the first number is the value from the event timestamp, the second is the time value obtained in the handler. You can see that the second is delayed by one frame.There may be a slight discrepancy because the starting time (stored in the constructor) may not be exactly the same as the one used by the event mechanism. But it's clear that the handler is always 1 frame behind the timestamp. This is understandable, but it's just the top of the iceberg. Actual response to a keypress lags by 4 or 5 frames.
So, for example, you can add a load with arrow keys so that the frame takes, say, 400 ms to draw, and then press Esc—the program responds not after the expected 400 ms, but after about 2 seconds. So, four whole frames pass without a response. Under low loads, this four-frame delay is also present.
I tried receive keystrokes through winapi (GetAsyncKeyState) instead of events, directly in the rendering function, just before drawing. Basically, it's the same! And the same four-frame delay.
It seems like the frames themselves are queued up before being displayed and aren't drawn immediately. This is despite the fact that I have a gaming monitor with zero input lag. I also tried enabling low-latency mode in the video card settings—it had no effect.
@Hypergeek said in Strange delay of keyboard input:
But it's clear that the handler is always 1 frame behind the timestamp. This is understandable
What's also understandable that usually you'll be using at least double buffering: Showing one buffer and writing to a second one then switching. That'll add one other frame to the delay. There is also triple-buffering, but it is highly unlikely that this is actually used. I don't have an explanation ready to explain further frame delays.
-
After spending about 20 minutes rewriting your code and .pro file so that it compiles: you are stepping on the keyPressEvent handler with a less strict event() handler. You already have the timer updating the render for you. why are you trapping a generic event to trigger render() too?
@Kent-Dorfman said in Strange delay of keyboard input:
After spending about 20 minutes rewriting your code and .pro file so that it compiles
Thanks! But why didn't my code compile? It's strange. My Qt version 5.15.2.
@Kent-Dorfman said in Strange delay of keyboard input:
you are stepping on the keyPressEvent handler with a less strict event() handler. You already have the timer updating the render for you. why are you trapping a generic event to trigger render() too?
Yes, this is just old code. It can be removed, and it doesn't really affect rendering.
@SimonSchroeder said in Strange delay of keyboard input:
Showing one buffer and writing to a second one then switching. That'll add one other frame to the delay. There is also triple-buffering
I also tried to change it by setSwapBehavior (tried all 4 variants) - this had no effect on delay.
-
As a larger issue, you should not use a framework like Qt for metering timing windows with periods less than about 25ms. The OS scheduling jitter inhibits accurate data collection. The std-dev between samples will quickly increase when you use small period event timers or track the system clock at the ms level. If you require ms level accuracy for event windows or metrics then you have to do things like run in realtime schedule mode and not run other processes concurrently. The framework is fine for general user interfaces but not for high framerate game development.
-
@Kent-Dorfman said in Strange delay of keyboard input:
After spending about 20 minutes rewriting your code and .pro file so that it compiles
Thanks! But why didn't my code compile? It's strange. My Qt version 5.15.2.
@Kent-Dorfman said in Strange delay of keyboard input:
you are stepping on the keyPressEvent handler with a less strict event() handler. You already have the timer updating the render for you. why are you trapping a generic event to trigger render() too?
Yes, this is just old code. It can be removed, and it doesn't really affect rendering.
@SimonSchroeder said in Strange delay of keyboard input:
Showing one buffer and writing to a second one then switching. That'll add one other frame to the delay. There is also triple-buffering
I also tried to change it by setSwapBehavior (tried all 4 variants) - this had no effect on delay.
@Hypergeek said in Strange delay of keyboard input:
@Kent-Dorfman said in Strange delay of keyboard input:
After spending about 20 minutes rewriting your code and .pro file so that it compiles
Thanks! But why didn't my code compile? It's strange. My Qt version 5.15.2.
I built it with qt6 and the pro file was missing the opengl module. You had a malformed connect() statement. Finally, your header includes didn't provide for QOpenGLPaintDevice.
-
As a larger issue, you should not use a framework like Qt for metering timing windows with periods less than about 25ms. The OS scheduling jitter inhibits accurate data collection. The std-dev between samples will quickly increase when you use small period event timers or track the system clock at the ms level. If you require ms level accuracy for event windows or metrics then you have to do things like run in realtime schedule mode and not run other processes concurrently. The framework is fine for general user interfaces but not for high framerate game development.
@Kent-Dorfman said in Strange delay of keyboard input:
You had a malformed connect() statement
Why malformed? Used form allowed in docs.
@Kent-Dorfman said in Strange delay of keyboard input:
The framework is fine for general user interfaces but not for high framerate game development
Is Qt Quick more suitable for it, or has same delays?
