"Input lag" on MacOS long-click since 1.11.0-beta2 #9179
Comments
|
Discussed this a bit on discord with OP, I don't see this on intel or M1 so I have no helpful data points :( |
|
What input device are you using, a track pad or a mouse? |
|
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? |
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. Screen.Recording.2021-05-02.at.13.24.01.mp4 |
|
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? |
|
same on me, when hardware acceleration is turned on |
Only with hardware acceleration turned on? |
|
This was caused by a third party app - BetterTouchTool. I'm not familiar enough with cocoa/c++ to understand how the code change from sleeping 1ms to sleeping until the next tick can interact with a third party app in this way. I added some logging of Closing this, as I don't think it's very actionable from OpenTTDs side. |
Version of OpenTTD
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.
The text was updated successfully, but these errors were encountered: