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.

  • talOPEnglish
    4·
    4 days 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.