Stutters after cursor auto hide in every game.

[Chococococococo]

The game stutters every time the mouse cursor disappear in steam deck game mode. It happens in every game. Not sure what cause this. The frame drop can be clearly see in gamescope overlay fps drop and frametime spike.

The only way to avoid is not to use any mouse input. I tried to change every setting mouse related but nothing help.

[david-rosca]

I'm seeing similar issues in the following games - Guild Wars Trilogy and Anno 1404.

In both instances there is a noticeable frametime spike when certain things are triggered.

For GW, it's when the cursor disappears due to right click being held down. For Anno 1404, it's when the cursor hovers over buildings and the building highlight renders.

Workarounds I've found:

1. Desktop mode resolves the problem
2. Lowering in game resolution for system FSR to kick in also fixes it.

[BeppisMAX]

Some notes regarding this issue:

• On the Steam Deck, this is only apparent when running games in Game Mode, where Gamescope is utilized.
• Appears to only happen when a hardware-based mouse cursor is being used in-game. Some games will use this by default, or will allow configuration to use either a hardware or software-based cursor in-game.
• As @david-rosca mentioned, eliminating the occurance will require FSR upscaling to be in-effect. As soon as FSR is disabled however, the issue will persist.
• On SteamOS, this issue seems to have been apparent since the 3.5 release. Changing the version of Proton in which a game runs does not appear to change the behavior.
• The lower the framerate, the lower FPS the stutter will cause the game to drop to.

Testing by the community has been conducted on several games. On my end, I've been able reliabily duplicate the issue on Final Fantasy XIV. Steps to duplicate for this particular game below.

1. On the Steam Deck, open the game in Game Mode with FSR upscaling off. (Optional: Enable the in-built Performance overlay in order to track FPS)
2. Log in via the launcher.
3. On the splash/main menu, navigate to Configuration or log into a Character, then access the Main Menu, navigate to System > System Configuration.
4. Navigate to Mouse setting, and ensure Hardware cursor is enabled.
5. Ensure your Steam controller configuration allows for mouse input.
6. Triggering the mouse to 'hide' either via click-and-hold to move the camera or allowing a few seconds of idle activity to hide the cursor, will trigger the stutter - causing the FPS to noticably tank.

The circumstances in which a cursor will 'hide' for each game my vary, however it seems when running a game in Gamescope, a hardware-based cursor entering a hidden state will 'tank' the FPS briefly. The severity of the issue could vary on how a game may rely on the appearance and disappearance of a mouse cursor. A hardware-based cursor serves to be a preference among users due to the immediate response rate and system's mouse configuration.

[sharkautarch]

@Joshua-Ashton Unless you had already figured out what was causing this issue, I think the best way of finding the root cause of this issue would be to hook up Tracy profiler to gamescope. It tracks start and end times of frame prep/submission like w/ gpuvis, but also helps you track down the problem code that could be delaying frame submission at any given point in time.

[pokkevil]

I'm not convinced the stutters identified by @Chococococococo and @david-rosca are caused by the same thing.

The cursor auto-hide stutter is caused by Gamescope's script to hide the mouse cursor after three seconds of inactivity. This can be disabled by editing the gamescope-session file in /usr/bin/ - specifically the line following line: --hide-cursor-delay 3000. Changing the value from 3000 to -1 stops the cursor from disappearing due to inactivity. No more stutter in gaming mode. Whether it's safe to do so I'm not qualified to judge - at your own peril and all that - but it's stopped the cursor-disappearing stutter for me in all games I've tested.

I'm still experiencing the issue @david-rosca identified with Anno 1404, however. In Steam Deck's gaming mode, mousing over buildings (in fact, mousing over any highlight-able object at all) causes Anno 1404's framerate to plunge briefly. The same problem occurs in construction mode when dragging a provisional building into a prohibited area (e.g. on top of another building, or out of range of a marketplace). What both activities have in common - I suspect, at least - is the loading in of a new visual asset or effect. When mousing over a building/ship/object, the asset changes to a "highlighted" version of itself, and the loading in of the highlight appears to cause the frame drop. Similarly when dragging a new building into a prohibited area, the building you're trying to place turns into a red version of itself, and the loading in of the "red" asset causes a framerate drop (this also happens in reverse - i.e. when dragging the building from a prohibited area back into an allowed "buildable" area, the asset changes from "red" to its original appearance and causes another frame drop).

As suggested in previous comments, lowering resolution and enabling FSR resolves the issue, as does playing in desktop mode. I'm not remotely technically-minded enough to understand why, but presumably it's a setting Gamescope is forcing.

[david-rosca]

This same issue seems to be present with Homeworld 3 as well.

[Eduardboon]

Whenever the mouse cursor shows on an embedded gamescope session (like gaming mode on the steam deck) it forces composite mode instead of scanout. This makes the whole screen slightly blurry as well.

I think the switching of these modes creates the fps spike as well, since the rendering mode changes.

I’ve been trying to fix the blurry part of the issue without any success at all. Since in most games that use the cursor I now have to play the entire game blurred. Or when the cursor disappears, enjoy the screen constantly switching between sharp and blurry rendering modes.

[trevyn]

Got hit by this as well; writing a little game experiment on steam deck, and I'm like why is this stuttering after I move the mouse? I think @Eduardboon nailed what's going on; I see a lag in getting a swapchain texture when this happens. I wonder if there's a way to composite just a hardware cursor without going into full compositor mode.

[sharkautarch]

@trevyn Hmm my one idea for "drawing" a cursor without doing full composition (& switching to/from blur layer) would be:

• Make use of VK_KHR_incremental_present (And might also need to use VK_KHR_display to present onto the drm surface) to vulkan-composite a small rectangle that fits the shape of the cursor (and probably also need to composite another small rectangle over where the cursor was at in the previous frame)

@Joshua-Ashton do you think that would work?

[misyltoad]

No, that's not how this works at all.

We should just use the cursor plane but AMDGPU bugs prevent us right now. I'll try and look at it soon.

[misyltoad]

The hitching is also another AMDGPU bug with plane transotions taking exceptionally long with color mgmt.

[misyltoad]

(FWIW we also have partial composition mostly implememted. I forget the reason that it is disabled right now)

[Eduardboon]

So is this normal compositing behaviour then? (Link to video

Because I could have sworn it didn’t blur by this much when using the cursor. It’s actually better to run games that use a hardware cursor on steam deck from desktop mode instead of gaming mode because of this. Or maybe my compositor is doing weird stuff? Since FSR also uses composite mode and FSR is always more blurry than not using it for me.

Edit: yeah it’s the same bug for me. FSR gets the exact same blur instead of sharpening the image. made another video that shows the blurring with the cursor more easily: link to video

[trevyn]

I was also able to reliably reproduce the blur/no-blur effect on Steam Deck in any game by setting a higher-than-native resolution in the Steam display properties, e.g. 1920x1080.

[Eduardboon]

I am getting the blur even on the native res of 1280x800 at any refresh rate. It doesn’t matter what resolution I use, blur always shows up here.

My gamescope log has started spitting out this line a lot:

Edit: the answer is: compositing shouldn’t cause blur. I rolled back my Bazzite install to a way earlier version with an older gamescope version and the issue is gone. So now I just have to find out where it broke so someone with more knowledge than me can look at the commits I guess.

It still happens when the resolution is non-native though. So FSR makes the screen blurry no matter what since it tries to upscale

[ubeogesh]

This issue is very annoying in Diablo 2 resurrected, because when you pick up and put down items, game replaces cursor with the item graphic - and backwards - which causes visible stutters. I can confirm that FSR indeed fixes the problem here, but unfortunately it's not usable otherwise, because the game cannot go smaller than 1280x720 - it's UI just doesn't fit. However the cursor show\hide lag disappears in this case

It also affects Hades 1, when you use gamepad control scheme, but assign right trackpad to mouse\mouse region (useful for aiming Festive Fog and Rail's special bomb)... whenever the mouse shows\hides you get a stutter

[ubeogesh]

Hi yall,

I wonder if it's possible to force FSR on somehow to work around this bug, when the game I'm playing doesn't support a resolution below 1280x800? Somehow trick the FSR filter to think the screen resolution is, for example, 1600x1000?

[sharkautarch]

@ubeogesh @Chococococococo I had a discussion with @misyltoad & @matte-schwartz about a group of issues wrt certain cases of stuttering that only happened on game mode. Tho, since people in this issue thread were talking about FSR mitigating the issue, I'm not entirely sure whether this is a separate issue from the one I had discussed about elsewhere. Anyhow, to summarize, I had reviewed gamescope's compositing code -- specifically the logic for selecting which layers to paint -- and came to the realization that theoretically, if multiple unrelated events (that all increment the same shared internal counter in gamescope) occurred in a short span of time, gamescope would be forced to start flipping a frame (before the contents of the main-layer/window are available) early. The reason why this could then lead to stuttering is that this can delay the next frame (the one that actually includes the contents of the main-layer/window) from being flipped To my knowledge, this is still only a conjecture, and hasn't actually been confirmed to be the root cause of any stutter-related issues yet. Btw, the specific aforementioned internal counter is nIgnoredOverlayRepaints And you can use gamescopectl to change the number of ignored repaint requests before repaint is forced, or to ignore all overlay repaint requests with the adaptive_sync_overlay_cycles and adaptive_sync_ignore_overlay gamescopectl variables respectively.