Input Lag with a simple game, even with --release

[masonk]

Bevy version

0.2.1

Operating system & version

Ubuntu 18.04

What you did

Working through a very simple bevy tutorial, I noticed significant input lag (with and without rapier).

I boiled an RTC down and uploaded it here: https://github.com/masonk/laggame
Clone that and
cargo run --release

This "game" just drives a cube around the screen when you press the arrow keys. Both starting and stopping the cube feels laggy, at least a few hundred ms of input lag, maybe up to 500ms.

I wouldn't be surprised to learn that I'm doing something wrong, but whatever that might be isn't obvious to me.

What you expected to happen

I would expect not to feel any input lag in a game this simple.

Additional information:

It shouldn't matter but I'm on monster of a machine, 16 cores, 2080Ti, etc.

Toolchain is recent:

mason@mason-threadripper:~/dev/laggame$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/mason/.rustup

installed toolchains
--------------------

nightly-2019-12-18-x86_64-unknown-linux-gnu
nightly-2019-12-19-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)

[masonk]

The same program has far less lag on Windows 10 - but still not zero.

[freylint]

@masonk Do you happen to be using wayland on your ubuntu setup?

There's currently longstanding input latency issues with X on gnome on wayland. I believe such a configuration is the current default setup for ubuntu. See the issue for more information.

[masonk]

I think that issue says Wayland is better than Xorg. Xorg is default on 18.04, and it's what I'm running.

I'd only heard of one issue with Xorg in 18.04 (Xorg v3.32), and it was that it was one frame laggier than Ubuntu 17's Wayland.

I probably do have that 16 extra ms of output lag, but I don't think that can fully explain what I'm experiencing. It's a bit hard to measure, but from long experience I'm guessing at least 250ms of lag between the time I press the arrow key and the time the cube starts moving. 16ms is barely detectible to a sharp human observer, but the amount of lag I'm getting would be obvious to anyone.

Just for fun I will try this program with a few different display servers and see if I can notice a difference.

[Kinrany]

Perhaps the lag would be easier to see by drawing a rectangle on the screen only while the button is pressed.

[razaamir]

Does that work? My LinkedIn contacts and profile have been wiped out

On Sat, Nov 7, 2020 at 4:29 PM Kinrany ***@***.***> wrote: Perhaps the lag would be easier to see by drawing a rectangle on the screen only while the button is pressed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#760 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHGK5THX7UEGQCHOPMN43BDSOUVQXANCNFSM4TGHICDQ> .

-- Raza Amir

[sapir]

I think it feels laggy for me, too, though I'm not sure.

I made a version where it follows the mouse cursor. It's easier to see the lag because you can see the mouse cursor moving relative to the rectangle.

https://github.com/sapir/laggame

I'm on Ubuntu 20.04 without wayland.

[bjorn3]

I tried laggame adapted for the latest Bevy. I added an info! in event loop handler of bevy_winit for the CursorMoved event. The first time I moved the move, for the first frame after I moved the cursor, nothing happened. The second frame, four INFO were shown. The third frame, the box moved. The second time, same with the was the case, except this time the box already moved at the second frame.

[sapir]

I think this happens less with current master.

[bjorn3]

I just had the time to test this on master. The lag is now almost completely gone, even in debug mode. There is maybe one frame lag, but I can barely notice the cursor moving relative to the center of the box.

[rafalsobota]

I see lagging mouse input on mac up to 500ms on button example on master.

When I move the cursor fast over the button it never changes state to hover.

When I spawn a simple cube on mouse click I have to wait up to 500ms to see it.

[maddiemort]

I'm also having very noticeable mouse input lag on bevy 0.4 on macOS only, mainly with bevy_egui, which results in button clicks not being registered if the mouse is moving at any speed during the click, as well as slow highlighting on hover. I tested the same code on NixOS under X11 and didn't notice any input lag at all.

Edit: forgot to mention it's not just with bevy_egui, I also get input lag on macOS when trying to move or resize the window. I have to click and hold for at least 500ms before moving the mouse, or the move/resize just won't happen. If I do wait, the move/resize works, but the window stays stationary/the same size for an additional delay, and then jumps to where the cursor is.

[cart]

I left a comment about the current state of this here: #2871 (comment)
Hopefully we'll have a fix for this prior to the 0.6 release.

[perludum]

I tried both "laggames". Here on macOS keyboard input seems okay (no lag noticeable), but mouse lag is definitely an issue. Deactivating Vsync doesn't help. This mouse input problem on macOS might also be related to this winit issue.

[nyvs]

Also having massive lagg issues on Arch Linux(5.15.7-arch1-1) with Wayland/Mutter/GNOME 41.2
Both my own simple bevy game and the breakout example are unbearable.
Using AMD for CPU and GPU.
I used the latest version available here :)

[nyvs]

(The lagg is so strong that sometimes the collision from the breakout example is ignored and the ball flies out to space)

[cart]

For input-lag issues, check out #3317. @aevyrie has a work-in-progress solution with promising results.