FScopedSlowTask has been refactored to better allow for nesting of slow operations. This allows us to cascade nested scopes and provide accurate feedback on slow tasks. FScopedSlowTasks now work together when nested inside sub functions. Break up long functions that contain calls to multiple nested FScopedSlowTasks with FScopedSlowTask::EnterProgressFrame().
Example Usage:
void DoSlowWork()
{
FScopedSlowTask Progress(2.f, LOCTEXT("DoingSlowWork", "Doing Slow Work..."));
// Optionally make this show a dialog if not already shown
Progress.MakeDialog();
// Indicate that we are entering a frame representing 1 unit of work
Progress.EnterProgressFrame(1.f);
// DoFirstThing() can follow a similar pattern of creating a scope divided into frames. These contribute to their parent's progress frame proportionately.
DoFirstThing();
Progress.EnterProgressFrame(1.f);
DoSecondThing();
}
This addresses TTP#338602 - NEEDS REVIEW: Editor progress bars nearly always just show 100%, don't offer useful indication of progress
[CL 2322391 by Andrew Rodham in Main branch]
Cocoa isn't an event-polling API as UE4 expects, so previously we were subverting the NSApplication's event handling to pretend that it was. When the engine wasn't running the event loop fast enough, such as when loading where it isn't processed at all, this resulted in unresponsive windows and Spinning-Beachball-Of-Death. That isn't very satisfactory & to some users appears as if the application has crashed. To address these deficiencies without further attempts to subvert Cocoa, the game is now punted onto a separate thread where it can run its own tight-loop, leaving the main thread to handle the Cocoa event run-loop. Events are captured by delegate objects, as Cocoa requires, but dispatched and handled on the game thread which makes Cocoa appear more like other platform APIs to the higher-level UE4 code.
This can all be disabled using the MAC_SEPARATE_GAME_THREAD define in CocoaThread.cpp.
#codereview michael.trepka
[CL 2262543 by Mark Satterthwaite in Main branch]
