Cursor ocassionally stops (input thread stutter)

[YesLifer]

Type

Game behaviour

Bug description

After updating lazer I've discovered a really annoying thing: when playing STD (may also happen in Song Select menu) cursor ocassionaly stops while dragging tablet pen and after some time just "teleports" to the point where the pen is currently located. It happens anytime during gameplay and it is especially irritating when it happens at the end of a song.

Screenshots or videos

https://github.com/ppy/osu/assets/152286401/b5bf8143-000a-4bee-975c-5d32c992b917

Version

2024.131.0

Logs

compressed-logs.zip

[longnguyen2004]

Tracked at https://github.com/ppy/osu-framework/issues/6181

[frenzibyte]

Keeping this issue open and pinning to give visibility for anyone else coming to report it, since it's been reported over 5 times in the span of few days.

[peppy]

Does turning off "high precision input mouse" with this?

[YesLifer]

Tried both turning off and on this option, but the problem still shows up

[BenCheung0422]

For my experience, I have a kind of 2 types of input lags: sudden stop and delayed movements, and luckily I am able to record them. For the type with sudden slow cursor movements, I have experienced for periods vary from a few hundreds of milliseconds to a few seconds. And sometimes coming with rendering lags, but it seems like it would be another problem.

• Sudden stop (blue circles "1" to "2"):

https://github.com/ppy/osu/assets/74168521/2b300a42-3f08-4ba0-960d-56b6b50129de

• Sudden delayed movements (near the end of this play, and apparent drop in input FPS is recorded):

https://github.com/ppy/osu/assets/74168521/ec2139e2-7618-4fcd-a333-41889e869ea4

From #9283 (the case with rendering lag), it is mentioned that it might be GC-related, but for my recordings, no apparent relationships to GC can be found. In the mean time, I will still try to collect more information related to the lags and delays as useful as possible.

[BenCheung0422]

This time. I have tracked on the logs and probably found that it might be related to the slow frames on the threads.

https://github.com/ppy/osu/assets/74168521/ced6979b-bc86-4eff-8863-21f37c7a892e

Here, I used 2880x1620 DSR for my 1920x1080 monitor, and 8 font size instead of 12 (default) for the terminals.

logs-1710256102.zip

[peppy]

Having the stats open probably does that, and is probably not related.

Also having windows displayed above the game, and potentially the game not focused, will not help.

ALso it's not running in fullscreen mode since windows are being displayed.

@BenCheung0422 Please open a separate discussion for your issue (or better yet, self-troubleshoot), it's not the same issue as what is being tracked here.

[BenCheung0422]

I am not sure if stats affect that. Also, in the video clip, I used OBS so that the console windows on the back can be rendered in front of the game window. Yesterday, I just captured the moments with cursor movement pauses. I will try to record with stats opened and see if I can capture the moments with slow movements. It is like there is frame loss in input threads in this case. I will open a new discussion (or issue) for this.

[yomikomanda]

I had this problem too and switching from Multi threaded rendering to Single threded fixed it for me

[iwa]

i had a few input stutters in the last 2-3 weeks, and recorded one tonight

here's the clip: https://github.com/ppy/osu/assets/19956672/a9b5bb30-3953-48df-b4ec-1eefaccdab6d edit: seems we can't really see the input lag on the clip as the clip itself stuttered too

the logs: compressed-logs.zip

specs (dunno if you have them in the logs but in case):

• ryzen 7 7700x, rx 7800 xt, 32gb ddr5 ram
• wacom ctl-472, using external opentabletdriver
• in-game tablet support disabled, high precision mouse disabled (always had issue with this setting on when using my tablet)
• directX 11 experimental (my fps are more stable with it than normal directX 11)

if you need further details don't hesitate to @ me

edit 2: happened again, also have clip + logs if needed

[BenCheung0422]

@iwa I think they are still working on it to fix this issue.

[iwa]

@iwa I think they are still working on it to fix this issue.

ikik but as it seems to be kind of an awkward issue, the more logs / cases they can analyze, the merrier i guess?

[Packsolite]

What i find interesting with this issue is that i'm playing lazer for years but it only started occuring around feburary this year. Also you can easily recreate this by stressing your cpu using prime95.

[bdach]

Also you can easily recreate this by stressing your cpu using prime95.

That sounds like conflating two issues with different causes unless prime95 is doing windows input hooks for whatever reason which I find unlikely.

[Packsolite]

Also you can easily recreate this by stressing your cpu using prime95.

That sounds like conflating two issues with different causes unless prime95 is doing windows input hooks for whatever reason which I find unlikely.

Not sure, could be some weird windows services, update or whatever program in the background causing this. Stable/old client doesn't suffer from this issues when running stress tests (except a few dropped frames, but not like 1 sec input freezes).

Edit: I obviously won't get nearly the same performance when running prime95 in the background - no shit. The problem is the inconsistency, why do i get 200+ fps and a smooth gameplay for the first 30 seconds and then a random 500ms or so long input freeze when there is a little stress on the cpu? I'm in no way familiar with the osu framework so it's just guessing but it might be worth investigating. Of couse this doesn't rule out there being a sescond/different issue that is unrealted to this "seemingly-poor-scheduling" issue.

[BenCheung0422]

In my opinion, I would think this might not be really related. In my observation, there are mainly 4 types of threads: input, audio, update, draw. Certainly, draw (rendering) would be mainly handled by GPU threads alone, either single or multi-thread, and both input, audio and update handled mainly by CPU process. Lagging in threads absolutely can have several causes, including but not limited to: background services, process bottlenecks, library/API (including Windows API) incompatibility, driver incompatibility, driver or service errors, incompatible BIOS configurations, etc. In my case, there is only a hanging in input thread is the cause of input lagging, as what handled by the coming changes.

It seems like their believe is the issue related to some incompatibilities of Windows API input handling. Also, certainly, stressing CPU can cause all the threads (and processes) lagging as mostly they are handled by CPU, doubtlessly, so it might not be really related.

[iwa]

something is definitely wrong on the rendering side

I was having the freeze issue with Valorant so I disabled GPU Scheduling (windows 11), and my issue worsen drastically, to the point where my tablet would sometimes freeze and dont respond at all unless I restarted opentabletdriver it never happened with stable, and nothing changed expect the GPU scheduling setting I then tried @yomikomanda 's suggestion to set render mode to single thread and it fixed everything (played all day and no stutter nor tablet freeze)

I can retrieve clips & logs if needed

[bdach]

@iwa unless you can produce a video with frame graph showing (ctrl-f11) any speculation that this issue has anything "to do with the rendering side" is unsubstantiated. i don't even know if you're trying to report the same issue which the OP is.

[iwa]

@iwa unless you can produce a video with frame graph showing (ctrl-f11) any speculation that this issue has anything "to do with the rendering side" is unsubstantiated. i don't even know if you're trying to report the same issue which the OP is.

fair enough, I should be able to provide a video proof sometime during this week should i enable/grab something else during my testing besides frame graph + logs?

[BenCheung0422]

For your information, this case we would have this kind of situation or otherwise it should be another issue. Here, you can see that in the graph (by clicking twice CTRL-F11), you can see there are tall lines in ticking thread graph but not any observable and obvious tall lines in rendering thread graph. If you case is different (like rendering lags), that should be another issue.

EDIT: This can occur regardless of rendering mode (either single or multi-thread) setting. Also, I cannot see any related logs regarding this (unless there is something detailed debugging logging settings).

[iwa]

alright, thanks for your clarifications

after reviewing the original clip i posted, i can understand that y'all feel like it's a different issue (clip is cutting during the stutter for whatever reasons), but i'm pretty confident that i get stutter like OP does, or at least it feels the same I'll change my recording method to be sure we can visualize the issue + include frame graph

the only thing that makes me think it's rendering-related is that, strangely enough, input stutters totally stopped when i switched to Single thread rendering mode, but without any proofs my thinking is pointless, so i'll work on that

edit: after re-reviewing my original clip but at 0.25x, seems like i'm wrong & we can clearly see the input stutter happening, but still no frame graph so still pointless

edit 2 on 24/06: im not dead lol, still doing testings but i havent been able to replicate the issue since switching to single threaded rendering. even though i've set back to multi threaded for testings, no issues so far. strange.

[LWapsyTN]

i might have an idea what is causing this. if you have a gamepad or controller connected disconnect it, if you also have any input mapping software such as rewasd or xoutput stop it, for some reason they cause this, i think it is part of the input mapping process, but if you have any of these running and experience this issue, stop them, even steam input, it might cause the same issue. this might not actually be the real reason, but it is worth a try, it might work for you same as it did to me.

[BenCheung0422]

I have none of these software running, but seemingly it would interact with windows input and could cause delays in osu input handling, as osu at the moment is not handling with really raw input signals/events.

Edit: By the way, why would people use input mapping apps when playing osu? Though I am not sure if tablet pen driver affects.

[iwa]

i have never used this kind of software, always disabled steam input, and using a controller only when playing RL, controller is disconnected otherwise

i don't fully exclude steam hypothesis tho, will try to test with steam opened and steam input enabled

i was thinking about it but couldn't it be a regression with old lazer installations? something that maybe would "magically" get fixed in the local config by updating the single/multi threaded setting? some of my friends installed lazer a month ago, fresh installs, some are playing with a tablet with external opentabletdriver, and they never had any kind. i've been running the same lazer install since 2018/2019, could maybe be related? (100% speculation here, idk how lazer works internally, trying to figure out as much ideas as i can)

[ni5arga]

Had the same issue, tried switching from multi thread rendering to single thread rendering and it seems to be fine now.

[iwa]

@ni5arga if you switch back to multi threaded, does the issue reappears for you by any chance?

[BenCheung0422]

It does not help anything for my case. Logically, rendering is tacked by renderer (either GPU or CPU), but input is tacked by CPU, so there seems to be no obvious intersection between them. However, changing max FPS value may change something, but the input thread would still be 1000Hz (for me).

Edit: Actually, different computer configuration may give different results.