Ugh, that's a pretty insane default. Thanks for the heads-up.
Linux Gaming
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:
I think a dev for Factorio discussed this issue on Brodie Robertson’s podcast.
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.
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.