WindowEvent::KeyInput lags on gnome X11, but not on i3

[cfagot]

Description

This issue most prominently displays itself in games when holding a key down for an action and repeat rate is faster than the frame rate. In that case when you stop pressing the key you will immediately get a device event for the key release, but the WindowEvent::KeyboardInput will continue for some time before the release event arrives. I haven't seen this on wayland, windows, or x11+i3, which is all I've tested on. But I have seen it on 2 ubuntu+gnome+x11 installs, and Johhn-Nagle saw it on same.

Note that nothing like this happens with mouse events even though they are generated at a much higher frequency, so has nothing to do with the app not draining events fast enough.

The following app demonstrates this and can be used to test on different platforms (visually with the animated triangles and also in the console output where you can see what events arrive between new_events and about_to_wait:

https://github.com/cfagot/test_winit_event

Even though this is most easily seen with repeat events, this also happens with any key events that happen in clumps, which is typical typing behavior. I test by just mashing on the keyboard which I find strangely satisfying.

Also important to note that when run with i3 instead of gnome, this does not happen.

Note: a lot of the details can be found in this thread (start after John-Nagle starts posting).

OS and window mananger

Ubuntu 22.04 LTS/Gnome. But as mentioned in the description, I tested with i3 and the issue does not occur there.

Winit version

0.30.3, but have also seen the same issue on 0.29.*

[John-Nagle]

Thanks. I have a program that sometimes runs at low frame rates, and key events can get way behind. If key repeat is 15Hz and frame rate is 12Hz, and you hold down an arrow key, you can build up a huge backlog.

(Use case: I'm working on improving performance, and sometimes run in debug mode, which is why I hit this.)

[kchibisov]

Just for the clarity.

Repeat can not be disabled per application level on X11. If your app is not draining the loop, you're out of luck, so don't stall the connection and do batching, whatever.

single_iteration drains all the events from the X queue. If you read it, you'll see drain_events which has while loop over all the events inside the connection. If they are not there means that we haven't received them from the X server yet.

However on the gnome vs i3 is a completely different issue and is related to how input method works.

[cfagot]

I understand what drain is doing, which is why I mention that mouse events don't have the same issue. So for whatever reason that key events arrive one per single_iteration call, it's surely not ideal (and also seems to be unique to x11 with gnome).

[John-Nagle]

Right, mouse events are fine. Only keyboard events have this problem. I see it on x11, but don't have other platforms for testing.

[kchibisov]

As I said, they arrive normally, it's just they go through the input method and SendEvent one more time. The solution would probably to just straight disable this forwarding.

[kchibisov]

Can someone test this #3940? It should be trivial to apply to 0.30.

[cfagot]

Sure thing. It might not be till tomorrow but I'll get to it. Thanks for the fix.

…

On Tue, Oct 8, 2024 at 6:40 AM Kirill Chibisov ***@***.***> wrote: Can someone test this #3940 <#3940>? It should be trivial to apply to 0.30. — Reply to this email directly, view it on GitHub <#3815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3TEXN5GSK3YDZFISPIQ3Z2POFXAVCNFSM6AAAAABLK4M3H2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZHA4DCNRWG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cfagot]

I couldn't fully apply to 0.32 (the version I am using) because ime is not defined on ActiveEventLoop. Needed for this line in src/platform_impl/linux/x11/event_processor.rs: let ime = self.target.ime.as_ref(); But I tested by just setting forward_to_ime to false and it fixes the problem. I think that's the only thing you need me to test. Anyway, yes, I think this is the fix for what John and I were seeing. Thanks! clark

…

On Tue, Oct 8, 2024 at 9:26 AM Clark Fagot ***@***.***> wrote: Sure thing. It might not be till tomorrow but I'll get to it. Thanks for the fix. On Tue, Oct 8, 2024 at 6:40 AM Kirill Chibisov ***@***.***> wrote: > Can someone test this #3940 > <#3940>? It should be > trivial to apply to 0.30. > > — > Reply to this email directly, view it on GitHub > <#3815 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAB3TEXN5GSK3YDZFISPIQ3Z2POFXAVCNFSM6AAAAABLK4M3H2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZHA4DCNRWG4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[SUPERCILEX]

This caused a bug in egui, see #4048

[Knar33]

I am still seeing this issue in Bevy which uses winit version 0.30.6 - it propagates an ime_allowed property to set_ime_allowed() and even when I set it to false I still get this issue - when I release a key I get a released event then an extra pressed event followed by another released event (which comes much later if my framerate is low).

maybe it's related to this? #3092

[kchibisov]

You should try 0.30.7, if IME disable doesn't work (we don't even init it at this point), then I'm not entirely sure how to solve this, since you literally have nothing in between and winit just forwards.

[Knar33]

That got rid of the extra release + press but the only release I get now is the one that is delayed. In 0.30.6 I got a release as soon as I released the key, followed immediately by a press, then a delay and another release.

[kchibisov]

If you were getting extra events that meant that you haven't disabled IME? Like the issue was only present when IME was around, without it it was not the case.

[Knar33]

I just double checked in both 0.30.6 and 0.30.7 to be sure, it seems like having ime enabled/disabled makes no difference. Maybe Bevy sets it incorrectly (winit_window is just a Window object) https://github.com/bevyengine/bevy/blob/8d9a00f5483b2ba28f40081759bd3d6f8b8a686d/crates/bevy_winit/src/system.rs#L516

In 0.30.6 releasing a key would give me an immediate release event followed by a press event, then a delay and a second release event

In 0.30.7 releasing a key gives just has a delay then a single release event.

[kchibisov]

Test with the --example window in winit to check, but I don't see why it wouldn't work.

[kchibisov]

idk, you can try #4056, but I'm not adding a new patch release just for that, since I have no idea if it's really how it should be.

On other compositors it seems that the current code works just fine.