Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add async threads #2219
This PR introduces a way to split loading/processing stuff and GUI stuff.
An example split is done in the WaitingForGameStart state of the human client.
This should be "work in progress" until someone decides what to do with unhandled exceptions in async threads, which is not my decision to make. For now I'm just adding a line to ErrorLogger().
As for the last commit. I added is_loading code when I was reverting changes to trace messages before pushing this PR. I though I had tested it at the time but it seems like I only tried compiling... won't happen again, sorry. :(
Currently the main thread is used as GUI thread and processing thread, causing visible freezes every time processing takes a bit longer than an instant (for me it drops to 0/1 FPS quite often).
In OpenGL, almost every interaction must happen in the thread that created the OpenGL context. It is possible to create additional contexts but that would only complicate things.
If I want to separate processing from the GUI thread, then the processing code must have some way to tell the GUI thread that it can execute the UI code that depends on the processed data.
In this approach the processing code can add work (arbitrary code as a
In short, GUI work is arbitrary code to be executed before rendering a frame, and any thread can add GUI work. Some renaming might be needed to make it clearer, but I can't think of better names...
Now then, let's explain the split in WaitingForGameStart...
When the GameStart message is received,
The code here modifies Universe-related data and then updates the UI.
What I did was split that into two functions,
This is the new sequence:
Ideally the FSM would run in it's own thread, allowing you to post events from anywhere, but that would require splitting all UI code from the react functions of the FSM and that is not what this PR is about.
@geoffthemedio I tried to answer all your questions with comments in the code.
It would be nice if you guys documented the preferred code style.
I've tested this now, in comparison with master, with a 650 star galaxy and about 10 AIs, medium or high on most settings. I don't see much difference... There's a less-than-half second pause for the mid-turn update, and a slightly longer pause for the main turn update, during which the UI seems to hang. Seems quite similar for both. Do you have a better test case or expect to see a more substantial difference with this pull request applied?
I'm not gonna be around to continue this so maybe it should be closed?
I hate seeing software freeze. From a UI perspective, not giving feedback is bad.