Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Input lag" on MacOS long-click since 1.11.0-beta2 #9179

Open
rexxars opened this issue May 2, 2021 · 8 comments
Open

"Input lag" on MacOS long-click since 1.11.0-beta2 #9179

rexxars opened this issue May 2, 2021 · 8 comments

Comments

@rexxars
Copy link

@rexxars rexxars commented May 2, 2021

Version of OpenTTD

  • All versions on or after 1.11.0-beta2
  • Same behavior on MacOS Catalina and Big Sur
  • Macbook Pro 2018 (2.2GHz 6-core Intel i7, Radeon Pro 555X 4 GB)
  • Tried with and without hardware acceleration and with hidpi set to false

Expected result

Using menus and tools should be lag-free and feel instant.

Actual result

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):

beta1-slow.mp4

Beta 2 (dragging "stalls", jumps multiple squares after first post-click draw):

beta2-slow.mp4

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.

@andythenorth
Copy link
Contributor

@andythenorth andythenorth commented May 2, 2021

Discussed this a bit on discord with OP, I don't see this on intel or M1 so I have no helpful data points :(

@nielsmh
Copy link
Contributor

@nielsmh nielsmh commented May 2, 2021

What input device are you using, a track pad or a mouse?

@PeterN
Copy link
Member

@PeterN PeterN commented May 2, 2021

Pauses possibly correspond with playing sounds... I don't know if you have sound on or not in game, if you do could you try muting it in game?

@rexxars
Copy link
Author

@rexxars rexxars commented May 2, 2021

What input device are you using, a track pad or a mouse?

Tried on both the track pad and mouse, same behavior on both

Pauses possibly correspond with playing sounds... I don't know if you have sound on or not in game, if you do could you try muting it in game?

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

@rexxars
Copy link
Author

@rexxars rexxars commented May 2, 2021

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.

Screen.Recording.2021-05-02.at.13.24.01.mp4
@rexxars
Copy link
Author

@rexxars rexxars commented May 4, 2021

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?

@ecolortest
Copy link

@ecolortest ecolortest commented May 4, 2021

same on me, when hardware acceleration is turned on

@rexxars
Copy link
Author

@rexxars rexxars commented May 5, 2021

same on me, when hardware acceleration is turned on

Only with hardware acceleration turned on?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants