Hello,
In our project, we are using the “DefaultGameMoviePlayer” to display a loading screen when loading our map. During the frame that we load the map (I’m saying frame because the load map is a blocking function), the loading screen is properly updated thanks to a thread via “FSlateLoadingSynchronizationMechanism”. However, once the map is loaded, we want to keep the loading screen active for a while because we must wait on various loading conditions in the world to be ready and we must have at least some “Ticks” called on it.
However, it seems that the threading concept for the movie player was only added to support a blocking function in the same frame (like loading a map) since in “FEngineLoop::Tick”, at the end of it, it will call “GetMoviePlayer()->WaitForMovieToFinish(true);” which will then destroy the “SyncMechanism” inside of it (in “DefaultGameMoviePlayer”) and force the update of the loading screen on the game thread instead (along with ticking the engine optionally). This means that if a streaming operation is blocking for many seconds on the game thread (because we want to preload spawned things behind the loading screen for example), the loading screen will appear to freeze/stutter during this time.
Is there a way to avoid this situation and make the loading screen work properly in a thread without having to fragment the loading done on the main thread each tick for instance (the goal of the loading screen is to eliminate this kind of issue)?
Thank you!
Hi,
You’re correct that the movie player is only really meant to support blocking loads, and it makes some assumptions about the blocked game thread to run Slate on a worker thread (which would otherwise be unsafe and can lead to weird race conditions). Modifying that movie player is fairly risky (usually the crashes turn up accessing some shared resource like the FontCache), so usually some sort of two-phased load is the best approach. Sometimes it makes sense to quickly load into some minimal level so that the blocking portion is very fast and can show a splash screen with a rotating throbber, and then the majority of the work is done asynchronously with a standard UMG-built loading screen covering up the scene until it’s ready. However, that won’t really help the issue of larger operations causing the load screen to hitch, but the game thread needs to access Slate at this point so there isn’t a great alternative.
You could try tweaking streaming settings to better amortize the load across frames, and grabbing traces to see where the big hitches occur, though the more common approach is to just accept a bit of hitching in the load screen since it shouldn’t affect gameplay at all.
Best,
Cody
Hi Cody,
Thank you for your answer and for the confirmation about the issue! Before I got your answer I experimented with keeping the initial thread alive until a certain part of our loading process and so far it seems to work well on our side after fixing some issues (like a deadlock between the movie player sync mechanism and the slate tick function which I fixed by locking the mutexes in the right order or preventing the slate tick to be done later in the main thread tick function to only keep the one from the thread).