"Input lag" on MacOS long-click since 1.11.0-beta2 #9179
Version of OpenTTD
Using menus and tools should be lag-free and feel instant.
When long-clicking menus in the toolbar, or dragging rail tracks, signals etc there is a noticeable "lag" just as you initiate the click. After the toolbar is open or the dragging action has started, the performance is smooth until you let go.
It's a bit hard to describe - one of those things you can easily feel but may not "see" on video, but here are two videos showing the difference between 1.11.0-beta1 and 1.11.0-beta2, with the speed of the video reduced to 0.5x - this makes it easier to see how in beta2 it jumps from the original square/location to a different spot on the first post-click render. It's like it drops a number of frames.
Beta 1 (works as intended, dragging is smooth, one square at a time):
Beta 2 (dragging "stalls", jumps multiple squares after first post-click draw):
Steps to reproduce
Not sure! I'm a bit surprised that I can't find any reports of others having the same problem, but I also don't know how common playing it on MacOS is.
The text was updated successfully, but these errors were encountered:
Tried on both the track pad and mouse, same behavior on both
Playing with NoSound and NoMusic. Pulled the audio and music volume all the way down just in case, but doesn't seem to make a difference
Ok, this is interesting: I don't actually have to do any toolbar or build action to reproduce - clicking and holding the left mouse button and moving the cursor around has the same behavior. Right clicking (to scroll) works smoothly.
Here's a video of me just click and holding random points on the map - you'll notice how the cursor "stalls" every time I click a new location. I'm moving the mouse in a totally smooth motion continuously, but as you can see it jumps from place to place on the screen as if frames are dropped somehow - but the FPS counter seems to be stable.
I went through nightlies between beta1 and beta2 and identified that the issue started appearing in the 2021-02-19 nightly. From there, I tried to figure out which commits might be responsible by building OpenTTD for each commit since the 2021-02-18 release.
The input lag problem seems to be reintroduced in eb9b1ad. I didn't keep on checking after that, but nightlies following from this date seems to contain the same problem.
@TrueBrain do you have any ideas as to what could be causing these commits to exhibit this behavior? Seems to be related to the chrono changes, but I'm not familiar with clocks enough to make sense of it. Are there any changes I can apply or debug information I can give that will help pinpoint what might be causing this?