[2.0.28] Window is unresponsive during launch

[spacedog]

If you run the game (on Windows) in windowed mode, the window cannot be moved, resized, or minimized for long periods of time while the game is launching. Attempting to click anywhere in the window causes "not responding" to be added to the window title. This only seems to happen the first time the game is launched after rebooting, which possibly points at lots of blocking disk I/O for data that's not cached yet.

I couldn't find any existing bug reports about this, which surprised me. It was a minor issue prior to Space Age, but it's been really bad since then (likely due to the larger number of assets being loaded for Space Age). Whatever is happening on the GUI thread is preventing the message queue from being pumped, and should get moved to a worker thread instead. Or if it's really just blocking disk I/O, switch to overlapped I/O.

[Jap2.0]

I have seen this from time to time in fullscreen as well. (Perhaps across multiple computers?)

[Brathahn]

I have the same "problem" or behavior. but i never seen it as a bug, just the game loading its stuff from the disk.
Moving the game from HDD to SSD helped to shorten the time the window is unresponsive a lot.
In my experience a lot of games have this behavior on starting.

[spacedog]

Well, I'm on an i7-13700 with a hardware RAIDed NVM setup with read benchmarks close to 6GB/s through DirectStorage. I never see the disk utilization go above ~15% while the game is launching, which makes me really wonder what the game code is doing that hangs the window for 6-7 seconds...

Other games I own have this issue for a fraction of a second here or there, but it's so much worse with Factorio that it stuck out enough for me to post here.

I realize this is fairly low priority compared to crashes and whatnot, but I hope they get around to looking at it at some point.

[Rseding91]

Thanks for the report however there's very little that can be done about this. On windows, you can only poll window-events from the operating system on the thread that created the window. You can also only ever interact with the GPU on the thread that created the GPU context (which will be the same one that made the window). Because of that, the window almost always has to be created on the main thread and while creating/loading GPU resources (textures, shaders) it blocks the main thread while they run, and prevents handling window events.

Not handling window events is what generates the "window not responding" from the operating system.

In 1.1 and previous versions we worked around this by moving the window creation and event handling into a different thread and polling it for the data it had collected/pushing things to it. This worked mostly fine, but failed if you used OpenGL. In 2.0 with controller support that was no longer viable because the controller logic in SDL did not work with this background-thread approach and so it was disabled and all of the logic moved back to the main thread.

Basically, Windows "window" model is really annoying in how it works not allowing other threads to poll events and we get stuck with this behavior. You may notice it in other applications/games as well - if you resize them and the entire render area stops responding that's what is happening.