Windows Input Optimizations Causing Soft Lock

Development Programming & Scripting
, ,
1

This question was created in reference to: [WinPumpMessages - High CPU cost of Windows mouse [Content removed]

I cherrypicked the following CLs into Unreal Engine 5.5 and we are now running into a rare bug where input breaks and the game gets nearly soft locked.

42152017, 42166476, 42232996, 42762914, 43032922, 43352118, 44252455, 44282257, 44455025, 44482035, 44483612, 44485144, 44494703

When this happens you can see your cursor in game and it’s almost like the window is no longer focused, I can’t move in the game anymore or open my console via ~ or settings via escape or do much of anything. Restarting the game fixes the issue. Clicking on buttons and UI elements often doesn’t work when this bug occurs too. Basically input breaks in very large ways when it occurs but not entirely.

We have caught it with a debugger attached a couple times and have observed that when it occurs `FWindowsApplication::ProcessDeferredMessage` stops processing a bunch of the things it usually does process (e.g. WM_MOUSEACTIVATE and WM_LBUTTONDOWN)

I am running with WindowsApplication.UseWorkerThreadForRawInput=True

Are there any CLs that I might have missed to bring this functionality into 5.5? Or any ideas you have on what could be going wrong? Have you had any issues with this functionality?

It seems as though the game fails to accept window focus at all.

It almost feels similar to this commit but on Windows and not Linux.

https://github.com/EpicGames/UnrealEngine/commit/73f4457617a02ae371dd9488ed8375b1f0a180d1

Thank you,

Ethan

2

Hi,

Just to clarify, does this issue reproduce with UseWorkerThreadForRawInput set to false? And does it still reproduce with that cvar on if you revert the CL from the linked post (44455025)? I wonder if it could be some interaction between these two optimizations since they were made independently, though we enabled UseWorkerThreadForRawInput by default so I would have expected us to run into similar issues. It may also be worthwhile (if you can reliably reproduce this) to enable the Console Slate Debugger to see where input is going before the window stops accepting focus.

Best,

Cody

3

Hi,

What does the Slate Debugger show when this happens? I’d expect at the moment things break you’ll either see one final log line about the window deactivating and nothing else, or you’ll see log spam about it directing focus elsewhere (which would explain why things are softlocked, if anything you do is just immediately stomped). That might give us more of a hint on what could be happening here.

4

Hey Cody,

It does still reproduce with UseWorkerThreadForRawInput set to false. I’ll try reverting 44455025 specifically

5

Reverting only 44455025 did not fix the problem. I’m going to start reverting more.

Also this breaks input on the Steam Deck in an even more reproduceable way. When navigating any menu most buttons can’t be interacted with at all, the only indication you’re navigation at all in most cases is a very brief flash of a hovering animation.