this post was submitted on 09 Nov 2024
46 points (97.9% liked)

Linux Gaming

15374 readers
182 users here now

Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.

This page can be subscribed to via RSS.

Original /r/linux_gaming pengwing by uoou.

Resources

WWW:

Discord:

IRC:

Matrix:

Telegram:

founded 1 year ago
MODERATORS
 

I use sway in Wayland, and tend to keep games on a separate workspace.

In X11, with i3, I'd frequently switch away from the game and leave it running when something was loading or progression was required, and do something else while waiting. In Wayland, pretty much every game would suspend while viewing another workspace, which drove me bananas. I assumed that this was toggleable functionality, but couldn't find where the toggle was.

Today, I finally ran across an answer to this and wanted to highlight it for anyone else who dislikes this behavior. By default, if a window is not visible, rendering will block. Setting the vk_xwayland_wait_ready=false environment variable will disable this functionality.

top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 10 points 2 weeks ago

Im having what seems like the exact same problem with Satisfactory and other idler games. I'll come back and it seems like nothing happened when I left.

The other weird one is guild wars 2. If I lock my screen long enough, ill come back and itll render every frame I didnt see for that time at like 20x speed. Its super bizarre.

[–] [email protected] 6 points 2 weeks ago (1 children)

I think a dev for Factorio discussed this issue on Brodie Robertson’s podcast.

[–] [email protected] 5 points 2 weeks ago

Assuming that this is the episode and the Factorio dev post that references, I think that that's a different issue. That dev also was using Sway under Wayland, but was talking about how Factorio apparently doesn't immediately update the drawable area on window size change -- it takes three frames, and Sway was making this very visible.

I use the Sway window manager, and a particularity of this window manager is that it will automatically resize floating windows to the size of their last submitted frame. This has unveiled an issue with our graphics stack: it takes the game three frames to properly respond to a window resize. The result is a rapid tug-of-war, with Sway sending a ton of resize events and Factorio responding with outdated framebuffer sizes, causing the chaos captured above.

I spent two full days staring at our graphics code but could not come up with an explanation as to why this is happening, so this work is still ongoing. Since this issue only happens when running the game on Wayland under Sway, it's not a large priority, but it was too entertaining not to share.

I'd guess that he's maybe using double- or triple-buffering at the SDL level or something like that.

[–] [email protected] 3 points 2 weeks ago

Ugh, that's a pretty insane default. Thanks for the heads-up.